Bug 2064606

Hi Roy,

the issue is actually not present only at printing test page from control-center, but I can get the behavior in CUPS Web UI as well.

I've found out RHEL 9 and current Fedora are not affected, so the possible patch exists in upstream - I'm going to bisect the cups-filters project, because if I create a file device printer, use the IPP Everywhere driver for it and print test page, I see the PDF is garbled, so the issue seems to lie in the filters - bannertopdf or pdftopdf.

Logs from the job:

```
Mar 16 11:16:26 localhost.localdomain cupsd[970]: [Job 3] 4 filters for job:
Mar 16 11:16:26 localhost.localdomain cupsd[970]: [Job 3] bannertopdf (application/vnd.cups-pdf-banner to application/pdf, cost 32)
Mar 16 11:16:26 localhost.localdomain cupsd[970]: [Job 3] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
Mar 16 11:16:26 localhost.localdomain cupsd[970]: [Job 3] - (application/vnd.cups-pdf to printer/test/application/pdf, cost 10)
Mar 16 11:16:26 localhost.localdomain cupsd[970]: [Job 3] - (printer/test/application/pdf to printer/test, cost 0)
```

The last two filters don't start any executables which convert the document, so the garbling of the PDF happens in the first two.

Then I ran the first filter - bannertopdf - by hand with the file which an application sends to CUPS (file from /var/spool/cups) as an input:

```
[user@localhost ~]$ PPD=test.ppd /usr/lib/cups/filter/bannertopdf 1 user '' 1 '' d00003-001 > out.pdf
PDF template file doesn't have form. It's okay.
[user@localhost ~]$ evince out.pdf
some font thing failed
some font thing failed
some font thing failed
```

The resulting PDF is missing the text and the failures are generated - I'm attaching the PDF in the next comment.

The additional I've found out - printing the test page does not work only when the desired destination document format is PDF. The destination document format is taken from a driver or from the printer (in case of '-m everywhere'), so the affected devices are ones with PDF drivers or AirPrint/IPP Everywhere printers, which supports application/pdf format.

Created attachment 1866171 [details]
Output of bannertopdf

Roy,

the filter at fault, bannertopdf, was rewritten with using a different library slightly after RHEL 8 forked from Fedora. We use poppler for bannertopdf in RHEL 8, but the filter is written with qpdf in RHEL 9, where the printing test page works.

Updating cups-filters and qpdf to higher versions where bannertopdf works (not to the exact RHEL 9 versions, the fix happened between RHEL 8 and RHEL 9) is unfortunately not possible, because the newer cups-filters requires a newer qpdf which, which breaks API and ABI compatibility for our customers.

So I see the following options:

A) write a downstream patch, which will use Poppler, just for RHEL 8
Pros:
- bannertopdf will work for testing page and banners
Cons:
- downstream patch (we cannot send the patch to the community for further testing), higher time requirement

B) use pregenerated PDF instead of template for testing page
Pros:
- bannertopdf is not used and printing test page will work for driverless PDF printers
Cons:
- printing banners will be still broken for driverless PDF printers


WDYT, Roy? Which option is acceptable for you? Does our users print banners often to get hit by this, if we switch to IPP?

I would prefer the option B.



P.S. The printer Tom Lizuch used for testing - BRQ-TPBB-0B240-North - has probably got a firmware update, which broke IPP compatibility. Sampath already encountered several printers with this breakage, was it reported to Canon? We will have to have this fixed before we go to IPP together with this ticket.

(In reply to Zdenek Dohnal from comment #3)
> P.S. The printer Tom Lizuch used for testing - BRQ-TPBB-0B240-North - has
> probably got a firmware update, which broke IPP compatibility. Sampath
> already encountered several printers with this breakage, was it reported to
> Canon? We will have to have this fixed before we go to IPP together with
> this ticket.

Ok, I'm sorry for confusion - that specific printer now works for IPP get-printer-attributes request. It didn't work some time ago, I swear... It would be great if we could check other printers whether they could answer properly to the IPP request.

Thanks Zdenek,

Option B will work for us as well. Banners are pretty rare and i am not aware for requirements for it.

Let me know when you like us to run some tests and confirm this is fixed.

Kind Regards,
Roy

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cups-filters bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7653