Sean,
> On Dec 7, 2020, at 6:55 PM, Sean Kau via ipp <ipp at pwg.org> wrote:
>> I could see a desire to support job-release on lower end printers that wouldn't have enough memory to spool a job. However, I think this is undesirable from a service perspective as this will likely cause a print spooler to hang, waiting forever for the printing to start. However, what do we do if the printer "supports" spooling but the job is too large? This would require similar resolution (unless we reject those jobs).
Typically, if a *document* is too large a printer will return the 'server-error-too-many-documents' or 'server-error-busy' status-code, with 'spool-area-full' in the "printer-state-reasons" attribute. We also have attributes reporting the maximum document size in k-octets (1024 bytes or "kibibytes"): "job-k-octets-supported", "pdf-k-octets-supported", and "jpeg-k-octets-supported" (the latter two were added so that a Client doesn't need to query the printer multiple times for those two popular formats).
If we decide that job release requires spooling support (and I think we should), it might be useful to have EPX require a minimum amount of job spooling space (AirPrint requires 64MiB or 65536 k-octets) for interoperability. Of course, if you have complex PDF documents with multiple embedded high-resolution images the size of the PDF can easily grow beyond 64MiB, but typical office documents are much smaller, e.g., PWG 5108.1-2011 (MFD Model 1.0) is the largest of our specifications and comes in at 10.2MiB for 216 pages...
________________________
Michael Sweet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201208/49725969/attachment.sig>