Language monitor is usually the best choice (but not a perfect one, especially if your printer already has one) for this sort of filtering.
But a print processor will cover most of the bases for a RAW printer- did you actually tell the spooler to use YOUR print processor on the printer (by default it will use the default winprint print processor for RAW- at last, that’s how it used to work…). You can use the advanced settings on the printer in the printers folder to change the print processor- easiest way to experiment with this sort of thing.
As far as the first statement, IIRC, Print processors don’t get separator pages is the primary difference. One of many architectural anomalies (IMO) that make me glad to have printing safely behind me.
Thanks for the suggestion.
I will take a look on the Language monitor code from the DDK.
Also, is it possible to have a chain of print processors or language
monitors? I don’t want to replace any of the current drivers with my own,
but rather have the ability to pass on the data to the original one and only
act as a pure filter.
Thanks,
Itzik
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Monday, December 18, 2006 7:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Printer filters
Language monitor is usually the best choice (but not a perfect one,
especially if your printer already has one) for this sort of filtering.
But a print processor will cover most of the bases for a RAW printer- did
you actually tell the spooler to use YOUR print processor on the printer (by
default it will use the default winprint print processor for RAW- at last,
that’s how it used to work…). You can use the advanced settings on the
printer in the printers folder to change the print processor- easiest way to
experiment with this sort of thing.
As far as the first statement, IIRC, Print processors don’t get separator
pages is the primary difference. One of many architectural anomalies (IMO)
that make me glad to have printing safely behind me.
Possible- maybe. Realistically, no (purely my opinion). I’ve experimented with this a few times (for instance, I wrote [or more accurately, started and got partially done] such a print processor and port monitor as testing aids when I was responsible for testing the print subsystem on NT 3.1- but in those days, I still had ambition, optimism, and a lot of youthful energy). If you aren’t too extreme, and are only trying to modify the output stream- probably, but the buffering issues might get to be a problem, particularly when cancellation, pause and resume come into play.
But a warning, again- I’ve been out of the world of printing for close to 5 wonderful years- I spent most of mine in it pushing the boundaries everywhere I could, and most of what I have to show for it is an endless supply of rants and horror stories (I shall spare you any more of either). Other opinions are certainly plausible (or I’m as endlessly optimistic as I sometimes suspect)…
The general idea, though, is that it wasn’t designed with this usage in mind, so don’t assume that it will just work, or that if you made it work today, it will work that way tomorrow… The hacker’s dilemma.