279711 - Mozilla can not print multi-copies on some linux platforms.

Status: RESOLVED FIXED

(Core :: Printing: Output, enhancement)

Description

[Leon Sha]

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.

Comment 1

[Kenneth Herron]

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?

Comment 2

[Leon Sha]

(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.

Comment 3

[Leon Sha]

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.

Comment 4

[Kenneth Herron]

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.

Comment 5

[Leon Sha]

Maybe we can add "copies" into print command. For example lpr -# number, lp -n
number.

Comment 6

[Kenneth Herron]

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.

Comment 7

[Kenneth Herron]

Attachment: 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 8

[Christian :Biesinger (don't email me, ping me on IRC)]

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 :-)

Comment 9

[Asa Dotzler [:asa]]

Comment on attachment 182591 [details] [diff] [review]
Handle copy count through the print job class

a=asa

Comment 10

[Kenneth Herron]

Checked in, resolving FIXED.