Signaling printer status from a filter

[Josh Mathis]

Ok, that helps. Now the million-dollar question - for new development, 
would it make sense to use simple backchannel read/write in the main 
rendering filter (rastertoxxx), or would it be more forward-thinking to 
move all status stuff into the port monitor right now, anticipating a 
periodic update module for status monitoring?

-Josh

Michael Sweet wrote:
> Josh Mathis wrote:
>> Hello Mike,
>>
>> Thanks for the information. As I was doing some more reading about 
>> these new functions in v1.2, I a little about a port monitor. This 
>> sounds like it would be even more ideal, since it can do periodic 
>> polling in the background, rather than just during a print job when 
>> the other filter is active, giving me momentary rather than historic 
>> status. Is that correct? It seems like an idea similar to the Language 
>> Monitor in Windows printing. I was unable to find any documentation 
>> about the port monitor, other than it exists.
> 
> No, the port monitor (currently) only runs when there is a job.  Its
> primary purpose is to allow driver developers to support printer-
> specific protocol stuff regardless of the type of file that is
> printed.  In the future, it may get used for periodic status updates
> for a queue...
> 
>> Basically, what is the port monitor? Are there any samples available?
>> How do they interact with the core CUPS system and other 
>> filters/backends? Any information would help.
> 
> Look in the monitor subdirectory - you'll find the two standard
> port monitors, bcp and tbcp, which are used to support binary
> encoding for PostScript printers.  In the future the tbcp port
> monitor will also get updated to do page accounting and status
> monitoring...
>