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

Petrie, Glen glen.petrie at eitc.epson.com
Fri Apr 24 11:33:51 PDT 2009


> > ----- If the print dialog shows a paper-size (PPS) option, then the
> > still uses the preview to see that they will get.  If the user
> > 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
> > to powerpoint to modify things.  This is what I hope is the final
> > for OpenPrinting.
> I think we should go this way. But we should have the choice of taking
> the document paper size so that (if the printer is appropriately
> equipped) documents with multiple paper sizes are printed correctly,
> too. One could warn the user if the document contains pages which the
> printer is not capable of doing (which are not in the printer's PPD
> in the range of supported custom sizes if the printer supports custom
> sizes according to the PPD). If a certain paper size is not loaded,
> printer can prompt for it. The warning that the document contains
> which the printer is not capable of, could have buttons to let the
> choose between scale to fit, crop to fit, and print over several

This is great.

> > ==============================================================
> > ==============================================================
> > ==============================================================
> > 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
> > preview to display the best representation (we can do today) that
> > printer will actually print.
> >
> What we do is taking the output geometry from the printer by polling
> PPD from the CUPS server. We will also poll the ICC profile to allow a
> preview of the color reproduction of the printer. CUPS' page
> options and their behavior are known so we can emulate them in the
> preview. Also PPD options with known behavior (like grayscale) we can
> emulate in the preview. So the dialog will display the preview based
> PDF coming from the app.

1. I was not aware that the print preview would be concerned with CM.  I
though of it more as what the print format would be and not on the fine
details like "is this the right blue".  I am confused how this works.  I
would have thought the preview would have to use CM stuff for the
display; I guess the preview could use the reduced gamut of the printer.
But, what will the user do with this knowledge.  The best the user can
do is go back to the calling application.  But, if the calling
application cannot adjust the content to account for the intended
printer; then what.  

2. I thought the major emphasis of the current printing activities was
for the desktop.  I didn't really consider that an individual's desktop
(really the computer) would just have CUPS clients and the CUPS server
would hosted some place else.  In mobile/handheld this may be true. 


> >
> > As a vendor supporting photo printing; print vendors may have an
> > with step 5.  If the filters (i.e. Ghostscript) dithers, halftone or
> > changes the colors and, then, the printer-driver dithers and
> > color-to-ink conversion you have high risk of creating artifacts in
> > final print.  Who will the user call or issue a bug report against -
> > print vendor.  And the user has a bad experience.
> >
> In 5. we get CUPS Raster. This is not yet dithered. The dithering is
> done by the rasterto... driver.

As Ghostscript is the most critical filter here, I would like to verify
this with the Ghostscript folks.

More information about the Printing-architecture mailing list