Print jobs get canceled at printer

[mcp292]

Purpose

This issue is being made at the request of @zdohnal in #1090.

Have

I have a Brother HL-L2325DW. I set it up as a driverless network printer through the GNOME settings using add printer and leaving defaults.

Running Fedora 40 (Workspace Edition) with GNOME on a Thinkpad T14s laptop. OpenPrinting CUPS 2.4.11.

Problem

Print jobs get canceled at printer repeatedly. Usually the first print after powering on the printer goes through, and anything else gets canceled.

Tried

I've tried to remove the printer and re-add, change settings, print from different places (lp, lpr, firefox, document viewer), factory reset printer, reset printer network settings.

Logs

• multiple_prints.txt - Here is a session where the first document sent printed successfully, and the rest were canceled at printer. Search for Unable to add document to print job. which appears in red in my terminal. Sorry I cannot preserve the color coding. There's some odd stuff about "cropping" near the end. These were set to print from Firefox.
• ppd_before_printing.txt - Added DirtyCleanInterval 0 to cupsd.conf, issued sudo systemctl restart cups, removed printer, re-added printer, copied /etc/cups/ppd. (Removed and added printer through GNOME settings.)
• ppd_after_printing.txt - Printed document through Firefox. Got a GNOME notification saying printing complete but nothing happened. Nothing printed.

[zdohnal]

Ok, *cupsMandatory is defined as ```*cupsMandatory: "value1 ... valueN", but we don't use quotes there.

Can you try editing the PPD and reinstalling printer with the edited PPD?

Like you change in the PPD (/etc/cups/ppd/HL-L2325DW.ppd) the line:

*cupsMandatory: attributes-charset attributes-natural-language printer-uri

to

*cupsMandatory: "attributes-charset attributes-natural-language printer-uri"

and then reinstall the printer this way:

$ sudo lpadmin -p HL-L2325DW -P /etc/cups/ppd/HL-L2325DW.ppd -E

and try to print?

Ad the problem itself - does it happen even for the same file? First print goes well, but the next of the same file does not print? (from the same application)

Additionally, can you check if you get the same situation if you print the same file from command line? The command is:

lp -d HL-L2325DW <file>

[mcp292]

Okay, I changed the line in the ppd, ran the install line, then tried to print with two-sided, 9-up (what I used when producing the logs). Printing canceled at printer.

I tried again with two-sided, 1-up and it went through. (This and above with Firefox.)

Tried to print two-sided, 9-up for consistency with:

lp -d HL-L2325DW -o number-up=9 -o sides=two-sided-long-edge  ~/downloads/printing.pdf

Canceled at printer.

Tried two-sided, 1-up (what worked in FF):

lp -d HL-L2325DW-2 -o sides=two-sided-long-edge ~/downloads/printing.pdf

Canceled at printer.

Tried the above line again to try to rule out "luck of the draw". Canceled at printer.

[mcp292]

Did you need me to explicitly remove the printer before running the lpadmin install line? Or restart any services?

[zdohnal]

What is "HL-L2325DW"? The reinstalled printer with the updated PPD?

There is no need to restart the service or remove the original printer - cupsd should update the cache and files accordingly asap. However, cupsd might rewrite the PPD to incorrect form again, but since even the first printing was cancelled, it might be red herring.

So to simplify this and rule out any possible divergences, stick with CUPS utils and no options from now (so no Gnome, no Firefox, no additional options, until we found out what triggers it):

1. check if the issue happens with IPP Everywhere - you install it by:

$ lpadmin -p <eve_name> -v ipp://<ip or hostname>/ipp/print -m everywhere -E

and print to it twice the same file (choose of course some one page PDF, so you don't get swarmed by papers and we can rule out this possibility):

$ lp -d <eve_name> <file>.pdf

If those two print okay, try larger file and add options with lp - if that prints ok, try printing to the queue from Firefox or other app you use.

If all this work, we can say the issue is related to driverless driver and not to IPP Everywhere. If it does not, then the issue might be in cups in general or in cups-filters, or in printer itself - so type of no-driver solution does not matter.

2. If IPP Everywhere worked, let's focus on "driverless", which is the driver Gnome sets up for the printer. You can reinstall it by this way:

$ lpadmin -p <name> -v ipp://<ip or hostname>/ipp/print -m driverless:ipp://<ip or hostname>/ipp/print -E

then try print twice with lp again, first one page PDF without options, then multipage pdf and options, and in the end via Firefox.

I'm sorry for lot of printing, but there can be different things in play, so I need to find out the minimal reproducer which triggers the issue - especially the fact it shows only after first printing is tricky.

[mcp292]

I'm sorry for lot of printing, but there can be different things in play, so I need to find out the minimal reproducer which triggers the issue - especially the fact it shows only after first printing is tricky.

No worries about the printing. This problem costs me a considerable amount of time and focus so fixing it is well worth the additional time and resources expended. I appreciate your help.

What is "HL-L2325DW"? The reinstalled printer with the updated PPD?

Regarding HL-L2325DW vs HL-L2325DW-2. That is a very good catch. Sorry for the confusion. From what I recall, there is only HL-L2325DW-2 and I was listing it here without the two to avoid added complexity. I understand that in doing so I made things more complicated. I will not modify anything from here on out.

To answer your question, both are the reinstalled printer with updated PPD. Reinstalled as instructed without removing the original.

So to simplify this and rule out any possible divergences, stick with CUPS utils and no options from now (so no Gnome, no Firefox, no additional options, until we found out what triggers it):

Perfect, got it!

I'm going to list what I do so you can validate each step.

1. Check if the issue happens with IPP Everywhere

Finding URI:

$ lpinfo -v
file cups-brf:/
network beh
network https
network http
network ipps
network ipp
direct hp
network socket
network lpd
network smb
direct hpfax
network dnssd://Brother%20HL-L2325DW._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-00410ef027f1
network lpd://BRW00410EF027F1/BINARY_P1
network ipp://Brother%20HL-L2325DW._ipp._tcp.local/

Installing:

$ lpadmin -p ipp_everywhere -v ipp://Brother%20HL-L2325DW._ipp._tcp.local/ipp/print -m everywhere -E

Printing twice:

$ lp -d ipp_everywhere printing.pdf
request id is ipp_everywhere-647 (1 file(s))

Success!

$ lp -d ipp_everywhere printing.pdf
request id is ipp_everywhere-648 (1 file(s))

Success!

Printing large file with options:

$ lp -d ipp_everywhere -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf 
request id is ipp_everywhere-649 (1 file(s))

Success!

Trying same file (webpage) from Firefox with same options:

Success!

Trying same downloaded file from PDF Viewer with same options:

Canceled at printer.

Tried from commandline again to see if any settings were overwritten by PDF Viewer:

$ lp -d ipp_everywhere -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf 
request id is ipp_everywhere-654 (1 file(s))

Success!

Tried from PDF Viewer again while checking journal:

pdf_log.txt

(The evince line is not part of the log, but instead something that gets printed to stdout by the PDF Viewer. It printed out while logs were printing.)

2. If everything works we can say it's related to driverless

Since the only thing that failed is PDF Viewer, I will move forward and test driverless.

Re-installing:

$ lpadmin -p driverless -v ipp://Brother%20HL-L2325DW._ipp._tcp.local/ipp/print -m driverless:ipp://Brother%20HL-L2325DW._ipp._tcp.local/ipp/print -E
lpadmin: Unable to open PPD "/tmp/71d2967280f8c": Missing PPD-Adobe-4.x header on line 0.

Tried:

$ lpadmin -p driverless -v ipp://Brother%20HL-L2325DW._ipp._tcp.local/ipp/print -m driverless -E
lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS.
lpadmin: cups-driverd failed to get PPD file - see error_log for details.

Tried first install line again:

$ lpadmin -p driverless -v ipp://Brother%20HL-L2325DW._ipp._tcp.local/ipp/print -m driverless:ipp://Brother%20HL-L2325DW._ipp._tcp.local/ipp/print -E

Oddly, now it installed.

Testing one page twice:

$ lp -d driverless printing.pdf 
request id is driverless-656 (1 file(s))

Success!

$ lp -d driverless printing.pdf 
request id is driverless-657 (1 file(s))

Success!

Trying with options twice:

$ lp -d driverless -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf 
request id is driverless-658 (1 file(s))

Canceled at printer.

$ lp -d driverless -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf 
request id is driverless-658 (1 file(s))

Canceled at printer.

Trying with Firefox with options:

Success!

Trying with PDF Viewer with options:

Canceled at printer.

[mcp292]

I highly suspect this has something to do with print scaling. Scaling options are not present in the GUI system print when using an IPP Everywhere printer. But are for driverless. This alone is not enough evidence.

I wonder if it has anything to do with OpenPrinting/cups-filters#108 and its PR.

[mcp292]

Let me know if you need me to try anything else.

[zdohnal]

@mcp292 thank you very much for the detailed testing! And I'm sorry for delay, I was stuck with other things :(

So I guess we can rule out the fact the PPD change would make a difference, since repeated printing brought the same results, and the issue is probably in filter chain, since both models fail when printing from PDF viewer, but driverless model seems to be more prone to the cancellation.

I wonder about print-scaling - it is a good find that the setting is not present in GUI of PDF viewer, but I don't see the setting in the previous logs from driverless either (there is only the default one applied in the filter, which happens for both prints, successful and failed).

So based on your findings, let's see the logs where those two models started to differ:

lp -d ipp_everywhere -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf 

and

lp -d driverless -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf 

Please provide me logs for both jobs, and both PPDs. If there is any change in behavior in comparison to the past, do let me know - I count on it will behave the same - everywhere prints, driverless gets canceled.

Hopefully it will give us some ideas which will lead even to fixing PDF viewer printing.

[mcp292]

I'm sorry for delay...

No apology needed. I appreciate your help.

ipp_everywhere

lp -d ipp_everywhere -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf

Printing succeeded.

ipp_everywhere_log.txt

ipp_everywhere_ppd.txt

driverless

lp -d driverless -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf

Printing canceled.

driverless_log.txt

driverless_ppd.txt

[mcp292]

Bumping, in case it fell off your radar. Still having issues daily.

[zdohnal]

@mcp292 I'm sorry, I was focused on my work and just tried to answer on the new issues, so I missed the backlog :( .

I've checked the logs now and it looks to be connected to print quality.

IPP Everywhere:

*DefaultResolution: 300dpi
*OpenUI *cupsPrintQuality: PickOne
*OrderDependency: 10 AnySetup *cupsPrintQuality
*en_US.Translation cupsPrintQuality/Print Quality: ""
*DefaultcupsPrintQuality: Normal
*cupsPrintQuality Draft: "<</HWResolution[300 150]>>setpagedevice"
*en_US.cupsPrintQuality Draft/Draft: ""
*cupsPrintQuality Normal: "<</HWResolution[300 300]>>setpagedevice"
*en_US.cupsPrintQuality Normal/Normal: ""
*cupsPrintQuality High: "<</HWResolution[1200 1200]>>setpagedevice"
*en_US.cupsPrintQuality High/High: ""
*CloseUI: *cupsPrintQuality

driverless

*DefaultResolution: 600dpi
*OpenUI *cupsPrintQuality/Print Quality: PickOne
*OrderDependency: 10 AnySetup *cupsPrintQuality
*DefaultcupsPrintQuality: Normal
*cupsPrintQuality Draft/Draft: "<</HWResolution[300 300]>>setpagedevice"
*cupsPrintQuality Normal/Normal: "<</HWResolution[600 600]>>setpagedevice"
*cupsPrintQuality High/High: "<</HWResolution[1200 1200]>>setpagedevice"
*CloseUI: *cupsPrintQuality

Only the highest resolution matches, draft and normal have a different numbers and "normal" is used by default.

So it looks like the printer somehow manages to process smaller files with higher resolution (like it influences the Apple raster file generation at the end of filtering), but fails for larger ones if the job is set as resolution 600x600.

Can you get attrs.txt file with output from ipptool command:

$ ipptool --ippserver attrs.txt ipp://BRW00410EF027F1.local:631/ipp/print get-printer-attributes.test

it will get us IPP attributes from the printer, so we will see what resolutions it reports so we can track what driverless PPD generator did wrong, or if there is discrepancy on the printer side.

You can try taking driverless PPD, change the normal quality resolution, create a new queue with it (the same connection as before) and see if the testing command passes.

In general you:

$ sudo cp /etc/cups/ppd/driverless.ppd /tmp
change "<</HWResolution[600 600]" to "<</HWResolution[300 300]" in new PPD
$ sudo lpadmin  -p new-driverless -v ipp://BRW00410EF027F1.local:631/ipp/print -P /tmp/driverless.ppd -E
$ lp -d new-driverless -o number-up=9 -o sides=two-sided-long-edge printing_full.pdf

If the suspicion is correct, new-driverless should now print.