[Printing-architecture] Two more PDF CUPS filters: pstopdf and cpdftocps ("PostScript driver")

Till Kamppeter till.kamppeter at gmail.com
Mon Aug 4 10:01:36 PDT 2008


Michael Sweet wrote:
> Till Kamppeter wrote:
>> Hi,
>>
>> to complete the PDF printing workflow there are two more, rather simple
>> CUPS filters needed: pstopdf and cpdftocps.
> 
> Comments in-line.  In short, only pstopdf is needed.
> 
>> pstopdf
>> -------
>>
>> This filter kicks in if a legacy application emits its print jobs in
>> PostScript. I started about something very simple, like the pstoraster
> 
> Since this filter would need to be based on Ghostscript, limit the
> scope of the pstopdf filter to convert application/postscript to
> application/pdf, which can then be filtered through pdftopdf to
> support PDF printers.
> 
> PostScript printers would use pstops.
> 
> Raster printers would use pstoraster plus their raster filter.
> 
> As for getting options from the PostScript data stream, today we
> can embed page size and duplex mode in the PDF document.  Supporting
> other embedded features is not feasible, although applications can
> use the CUPS PS job ticket comments at the top of the file:
> 
>     %!PS-Adobe-3.0
>     %cupsJobTicket: option=value ... option=value
>     %cupsJobTicket: option=value ... option=value
>     %cupsJobTicket: option=value ... option=value
>     ... other PS comments
>     %%EndComments
> 
>> cpdftocps
>> ---------
>>
>> This filter converts application/vnd.cups-pdf to
>> application/vnd.cups-postscript. It runs after the pdftopdf filter to
>> support manufacturer-supplied PostScript printer PPD files without
>  > ...
> 
> This filter is NOT required.  We ALREADY have a pdftops filter that
> takes application/pdf and produces application/ps, which is then run
> through pstops for PostScript printers.  We DO NOT want to have a
> filter for every combination of file formats because it will be a
> maintenance nightmare.
> 

So this would mean that a real PDF workflow (always using the pdftopdf 
filter) would only happen if

- The printer is a PDF printer
- The printer/driver PPD takes exclusively CUPS PDF

In the following cases pdftopdf will be at least be used if the input is 
PDF, an image, or text:

- The printer/driver PPD takes CUPS raster (then we can go through
   pdftopdf + pdftoraster or pstops + pstoraster)
- The printer/driver PPD has cupsFilter lines for both PDF and
   PostScript input (Foomatic 4.0 or OpenPrinting Vector)

In case of PostScript input they would lead to pstops + pstoraster or 
pstops + foomatic-rip filter chain and so they are subject to page 
management problems caused by bad PostScript input.

If we can assume that the pdftops filter produces fully DSC-conforming 
PostScript (Is this the case?), then we solve all page management 
problems if all apps send jobs in PDF, as CUPS takes then care of clean 
PostScript by generating it with the pdftops filter. Then page 
management issues get even solved with current CUPS, without adding all 
the new PDF filters. In addition, apps producing PDF jobs can also not 
raise problems with embedded option settings. They HAVE to send option 
settings as job attributes.

So the most important step to benefit from PDF as standard print job 
format is to make all apps outputting print jobs in PDF instead of in 
PostScript. This solves at least all page management problems and 
reduces the job size. This also leads to a complete PDF workflow if the 
printer or driver understands PDF.

Printers and drivers which accept PDF make up a complete PDF workflow if 
the input data is PDF and so these can make use of the additional PDF 
benefits like more sophisticated graphical elements and color management.

The pstopdf filter should be handled with caution as it can lead to the 
loss of embedded option setting code. So it should have a high cost 
factor to make it only be used in the case that it is really needed, 
like if an application produces PostScript output and the output device 
is PDF-only (and in this case the PDF should not contain embeddable 
PostScript code).

So we will only add the simple Ghostscript-based pstopdf printer. One 
question: Does GhostScript embed the PageSize and Duplex settings 
correctly in the PDF file?

Most important for completing the workflow is that all desktop 
developers, application developers and maintainers of appropriate parts 
in distributions make sure that all applications produce PDF output when 
sending print jobs.

    Till


More information about the Printing-architecture mailing list