Bug#851499: cups-filters-core-drivers: Everywhere PPD content depends on queue creation method
Fixed in cups-filters upstream, BZR rev. 7599.
Thank you for the bug report.
"lpadmin -m everywhere" uses the PPD generator in the CUPS library. The
generator has no public API and so it cannot be used by other programs
using the CUPS library.
Therefore I have copied the PPD generator from CUPS and put it into the
libcupsfilters library, WITH public API, and keep it in sync with the
original by overtaking any changes.
This version of the PPD generator is used
- When cups-browsed creates a local print queue and generates a queue
for it (IPP network printers).
- When a queue is set up with a printer setup tool like system-config-
printer or localhost:631. In this case the "driverless" utility of
cups-filters is used to generate the PPD file.
The two PPD generators are not absolutely equal because I have added
- The original PPD generator only supports PWG Raster, Apple Raster,
PDF, and JPEG as printer PDL, my generator also accepts (with lower
priority) PostScript, PCL-XL, and PCL 5c/e, for legacy printers.
- The original PPD generator requires all printer capability, option,
and choice information from the printer attributes IPP request, my
generator can in some cases fall back to info from the Bonjour record
or even hard-coded default values. This adds support for some legacy
The difference in the generation of *cupsFilter2 lines in the PPD
generator is due to the support for the additional legacy PDLs. I had
overlooked JPEG that time. Now I have added the JPEG support the same
form as CUPS does. If input is JPEG and the printer understands JPEG,
the JPEG input gets passed through without filtering.
As JPEG supports only one-page documents (pictures) and most common PDLs
are multi-page (needed for typical print jobs), there should never be a
filter rule turning PDF (or any other multi-page language) into JPEG.