Re: [Printing-architecture] high delay while printing

On 11/12/2023 17:12, Michael Sweet via Printing-architecture wrote:
> 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.
> 

So slow printing speed can also be caused by the printer failing on the 
PDF and then CUPS sending Raster, but this should be easily visible in 
CUPS' error_log (in debug mode). This should also be checked. Perhaps a 
certain application's PDF (or pdftopdf's output) is always failing on a 
printer and CUPS retries with Raster ...

    Till