🚀 go-pugleaf

Amit Maheshwari wrote:
> We have Xerox DocuPrinter which allows us to store an image on it. This image can be printed along with the contents of the postscript file by including the following command as a part of the postscript file.
> 
> gsave initgraphics (/var/db/forms/inv1.frm.p0001.b.tif) GetTiff grestore
> 
> The report utility generating the postscript file does not allow us to add postscript command at the time of postscript generation. The generated postscript file has mutiple pages and the image needs to be printed on all the pages.
> We have two images to choose from depending on the existance of a specific string on the page.
> To achieve the above the following logic has been used:
> 1> Buffer the contents of individual pages with the help of %%Page.
> 2> Search for existance of the string in the page content buffered by Step1> - so as to ascertain the image that needs to be printed.
> 3> Look for %%EndPageSetup and add the above command after it.
> Pl. suggest if the above approach is appropriate and if there any better solution exists?

This is an appropriate approach.  Depending on your platform, there are 
several ways (places) to do this.

Assuming you are on a Windows box, you can do this by 
replacing/augmenting the Windows print processor part of the Windows 
printing subsystem.  This is a DLL that is designed to be replaceable. 
You need the DDK to do this.

There is a place in the Print Processor code (raw.c, PrintRawJob under 
NT, I don't know what it is under 2K) where the PS that is output from 
the driver is captured and buffered for transmission to the device. 
Presumably, the PS emitter for Oracle might use the same entry point. 
At this point, you can monitor the PS data stream and insert whatever 
you want.

For example, we inserted several DSC comments into the datastream that 
our PS interpreter used for banner page generation and  job accounting. 
  We also use this technique to "fix" special xerox output.  For 
example, DocuSomething outputs Postscript with special DSC comments 
(%%Xrx) at the beginning of the file.  The problem here is that the 
%%Xrx strings come before the %! (the Postscript file identifier) and 
can cause some RIPs to treat the stream as text rather than interpret it 
as PS because the RIP expects the %! as the first characters in the stream.

This could easily be adapted to work for your needs.  The thing you have 
to be careful of is that under Windows "raw" is either Postscript or any 
other printer ready file (like PCL or Epson Escape codes) so you have to 
  make sure that the data stream you are monitoring is actually PS and 
not one of the others.  This is easy enough to code though.

On Linux/Unix, this depends on which printing system you are using. 
CUPS is the easist to modify because the filters are provided under the 
GPL and you can modify them as needed.  You can't sell you changes, but 
you are free to make them and use them.

In this case, the pstops filter would probably be the place to do the 
changes.  You could also define a new filter chain for this particular 
printer and have a custompstops filter as the last filter in the filter 
chain that inserts the requried Postscript code blocks into the stream.

Nick.
www.tentechnologies.com