Bugs in resolution handling, especially garbage printed when invalid resolution value supplied
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libcupsfilters (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Lunar |
Fix Released
|
High
|
Unassigned | ||
Mantic |
Fix Released
|
High
|
Unassigned | ||
libppd (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Lunar |
Fix Released
|
High
|
Unassigned | ||
Mantic |
Fix Released
|
High
|
Unassigned |
Bug Description
This bug was originally reported upstream as
https:/
The reporter uses Fedora 38, besides Ubuntu 23.04 the second distro using cups-filters 2.x and libcupsfilters 2.x. As I am able to reproduce the bug on Ubuntu 23.04 and it is a problem many users could run into (it especially happens with driverless IPP printers) I post this bug report as base for an SRU in 23.04.
What happens is that if a job is printed and along with it a resolution setting is supplied which is not supported by the printer, garbage is printed as the job gets actually rasterized with the wrong resolution. This was discovered by the Chromium Browser sending print jobs with `-o resolution=96dpi` regardless which resolutions the printer actually supports. Most driverless printers receive their jobs rasterrized into Apple Raster or PWG Raster and so for them this bug occurs.
I have already fixed the bug upstream in libcupsfilters via
https:/
The fix makes the function cfIPPAttrResolu
https:/
Now unsupported resolutions supplied to jobs are ignored so that the default resolution gets used then.
The bug masked another bug in resolution handling which got revealed once the above-mentioned fix was applied.Here the problem is that for driverless IPP printers, printing in Apple Raster or PWG Raster always the minimum resolution got used, even if I higher one was requested, as the default resolution or by a job attribute/option which sets a higher resolution. This I fixed in libppd via:
https:/
Now always the correct resolution gets used for the rasterization of the job and so the correct print quality obtained.
The fixes get applied to the libcupsfilters and libppd source packages both in Mantic and in Lunar (SRU).
[ Impact ]
The bug impacts at least all users of driverless IPP printers which take print jobs in raster formats, and these are most common printers nowadays. Probably also other printers are affected.
The principal bug, jobs with unsupported resolution settings being accepted leads to unusable printouts wasting paper and toner/ink.
The secondary problem of always the lowest supported resolution being used leads to a lower print quality than expected.
The fact that the Chromium Browser from version 112 on (we use the Snap and current version there is 113) sens "-o resolution=96dpi" along with jobs will trigger this bug for many people.
[ Test Plan ]
Download the attached sample PPD file, a file to use the HP OfficeJet Pro 8730 in driverless mode, sending the job data in Apple Raster. Also have a PDF file handy.
No printer is required for the tests, simply observe the log output on the terminsl, the resolution used in the Ghostscript command line (the actual rasterization is done by Ghostscript).
cupsfilter -P driverless.ppd -m image/urf -o printer-
The terminal output contains a line like
DEBUG: cfFilterGhostsc
Note the "-r96x96" showing that the unsupported resolution got accepted for the rasterisation.
With the SRU applied we get "-r600x600" so the rasterisation is done with the default resolution of 600 dpi.
To reproduce the secondary problem of always the lowest resolution be used run
cupsfilter -P driverless.ppd -m image/urf file.pdf > out
Here you will get "-r300x300" despite the default resolution specified in the PPD file is 600 dpi ("*DefaultResol
You get also the correct resolution according to the requested print quality:
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQualit
gives "-r300x300" after applying the SRU and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQualit
and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQualit
both give "-r600x600" after applying the SRU.
You can also verify the resolution of the Apple Raster file "out" by installing rasterview
sudo snap install rasterview
and opening the file and see its metadata:
rasterview out
[ Where problems could occur ]
As the patches are rather small and the changes relatively easy to understand the potential for a regression is low but naturally not 100% excluded.
At least no complex changes in handling dynamic memory are contained, so the chance of having introduced a crasher is extremely low.
Changed in libcupsfilters (Ubuntu Lunar): | |
importance: | Undecided → Critical |
importance: | Critical → High |
Changed in libcupsfilters (Ubuntu Mantic): | |
importance: | Undecided → High |
Changed in libppd (Ubuntu Lunar): | |
importance: | Undecided → High |
Changed in libppd (Ubuntu Mantic): | |
importance: | Undecided → High |
description: | updated |
description: | updated |
Changed in libcupsfilters (Ubuntu Mantic): | |
status: | New → Fix Committed |
This bug was fixed in the package libcupsfilters - 2.0~rc1-0ubuntu3
---------------
libcupsfilters (2.0~rc1-0ubuntu3) mantic; urgency=medium
* libcupsfilters2 .symbols: Added 2 riscv64-only symbols with (otional).
-- Till Kamppeter <email address hidden> Mon, 5 Jun 2023 23:59:59 +0200