After generating a postscript-file with fop and sending the file/stream to the printer (Lexmark T632 and 630 - no other printers here for testing), the printer restarts ~30 seconds after printing the last page of the document (runs on again but nothing else happens). This failure appears not on all Windows-XP Versions. After hours of debugging i found the bug in the PSRenderer-Class and the builded PS-File: At the end an EOF-Command is send, but before there should be an end-of-page "eop"-command as well. Frankly - please add in stopRenderer() the line: gen.writeln("eop"); before the trailer and everything is fine ;)
Could you please attach the FO that you used which produced this problem. Can I also verify with you that this happened on a 0.93 version of FOP.
Created attachment 20369 [details] FO File example example fo file
Created attachment 20370 [details] Extract of the generated Postscript-File The header and footer part of the fop-generated .ps file
Every fo file i used produced this problem, because the bug is in the PSRenderer-Class. I also attached an extract of the generated .ps file showing the header and footer information produced by the renderer. As you can see, the version of fop is 0.9.3 ... the version of xmlgraphics-commons is 1.1. Beside that - the bug only appears on "some" xp-versions i tested. The customer uses a specialised customer version of win-xp - the bug does not appear on my personal version of xp. Nevertheless as i understand the postscript specification an eop must exist after a page ends. So it would be great to include this command in the stopRenderer-Method of the renderer.
Created attachment 20371 [details] patch file to fix page width reset behaviour I couldn't reproduce this printer reseting behaviour with my HP Laserjet printer. I don't believe the fix is to issue an "eop" instruction after the page trailer. However, when I tried producing a postscript rendition of the FO file you provided it seemed to produce incorrectly formatted output with the page width not being adhered to. I believe this problem (well the problem I found at least..) was caused by the /ImagingBBox null instruction following the /PageSize instruction when rendering the page. This may somehow be causing the problem you are experiencing on your printer. Anyhow, please try out your Lexmark printer again with fop patched with this patch file and let me know if this seems to fix the restart problem. Adrian.
I'm looking around whether i could get the time to test that patch... because afterall i fixed the misbehaviour of the printer by adding an EOP after the page-content - you can believe it or not ;)
I believe the EOP may fix the problem on your printer for you, and it also fixed the page width problem in my testing. From what I can gather EOP is a very old postscript (postscript level 1) instruction which I believe was used with dot matrix style line printers, it appears to be little used these days and largely undocumented. I don't believe it should be necessary. Please try out my patch, it will only take you a couple of seconds ;-). Adrian. (In reply to comment #6) > I'm looking around whether i could get the time to test that patch... because > afterall i fixed the misbehaviour of the printer by adding an EOP after the > page-content - you can believe it or not ;)
> From what I can gather EOP is a very old postscript (postscript level 1) > instruction which I believe was used with dot matrix style line printers, it > appears to be little used these days and largely undocumented. I don't believe > it should be necessary. Please try out my patch, it will only take you a couple > of seconds ;-). Okay - i'll do my very best... have to switch the pc and make some physical work to do that *g*
What concerns me about the use of EOP is that other PS generators do not add EOP at the end of their Postscript stream yet we print thousands of documents on hundreds of different printers and do not run into a problem. Therefore I would be reluctant to add EOP to the end of the stream because whilst it may work for your printer it may break other printers. And as Adrian already said its a legacy command with no mention in PS Red Book. Setting /ImagingBBox to null seems unnecessary because changing the page size should do this anyway (according to the PS spec). Removing this superflous statement seems to fix the odd behaviour in the FO you provided. Well for the printers I had within easy reach at least :)
resetting P2 open bugs to P3 pending further review
change status from ASSIGNED to NEW for consistency