Apache OpenOffice (AOO) Bugzilla – Issue 65491
Write setup to %%Begin(End)Setup, instead of %%Begin(End)PageSetup
Last modified: 2011-07-03 06:50:29 UTC
The PostScript created by OOo does not play well with CUPS n-up feature; the problem seems to be a bit similar to issue 7262, but not entirely. - generate a simple document with 2 pages - print it to a PS file - run "lp -d <name_of_the_queue> -o number-up=2 <name_of_the_file>" Just the second page is visible on the print-out. If you remove all the %%Begin(End)Feature DSC tags (including their contents), or move to %%Begin(End)Setup (from first page's %%Begin(End)PageSetup), the file prints fine. Our printing expert argues that %%Begin(End)Features should not be present in PS intended for CUPS at all, I think that CUPS should handle them OK according to the DSC paper ;-) - but it's not completely clear. Anyway, I'll attach a patch that seems to improve the situation a lot - it moves the %%Begin(End)Features (for InputSlot, PageSize, etc.) to %%Begin(End)Setup - which is better than what is there now; eg. in situation when the printing manager decides to send pages to more printers the %%Begin(End)Setup should be copied to all of them according to the DSC. Please see also https://bugzilla.novell.com/show_bug.cgi?id=80448 What do you think, please?
Created attachment 36540 [details] The patch.
The problem with CUPS is that it does not behave as a print manager should (by Adobe's definition). CUPS only puts a prolog before a file, CUPS has no idea at all about pages and therefore no handling for PageSetup. Alas this is not the reality of existing documents; documents have different page sizes in one job (think e.g. envelope, then document or first page from tray 1, further pages from tray 2). CUPS does not reflect printer settings changing during the job and this is major downside. Of course CUPS does not have an API for setting page features. And consequently it does not parse page setups and replace feature code according to what should be in there as of the PPD file of the printer. In short, CUPS is crap for documents that have not the same settings for the whole job. But if we use that patch, then we disable these features for all, not only the CUPS users. Moreover we remove every possibility for a workaround for the user who as of now can set SAL_DISABLE_CUPS and see how he gets his file to the printer from a command line. Also for at least some PostScript printers the PageSetup features work despite CUPS since CUPS does at least not meddle with the PostScript besides prepending a Prolog. As for n-up printing i suggest the builtin functionality of writer in the page preview. By the way this is not really a CUPS issue (CUPS does not handle that) but an a2ps issue (CUPS uses a2ps to produce n-up last time i looked). a2ps is handicapped the same way with regard to printjobs of multiple page sizes, also it should of course remove all PageSetups since it reorders the pages anyway and so invalidates the PageSetup sections. The solution to this problem is not so easy; what i certainly can agree with is that in most cases a CUPS user does not benefit from the printer specific PostScript produced by OOo. What I'd rather like would be a user configurable setting to produce PostScript either printer specific or printer independent and that in the CUPS case printer independent PostScript should probably be the default case. But i don't think we should simply throw out the whole funtionality just because CUPS is too simpleminded about printing. Side note: what i'd like even more would be a printing subsystem that actually is suited to printing, not just spooling. Well, one can dream :-) Just a sketch of a solution how i envision it: the user can select in the printer settings (either within spadmin or in the jobsetup that one can bring up in the printer dialog) whether to produce printer indepent PostScript or not. The default would be printer independent in the CUPS case. If the user decided to produce printer independent PostScript then we simply skip the emission of printer specific code, that is everything surrounded by %%BeginFeature and %%EndFeature. How does that sound to you ?
> The problem with CUPS is that it does not behave as a print manager should > (by Adobe's definition). CUPS only puts a prolog before a file, CUPS has no > idea at all about pages and therefore no handling for PageSetup. > ... omitted the rest of the incorrect information ... (choking and sputtering!) Um, no. CUPS behaves exactly as a print manager is supposed to according to Adobe's DSC. The only things it doesn't implement are some of the resource inclusion bits which have security and/or usability issues. CUPS also includes EXTENSIVE APIs for embedding PPD-specific printer commands (including the corresponding DSC comments required for conformance), and has done so since CUPS 1.0. You just need to use the APIs... a2ps is a text converter, and CUPS DOES NOT use a2ps for anything. For text printing we have our own texttops filter, and all PostScript documents go through the pstops filter which handles imposition, feature code insertion, and so forth. As for properly supporting printer features, you can continue to insert printer-specific commands (be sure to use the proper Begin/EndFeature comments!), ideally using the CUPS APIs for this or your own PPD parser. Alternately you can just use the IncludeFeature comment to get CUPS to embed the commands for you, or use the cupsJobTicket comment in the document header to embed arbitrary CUPS options in the PostScript file. Regardless, the current CUPS release already seems to work fine with OOo output, so I don't think you need to do anything. N-up and "fitplot" (scale to fit) output automatically strips any Begin/EndFeature code.
> But if we use that patch, then we disable these features for all, not only the > CUPS users. If I did not make a mistake in my assumptions & implementation, the patch should not disable the features. Without the patch, they are dumped in %%Begin(End)PageSetup of the first page. I just moved it a bit higher, to %%Begin(End)Setup (for the first page, it should stay set from %%Begin(End)Setup, the other pages can set that as they wish; but mayby I am wrong...) No change for printers that do not understand DSC, hopefully OK for the others as well, and CUPS seems to handle it better. > Side note: what i'd like even more would be a printing subsystem that actually > is suited to printing, not just spooling. Well, one can dream :-) Agreed :-) > Just a sketch of a solution how i envision it: the user can select in the > printer settings (either within spadmin or in the jobsetup that one can bring > up in the printer dialog) whether to produce printer indepent PostScript or > not. The default would be printer independent in the CUPS case. If the user > decided to produce printer independent PostScript then we simply skip the > emission of printer specific code, that is everything surrounded by > %%BeginFeature and %%EndFeature. How does that sound to you ? That's exactly what Johannes originally wanted in https://bugzilla.novell.com/show_bug.cgi?id=80448 I think, so OK for me; he understands the printing much more than me :-) I thought that we could go with something simpler (my patch), but no problem with another solution either...
pl: Did not notice that you are not in Cc: any more...
easysw: Oh, I see... Which CUPS version that fixes the n-up printing, please? I reproduce the behavior with our cups-client-1.1.23-27 package; so 1.2.0? Also, I'll attach print-out before the patch & after the patch to avoid confusion. Could you please check both and tell which is the 'more correct' from the CUPS/DSC point of view? Thank you in advance!
Created attachment 36548 [details] Before the patch.
Created attachment 36549 [details] After the patch.
The N-up change happened for CUPS 1.2. "before-patch.ps" is incorrect since it does not embed the printer commands for every page - that breaks page independence which is required by %%PageOrder: Ascend... "after-patch.ps" is correct for this document, however you'll need to revert to per-page commands if the document contains multiple media settings.
kendy: reading the patch again i see you are right, this would move the first pagesetup to the documentsetup and not change subsequent pagesetups, so is far less dramatic than i thought. I should have looked more closely before concluding this would not write PageSetups anymore, sorry. easysw: psprint originally exported the page features in every PageSetup, however this soon lets you discover problems with real printers. Prominent example: switch on duplex mode, and emit page size A4 for every page. This effectively disables duplex again on some printers because setting the media size will let the printer begin on a new sheet as opposed to a new page (which would be the backside of the last sheet). In theory we of course should have them independent, in reality sadly printers depend on the state that was on the last page. If you know a way around that i'd gladly change this.
easysw: regarding your earlier comment, I'd like to see the API that can let me insert features to my PostScript code. The way i see it the API is cupsPrintFile which of course take an options array, but for that i already have to have created a PostScript file which will be prepended by the prolog representing the options passed to cupsPrintFile. OOo already creates those options by using CUPS API (how else), but there is no way in the API to change them during a job, e.g. on a per page basis. And my remark regarding Adobe print managers was probably what you meant would not be done for security reasons: a print manager would exchange the feature sections to something suitable for the specific printer - which would be the only way to actually handle a non-PostScript printer which in CUPS is also handled via PPDs and PostScript. But please, if i'm wrong (which is certainly possible), please explain to me how i should improve our code.
The PPD API is documented here: http://www.cups.org/documentation.php/api-ppd.html The ppdEmit*() functions handle embedding printer-specific commands in your PS file - use ppdMarkDefaults and ppdMarkOption (and/or cupsMarkOptions) to select the options to emit. As for replacing feature code, we *don't* do this because the spec doesn't provide sufficient information to reliably implement it for all types of options. Specifically, custom page sizes (and now custom options) cannot be substituted (all you get is %%BeginFeature: *CustomPageSize True) and it only works for PostScript options. That is one of the reasons we added support for "%cupsJobTicket: option=value" lines in the document header in CUPS 1.1.x, and we now also support %%IncludeFeature: in CUPS 1.2.x. Like I said, what you are doing now is OK - the only changes you need to make are to put the document-wide options in the setup section and/or put the page-specific options at the beginning of each page in the page setup section. Otherwise, your pages are not independent, which prevents us from doing ordering and page ranges properly. As I mentioned before, CUPS 1.2 and beyond strips the feature code when a user prints N-up or scaled-to-fit.
Re: doing the page commands on each page, the simple solution is to just use the %%IncludeFeature comment instead of embedding the commands - CUPS will figure out what is necessary. That said, many high-end printers don't allow the duplex mode, input slot, etc. to change during a job (!), so pay close attention to the OrderDependency for each option - you can only do per-page for PageSetup and AnySetup options... Again, the CUPS IncludeFeature support is smart enough to deal with this...
We have the PageSetup and AnySetup according to order dependency already. What i didn't know was about %%IncludeFeature functionality in CUPS; i guess i didn't consider ppdEmit much since we don't have a FILE* at that point. Would we improve CUPS support by using %%IncludeFeature instead ? Is this backwards compatible to - say - CUPS 1.1.13 ? Or would you rather suggest that we use ppdEmit in the case CUPS is available ?
[Sorry for the delay] %%IncludeFeature support is new in CUPS 1.2. Our preference would be to use %%IncludeFeature if you are building against CUPS 1.2, and fallback to ppdEmit (any of the varients) for older CUPS releases.
easysw: will do, i created issue 65684 for that.
I think we should resolve this issue finally. Is the patch still wanted ? If so I'll take it and commit it after some testing.
seems no one is interested anymore, closing
closing
It is not clear that CUPS can properly handle the use of %%IncludeFeature, at least as of 1.2.4. See issue 806680: http://www.openoffice.org/issues/show_bug.cgi?id=80680
reopening, have an interest here
Created attachment 65269 [details] update patch to apply against DEV300_m61
Can we consider this again. It should make things easier to support n-up printing using the gtk print dialog and a gtkprint job that routes to cups to do the n-up when the printerpull stuff ends up in say 3.3
Ok, will add that to CWS printerpullpages then
comitted in CWS printerpullpages
please verify in CWS printerpullpages
seems good
closed, in m70.
asking for reopening. I have constant troubles printing with OOwriter twice in succession, some documents show garbage (mixed up fonts?) in the 2nd and all following printouts. I did a lot to analyze the problem, even an new printer of the same type didnt help. I guess, this still existing problem is related to what is discussed in this bug report. I downloaded the newest version (from 10/2008) of oopstops from www.cups.org, with or without this filter no success. I do not understand enough of postscript to analyze the print-file. Debian 6.0, cups 1.4, OO ...3.3. see also bugs 7262, 576 and especially 61458. Thanks, Walther