| 2023-06-05 13:28:54 |
Till Kamppeter |
bug |
|
|
added bug |
| 2023-06-05 13:29:21 |
Till Kamppeter |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-06-05 13:29:21 |
Till Kamppeter |
bug task added |
|
libcupsfilters (Ubuntu Mantic) |
|
| 2023-06-05 13:29:21 |
Till Kamppeter |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-06-05 13:29:21 |
Till Kamppeter |
bug task added |
|
libcupsfilters (Ubuntu Lunar) |
|
| 2023-06-05 13:29:41 |
Till Kamppeter |
bug task added |
|
libppd (Ubuntu) |
|
| 2023-06-05 13:29:47 |
Till Kamppeter |
libcupsfilters (Ubuntu Lunar): importance |
Undecided |
Critical |
|
| 2023-06-05 13:29:51 |
Till Kamppeter |
libcupsfilters (Ubuntu Lunar): importance |
Critical |
High |
|
| 2023-06-05 13:29:54 |
Till Kamppeter |
libcupsfilters (Ubuntu Mantic): importance |
Undecided |
High |
|
| 2023-06-05 13:29:57 |
Till Kamppeter |
libppd (Ubuntu Lunar): importance |
Undecided |
High |
|
| 2023-06-05 13:30:00 |
Till Kamppeter |
libppd (Ubuntu Mantic): importance |
Undecided |
High |
|
| 2023-06-05 14:10:13 |
Till Kamppeter |
description |
This bug was originally reported upstream as
https://github.com/OpenPrinting/libcupsfilters/issues/29
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://github.com/OpenPrinting/libcupsfilters/commit/2892e9a63
The fix makes the function cfIPPAttrResolutionForPrinter() more intensely, in which another bug showed, the list of supported resolutions searched for as a range data type which was wrong and so the list not being found. So I fixed this here, also in libcupsfilters:
https://github.com/OpenPrinting/libcupsfilters/commit/9ff1341c2
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://github.com/OpenPrinting/libppd/commit/e2190988ff6c1
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). |
This bug was originally reported upstream as
https://github.com/OpenPrinting/libcupsfilters/issues/29
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://github.com/OpenPrinting/libcupsfilters/commit/2892e9a63
The fix makes the function cfIPPAttrResolutionForPrinter() more intensely, in which another bug showed, the list of supported resolutions searched for as a range data type which was wrong and so the list not being found. So I fixed this here, also in libcupsfilters:
https://github.com/OpenPrinting/libcupsfilters/commit/9ff1341c2
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://github.com/OpenPrinting/libppd/commit/e2190988ff6c1
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-resolution=96dpi file.pdf > out
The terminal output contains a line like
DEBUG: cfFilterGhostscript: Ghostscript command line: gs -dQUIET -dSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dUsePDFX3Profile -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=appleraster -sOutputType=automatic -r96x96 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=19 -dcupsBorderlessScalingFactor=0.0000 -dcupsInteger1=1 -dcupsInteger2=1 -scupsRenderingIntent=auto -scupsPageSizeName=A4 -dcupsManualCopies -I/usr/share/cups/fonts -sOutputICCProfile=srgb.icc -c -f -_
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 ("*DefaultResolution: 600 dpi" in the PPD file). After applying the SRU you get the expected "-r600x600".
You get also the correct resolution according to the requested print quality:
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=draft file.pdf > out
gives "-r300x300" after applying the SRU and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=normal file.pdf > out
and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=high file.pdf > out
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. |
|
| 2023-06-05 15:23:37 |
Till Kamppeter |
description |
This bug was originally reported upstream as
https://github.com/OpenPrinting/libcupsfilters/issues/29
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://github.com/OpenPrinting/libcupsfilters/commit/2892e9a63
The fix makes the function cfIPPAttrResolutionForPrinter() more intensely, in which another bug showed, the list of supported resolutions searched for as a range data type which was wrong and so the list not being found. So I fixed this here, also in libcupsfilters:
https://github.com/OpenPrinting/libcupsfilters/commit/9ff1341c2
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://github.com/OpenPrinting/libppd/commit/e2190988ff6c1
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-resolution=96dpi file.pdf > out
The terminal output contains a line like
DEBUG: cfFilterGhostscript: Ghostscript command line: gs -dQUIET -dSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dUsePDFX3Profile -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=appleraster -sOutputType=automatic -r96x96 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=19 -dcupsBorderlessScalingFactor=0.0000 -dcupsInteger1=1 -dcupsInteger2=1 -scupsRenderingIntent=auto -scupsPageSizeName=A4 -dcupsManualCopies -I/usr/share/cups/fonts -sOutputICCProfile=srgb.icc -c -f -_
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 ("*DefaultResolution: 600 dpi" in the PPD file). After applying the SRU you get the expected "-r600x600".
You get also the correct resolution according to the requested print quality:
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=draft file.pdf > out
gives "-r300x300" after applying the SRU and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=normal file.pdf > out
and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=high file.pdf > out
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. |
This bug was originally reported upstream as
https://github.com/OpenPrinting/libcupsfilters/issues/29
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://github.com/OpenPrinting/libcupsfilters/commit/2892e9a63
The fix makes the function cfIPPAttrResolutionForPrinter() used more intensely, in which another bug showed, the list of supported resolutions searched for as a range data type which was wrong and so the list not being found. So I fixed this here, also in libcupsfilters:
https://github.com/OpenPrinting/libcupsfilters/commit/9ff1341c2
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://github.com/OpenPrinting/libppd/commit/e2190988ff6c1
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-resolution=96dpi file.pdf > out
The terminal output contains a line like
DEBUG: cfFilterGhostscript: Ghostscript command line: gs -dQUIET -dSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dUsePDFX3Profile -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=appleraster -sOutputType=automatic -r96x96 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=19 -dcupsBorderlessScalingFactor=0.0000 -dcupsInteger1=1 -dcupsInteger2=1 -scupsRenderingIntent=auto -scupsPageSizeName=A4 -dcupsManualCopies -I/usr/share/cups/fonts -sOutputICCProfile=srgb.icc -c -f -_
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 ("*DefaultResolution: 600 dpi" in the PPD file). After applying the SRU you get the expected "-r600x600".
You get also the correct resolution according to the requested print quality:
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=draft file.pdf > out
gives "-r300x300" after applying the SRU and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=normal file.pdf > out
and
cupsfilter -P driverless.ppd -m image/urf -o cupsPrintQuality=high file.pdf > out
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. |
|
| 2023-06-05 16:00:28 |
Till Kamppeter |
attachment added |
|
driverless.ppd https://bugs.launchpad.net/ubuntu/+source/libppd/+bug/2022929/+attachment/5677899/+files/driverless.ppd |
|
| 2023-06-05 17:37:41 |
Till Kamppeter |
libcupsfilters (Ubuntu Mantic): status |
New |
Fix Committed |
|
| 2023-06-06 01:33:49 |
Launchpad Janitor |
libcupsfilters (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2023-06-06 02:02:21 |
Launchpad Janitor |
libppd (Ubuntu Mantic): status |
New |
Fix Released |
|
| 2023-06-06 07:12:11 |
Till Kamppeter |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-06-06 18:21:25 |
Brian Murray |
libppd (Ubuntu Lunar): status |
New |
Fix Committed |
|
| 2023-06-06 18:21:27 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2023-06-06 18:21:33 |
Brian Murray |
tags |
|
verification-needed verification-needed-lunar |
|
| 2023-06-06 18:29:59 |
Brian Murray |
libcupsfilters (Ubuntu Lunar): status |
New |
Fix Committed |
|
| 2023-06-14 08:51:43 |
Till Kamppeter |
tags |
verification-needed verification-needed-lunar |
verification-done verification-done-lunar |
|
| 2023-06-15 19:30:14 |
Launchpad Janitor |
libppd (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
| 2023-06-15 19:30:53 |
Launchpad Janitor |
libcupsfilters (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
| 2023-06-15 19:31:00 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
