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

Petrie, Glen glen.petrie at eitc.epson.com
Thu Apr 23 11:56:44 PDT 2009

I tried to explain differently my concerns and hope this long discussion
continues.   Please, I am not trying being stubborn; I just want to help
create a solution that is best for the user, the application and driver
developers (oops, forgot CUPS).  So help me understand some of your
choices and understand some of my suggestions.

This discussion is really hard by email, this would be a good one for a

This note has three issues; namely,

1. What to do when the application page-size does not match the print
2. Who renders the preview
3. Should applications support just PDF print format.

1. What to do when the application page-size does not match the print

I believe it is becoming clearer that the key to this on going
discussion is how we are thinking about the relationship between 

Electronic paper-size === Electronic page-size === EPS
  This is set only by the application


Physical paper-size === Printer paper-size ===  PPS
  This is set only by the print dialog

EPS really has/should-have nothing to do with PPS.  I can have an A3 EPS
while the printer only support letter.  This is an issue.  This issue
needs to be handled by the print-system and shown in the print dialog,
so the user will know what to expect and what to do.

I think examining this issue is something you really need to actually
perform; so I tried it on a Mac and Window using PowerPoint.  In either
system, when the EPS != PPS then the preview show the EPS clipped to the
PPS (I assume the paper-size (PPS) the currently selected printer
reports as the installed paper-size (PPS)).  If the scale-to-fit option
is set; then, the EPS is scaled (maintaining the aspect ratio) to the

Mac's version of PowerPoint also illustrates more about dialog <->
application interaction. (I believe Michael already commented on this
but I will repeat here for completeness).  In the print dialog, you will
not see a paper-size (PPS) option but you will see a button for
page-size (EPS).  When this button is pressed, the print dialog returns
control to the application (powerpoint) and powerpoint shows its dialog
for the page-size (EPS) (this is completely independent of the print
dialog).  The user can change the page-size (EPS) and indeed the
powerpoint pages are reflowed in powerpoint and the powerpoint display
changes.  Unfortunately, control is transferred automatically to the
print dialog and user has to cancel the print dialog to fix any changes
the new page-size (EPS) caused.

----- I don't believe this experience was end-user friendly.  If the
print dialog is not going to have paper-size (PPS), then the user uses
the preview to see what they will get.  Then if the user does not like
what will be printed (scale-to-fit or center-and-clip) then the user
should cancel the print dialog and return to the application to fix
----- If the print dialog shows a paper-size (PPS) option, then the user
still uses the preview to see that they will get.  If the user changes
the paper-size (PPS) then the print-system should scale-to-fit or
center-and-clip the print content (format at EPS) to the paper-size
(PPS).  Otherwise, the user needs to cancel the print dialog and return
to powerpoint to modify things.  This is what I hope is the final choice
for OpenPrinting.

((( An interesting case to consider is when a photo-printer (PhotoSmart,
PictureMate) is the connected printer.  )))

I hope we have been saying the same thing but just in a different way.

??? Do we have a way to support custom paper size (EPS and PPS) ???

2. Who renders the preview

I really do want to push the case where the print-system creates the
preview from the print-content.  It is really the only way for the print
preview to display the best representation (we can do today) that the
printer will actually print.

3. Should applications support just PDF print format.

Till, in general I understand and probably agree with your comments.  

PDF format is great for documents.  There are concerns about have any
filters in the print-chain between photo applications and the
printer-driver (i.e. rendering and re-rendered image).

Can we support at least one image format or have a way for the filers
that process PDF to not alter the original images.  

Till below are some additional comments on your reply

> > 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. 

Doesn't CUPS needs to transform (filter) input data to a format the
driver can accept (image, ps, pdf, ???)!!!

> Usually they accept PostScript and PDF (Ghostscript-based
> drivers) or CUPS Raster (CUPS Raster drivers). 

None of Epson's consumer inkjet printers accept PDF or PS; that why
Ghostscript is needed.  Yes, office printer and high-end printer accept
PS and PDF - is this the only printers we are targeting.

Cups Raster is not really "raster" content; it is better described as a
job-ticket (print-ticket) (actually done at on a page to page if I
remember correctly) with image data attached.  So it really helps
(although increase the processing) in rendering pages (to actual printer

The point is "why the constraints".

> CUPS converts PostScript
> and PDF to the driver's input format.

> >
> > 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
> the app. The app sends JPG or PNG, in 5. PCL, ESC/P 2, or CUPS Raster
> created.

As a vendor supporting photo printing; print vendors may have an issue
with step 5.  If the filters (i.e. Ghostscript) dithers, halftone or
changes the colors and, then, the printer-driver dithers and performs
color-to-ink conversion you have high risk of creating artifacts in the
final print.  Who will the user call or issue a bug report against - the
print vendor.  And the user has a bad experience.

> > 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. 

I bet that neither openoffice nor firefox cares about PDF; what they
prefer is that the GDI they are using supports a printer deviceContext
and they just "display" to the printer deviceContext and deviceContext
generate the print content (image, pdf, ps, cups raster, foo....)

> 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.

Not if the dialog request CUPS to create the preview via it's filters.

> 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. 

Not if the dialog request CUPS to create the preview via it's filters.

More information about the Printing-architecture mailing list