Apache OpenOffice (AOO) Bugzilla – Issue 7262
PS Output is not DSC-compliant, and does not work 100% with CUPS
Last modified: 2011-07-03 06:42:21 UTC
I recently received a file from a CUPS user that did not work correctly when printing the file 2-up. After looking at the file, the problem is fairly apparent, and should be easy to fix on your end... Here are the "required" ones: 1. %%Page: comments contain the displayed page number (first argument) and the ordinal page number (second argument). The ordinal number starts at one and increased for the entire document. The displayed page number can be anything. Your output has a starting ordinal number of 0... 2. %%BeginSetup is only valid before the first page. You really want to use %%BeginPageSetup. Also, you probably want to trap your PS commands with: [{ %%BeginFeature: *... ... ... some code ... %%EndFeature } stopped cleartomark That will allow the document to print properly even if the printer does not support those commands. 3. All embedded fonts need to use the %%BeginResource and %%EndResource comments around them (you just have EndResource), otherwise the comments inside those resources are treated as part of the original document data (that is what causes the number-up functionality in CUPS to stop working...) If you require assistance to make these changes, I'll be happy to volunteer my time...
THANK YOU! THANK YOU! THANK YOU! I applied your changes to my ps files which I just CANNOT otherwise print on my HP 8000 DN printer, and everything just works now! I haven't hacked the source (yet), and maybe this has already been fixed, but the brace trap fixed all my printing troubles (so far). Unfortunately, I actually have to manually edit (a la emacs function) any ps file I create with OO, currently. I plan on downloading the latest devel tree and hack (if necessary) as a result of this. Again, thanks!
reassign
will change that
easysw: done. If you have any other suggestions how to improve our PostScript output they are always welcome. pl->mh: please update the followin g files in psprint int the next 644 build: psprint/inc/psprint/printerjob.hxx rev 1.2 psprint/source/fontsubset/sft.c rev 1.17 psprint/source/printergfx/glyphset.cxx rev 1.15 psprint/source/printergfx/printerjob.cxx rev 1.19 psprint/source/helper/ppdparser.cxx rev 1.4
*** Issue 9843 has been marked as a duplicate of this issue. ***
there will be in the next 644 automagically
*** Issue 7790 has been marked as a duplicate of this issue. ***
verified.
close issue.
Please reopen this issue; I have checked the output from OpenOffice 1.1 based upon a bug report from a CUPS user and there is a problem with the current Begin/EndPageSetup comments. Here is an excerpt from a simple 1-page test file: %%Page: 1 1 %%PageBoundingBox: 12 12 600 780 %%BeginPageSetup % [{ %%BeginFeature: *InputSlot Middle <</ManualFeed false /MediaPosition 0>> setpagedevice %%EndFeature } stopped cleartomark [{ %%BeginFeature: *PageSize Letter <</PageSize [612 792] /ImagingBBox null>> setpagedevice %%EndFeature } stopped cleartomark >>> gsave >>> [0.06 0 0 -0.06 12 780] concat >>> gsave %%EndPageSetup The lines marked with >>> must *not* be inside the Begin/EndPageSetup comments since they affect the graphics state. The end result is that N-up printing and page markings (such as classification, "draft", etc. that a user might want to add to the print job) are lost and the page is scaled improperly. Simply moving the marked lined after the %%EndPageSetup comment will fix things nicely. Thanks!
JA->PL: please have a look at this. Reassigned
As i understand it the Adobe DSC spec says exactly the opposite: <quote> %%BeginPageSetup (no keywords), %%EndPageSetup (no keywords) These comments are analogous to the %%BeginSetup: and %%EndSetup comments, except that %%BeginPageSetup: and %%EndPageSetup appear in the body of a document right after a %%Page: comment. They delimit areas that set manual feed, establish margins, set orientation, download fonts or other resources for the page, invoke particular paper colors, and so on. This is the proper place to set up the graphics state for the page. It should be assumed that an initgraphics and an erasepage (i.e. showpage) have been performed prior to this page. Take special care to ensure that the code in the page setup modifies the current graphics state rather than replaces it. See Appendix I of the PostScript Language Reference Manual, Second Edition for more information about how to properly modify the graphics state. </quote> Especially the line "Take special care to ensure that the code in the page setup modifies the current graphics state..." suggests to me that it is perfectly reasonable to change the graphics state inside the page setup (in fact that the gsave/concat/gsave basically sets up the page). Perhaps you can tell me if i'm wrong.
OK, I've done a full review of the DSC spec, and it appears that you are correct about the graphics state stuff... The kicker is that the page device commands are preventing the number-up stuff from working, among other things, so we need to somehow filter those out in CUPS I guess.
Ok, i'll close this issue again. But please tell me if there turns something up that OOo does wrong anyway; i could not yet lay hands on said PostScript Ref. manual appendix - the third edition does not seem to have the same appendix.
It is available as a separate technote (#5001) from the developer site. The current link appears to be: http://partners.adobe.com/asn/tech/ps/technotes.jsp
Thanks, but that's where i got the quote from ;-) What i meant was the Appendix 1 of the PostScript reference manual it points to (where should be described what is appropriate in the graphics context to be changed).
The second edition language reference manual is still available from the link I gave you, and Appendix I is part of the PDF file... That said, it doesn't provide any info on this particular situation, so I don't know what we will be doing in the short term... Moving the graphics state stuff out of the page setup section won't hurt, though, and might be the best way to avoid problems with apps that filter/modify the PS output from OO.
Originally cp put the gsave/concat there exactly because of other applications that would want to parse our PS output ... but as we have now seen PageSetup seems to be not so well defined after all. I can of course change the code as you want, i just wanted to make sure that's it's the right thing to do this time. But it seems feasible that the PageSetup should only contain PPD features. I've opened a issue 26147 for that as the original problem was and still is fixed.
asking for reopening still there are serios problems printing OO documents via cups, i.e. OO3.3 and cups 1.4 produce garbage on 2nd printout if you print twice the same writer document (unpredictably some documents, but in those reproducible) (Debian 6.0, Brother HL-6050D) please see bug #61458 (#576, 7262)