Issue 65491 - Write setup to %%Begin(End)Setup, instead of %%Begin(End)PageSetup
Summary: Write setup to %%Begin(End)Setup, instead of %%Begin(End)PageSetup
Status: CLOSED FIXED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: 680m167
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: caolanm
QA Contact: issues@gsl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-17 13:29 UTC by kendy
Modified: 2011-07-03 06:50 UTC (History)
6 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
The patch. (3.38 KB, patch)
2006-05-17 13:39 UTC, kendy
no flags Details | Diff
Before the patch. (229.43 KB, text/plain)
2006-05-17 15:27 UTC, kendy
no flags Details
After the patch. (229.44 KB, text/plain)
2006-05-17 15:27 UTC, kendy
no flags Details
update patch to apply against DEV300_m61 (3.22 KB, patch)
2009-10-09 13:38 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description kendy 2006-05-17 13:29:34 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?
Comment 1 kendy 2006-05-17 13:39:47 UTC
Created attachment 36540 [details]
The patch.
Comment 2 philipp.lohmann 2006-05-17 14:28:23 UTC
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 ?
Comment 3 easysw 2006-05-17 14:39:19 UTC
> 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.
Comment 4 kendy 2006-05-17 15:03:46 UTC
> 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...
Comment 5 kendy 2006-05-17 15:06:32 UTC
pl: Did not notice that you are not in Cc: any more...
Comment 6 kendy 2006-05-17 15:25:25 UTC
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!
Comment 7 kendy 2006-05-17 15:27:19 UTC
Created attachment 36548 [details]
Before the patch.
Comment 8 kendy 2006-05-17 15:27:58 UTC
Created attachment 36549 [details]
After the patch.
Comment 9 easysw 2006-05-17 15:43:26 UTC
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.
Comment 10 philipp.lohmann 2006-05-17 16:16:44 UTC
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.
Comment 11 philipp.lohmann 2006-05-17 17:42:51 UTC
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.
Comment 12 easysw 2006-05-17 19:50:09 UTC
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.

Comment 13 easysw 2006-05-17 19:56:24 UTC
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...
Comment 14 philipp.lohmann 2006-05-18 08:49:57 UTC
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 ?
Comment 15 easysw 2006-05-19 20:51:22 UTC
[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.
Comment 16 philipp.lohmann 2006-05-22 09:35:47 UTC
easysw: will do, i created issue 65684 for that.
Comment 17 philipp.lohmann 2007-05-31 09:44:04 UTC
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.
Comment 18 philipp.lohmann 2007-06-28 12:15:53 UTC
seems no one is interested anymore, closing
Comment 19 philipp.lohmann 2007-06-28 12:16:15 UTC
closing
Comment 20 rag56 2007-08-14 22:12:19 UTC
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
Comment 21 caolanm 2009-10-09 13:38:01 UTC
reopening, have an interest here
Comment 22 caolanm 2009-10-09 13:38:41 UTC
Created attachment 65269 [details]
update patch to apply against DEV300_m61
Comment 23 caolanm 2009-10-09 13:40:28 UTC
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
Comment 24 philipp.lohmann 2009-10-09 15:00:43 UTC
Ok, will add that to CWS printerpullpages then
Comment 25 philipp.lohmann 2009-10-13 11:42:26 UTC
comitted in CWS printerpullpages
Comment 26 philipp.lohmann 2009-10-26 13:44:31 UTC
please verify in CWS printerpullpages
Comment 27 caolanm 2009-10-26 18:01:40 UTC
seems good
Comment 28 caolanm 2010-01-23 17:22:01 UTC
closed, in m70.
Comment 29 walther 2011-07-03 06:50:29 UTC
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