Canon iR-ADV 8285 Driver for Linux

This is a test of “Canon imageRUNNER ADVANCE 8285 PRO” Linux Driver as downloaded from the Canon Support site.

We compared usability, functionality and quality of prints with the Canon PCL Driver for Windows. We communicated test findings with Canon Belgium Services & Support, who on turn consulted Canon Europe. Both are referred to as “Canon Support” in this posting.

Canon Business Center Belgium advised the UFR II Driver, so this was the start of our test.

Tests were performed on a headless Debian GNU/Linux 9 (stretch) Server:

• Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux
• cups 2.2.1-8
• cndrvcups-common 3.80-1 Canon Printer Driver Common Modules Ver.3.80
• cndrvcups-ufr2-uk 3.40-1 Canon UFR2 Printer Driver for Linux

For lpr options, we consulted guide-ufr2-3.4xUK/frame_htmls/home.html, which is part of the driver package.

https://wiki.debian.org/PrinterDriver/Canon/UFR-II: “The Ultra Fast Renderer (UFR) is a proprietary rendering engine that is functionally similar to PostScript and PCL. It is claimed to be faster than either the PostScript or PCL drivers and is associated with Canon printers.”

A printer expecting to be provided with UFR II would have a PPD file containing the line:

*cupsFilter: "application/vnd.cups-postscript 0 pstoufr2cpca"

pstoufr2cpca is a filter program which converts PostScript data to the Canon UFR II printer command stream.

Punching is done correctly.

The following commands fail to give stapled output, when the driver default is Collate/True :

lpr -P printer -o Collate=Staple        -o StapleLocation=TopLeft document.pdf
lpr -P printer -o Collate=StapleCollate -o StapleLocation=TopLeft document.pdf

When the driver default, as set in CUPS Web Interface, is Collate/StapleCollate, stapling is applied correctly, but then again, lpr commands asking for Collate/Group and Collate/GroupCollate fail.

Canon Support suggested to set driver defaults with lpoptions just before issuing the lpr command, like:

lpoptions -p printer -o Collate=StapleCollate -o StapleLocation=TopLeft

Canon's advise, to set printer defaults with the lpoptions command before issuing the lpr command, confirms our presumption that the -o Collate option is ignored when used with lprcommand. Which is odd, especially since we can use punch (and other) options, that override printer defaults, with lpr without any problems.

Also, changing printer defaults each time before sending a job does not work in those cases, where all kinds of print requests are handled concurrently by a single server application.

The commands below …

# A4 sheet booklet
lpr -P printer -o PageSize=A5 -o Booklet=Left -o CNSaddleStitch=True -o BindEdge=Left doc.pdf
# A3 sheet booklet
lpr -P printer -o PageSize=A4 -o Booklet=Left -o CNSaddleStitch=True -o BindEdge=Left doc.pdf

… give this message:

However, this is a false alarm, since the booklets are printed as expected.

Canon Support urged us to “Ensure input data is PS”, which is odd. The fact that we use PDF and not PS as input, should not be an issue. Actually, “One of the decisions which was made on the OSDL Printing Summit in Atlanta in 2006 and widely accepted by all participants was to switch the standard print job transfer format from PostScript to PDF.” , as stated on Linux Foundation Wiki.

When a simple LibreOffice text document, with Times New Roman font, is exported as PDF, and this PDF is printed with lpr, printing fails, and CUPS job log reports:

"src = bidiCommon.c, line = 1200, err = 0¥nGPL Ghostscript 9.18:
Some glyphs of the font IWMJFA+TimesNewRomanPSMT requires a patented True Type interpreter."

For other prints that do succeed, the CUPS job log shows …

"src = bidiCommon.c, line = 1200, err = 0¥n

… appended with various DEBUG and INFO messages.

The 2-step CUPS filtering of the URF2 driver, from PDF → PostScript → OpenPrinting Vector, may cause extra delay. Although CUPS filtering may take extra time, the UFR PDL ensures fast execution on the printer.

A PDF document generated from a 51 page MS Word document (text + graphics) shows significant differences in PDL rendering time, depending on how the PDF is generated.

Q: Is Font Embedding the decisive factor here?
A: No, a test that compares a non-embedded font PDF, with its converted embedded font version (using pdftocairo -pdf non-embedded-fonts.pdf embedded-fonts.pdf), shows this is not the case.

Q: Does flattening the PDF (with pdftk input.pdf output flattened.pdf flatten) help?
A: Nope.

Print quality is good. But, for certain documents graphics are printed solid black.

Tests were performed on a headless Debian GNU/Linux 9 (stretch) Server:

• Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux
• cups 2.2.1-8
• cqcque-en 3.0-5 CQue - Driver for Canon iR, CLC, LPB and MF laser devices (English)

Since we could not set stapling options in one go with with lpr, Canon Support advised us to use the CQue driver. This driver comes with PostScript, PCL and PXL versions. We started testting with mainstream PostScript.

So, we moved on to the PCL version, and indeed this driver did trigger printing.

Stapling is seriously restricted. Paragraph 3.4.11 “Printing Multiple Copies of a Document with Stapling” in the CQue3.0ReferenceManual states:

“When printing multiple copies (say N copies) of a document with stapling most CUPS implementations will concatenate the output N times and then staple the resulting concatenated file. To prevent this CQue 3.0 PPDs support a feature: Repeat Job within the Canon Specific Options section. This allows you to specify from 1 to 99 copies for applications with the GTK+ print interface and 1 to 25 otherwise, with proper stapling of each copy. This feature is supported for PostScript, PCL5 and PCL6 Canon devices allowing PJL headers, i.e. some pure PostScript EFI devices are excluded. Note: N copies of a document may generate N separate entries in the log file of the Canon device.”

Output quality on paper is visibly inferior to Windows PCL Driver and Linux UFRII Driver. Even when quality is boosted with Image and Line Refinement ON, Toner Save OFF, and Halftones set to Resolution (600 dpi), it still lacks contrast.

From CQue 4.0 Reference Manual: “CQue 4.0-0 is a major release of CQue. It comes with the same PPDs as previous versions but the graphical user interface is absent. This eliminates many security and compatibility issues.”

Stapling is restricted to 999 copies. See paragraph 5.3 “Printing Multiple Copies of a Document with Finishing” in the CQue4.0 Reference Manual. So, things have greatly improved since the 99 max stapled copies restriction in the 3.0.5 version.

CUPS PostScript filtering is straightforward and faster that UFR2 filtering. But, execution on the printer is slower than the UFR PDL.

Print quality is good. The UFR driver problem with some graphics printed solid black, does not occur.