Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HP Color LaserJet Pro MFP M281fdw prints garbage printing with IPP Everywhere printing #343

Closed
VorpalBlade opened this issue Mar 1, 2022 · 9 comments
Labels
bug Something isn't working duplicate This issue or pull request already exists waiting for reporter There are data requested from the reporter

Comments

@VorpalBlade
Copy link

I'm having trouble printing to a "HP Color LaserJet Pro MFP M281fdw" using the new fancy IPP Everywhere support in CUPS. When I select to print a test page from the CUPS web GUI I get a garbage output printed with the following lines:

#PDF-BANNER
           Template default-testpage.pdf
                                        Show printer-name printer-info printer

The last line ends at the right edge of the A4 paper. The rest of the page is blank. Other files also print strangely. I tried to print a simple PDF with colour vector graphics and it ended up in greyscale instead of colour. Multi-page prints doesn't work at all (no page at all comes out, not even the first one). Double sided printing (this printer is capable of automatic duplex) obviously fails completely for that reason alone.

The printer in question works properly using the "Postscript" driver option, and prints the normal test page. Printing other things also works. The printer also works properly using the "driverless, cups-filters" option.

Thus the actual bug itself: Presumably the "IPP Everywhere" driver suggested should either work or at least not be suggested as the top driver for this particular printer.

Detailed testing

According to the web GUI of the printer it does support both IPP and AirPrint.

CUPS finds the printer several times, using different protocols presumably:

  • HP Color LaserJet MFP M281fdw (81A44A) (HP ColorLaserJet MFP M278-M281)
    • Actual URI: dnssd://HP%20Color%20LaserJet%20MFP%20M281fdw%20(81A44A)._ipp._tcp.local/?uuid=<cut out in case it is personally identifiable>
  • HP Color LaserJet MFP M281fdw (HP ColorLaserJet MFP M278-M281)
    • Actual URI: socket://192.168.2.12
  • HP ColorLaserJet MFP M278-M281 (driverless) (HP ColorLaserJet MFP M278-M281)
    • Actual URI: ipps://HP%20Color%20LaserJet%20MFP%20M281fdw%20(81A44A)._ipps._tcp.local/

For all of these the following drivers are suggested at the top of the list (before the full list of HP printers follow alphabetically):

  • HP ColorLaserJet MFP M278-M281 - IPP Everywhere ™
    • Produces garbage output
    • Almost all options missing (such as: duplex printing, page size, feed tray, ...)
  • HP ColorLaserJet MFP M278-M281 Postscript (en, en, da, de, es, fi, fr, it, ja, ko, no, nl, pt, ru, sv, zh_CN, zh_TW)
    • Works, but gives warning about it being a legacy driver that will be unsupported in the future.
    • Has the most options
  • HP ColorLaserJet MFP M278-M281, driverless, cups-filters 1.28.12 (en)
    • Works
    • Missing several options, such as edge control, print text as grey, etc.
  • HP ColorLaserJet MFP M278-M281, Fax, driverless, cups-filters 1.28.12 (en)
    • Same as the above one.

I have not tested all combinations of URIs and suggested drivers, but I did test everything for both the socket:// and ipps:// URIs and saw no differences.

Software versions

  • Arch Linux (rolling release)
  • CUPS 2.4.1-1 (packaged by distro)
  • avahi 0.8+22+gfd482a7-3 (packaged by distro)
@zdohnal
Copy link
Member

zdohnal commented Mar 2, 2022

Hi @VorpalBlade ,

thank you for reporting the issue!

It would be great if you attached the files from the following commands:

$ ipptool --ippserver printer.txt ipp://192.168.2.12:631/ipp/print get-printer-attributes.test

(the file to attach here is printer.txt)

Then we need to install the everywhere queue, enable debug logging, print one page from a pdf to 'everywhere' queue, and then to driverless queue and get the logs:

$ lpadmin -p <queuename> -v ipp://192.168.2.12:631/ipp/print -m everywhere -E
$ cupsctl --debug-logging
$ tail -f /var/log/cups/error_log > debug_log.txt &
$ lp -d <queuename> <some_pdf> -P 1
(once the job is finished)
$ lp -d <driverless_queuename> <some_pdf> -P 1
(once the job is finished)
$ kill $(pidof tail)

(debug_log.txt is the desired file)

And in the end please attach PPD files for 'IPP Everywhere' queue and for driverless queue from /etc/cups/ppd - you will have to add a .txt suffix to add them directly to github.

Thank you in advance!

@zdohnal
Copy link
Member

zdohnal commented Mar 2, 2022

Note:

It looks similar to #340 .

@zdohnal zdohnal added bug Something isn't working investigating Investigating the issue waiting for reporter There are data requested from the reporter labels Mar 2, 2022
@VorpalBlade
Copy link
Author

Here is the printer.txt.

I did the test print using lp as you suggested. However this time it worked and I got the output in color(?!). Also, for the queue created using lpadmin this way, all the expected options exist in the printer dialog.

Interestingly, when I look in the printer list in the web UI of CUPS the one added with lpadmin shows up as "Make and Model: ColorLaserJet MFP M278-M281 - IPP Everywhere", while the one added using the web UI and selecting "IPP Everywhere" shows up as "Make and Model: Local Raw Printer". Maybe the issue is that the web UI is bugged for adding the printer? Or the URI being the IP instead of the mdns/avahi thing helps?

Anyway, the log is attached, though I doubt it will shed much light on the issue given the above information: debug_log.txt

Thus I decided to do the same print using the IPP printer added via the web UI and take a debug log of that too: debug_log2.txt. In this case, no page came out, but the printer woke from low power mode (screen turned on and a relay clicked) and then went back to sleep again.

In conclusion: I'm utterly confused as to what is going on.

@VorpalBlade
Copy link
Author

Looking in the printer details in the web UI the "Driver" is listed as:

  • For the broken printer added via web UI and selecting IPP Everywhere: Local Raw Printer (grayscale, 2-sided printing)
  • For the working printer added via lpadmin: ColorLaserJet MFP M278-M281 - IPP Everywhere (color, 2-sided printing)

@zdohnal
Copy link
Member

zdohnal commented Mar 2, 2022

Or the URI being the IP instead of the mdns/avahi thing helps?

IMO it is this one - and similar thing happens in #340 .

Looks like the command with mdns uri wasn't able to communicate with the printer and left the queue as raw.

Can you capture the CUPS logs when you create the queue via lpadmin:

$ lpadmin -p <queue> -v ipps://HP%20Color%20LaserJet%20MFP%20M281fdw%20(81A44A)._ipps._tcp.local/ -m everywhere -E

?

Thank you in advance!

@jsmeix
Copy link

jsmeix commented Mar 2, 2022

Only as a side note FYI regarding printout like

#PDF-BANNER
           Template default-testpage.pdf
                                        Show printer-name printer-info ...

cf. apple/cups#6024

That text comes from a file like /usr/share/cups/data/testprint
(the file path could be different depending on the Linux distribution).
which does not belong to CUPS but to the separated cups-filters project.
The CUPS test page is no longer directly supported by CUPS since CUPS >= 1.6.
Since CUPS >= 1.6 only the test page in the cups-filters package work
via the cups-filters PDF workflow and the cups-filters package that provides
/usr/share/cups/data/testprint which has the form of a banner template page
so it should be handled by the matching bannertopdf filter in cups-filters.
But what you get printed as test page is the (unexpected)
raw /usr/share/cups/data/testprint file content
instead of the output of the bannertopdf filter.

zdohnal added a commit that referenced this issue Mar 2, 2022
Users sometimes pass URIs from dnssd and driverless backends as a
device URI for IPP Everywhere queues. These URIs have mDNS hostnames in
it, so they need to be resolved before used in connection.
@zdohnal
Copy link
Member

zdohnal commented Mar 2, 2022

@VorpalBlade Can you check if the referenced commit helps you when you install the permanent IPP Everywhere queue with mDNS hostname-based URIs?

@zdohnal zdohnal added duplicate This issue or pull request already exists and removed investigating Investigating the issue labels Mar 2, 2022
@zdohnal zdohnal closed this as completed Mar 2, 2022
@VorpalBlade
Copy link
Author

Can you capture the CUPS logs when you create the queue via lpadmin: [...]

Sure! And based on reading the log it looks to me that you are right. Here is the log: debug_log.txt

Can you check if the referenced commit helps you when you install the permanent IPP Everywhere queue with mDNS hostname-based URIs?

Assuming it can be applied as a patch on the version in the Arch Linux PKGBUILD without massive backporting effort, sure. While I do know C, it has been a few years since I coded anything except python and various scientific domain specific languages, so I'm a bit rusty.

@VorpalBlade
Copy link
Author

VorpalBlade commented Mar 2, 2022

@zdohnal Unfortunately that patch did not change the behaviour at all.

EDIT: See comment in issue #340

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists waiting for reporter There are data requested from the reporter
Projects
None yet
Development

No branches or pull requests

3 participants