====== Canon iR-ADV 8285 Driver for Linux ====== This is a test of "Canon imageRUNNER ADVANCE 8285 PRO" Linux Driver as downloaded from the [[https://www.canon-europe.com/support/products/imagerunner/imagerunner-advance-8285-pro.aspx?type=drivers&language=EN&os=Linux%20(64-bit)|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. 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. | The PostScript is produced by a cups-filters filtering chain and ''pstoufr2cpca'' renders it into a form suitable to be sent to the printer.| ==== Punch ==== Punching is done correctly. ==== Staple ==== 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 ''lpr''command. 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. ==== Booklet ==== 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 [[https://wiki.linuxfoundation.org/openprinting/pdf_as_standard_print_job_format|Linux Foundation Wiki]]. ==== Bugs ==== 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. ==== Performance ==== 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 - [[http://www.pdfill.com/|PDFill]] PDF&Image Writer | 1.4 | 0:59 | | | MS Word - Print - [[http://www.pdfforge.org/pdfcreator|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. ==== Quality ==== 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. ==== Staple ==== 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. | ==== Quality ==== 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. | ==== Staple ==== 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. ==== Performance ==== CUPS PostScript filtering is straightforward and faster that UFR2 filtering. But, execution on the printer is slower than the UFR PDL. ==== Quality ==== Print quality is good. The UFR driver problem with some graphics printed solid black, does not occur.