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

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

[Till Kamppeter]

Hi,

to complete the PDF printing workflow there are two more, rather simple
CUPS filters needed: pstopdf and cpdftocps.


pstopdf
-------

This filter kicks in if a legacy application emits its print jobs in
PostScript. I started about something very simple, like the pstoraster
and pstopxl wrapper scripts which come with Ghostscript, only that this
wrapper will use "pdfwrite" as output device. This will at least work
for apps which supply the options as job attributes (attributes for the
CUPS library function to submit a job, or command line options for the
"lpr" command).

It is possible and legal that applications supply the options embedded
in the PostScript data stream. For that options to work, the pstopdf
filter needs an extension: It must read the PostScript data stream
before feeding it into Ghostscript for conversion and whenever it finds
a line like

%%BeginFeature: <option>=<value>

to add the key value pair to a JCL header for the output:

pdftopdf jobInfo: <option>=<value>
<option2>=<value2>
...
%PDF-1.3
...

pdftopdf must read this JCL header and pass it through to the next
filter, perhaps interpret some options by itself, like PageSize. Driver
filters like pdftoraster, pdftopvp, pdftoijs, cpdftocps, and
foomatic-rip have to read out these option settings to control the
driver accordingly.

I think this is the only and easiest way in the CUPS architecture to
propagate options which are embedded in PostScript input.

This is a way to get a complete PDF printing workflow (page management 
always through pdftopdf, never through pstops) without regressions (like 
loss of option settings embedded in PostScript data stream). Problem is 
that many of the other filters (all with PDF or CUPS PDF as input 
format) will need to be changed to be able to read out and pass on the 
JCL header with the option settings.

Alternatively, the pstopdf filter can be left out and then PostScript 
input goes its old way through pstops, but these means that page 
management keeps unreliable for legacy applications with PostScript 
printing output and driver PPDs must be made in a way that both PDF and 
PostScript input is possible for a longer time.


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
"cupsFilter" line or legacy PPDs which do not explicitly support the PDF
printing workflow (only one "cupsFilter" line with 
application/vnd.cups-postscript as input format). Therefore we call this 
filter "PostScript driver", as it allows to print on output devices 
which understand only PostScript.

The filter can be a wrapper script around other filters. At first 
pdftops is called with the same command line parameters as they were 
used for calling the cpdftocps script. After that the data is passed 
through pstops, but in the call of pstops we filter all CUPS options out 
of the fifth command line argument (we leave only the PPD options in the 
fifth argument) so that only the PPD options get embedded into the 
PostScript data stream but the page management will not get repeated. 
Otherwise we would get unwished effects like N-up getting N^2-up.

This filter will assure that any legacy PPD file/printer driver can be 
continued to be used with a PDF workflow. This keeps especially print 
queues working which existed before when updating from a 
PostScript-printing-based version of the OS to a PDF-printing-based version.


Anyone wants to code these filters? They are not too complicated scripts 
or they can also be made by rearranging some existing CUPS code.

    Till

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

[Till Kamppeter]

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

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

[Till Kamppeter]

Michael Sweet wrote:
> 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
> 

What does CUPS exactly do when it encounters these %cupsJobTicket: 
comments? Which part of CUPS is handling them? How can one benefit from 
them in a PDF printing workflow (PostScript -> PDF -> pdftopdf -> 
pdftoraster ...)? Do they have to be in the beginning of the PS file or 
can they be anywhere?

    Till

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

[Till Kamppeter]

Michael Sweet wrote:
> Till Kamppeter wrote:
>> Michael Sweet wrote:
>>> 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
>>>
>>
>> What does CUPS exactly do when it encounters these %cupsJobTicket: 
>> comments?
> 
> It adds them as job template attributes (options) for the job.
> 
>  > Which part of CUPS is handling them?
> 
> The scheduler (cupsd) scans application/postscript files for these
> comments.
> 
>  > How can one benefit from
>> them in a PDF printing workflow (PostScript -> PDF -> pdftopdf -> 
>> pdftoraster ...)?
> 
> We could update cupsd to do the same scan for application/pdf;
> PDF supports comments just like PostScript.
>

Good idea, please do it.

>  > Do they have to be in the beginning of the PS file or
>> can they be anywhere?
> 
> They have to be in the initial comment block, after the "%!PS-Adobe"
> line.  The scheduler stops on the first line that does not begin
> with a "%".
> 

Thank you for the info. Did not find anything about that in the 
documentation.

    Till