Open Bug 334485 Opened 18 years ago Updated 2 years ago

if CUPS is used we don't want setpagedevice commands in postscript

Categories

(Core :: Printing: Output, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: wolfiR, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

setpagedevice is printer specific and creating printer specific postscript is suboptimal if advanced printing systems like Cups are in use.

Please see:
https://bugzilla.mozilla.org/show_bug.cgi?id=324635#c6
Assignee: printing → mozilla
Status: NEW → ASSIGNED
Attachment #218816 - Flags: review?
Attachment #218816 - Flags: review? → review?(kherron+mozilla)
The first patch only fixes the paper size command.

I'm working on another one fixing the num-copies stuff.
Assignee: mozilla → printing
Status: ASSIGNED → NEW
num_copies is already handled by the CUPS code and therefore it should just be removed from the postscript output.
Attachment #218816 - Attachment is obsolete: true
Attachment #218816 - Flags: review?(kherron+mozilla)
Attachment #218850 - Flags: review?(kherron+mozilla)
Summary: if CUPS is used we don't want setpagedevice commands in postscript for paper selection → if CUPS is used we don't want setpagedevice commands in postscript
Comment on attachment 218850 [details] [diff] [review]
avoid setpagedevice commands

(In reply to comment #0)
> setpagedevice is printer specific...

Mozilla's use of setpagedevice to set paper size and number of copies is straight out of the PLRM. <http://www.cups.org/str.php?L1542> just says that it "might cause problems for some printers". And bug 324635 is just about the policies setting, not about using setpagedevice in the first place.

>@@ -1858,13 +1869,13 @@ nsPostScriptObj::write_script(FILE *aDes
>  */
> void 
> nsPostScriptObj::begin_page()
> {
>   fprintf(mScriptFP, "%%%%Page: %d %d\n", mPageNumber, mPageNumber);
>   fprintf(mScriptFP, "%%%%BeginPageSetup\n");
>-  if(mPrintSetup->num_copies > 1) {
>+  if(mPrintSetup->num_copies > 1 && !mPrintSetup->isCUPS) {
>     fprintf(mScriptFP, 
>       "/setpagedevice where\n"

This change isn't necessary. Take a look at <http://lxr.mozilla.org/seamonkey/source/gfx/src/ps/nsDeviceContextPS.cpp#167>. The device context asks the print job object to handle the copy count first; if the print job object can't do it, then the PS object handles it. For a CUPS printer, the PS object's copy count will always be 1.


>Index: gfx/src/ps/nsPostScriptObj.h
>===================================================================
>RCS file: /cvsroot/mozilla/gfx/src/ps/nsPostScriptObj.h,v
>retrieving revision 1.47
>diff -u -p -6 -r1.47 nsPostScriptObj.h
>--- gfx/src/ps/nsPostScriptObj.h	8 May 2005 15:01:20 -0000	1.47
>+++ gfx/src/ps/nsPostScriptObj.h	18 Apr 2006 11:07:52 -0000
>@@ -121,12 +121,13 @@ struct PrintSetup_ {
>   
>   const char* header;
>   const char* footer;
>   const char* paper_name;
> 
>   int *sizes;
>+  XP_Bool isCUPS;

I'd rather not add knowledge about specific printjob capabilities to the PS generator. If we were going to implement something like this, a better approach would be something like the way we handle the copy count. Add functions to the print job and PS APIs and let the device context negotiate between them. We would also need some way to set the paper size through CUPS; it doesn't do that right now.

But in fact, CUPS STR #1542 is just suggesting we should put DSC comments around the papersize-setting code, not that we need to remove it entirely. Doing that would be fine.

In reading through the DSC spec, I see they also recommend setting the copy count once during document setup instead of doing it for each page. We should probably comply with that as well, though it wouldn't affect printing through CUPS.
Attachment #218850 - Flags: review?(kherron+mozilla) → review-
(In reply to comment #4)
> (From update of attachment 218850 [details] [diff] [review] [edit])
> (In reply to comment #0)
> > setpagedevice is printer specific...
> 
> Mozilla's use of setpagedevice to set paper size and number of copies is
> straight out of the PLRM. <http://www.cups.org/str.php?L1542> just says that it
> "might cause problems for some printers". And bug 324635 is just about the
> policies setting, not about using setpagedevice in the first place.

That's true. But what happens if CUPS sets another paper size as the setpagedevice command?
Is it sure that the current implementation works in every case?
 
> This change isn't necessary. Take a look at
> <http://lxr.mozilla.org/seamonkey/source/gfx/src/ps/nsDeviceContextPS.cpp#167>.
> The device context asks the print job object to handle the copy count first; if
> the print job object can't do it, then the PS object handles it. For a CUPS
> printer, the PS object's copy count will always be 1.

hmm, sorry. I didn't notice this because I've tested it with "print to file" which creates the Postscript command.

> I'd rather not add knowledge about specific printjob capabilities to the PS
> generator. If we were going to implement something like this, a better approach
> would be something like the way we handle the copy count. Add functions to the
> print job and PS APIs and let the device context negotiate between them. We
> would also need some way to set the paper size through CUPS; it doesn't do that
> right now.

That's the next on my list.
There is already a patch somewhere which implements it for the backend.

> But in fact, CUPS STR #1542 is just suggesting we should put DSC comments
> around the papersize-setting code, not that we need to remove it entirely.
> Doing that would be fine.

That's the minimum, agreed.

Thanks for your comments.
(In reply to comment #4)
> This change isn't necessary. Take a look at
> <http://lxr.mozilla.org/seamonkey/source/gfx/src/ps/nsDeviceContextPS.cpp#167>.
> The device context asks the print job object to handle the copy count first; if
> the print job object can't do it, then the PS object handles it. For a CUPS
> printer, the PS object's copy count will always be 1.

Ken, after some more thought I have another suggestion:
I think it's suboptimal to hardcode the num-copies into postscript if
"Print to File" is chosen. How about disabling the option for "Print to File" jobs? This is little offtopic. Is there any location outside of bugzilla to discuss this postscript/cups/... stuff?
Regarding comment #4 "Mozilla's use of setpagedevice to set paper size
and number of copies is straight out of the PLRM":

The Adobe PostScript Language Reference has only PostScript output
devices in mind (e.g. a PostScript printer).
Therefore setpagedevice stuff may not work on a non-PostScript
output device.
For example Ghostscript cannot (or does not) translate any
setpagedevice stuff for any non-PostScript output device.
Sometimes it may work (depending on the Ghostscript driver)
sometimes it may not work.

In contrast when CUPS is used, the application doesn't need to care about
how to actually set whatever kind of output device specific stuff.
This is done by the CUPS pstops filter and for non-PostScript printers
by additional stuff like GhostScript and foomatic-rip.

When CUPS is used, the application only needs to produce PostScript "images"
(i.e. plain PostScript page description without output device specific stuff,
I do not mean bitmap images, I mean any kind of PostScript page description)
in a reasonable image size (i.e. the bounding box of the image shoud not
exceed the imageable area of the media).

When CUPS is used, the application can additionally ask the CUPS system
for various output device specific values (like imageable area, whether
it is a monochrome or color device, ...) so that it can produce an
optimal matching PostScript page description.

When CUPS is used, the application can additionally implement a user
interface to let the user choose output device specific stuff and
produce an optimal matching PostScript page description for what
the user has actually choosen but even then the application
does not include any output device specific stuff in its PostScript
output but it would set all output device specific stuff as print
job parameters to let the CUPS system do the output device specific
stuff based upon those job parameters. This makes sure that the
output device specific stuff works for any kind of output device
and not only for PostScript output devices.

In particular see the Adobe PostScript Language Reference
"Using Page Devices" section regarding the "two seperate
tasks when printing from an application":
----------------------------------------------------------------------
1.
Generate a device-independent page description.
2.
Request that the page description be rendered on a particular device.
At this point, the user should have an opportunity to add processing
options, including device-dependent ones, to the page description.
----------------------------------------------------------------------

With old-style printing systems, an application had to do both steps.
Since CUPS it is different:
CUPS does step 2 and it does it even for non-PostsScript devices.
Therefore with CUPS an application has to do only step 1.

Regarding "print to file", also see the Adobe PostScript Language
Reference "Using Page Devices" section:
-----------------------------------------------------------------------
Even if a single application performs both of these functions,
it is best to maintainthe distinction. Many applications have an
option to store the generated page description in a file for later use.
Such a file should not contain unnecessary device-dependent processing
options. The distinction between document generation and document
rendering is essential when using PostScript programs for document
storage and interchange.
-----------------------------------------------------------------------

By the way:
I wonder why there seems to be any confusion at all about the plain
device-independent page description and the device-dependent stuff
when it is so clearly described in the well known Adobe PostScript
Language Reference?
Assignee: printing → nobody
QA Contact: printing
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: