Open Print Portal

User Tools

Site Tools


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.

UFR II/UFRII LT Driver v3.40

File version V3.40
Release date 09 November 2017
Operating system Linux (64-bit)

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. “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.

The PostScript is produced by a cups-filters filtering chain and pstoufr2cpca renders it into a form suitable to be sent to the printer.


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.

We conclude that the -o Collate option is ignored, and the driver default always takes precedence.

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:

CUPS job log shows: “Unsupported booklet value Left, using booklet=off!”

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

PostScript or PDF?

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.

Method PDF Time Comment
MS Word - Save As - PDF 1.5 2:30
MS Word - Save As - PDF/A 1.4 0:51 Some graphics disappear.
MS Word - Print - Microsoft Print to PDF 1.7 1:03
MS Word - Print - PDFill PDF&Image Writer 1.4 0:59
MS Word - Print - PDFCreator 1.4 1:00
MS Word - Save As - PDF GS convert to 1.4 compatibility 1.4 2:30

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.

CQue DEB Driver v3.0.5

File version v3.0.5
Release date 08 June 2017
Operating system Linux (64-bit)

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.

Although CUPS reports no errors, the PostScript version does not trigger the printer to print anything.

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.”

Restricted stapling is acceptable for personal use, but definitely not for bulk printing as applied in print rooms.


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.

CQue DEB Driver v4.0.1

File version v4.0.1
Release date 23 October 2018
Operating system Linux (64-bit)

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.”

We used the PostScript version for our tests.


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.

technote/ppd/canon-ir-adv-8285.txt · Last modified: 2019/04/24 14:49 by rijk