Comment 0 for bug 2022929
Revision history for this message
| Till Kamppeter (till-kamppeter) wrote | #0 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
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).