Ticket #178 (Invalid)Thu Sep 25 18:21:09 UTC 2008

I would also like to add that 1.73 through to 1.75 also cause an abort message when when using David Pillings SPrinter application. This results in a totally locked machine that requires a reset. 1.72 does print OK. Using Iyonix 5.13 and 512MB ram.

If it helps the data abort on transfer error is as follows:

&FC166500 pc=00038F4C registers 0003D250

Can you run the DebugTools module (from our web site) and the DebugButton module (also from here)? When the abort happens, click on the “Debug” button on the error box and type *Where at the command line. This should tell you something about where the error happened.

OK, downloaded both items and double clicked on them so they run and I can see them when typing *help modules.

Tried to print using SPrinter and 1.75 and the error box comes up but no debug button. If you carry on as normal then the machine locks.

Any help on running the tools would be appreciated.

With respect to the initial report: printing from NetSurf to PostScript printers using PDriverPS will not work. This is nothing new and is not something that Printers 1.7{3,4,5} attempt to address.

As for the SPrinter crashes, that’s odd, given I explicitly tested it with SPrinter. Can you check the version of PDriverDP you’re running?

I can confirm that I’m running the 4.55 (28 May 2008) version of PDriverDP.

SPrinter is v1.04.
Netsurf is 2.0 22 Sept r5401.

I’ve tried it from Draw 1.14 and also DPlngScan 1.24 as well.

Happy to help if someone could just let me know how i get the debug button to come up in the error box. For clarity I downloaded Debug Tool and debug button and double clicked on the to run before trying the test. No debug button came up , just the usual buttons and the abort error which then freezes the machine if you attempt to acknowledge the error.

If it’s not coming up already then you probably wont be able to make it.

Abort on data transfer has an error number of &80000002
DebugButtn puts up it’s debug button for any error > &80000000
The OS will display a Describe/Quit/Continue error box before the task’s own, if the error is > &80000000

My guess is that the error number is being munged by the printer manager to prevent the Describe/Quit/Continue error box from appearing. This also prevents DebugButtn from recognising that a serious error has occured. If you don’t see the Describe/Quit/Continue error box then this is clearly the case.

I’ve produced a dodgy modified version of DebugButtn, which will appear for any error: It’s available from http://www4.webng.com/resurgam/hide/DEBUGBT.ZIP

James

Information on two attempts using Draw 1.14, Printers 1.75 and Sprinter 1.04 attempting to print out Drawfile with WMF image.

Register dump (stored at &2001AC6C) is:

R0=209E4AC4 R1=000000F5 R2=00000005 R3=00000EF7
R4=20C9F6B8 R5=20C9F6B0 R6=0000006F R7=02D002D0
R8=30303030 R9=00000005 R10=00000008 R11=0000002B
R12=20A33234 R13=FA207F58 R14=20A2B4A4 R15=FFFFFB48

MODE SVC32 flags set: NzcVqifT
PSR=90000033

Address FFFFFB48 is not in module

Second try – as above apart from

R0=209E4984 R1=000000EF R4=20A929B8 R5=20A828B0
R12=20A32FB4 R14=20A3B224

I can’t seem to attach a file with the modules I have loaded to this report so if you need it then send me an email request.

Doug

PDumperSP 1.44 (14 Jun 2008)

There’s your problem. This PDumperSP is not the one for use with SPrinter. It outputs monochrome sprite data in a format that SPrinter is not expecting (and thus, SPrinter explodes)

The PDumperSP for use with SPrinter is 0.01 (23 Oct 2002). If you ensure that’s installed in !Printers.PDumpers, then everything will work correctly.

Question for ROOL people: is there an associated PDF for use with the monochrome PDumperSP? Using the one from SPrinter produces output, but it’s simply a Printout file containing scanline data, which isn’t exactly useful :)

John-Mark,

Thanks and that would explain why 1.72 worked and anything onwards didn’t as 173 introduced the ROOL PDumperSP module that overwrites the SPrinter one.

To ROOL, does this not mean we have a module name clash and who should sort this to avoid any confusion?

Doug

Hi guys,

Glad to hear you’ve made progress. Can you each drop me an email with the above questions to srevill@riscosopen.org so that I don’t forget about this stuff and can look into it when I get a chance?

Also, can you give me a bit of background about the SPrinter stuff – I’m afraid I don’t know much about it (e.g. what is it, why is version 0.01 of PDriverSP the ‘right’ version, etc).

If we do have a name clash, and it sounds like it, then it can only be resolved by checking the official allocations to see which module is correctly using the name and then the other one (the naughty one) will need to be changed somehow. May be difficult because the user(s) of that module will also need to be changed. Argh!

It’s from issue 1 of Foundation Risc User, two articles. The first explaining the structure of the printing system. The second an example of how to write a dumper module. (The first is available online at http://foundation.riscos.com/html/features/01/p…)

The most interesting bit (from the second article) is as follows:

“This is a single SWI call to declare the module’s intentions to RISC OS. We tell it our unique centrally allocated dumper number (DUMPER). For SPrinter I recalled that Acorn had an unreleased sprite dumper module, and pinched its number.”

Although technically David Pilling is in the wrong, it would be easier for the end users if you issued a new name/number for the ROOL sprite printer dumper.

Name and PDumper allocation clash fixed in cvs. Will be fixed in pre-build download soon.

With respect to the original report, printing from NetSurf with the Unicode font manager (as on RISC OS 5), causes Unicode characters to be printed. The PostScript printer drivers supplied with RISC OS can not handle this.

To get it working you need the PostScript3 printer drivers by John Tytgat and Martin Wurthner.

For more info see: http://www.netsurf-browser.org/documentation/ro…

I guess this bug can be closed now?

Closing as I can’t change the title and it’s not a fault per-se. Will open a new ticket for an enhancement to support unicode in PDriverPS.