Since mozilla now generate postscript level 3 ps file. Cups add a filter for mozilla which is pswrite. After this filter, mozilla can not print multi-pages. It is actually ghostscript bug. But mozilla should give this a workaround.
By "multi-pages" I assume you mean printing more than one page to a sheet of paper, aka 2-up or 4-up? Can you provide any further information about this filter and this ghostscript bug?
(In reply to comment #1) > By "multi-pages" I assume you mean printing more than one page to a sheet of > paper, aka 2-up or 4-up? Can you provide any further information about this > filter and this ghostscript bug? Can not print more than one copies. Mozilla use NumCopies to print multi-copies. After the filter pswrite, there is a line "userdict /#copies 2 put". But infact printer only print one copy. I filed a bug in cups.org. I was told that it is not a ghostscript bug. This is a Foomatic bug.
Summary: Mozilla can not print muti-pages on some linux platforms. → Mozilla can not print muti-copies on some linux platforms.
Summary: Mozilla can not print muti-copies on some linux platforms. → Mozilla can not print multi-copies on some linux platforms.
The filter information is: In /etc/cups/mime.types there is a line. application/mozilla-ps ps (string(0,%!) + \ contains(30,200,"Creator: Mozilla PostScript")) In /etc/cups/mime.convs there is a line. .............. application/mozilla-ps application/postscript 33 pswrite ............. The bug I filed in cups is http://www.cups.org:80/str.php?L1066 I have tried to use /#copies to replace NumCopies. It works on linux. But it does not work on solaris.
The CUPS configuration files on my system (mandrake 10.0, cups 1.1.20) don't contain any mozilla-specific lines, and the words "mozilla" or "firefox" don't appear anywhere in the CUPS 1.1.23 source distribution. The lines in your CUPS config may have been added by whomever packaged your copy of CUPS. #copies is the PS level 1 method for setting number of copies; level 2 and up uses NumCopies, reading #copies only if NumCopies is set to null. You say your printing backend is rewriting NumCopies to #copies, and #copies works from some systems but not others. So this workaround would have to avoid using either method. When printing through CUPS, we could request the number of copies through CUPS instead of by embedding a directive into the postscript. But in other cases, the only practical method I know of is to duplicate the postscript body once for each copy. It would be simple to do, but I don't really want to add a feature like that.
Severity: normal → enhancement
Maybe we can add "copies" into print command. For example lpr -# number, lp -n number.
Adding a number-of-copies feature to the "print through an opaque command" print job class would probably mean adding a new environment variable to communicate the value. I'd prefer not to do that; the code to set and clear these variables is messy, the resulting print commands are messy, and the whole mechanism is a crutch that removes the incentive for truly better solutions. What I'd really like is to add direct support for printing through lpr. We could parse /etc/printcap for a list of lpr printers, then construct an appropriate lpr command and print through that. (We could support lp the same way, provided a suitable method for printer detection.) Then, when printing through CUPS or through this hypothetical lpr class, we'd be able to let the print job object handle the number of copies. In other cases we would continue to add appropriate code to the generated postscript.
Created attachment 182591 [details] [diff] [review] Handle copy count through the print job class This patch allows the print job class to handle multiple copies, instead of always adding the copy count to the the postscript output. During initialization, the device context offers the count to the print job object, which can either accept it or reject it. If rejected, the device context offers it to the PS object instead. Currently only the CUPS print job class implements copy counts. As I explained in a previous comment, my personal preference is not to implement this for the classic print-to-a-pipe class, but it could be done if someone really wanted it.
Comment on attachment 182591 [details] [diff] [review] Handle copy count through the print job class gfx/src/ps/nsIPrintJobPS.h + * @return NS_ERROR_NOT_IMPLEMENTED if this print job class doesn't one @retval for each return value would look nicer in the output, but the file doesn't seem to use that... - nsCStringArray* printer = new nsCStringArray; + nsCStringArray printer(3); nice :-)
Attachment #182591 - Flags: review?(cbiesinger) → review+
Comment on attachment 182591 [details] [diff] [review] Handle copy count through the print job class a=asa
Attachment #182591 - Flags: approval1.8b2? → approval1.8b2+
Checked in, resolving FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.