[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