Setting number of copies causes too many copies to print

RESOLVED INVALID

Status

Core Graveyard
Printing: Xprint
RESOLVED INVALID
15 years ago
8 years ago

People

(Reporter: Jim Crumley, Assigned: Masaki Katakai)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
When using the xprint module with Sparc Solaris 7 xprint and Sparc Solaris
mozilla build 2002042422, too many copies print if I choose to print more than 1
copy in the print dialog.  If I choose 2 copies then copies print.  If I choose
3 copies then 9 copies print.  I didn't try any higher, but you get the idea ;).

First mentioned in bug 139566 which is a different number of copies bug with the
postscript module.
(Reporter)

Comment 1

15 years ago
Oops, I actually have this problem on my local build of mozilla from 20020424,
not  the Sparc nightly build which doesn't seem to have xprint built-in. 

Comment 2

15 years ago
The problem is burried within the Xprt code.

a. Xprt PS DDX code adds the PostScript "/NumCopies" to the PostScript job
b. Default spool command on Linux is "/usr/bin/lpr -P %printer-name%
-#%copy-count% -T %job-name% %options%"

... which means: The you get n^2 copies instead of the requested n copies.

Either [a] or [b] needs to be disabled (e.g. set to "1").
Currently I would vote to get [a] removed since [b] is the generic
solution for all DDX(=drivers).

But on the other hand there are cases like print-to-file or that %copy-count% is
not passed to the spooler command.
Status: NEW → ASSIGNED

Comment 3

15 years ago
Created attachment 80943 [details] [diff] [review]
Patch for X.org X11R6.6

Comment 4

15 years ago
The patch uses the following logic:
Add the /NumCopies PostScript instruction if the following conditions are true:
1. We are printing to a file.
  OR
2. We are printing to the spooler but do not pass the number of copies via
%copy-count% to the spooler.

Pro:
- The patch preserved the numcopies-feature across all combinations
Contra:
- More compliciated logic in Xprt

Any comments/suggestions/ideas ?

Comment 5

15 years ago
Some thoughts:
Xprint API allows one job, multiple documents per job and multiple pages per
document. Therefore I assume you can set the copy-count for each level
seperately:
1. Set number of copies for the whole print job
2. Set number of copies for the current document
3. Set number of copies for the current page

Currerntly our code does set the number of copies per document (e.g. [2]), but I
assume we want to set the number of copies for the whole job (Xprt needs to be
fixed since the code does use the document copy-count for both document and job
level) instead...

Comment 6

15 years ago
Reminder:
If we add "copy-count" to the list of supported job attributes
("job-attributes-supported") then we should do this _only_ of the spooler
command ("xp-spooler-command") gets the "%copy-count%" passed as argument.

Comment 7

15 years ago
I created a binary tarball distribution for Linux x86
(http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_006.tar.gz)
where I have turned-off one of the document-level copy-count (job-level
copy-count is still active) in Xprt - that should work around this issue on
Linux.

Final fix is under discussion...

Comment 8

15 years ago
Filed http://xprint.mozdev.org/bugs/show_bug.cgi?id=1378 to get a final fix for
Xprt...
Product: Core → Core Graveyard

Comment 9

8 years ago
XPrint support is gone.  See bug 326716.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.