SDB:Printing Copies

openSUSE Support Database

Portal - SDB Categories - How to write an article

Tested on openSUSE

Recommended articles

Related articles

Situation

You like to get the same content printed multiple times.

This article is for CUPS up to version 2.x under Linux with the traditional filtering system and backends there.

The nowadays driverless printing workflow is rather different.

There is no such thing as "just printing copies"

There are several essentially different ways how one could get the same content printed multiple times (vaguely called "copies").

Different ways to get something printed multiple times

For example when printing 3 "copies" of the content in a file_to_print it can be done in three essentially different ways by the following commands:

One print job where number of copies is a print job parameter

lp -d queue_name -n 3 file_to_print

This produces one print job where the intended number of copies is a print job parameter.

When the number of copies is a print job parameter it depends on various conditions what exact behaviour that print job parameter results so an unexpected printout could happen (that might be even technically correct but not what is intended).

When the printer itself does not support to print the content on its own as many times as requested (and many printers do not support that or do not support it sufficiently, cf. "collated copies" below) then a print job processing program (a so called "printing filter") needs to produce the requested copies for the printer.

When the number of copies (n) is only a print job parameter one could get the same content printed only once or n times (as intended) or n^2 times or even n^3 and more times depending on how often that print job parameter is actually evaluated (not at all, one time, 2 times, 3 times, ...).

When one gets no copies the reason could be that the printer itself is expected to make the copies but actually it does not do it, cf. "cupsManualCopies" below.

When one gets n^2 copies the reason is likely that first a printing filter makes copies and then the printer itself also makes copies.

Inspect the PPD file of your print queue /etc/cups/ppd/queue_name.ppd if there are some kind of copies options therein and if yes it may help to play around with those options in the PPD file. For an example see CUPS PPD Extensions: cupsManualCopies that reads (excerpt):

cupsManualCopies

This boolean keyword notifies the RIP filters that the destination printer
does not support copy generation in hardware. The default value is false.

Example:

*% Tell the RIP filters to generate the copies for us
*cupsManualCopies: True

where "RIP filters" mean printing filters that do what a so called "raster image processor" does (cf. Wikipedia: Raster image processor). There is a typo in CUPS PPD Extensions: cupsManualCopies which reads "*cupsManualCopies: true" but actually it must be "*cupsManualCopies: True", see https://github.com/OpenPrinting/cups-filters/issues/242

One print job with the content as many times as number of copies

lp -d queue_name file_to_print file_to_print file_to_print

This produces one print job that contains the content as many times as the intended number of copies.

Submitting the content as many times as the intended number of copies avoids possibly unexpected printout results (cf. above).

Whether or not submitting the content as many times as the intended number of copies wastes noticeably more resources depends on the particular case. There is likely not much difference in used overall computing resources (i.e. computing resources on the computer where the print job is produced plus computing resources in the printer) when a printing filter produces copies for the printer compared to when the printer itself makes copies. In the latter case less data needs to be transported to the printer and it could be noticeably faster when the printer itself makes copies in particular in case of non-collated copies (cf. below).

As many separated print jobs as the number of copies

lp -d queue_name file_to_print
lp -d queue_name file_to_print
lp -d queue_name file_to_print

This produces as many separated print jobs as the intended number of copies.

When submitting the content as many times as the intended number of copies as separated print jobs it can happen that other user's print jobs get in between so that the jobs from the other users appear in between in the whole printouts.

Submitting the content as many times as the intended number of copies as separated print jobs needs most resources but that is often the only possible way to submit the content as many times as the intended number of copies when printing from an application program via a printing dialog.

Collated copies versus non-collated copies

Collated copies means that when printing more than one copy of a document it will print all pages of each copy before printing the next copy.

So the printed page numbers for printing 3 collated copies of a 5 pages document are

1 2 3 4 5 1 2 3 4 5 1 2 3 4 5

versus printing 3 non-collated copies of a 5 pages document that results the following printed page numbers

1 1 1 2 2 2 3 3 3 4 4 4 5 5 5

In particular cheap/weak printers that provide a built-in copies functionality may not support collated copies but only non-collated copies (e.g. because of too little built-in memory to keep the whole document to print it as a whole multiple times but sufficient built-in memory to print a single page multiple times).

See also "Printing Multiple Copies" at CUPS: Command-Line Printing and Options that reads (excerpt):

Copies are normally not collated for you.
Use the -o collate=true option to get collated copies:

lp -n num-copies -o collate=true filename

Duplex printing on top of printing copies

Printing non-collated copies with duplex printing enabled does not make sense because one would get the first page printed on front side and back side of the first sheet of paper so only duplex printing of collated copies is described here.

Duplex printing an odd number of pages could be odd

When printing 3 collated copies of a 5 pages document with duplex printing enabled one would expect to get this printed sheets of paper:

page 1 on front side of 1. sheet of paper -+
page 2 on back side of 1. sheet of paper   |
page 3 on front side of 2. sheet of paper  | first
page 4 on back side of 2. sheet of paper   | copy
page 5 on front side of 3. sheet of paper  |
nothing on back side of 3. sheet of paper -+
page 1 on front side of 4. sheet of paper -+
page 2 on back side of 4. sheet of paper   |
page 3 on front side of 5. sheet of paper  | second
page 4 on back side of 5. sheet of paper   | copy
page 5 on front side of 6. sheet of paper  |
nothing on back side of 6. sheet of paper -+
page 1 on front side of 7. sheet of paper -+
page 2 on back side of 7. sheet of paper   |
page 3 on front side of 8. sheet of paper  | third
page 4 on back side of 8. sheet of paper   | copy
page 5 on front side of 9. sheet of paper  |
nothing on back side of 9. sheet of paper -+

When the printer itself does not support to print collated copies on its own a printing filter needs to produce the requested copies for the printer and then the produced pages to print 3 collated copies of a 5 pages document are normally (cf. above):

1 2 3 4 5 1 2 3 4 5 1 2 3 4 5

Those pages could result an unintended printout in case of duplex printing when there is no "magic" that inserts (only in case of duplex printing) an additional empty page after each page 5 to get nothing printed on the back sides of those sheets of paper where page 5 is printed on the front side:

page 1 on front side of 1. sheet of paper -+
page 2 on back side of 1. sheet of paper   |
page 3 on front side of 2. sheet of paper  | first copy
page 4 on back side of 2. sheet of paper   |
page 5 on front side of 3. sheet of paper -|
page 1 on back side of 3. sheet of paper --|
page 2 on front side of 4. sheet of paper  |
page 3 on back side of 4. sheet of paper   | second copy
page 4 on front side of 5. sheet of paper  |
page 5 on back side of 5. sheet of paper --+
page 1 on front side of 6. sheet of paper -+
page 2 on back side of 6. sheet of paper   |
page 3 on front side of 7. sheet of paper  | third copy
page 4 on back side of 7. sheet of paper   |
page 5 on front side of 8. sheet of paper -+
(nothing for back side of 8. sheet of paper)

When there is no such "magic" only the third copy is printed as expected but the printout of the first copy is broken because page 1 of the second copy is printed on the back side of the 3. sheet of paper which is the resason why also the printout of the second copy is broken because the 3. sheet of paper belongs both to the first and second copy.

Submitting the content as many times as the intended number of copies as separated print jobs should avoid this issue (cf. above) because when duplex printing an odd number of pages as separated print job the printer would output the last sheet of paper regardless that nothing is printed on its back side.

In general when duplex printing an odd number of pages there could be a noticeable delay until the printer outputs the last sheet of paper (with only the front side printed) because the printer may wait for more printing data for the last sheet's back side until a timeout happens in the printer which lets it consider the print job as finished. With proper "print job finished" signaling to the printer no such delay happens but communication with printers does not always happen perfectly in practice. For usual non-duplex printing a printer's possible timeout at the end of each print job is often not noticed because the last sheet of paper (with something printed on it) is output normally so one gets the complete printout without a noticeable delay. For non-duplex printing the delay happens (if it happens at all in this case) after the last sheet of paper was output until the printer is back in the "ready for next print job" state.

Adding an empty last page to an "odd" document to make its number of pages even should avoid such issues when duplex printing. But in case of non-duplex printing such an empty last page may cause needless output of an additional sheet of paper (which is also odd).

When one cannot adapt an "odd" document specifically for duplex printing (e.g. because the document is a PDF that cannot be changed) an "odd" workaround is to print all but the last page (an even number of pages) in duplex mode as one print job and then only the last page in non-duplex mode as separated subsequent print job. When using that workaround to print e.g. 3 collated copies it is perhaps easier to first print all but the last page in duplex mode three times in a row, then the last page in non-duplex mode another three times in a row, and finally manually add each last page to the "all but last page" printouts.

The ultimate way out of odd workarounds when printing copies with and without duplex is likely to use a PostScript+PDF printer (cf. SDB:Printer buying guide) that properly supports to print copies (in particular collated copies) and duplex on its own together with a matching PPD file from the printer manufacturer so that all printer's built-in functionality is properly usable from application printing dialogs.