Intercepting the fd for printing

[David Chappell]

On Fri, 2002-01-25 at 12:59, Michael Sweet wrote:
> Moody, Todd wrote:
> 
> > Hello all-
> > 
> > I am looking at integrating Samba 2.2.2  into an embedded printing device,
> > where limited spooling space for print jobs exists.  Samba's model of
> > spooling an entire job before submitting it to the printing interface is
> > going to be a problem in this environment.
> > 
> > I am hoping, instead, to intercept the fd of the spool file and substitute
> > it with a pipe to another process that will submit the print data for
> > printing on the fly.

> On a related note, this opens up some possible improvements for the
> CUPS support as well, since you can stream print data to an IPP
> server (via HTTP chunking, transparent to SAMBA/any app), and you
> can also pipe into lp/lpr without trouble.
> 
> *However*, I think one issue is that pipes can block, which might
> cause problems?  Also, SMB printing is inherently file-based,
> right? :)

I looked into this once.  I was hoping to eliminate the Samba spool file
so that the spooler could operate in less disk space.  However the
structure of the LanMAN API would seem to make this difficult.  As I
recall, the client creates a spool file, providing very little
information, and later makes other calls to fill in information such as
number of copies and job title.  The client can do this right away or it
can do it just before it closes the file.  So, I think the spooler would
have to support extensive modification of the options of already-spooled
jobs.  At the time, my spooler (PPR) didn't support this at all.  Now it
does, at least to a degree, so I am interested in re-examining this.