[Printing-japan] [gs-devel] upcoming freeze for the 8.63 release - Make CUPS filters/PPDs PDF ready

[Till Kamppeter]

Mike, Otani-san, WDYT, how should the architecture of the psto... CUPS 
drivers be changed to get working pdfto... or pdlto... CUPS drivers, as 
it seems that one cannot use PostScript options (options which insert 
PostScript code into the data stream) any more?

Probably the driver filter (pdfto... or pdlto...) and also pdftopdf 
should read the options from the 5th argument of the command line and 
then apply them at the right place, for example in the Ghostscript 
command line.

What is the concept here?

    Till

Koji Otani wrote:
> From: Till Kamppeter <till.kamppeter at gmail.com>
> Subject: Re: [Printing-japan] [gs-devel] upcoming freeze for the 8.63 release - Make CUPS filters/PPDs PDF ready
> Date: Fri, 18 Jul 2008 00:22:10 +0200
> Message-ID: <487FC612.1050105 at gmail.com>
> till.kamppeter> 
> till.kamppeter> The insertion of the PostScript code of the PPD CUPS does with the 
> till.kamppeter> pstops filter. When CUPS is used with a PDF printing workflow this 
> till.kamppeter> filter is replaced by the pdftopdf filter from OpenPrinting Japan. 
> till.kamppeter> Otani-san (or anyone else at OP Japan), does the pdftopdf filter somehow 
> till.kamppeter> insert the Postscript code of the options in the PPD file into the PDF 
> till.kamppeter> data stream? Or how should I proceed?
> till.kamppeter> 
> 
> The pdftopdf filter inserts no PostScript code into the PDF data
> stream. It only handles JCL options (such as JCLOpenUI) in the PPD file.
> It should be defined how should we inserts (Job) options into the
> PDF data stream. 
> 
> till.kamppeter> Ralph, can I simply preceed the PDF data stream with the PostScript code 
> till.kamppeter> from the PPD, putting "%!PS-Adobe-3.1" at first, then the code of each 
> till.kamppeter> option, and after that simply the PDF? Or how does it work?
> 
> ---------
> Koji Otani
>