[Gs-devel] Re: Possible approach to RasterOps in pdfwrite
stefan at artifex.com
Fri Jun 22 08:46:19 PDT 2001
"L. Peter Deutsch" wrote:
> > Two passes of the input stream is tough if you allow stdin.
> Good point.
> > This could have an early out for the pdf path, first non-paint rop stops
> > the high level pdf generation.
> Yup, good idea.
> > This may fit into the pcl server loop where multiple devices are allowed,
> > not sure about where to put the tee in postscript, or in the pdfwrite
> > device. Could do a tee device I suppose.
> Well.... It seems to me that this issue applies to any input language that
> supports RasterOp (currently PCL5 and PCL XL), and to any high-level output
> device that doesn't support RasterOp, including PostScript (pswrite), PDF
> (pdfwrite), and customer devices. So that seems to suggest building support
> for it outside any particular device or interpreter.
> On the other hand, a tee device per se may not be needed. Recall that a
> high-level output device always has the option of handing off an operation
> to another device, whether or not the HL device does anything itself. In
> other words, maybe the tee-ing function is simple enough that it can be
> built into each high-level device that needs it, with some guidance in
Since two different output files are created this seems like a natural
I was under the impression that the high level device could hand off the
operation but thought the destination would be the same.
More information about the gs-devel