[cups.general] Difference CUPS <-> Windows Spooler

[Stefan Monnier]

>>> With CUPS, an application will send either a PDF or PostScript file
>>> which is spooled in a temporary file (/var/spool/cups/dNNNNN-NNN)
>>> before printing - that is the main source of delay with large print
>>> files.
>> 
>> And this delay seems unrelated to the location and coupling of the
>> printer driver.  The issue is that CUPS decides to wait until
>> (/var/spool/cups/dNNNNN-NNN) is fully written before passing it to the
>> next filter instead of piping it directly while it gets written.
>> 
>> Is cupsd going to ever get the equivalent of gcc's "-pipe" option?

> No, never.

> While some file formats can be read from a stream, most cannot.  In

I don't know enough about cups internals, but from what I can tell it
mostly take pdf/ps as input and spits out raw-printer-data, all 3 could
be streamed just fine last time I checked.

> addition, we need to have some portion of the print data to identify
> the file type as most apps do not specify the document format, so we
> auto-type based on the contents.  Even then, if we streamed the
> incoming print data to the first filter and that filter needed random
> access to the print data, the filter would just copy it to a temporary
> file.  Finally, we'd still need to save the incoming print data to a
> spool file in case the print job did not succeed, so for many file
> formats we'd end up using twice the disk space and bandwidth with no
> improvement in print speed.

Huh?  If you told me that it would require too many changes to existing
code, I would take your word for it.  But claiming it can't be
worthwhile, on purely theoretical grounds, is hard to agree with.

I for one would be happy to use twice as much disk space or even network
bandwidth so that my documents start printing more quickly.

And if you structure your code accordingly *from the start*, then it's
not difficult to use a system where you can stream everywhere, and those
filters that need to peek at the beginning of the file to recognize its
content can peek just fine, and those that need random access or that
need to store the thing on disk for some other reason can do it as well.
It's not that hard.  And it does not require more disk space or network
bandwidth than what we use now.


        Stefan