[cups] Printing CCITT and JBIG2 encoded images fails
Till Kamppeter
till.kamppeter at gmail.com
Wed Jul 26 12:45:49 PDT 2017
On 07/26/2017 04:34 PM, Michael Sweet wrote:
> Emilio,
>
> The CUPS error_log will show which filter(s) are used for the job, at which point you can determine which packages are involved. IIRC the cups-filters PDF to PostScript filter (which will likely be invoked for this driver) can be configured to use either, so look at the /usr/lib/cups/filter/pdftops script to determine which program is getting used.
>
Note that the pdftops filter of cups-filters is not a script (none of
the filters is a script currently because they need libcups to read the
PPD file), but pdftops has an option to switch between the PDF renderers
Ghostscript, Poppler, and MuPDF. So you can try out which works best for
you. I, as upstream maintainer of cups-filters, can even add a quirk
handler to the filter if the outcoming PostScript of a certain renderer
interferes badly with the printer.
See the
/usr/share/doc/cups-filters/README.gz
file:
----------
POSTSCRIPT PRINTING RENDERER AND RESOLUTION SELECTION
If you use CUPS with this package and a PostScript printer then
the included pdftops filter converts the print job data which is
in PDF format into PostScript. By default, the PostScript is
generated with Ghostscript's "ps2write" output device, which
generates a DSC-conforming PostScript with compressed embedded
fonts and compressed page content. This is resource-saving and
leads to fast wire transfer of print jobs to the printer.
Unfortunately, Ghostscript's PostScript output is not compatible
with some printers due to interpreter bugs in the printer and in
addition, processing (by Ghostscript or by the printer's
interpreter) can get very slow with high printing resolutions when
parts of the incoming PDF file are converted to bitmaps if they
contain graphical structures which are not supported by
PostScript. The bitmap problem especially occurs on input files
with transparency, especially also the ones produced by Cairo
(evince and many other GNOME/GTK applications) which unnecessarily
introduces transparency even if the input PDF has no transparency.
Therefore there are two possibilities to configure pdftops at
runtime:
1. Selection of the renderer: Ghostscript, Poppler, pdftocairo,
Adobe Reader, or MuPDF
Ghostscript has better color management and is generally optimized
more for printing. Poppler produces a PostScript which is
compatible with more buggy built-in PostScript interpreters of
printers and it leads to a somewhat quicker workflow when
graphical structures of the input PDF has to be turned into
bitmaps. Adobe Reader is the PDF renderer from Adobe, the ones who
created PDF and PostScript. pdftocairo is a good choice for the
PDF output of Cairo (for example when printing from evince). It
is less resource-consuming when rasterizing graphical elements
which cannot be represented in PostScript (like
transparency). Note that pdftocairo only supports PDF input using
DeviceRGB, DeviceGray, RGB or sGray and is not capable of
generating PostScript level 1. So its support is only experimental
and distributions should not choose it as default.
The selection is done by the "pdftops-renderer" option, setting it
to "gs", "pdftops", "pdftocairo", "acroread", "mupdf", or "hybrid":
Per-job: lpr -o pdftops-renderer=pdftops ...
Per-queue default: lpadmin -p printer -o pdftops-renderer-default=gs
Remove default: lpadmin -p printer -R pdftops-renderer-default
By default, pdftops uses Ghostscript if this does not get changed
at compile time, for example by the Linux distribution vendor.
Hybrid means Ghostscript for most printers, but Poppler's pdftops
for Brother, Minolta, and Konica Minolta. Printer make and model
information comes from the PPD or via the "make-and-model" option.
2. Limitation of the image rendering resolution
If graphical structures of the incoming PDF file have to be
converted to bitmaps due to limitations of PostScript, the
conversion of the file by pdftops or the rendering by the printer
can get too slow if the bitmap resolution is too high or the
printout quality can degrade if the bitmap resolution is too low.
By default, pdftops tries to find out the actual printing
resolution and sets the resolution for bitmap generation to the
same value. If it cannot find the printing resolution, it uses 300
dpi. It never goes higher than a limit of 1440 dpi. Note that this
default limit can get changed at compile time, for example by the
Linux distribution vendor.
The resolution limit for bitmaps can be changed to a lower or
higher value, or be set to unlimited. This is done by the option
"pdftops-max-image-resolution", setting it to the desired value
(in dpi) or to zero for unlimited. It can be used per-job or as
per-queue default as the "pdftops-renderer" option described
above.
The "pdftops-max-image-resolution" option is ignored when Adobe
Reader is selected as PDF renderer.
POSTSCRIPT PRINTING DEBUG MODE
Sometimes a PostScript printer's interpreter errors, crashes, or
somehow else misbehaves on Ghostscript's output. To find
workarounds (currently we have already workarounds for Brother and
Kyocera) it is much easier to work with uncompressed PostScript.
To get uncompressed PostScript as output, send a job with the
"psdebug" option, with commands like the following:
lpr -P <printer> -o psdebug <file>
lp -d <printer> -o psdebug <file>
If you want to send your job out of a desktop application, run
lpoptions -p <printer> -o psdebug
to make "psdebug" a personal default setting for you.
To extract the PostScript output for a developer to analyse it,
clone your print queue to a one which prints into a file:
cupsctl FileDevice=yes
lpadmin -p test -E -v file:/tmp/printout \
-P /etc/cups/ppd/<name of original queue>.ppd
and print into this queue as described above. The PostScript
output is in /tmp/printout after the job has completed.
This option does not change anything if Poppler's pdftops is used
as renderer.
----------
Please try out the options and tell us what works. Thanks.
Till
More information about the cups
mailing list