Data flow through CUPS

[Sebastian James]

> Sebastian James wrote:
> > ...
> > Initially I thought I would change cups-lpd and some raw input
> > programs to spool data in chunks. The filters in this device simple
> > pass the data through to the backends (parallel and usb). This means
> > that the backend is likely to be passed a portion of a printjob,
> > which it'll spool to the printer. There shouldn't be and difficulties
> > with this, should there, as long as the next portion of the job is
> > spooled fairly soon after?
>
> Ok, that sounds like you would be using cups-lpd to provide an
> embedded implementation of LPD, not IPP, right?
>
> In that case, I'd just hack up cups-lpd to read a printcap file
> (or have one hardcoded in the program) which maps queues to UNIX
> devices and does an exclusive open on the port when printing.
> Then you can just write the data files to the port instead of to
> disk...

Basically, that's right, except that there is a need to pass the data through a filter which stores it for processing by an external program (it's a very specific application). Anyway, you're basically right that I just need to hack around with cups-lpd.

> > 2: The filenaming convention of cups data files is d00001-001 for the
> > first print job and d00002-001 for the second job and so on. Under
> > what circumstances does the -001 increment to -002? Initially I
> > thought, "oh must be page number" but how are the filters to know or
> > care what the page number of the print job is? I'd very much
> > appreciate a short explanation of how this works.
>
> cupsd (the IPP server) writes these files in response to requests
> from clients.  They start out as temporary files (0000000, 00000001,
> etc.) and are renamed as needed.  The -001 refers to the first file
> in the job, -002 is the second, and so forth.

Right, I see - the -001 is only used if the files are spooled using IPP.

Anyway, thanks for the help and I'll post any changes I make.

regards,

Seb.