Filter - backend communication example? - Significant progress

[Paul Newall]

> > Michael Sweet wrote:
> > > OK, if you are wrapping your driver in Foomatic you're going to run into
> > > problems like these. Real CUPS drivers should NEVER use Foomatic, which is
> > > just (and should remain) a wrapper for existing Ghostscript drivers and
> > > tries to support multiple spoolers (not just CUPS) which means it has
> > > trouble supporting all of the CUPS printing functionality.
> > >
> > > ___________________________________________________
> > > Michael Sweet, Senior Printing System Engineer
> >
> > I think what is needed is that the backend flushes the output to the
> > printer, but the fflush(stdout) in the filter only flushes the pending stuff
> > to the backend only (if the filter is wrapped by foomatic or not).
> >
> > Helge
>
> My filter is only wrapped in foomatic because my starting point was an existing driver which was foomatic, and I would have got nowhere with the project without that headstart. So maybe I'll try and move away from foomatic now.
>
> Helge makes the crucial point, I need the backend to send a short command packet to the printer, so that I can either read the reply (or just delay long enough to let the reply happen) before I send the print data.
>
> Paul Newall
Update 6 feb:
Progress!  With a new ppd file (made using ppdc) and no foomatic:
*cupsFilter: "application/vnd.cups-raster 50 /usr/bin/myminifilter"
I managed to send the printer command packet before the print data, and read the reply in the back channel.
So, provided I can get the actual print data right without foomatic, I'll be home and dry.
Thank you for all the hints so far.
Paul Newall