To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=65491
User pl changed the following:
What |Old value |New value
================================================================================
Assigned to|pl |kendy
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Wed May 17 06:28:23 -0700
2006 -------
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 ?
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
