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)
Tracking
()
NEW
People
(Reporter: wolfiR, Unassigned)
Details
Attachments
(1 file, 1 obsolete file)
4.56 KB,
patch
|
kherron+mozilla
:
review-
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Attachment #218816 -
Flags: review? → review?(kherron+mozilla)
Reporter | ||
Comment 2•18 years ago
|
||
The first patch only fixes the paper size command. I'm working on another one fixing the num-copies stuff.
Reporter | ||
Updated•18 years ago
|
Assignee: mozilla → printing
Status: ASSIGNED → NEW
Reporter | ||
Comment 3•18 years ago
|
||
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)
Reporter | ||
Updated•18 years ago
|
Attachment #218850 -
Flags: review?(kherron+mozilla)
Reporter | ||
Updated•18 years ago
|
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 4•18 years ago
|
||
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-
Reporter | ||
Comment 5•18 years ago
|
||
(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.
Reporter | ||
Comment 6•18 years ago
|
||
(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?
Updated•15 years ago
|
Assignee: printing → nobody
QA Contact: printing
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•