Printing multiple copies prints only 1 (pstopdf vs gstopdf)

[HonzaK94]

Hello.

PROBLEM DESCRIPTION: Printer only prints one copy even though we want to print multiple copies of a document.

Our company uses postscript to print documents from our POS system based on Java and everything was working fine until we reached OpenSUSE 15.x distribution (15.0, 15.1, 15.2).

With the help of a friend from OpenSUSE forums (thanks deano_ferrari) I have managed to pinpoint the culprit.

I have attached a print file generated from our POS system.

The last working distribution was LEAP 42.3 along with the package cups-filters version 1.8.2-3.1
On our new system running LEAP 15.2 along with cups-filters version 1.25.0-lp152.1.8 it is NOT working.

So I tried to downgrade the cups-filters package from 1.25.0-lp152.1.8 to 1.8.2-3.1 and the problem was FIXED. The printer corrently printed multiple copies of a document. Going back to the new version of cups-filters, the printer only prints one copy. It affects multiple printers of various manufacturers.

I have also managed to identify all the filters used in the operation.

GSTORASTER
PDFTOPDF
GSTOPDF
RASTERTOSPL - this is a Samsung driver used everywhere so this is not the problem

So based on my research I would guess that thr problem lies within the first three filters.

postscript print file.zip

If you need me to attach additional logs I am more than happy to provide.

Thank you for your time and for looking into this.

Honza

[HonzaK94]

cups-filters 1.8.2-3.1 use FOR THE SAME PRINT JOB:

GSTORASTER
PDFTOPDF - THIS ONE IS FINE
PSTOPDF

cups-filters 1.25.0-lp152.1.8 use:

GSTORASTER
PDFTOPDF - THIS ONE IS FINE
GSTOPDF

I tried swapping PDFTOPDF filter from older version and use it under new version of cups-filters and the print job works but only prints one copy.

[HonzaK94]

So the problem most likely lies within the GSTOPDF filter. I have tried using the PSTOPDF filter from 1.8.2-3.1 along with GSTORASTER + PDFTOPDF from 1.25.0-lp152.1.8 and it works just fine, as long as I rename PSTOPDF --> GSTOPDF.

[HonzaK94]

CORRECT AMOUNT OF COPIES.zip
ONLY 1 COPY LOG.zip

I have attached logs with detailed logging of the same print job.

[HonzaK94]

Further examining the 2 logs, I have found out that this parameter "-dDoNumCopies" is not called when using the original, new gstopdf. It is however called when using the pstopdf disguised as gstopdf.

[tillkamppeter]

Fixed in commit 6157b8f. Thank you very much for the bug report. Please test.

[johnh44]

Yes this issue was fixed in CUPS ver. 2.3.3op1. However, many OS packages still
come with older versions of CUPS. Among them are recent Apple and Linux
operating systems, including the popular Linux Mint 20.1, which come with CUPS
2.3.1. Until OS versions include newer versions of CUPS (the latest is 2.4.1),
the problem will persist.

As many have recommended, editing the .ppd file for your printer to change
"true" to "True" (oh, the absurdity of source code that would require such a
change!) does fix the issue -- for a time. But the inability to print more
than one copy MAY come back if you ever change the printer's properties.
And it WILL come back if you add a new printer.

Here are the steps to fix the problem for your current printer(s). It must be
done as the system root user:

sudo su
systemctl stop cups
cd /etc/cups/ppd

While the CUPS service is not running, edit ALL .ppd file in this directory.
Search for the line "cupsManualCopies: true" and change true to True. Then:

systemctl start cups
exit

[Photon89]

I am affected by this bug (or a bug with similar symptoms). The client is a Manjaro Linux machine, I don't know much about the server. Is the bug on the server or on the client side?

[sksundaramoorthy]

I have installed CUPS 2.2.6 in unix machine. I added printer using socket as recommended approach, like socket://11.22.33.44:9100.
Two cases

• Document printing is success if I print a document one by one.
• I send multiple document to the printer, It does not print and waiting in job queue.
  for example, I send 100 document to the printer.It didn't print and job status shows " processing since the 21 sep 2023 am PDT 'waiting for the printer to finish' "

In this case, I manually cancelled the job.
How to handle this case. Please advise.

[alexeymuranov]

Tried to print two copies of a document on TOSHIBA e-STUDIO3015AC from a fresh Linux Mint 22 (based on Ubuntu 24.04). Two copies were printed indeed, but they were stapled together, as if they were one.

[szlt5]

Tried to print two copies of a document on TOSHIBA e-STUDIO3015AC from a fresh Linux Mint 22 (based on Ubuntu 24.04). Two copies were printed indeed, but they were stapled together, as if they were one.

Maybe the same issue as OpenPrinting/libppd#42

[alexeymuranov]

Tried to print two copies of a document on TOSHIBA e-STUDIO3015AC from a fresh Linux Mint 22 (based on Ubuntu 24.04). Two copies were printed indeed, but they were stapled together, as if they were one.

I have to add that the issues with CUPS are weird and hard to debug. I'll try to explain.

I managed to get multiple copies printed and stapled correctly. For this I executed

# systemctl stop cups
# systemctl start cups

Then the issue was gone. However, after a reboot the issue was back.
Interestingly, using

# systemctl restart cups

instead of stop/start does not work.

Here are more detailed observations.

1. After a reboot, /etc/cups/ppd is initially empty. Once local network is connected, this directory is populated with PPD files for network printers.

2. If I try to print multiple stapled copies at that moment, they are all stapled together. I notice that on the "Color" tab in the GUI print dialog I have 3 options for "Print Color Mode": "Color", "Auto Monochrome", and "Monochrome".

3. After executing sudo systemctl stop cups, the files in /etc/cups/ppd disappear, and after executing sudo systemctl start cups the folder remains empty. However, once a network printer is selected in a GUI print dialog, the corresponding PPD file appears in /etc/cups/ppd.

4. Now, the "Color" tab for the same printer looks different, there is "Color Mode" selection with two options: "Color" and "Grayscale". Printing stapled multiple copies now seems to work fine.

5. After a reboot everything repeats.

I remember that couple of years ago (on Linux Mint 21) I managed to find a workaround for the issue with printing multiple copies on these same network printers somehow as follows, IIRC: I tweaked somehow the PPD files in /etc/cups/ppd, which did not solve the issue but somehow made the files "stick" and not disappear once the printer is disconnected. As a result, the same network printer would appear twice in the printing dialog: once with the tweaked persistent PPD, and once with automatically generated PPD. The one with automatically generated PPD was printing multiple copies correctly. (However, if the persistent PPD was removed, there was still an automatically generated one, but it did not work correctly.)

[szlt5]

I'll try to explain my understanding @alexeymuranov.

1. After a reboot, /etc/cups/ppd is initially empty. Once local network is connected, this directory is populated with PPD files for network printers.

After this step, the cups-browse will create a driver named "driverless". And the "driverless" will cause the bug: "Two copies were printed indeed, but they were stapled together".
And the bug is fixed yesterday, details please refer OpenPrinting/libppd#44.

• After executing sudo systemctl stop cups, the files in /etc/cups/ppd disappear, and after executing sudo systemctl start cups the folder remains empty. However, once a network printer is selected in a GUI print dialog, the corresponding PPD file appears in /etc/cups/ppd.

After this step, the GTK (GUI print dialog) will notify cups to create a temporary driver named "everywhere". And the "everywhere" driver prints well. After printing for a few seconds, the "everywhere" driver will automatically disappear.

Is the following trick feasible?
Step1：Open the GUI print dialog and copy the corresponding PPD file in the /etc/cups/ppd. Rename it as "a.ppd".
Step2: Use below command to add a persistent queue.
#lpadmin -p <foo-printer> -P a.ppd -v ipp://<ip-address>/ipp/print -E

Notes： The "foo-printer" in above command can be replaced by any queue name you like.

[alexeymuranov]

@szlt5 thanks for the information. I may try your suggestion when I am back at office.

Should I keep the a.ppd file in /etc/cups/ppd or put it somewhere else before executing the lpadmin command?

[szlt5]

Should I keep the a.ppd file in /etc/cups/ppd or put it somewhere else before executing the lpadmin command?

It's ok to put it somewhere else, if you put it in the /tmp, the command should be:
#lpadmin -p <foo-printer> -P /tmp/a.ppd -v ipp://<ip-address>/ipp/print -E

[alexeymuranov]

@szlt5 , tested you suggestion, it worked!

---

Update. I notice however that with the "everywhere" driver some PDF files are not printed correctly in "Color" mode: some content is replaced with thin horizontal colored lines or not printed at all. The problem seems to be related to the use of gradients in the PDF.