Re: [Printing-architecture] high delay while printing

Michael Sweet <[email protected]> Mon, 11 Dec 2023 11:12:45 -0500
Newsgroups dev.linux.lists.printing-architecture
Message-ID <[email protected]>
Zdenek,

> On Dec 11, 2023, at 3:53 AM, Zdenek Dohnal <[email protected]> wrote:
> ...
> So but even without possible bugs, it is a matter of choice - PDF printing is faster than raster, but sometimes you get issues. Raster is slower, but worked for me till now when PDF failed.
> 
> In the past I have tried to pass 'document-format' to the print to enforce the output format I would like to have, but it is not among job-settable-attributes.
> 
> @Mike, do you think supporting switching final format would possible/useful?

OK, so AirPrint (which is the spec that drove this; the same is true for IPP Everywhere) uses attributes (document-format-supported, pdf-*-supported) and job-state-reasons keywords ('document-format-error' and 'document-format-unprintable') to drive whether PDF is used for a job.

The preference is always PDF, because regardless of any speed concerns it is the most capable of producing optimal output for a printer (dynamic resolution features, color management, font hinting, etc.)  This functionality has been in place since the original AirPrint release in 2010, and we should not second guess the printer or the protocol.

*If* the PDF file is too large (pdf-k-octets-supported tells you this), uses unsupported PDF features (pdf-features-supported tells you what versions of PDF the printer supports), or the printer reports a problem with the PDF file (via the job-state-reasons keywords), then the Client (re)submits the job as raster (URF/Apple Raster for AirPrint, PWG Raster for IPP Everywhere/Mopria/Wi-Fi Direct).  The file size issue is easy to check and CUPS already does this.  The supported PDF versions are less of an issue today since PDF isn't going through as much churn today as 10-15 years ago.  But if a printer isn't able to print a particular PDF file you get the "document-format-unprintable" keyword and can automatically re-submit as raster.

On the question of speed, Apple/PWG Raster is almost always deflated (gzip'd) on the way to the printer, and the formats were designed to allow printers to quickly process and print the data.  I did a white paper on this in 2011:

    https://ftp.pwg.org/pub/pwg/ipp/whitepaper/RasterAnalysis-20110922.pdf

CUPS Raster v2 is PWG Raster.  Apple Raster uses the same compression codec (just smaller file/page headers) so the analysis is the same. From the conclusions:

The best combination seems to be CUPS Raster Version 2 with LZ77 which has low CPU and memory requirements with excellent overall performance. For extremely limited clients and servers CUPS Raster Version 2 provides extremely low CPU and memory requirements with good overall performance.

For the sample documents rendered at 300 PPI, CUPS Raster Version 2 can easily provide 18 pages per minute over Wi-Fi in color and and about 2 pages per minute over DSL. Adding LZ77 basically doubles the potential print speed to 32 pages per minute over Wi-Fi and 4 pages per minute over DSL.

(Wi-Fi in this case would have probably been 300Mbit/sec 802.11n...)

WRT print speed, Apple/PWG Raster *might* be printed more slowly on high end printers due to the extra processing they do in general, but those printers also will support PDF and *that* will print more quickly.  The challenge is the low-to-mid end printers with PDF support because they can print PDF documents with text very quickly but throw in images or gradients and then raster is faster.  There is really no easy way to know, unfortunately...

________________________
Michael Sweet