[Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Till Kamppeter]

[ Re-posting to the lists ]

Petrie, Glen wrote:
> Till,
> 
> What applications do you consider Not-Page Oriented.  I am having a hard thinking of an application that does not render it content to a paper-size (page-size).   
>

I mean applications where the user is not already working on the actual 
page size. These are for example e-mail clients, browsers, plain text 
editors, where text is simply a sequence of data and flowing somehow 
into the view area (screen, paper, ...). So for printing the document 
visible on the screen or for changing the paper size the text has to be 
flown again into the new paper size. Also photo viewers/editors are not 
page oriented. Photos are bitmaps of XxY pixels without defined absolute 
size. they have to get scaled into the requested ensemble of paper size, 
margins, and resolution.

For these applications a "document paper size" does not exist, so in 
contrary to page-oriented applications (OpenOffice.org, Scribus, PDF 
viewer, ...) "Document paper size(s)" should not be added to the paper 
size option (or grayed out). The page size has to be selected in the 
printing dialog (and the default taken from CUPS) and the app has to 
regenerate the preview data if the page size and/or the margins are 
changed in the printing dialog.

In the case of the page-oriented applications the preview does not need 
to be regenrated by the app when the page size or another printer or 
printing-system option is changed.

In any case the app needs to deliver a regenerated preview if an 
application-specific option changes, as for these options the 
application knows best what happens.

> Web pages must format the print-content before calling the print dialog.  If I look at Firefox in Ubuntu it supports page-set within the application; so it would format content before calling the print dialog.  The text editor in Ubuntu has page-set.  
>

Here the print content needs to be re-formatted if the user changes the 
page size.

> I don't think of the print dialog formatting generic print content like text.  I don't think of the application involved in a bi-directional communication with the print dialog.
>

Yes, the print dialog can only do things like scaling, rotating, N-up, 
color transformation, not re-flowing text for example. In such a case 
the app has to regenerate the preview.


> Can you help me with some specific examples.
> 

As I said, page size change when the app ius a browser or a plain text 
editor for example.

>> The application has to do the first step, creating a PDF from the
>> document, to have an app-independent format which the dialog
>> understands. To the PDF transformations can get applied.
> 
> I don't completely understand this.  Why do applications have to create PDF.  If the application is a photo application, it can send print content that is just an image.  If the application is a text application is can sent text (which has been laid out in the page-size required).

Not necessarily PDF but a format which the printer dialog understands. 
For the preview (at least a non-scalable one as Peter considers as 
sufficient) one could perhaps even take only a bitmap format like PNG. I 
was simply thinking in the format which the app usually sends to CUPS 
(PostScript or PDF) and also that we are now going towards PDF as job 
format. Theoretically one could let the dialog accept anything what CUPS 
accepts and let the "cupsfilter" command convert it to a format used by 
the preview (PDF or PNG), but this is probably an additional slowing 
factor. So the easiest is to standardize on a format, like PDF. One 
could let the app generate low-quality PDF for previews and high-quality 
PDF for printing.

> 
> Or are you saying that all drivers must accept/process PDF.
> 

Drivers only need to accept a format which CUPS can generate from the 
input data. Usually they accept PostScript and PDF (Ghostscript-based 
drivers) or CUPS Raster (CUPS Raster drivers). CUPS converts PostScript 
and PDF to the driver's input format.

> Or since Linux does not have a single gdi, that you are simply making all print content be in a single format.
> 

This is the idea. It is easier for the dialog and faster to process if 
it gets only one data format. PDF is the most universal one. Also note 
that there can be daemon-less CUPS clients, so CUPS is not always 
available for converting incoming documents on the client.

> I confused.
> 
> If I have a photo app that wants to print an image. The steps are
> 
> 1. app creates a pdf instantiation of the image
> 2. send pdf to print dialog
> 3. send pdf to CUPS
> 4. CUPS sends pdf to GhostScript to render
> 5. Ghostscript creates an image
> 6. Image is sent to a printer driver 
> 

The image created in 5. is not the same format as the image coming from 
the app. The app sends JPG or PNG, in 5. PCL, ESC/P 2, or CUPS Raster is 
created.

> Versus  
> 1. app sends image to print dialog
> 2. print dialog display image (as preview)
> 3. send image to CUPS
> 4. Image sent to print driver.
> 

So if all apps send images this would make sense, but apps like 
OpenOffice.org or Firefox would preferably send PDF. So the dialog would 
get much more complex if we make it capable of all formats which CUPS 
can convert. So standardizing on one format simplifies the 
implementation of the dialog a lot.

> My point is that not all drivers support PDF.  I think rendering to PDF and then de-rendering by Ghostscript may produce artifacts.
> 
> What if we define acceptable print formats: sRGB-Image, simple text, formatted text, PS, PDF, ???, ???, html-print, ????, ????
>

Up to now all apps have produced PostScript for print jobs. This was not 
perfect as PostScript gave to many liberties to application programmers 
(it is a programming language) which made page management (N-up, 
selected pages, ...) break very often. So we agreed on PDF to solve this 
problem. In general, we have one standard print job format. CUPS is 
converting everything to this standard format (currently PostScript, 
with the extra filters from OP Japan PDF), running the page management 
(pstops or pdftopdf filter), and passing the job ont to Ghostscript. 
Ghostscript understands both PostScript and PDF, so it does not matter 
which format arrives here.

You are now suggesting that the apps can send a wide range of formats 
(ideally the full range of formats which the stock CUPS package 
accepts). This would change the internal (not UI) design of the dialog 
(and the apps) vastly. Apps like text editors or image viewers could 
then internally "save into the print queue" and so delegate all the 
formatting for printing the file to the dialog. The dialog would need to 
use CUPS filters to find out how the printout will look like (or even 
reimplement them and then the maintainer has to hunt after each little 
change in CUPS).

It would be much easier to implement and much more reliable if the 
dialog supports one standardized format like PDF.

    Till