[Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question
Hal V. Engel
hvengel at astound.net
Thu Apr 23 20:22:13 PDT 2009
On Thursday 23 April 2009 11:56:44 am Petrie, Glen wrote:
> 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).
I would also argue that PDF is great for image formats as well. For example
it will facilitate color management and also help with correct page formating
(IE the user only wants to use the top or bottom half of the page for this
> Can we support at least one image format or have a way for the filers
> that process PDF to not alter the original images.
The problem is that current drivers do not handle images correctly at least
not without some external help. For example none of the current drivers does
color management and this must be done someplace upstream from the driver.
> 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.
Yes but the image embedded in the PDF is an unaltered JPG or PNG or TIFF...
file. The PDF is a container and the image is NOT altered when it is embedded
in the PDF. But there are necessary steps that will take place in #5 that are
currently NOT happening.
> 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
Dithering and half toning should not be happening at this stage. The only
transformation that should be happening at this stage is application of the
correct ICC profiles to target the print device. This is "changing the
colors" but it is a necessary step for getting correct results that can not be
avoided unless the user does not care about color accuracy and only then if
the user is only dealing with simple images or documents that are already in
the devices generic color space. After all if the driver expects images to be
RGB and the user sends a CMY(K) image to CUPS the color will have to be
changed at some point along the way. It seems logical that the software doing
this would use the images embedded CMY(K) profile and the printers RGB profile
to do the transformation correctly rather than using some generic CMYK to RGB
transform unless it had no other choice. The image(s) and other objects in
the PDF file should have embedded profile(s) and CUPS should pass the correct
printer profile to the pdftoraster filter based on the cupsICCProfile settings
in the PPD file. Images without embedded profiles can be handled in a more
generic way (IE. using default image profiles) but in that case the user
apparently does not care about color correctness.
The color management step has to occur somewhere and this is the logical place
for it to happen. In addition, this is one of the intended purposes of PDF
and I know of no current printer drivers that do this. The only way to avoid
this and satisfy the color management community is to make all of the printer
drivers handle the color transformations or to find another system wide
location where this happens (if not #5 or the printer drivers then where?).
If you are ready to add color management to your printer drivers and you can
convince all of the other vendors to do the same then I am fine with that.
But I don't think that is even a remote possibility. On the other hand the
PDF CM solution is being worked on right now and should be usable, at least
for testing, in the not too distant future. When this happens users using
your drivers will end up with CM without you doing anything if they are
sending PDFs to CUPS. In the long run this will benefit everyone.
> and, then, the printer-driver dithers and performs
> color-to-ink conversion
This is where dithering and half toning belong and the color management
transformation that takes place in the pdftoraster filter should target the
color and tonal characteristics that result from the driver doing these
things. And of course only the printer driver can handle the color to ink
processing, forgetting for the moment that this could also be handled with
deviceN printer profiles if the driver had deviceN support like the gutenprint
> you have high risk of creating artifacts in the
> final print.
Only if your assumptions are correct and I don't think all of them are.
> 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....)
This is probably correct for some applications but I think there are two sets
of exceptions and these exceptions cover a wide range of applications.
1. For some tool sets like Qt it is a fairly simple thing to create a PDF
document as the output when using the printer context. So this means that
this is a non-issue for KDE/Qt applications and there this may also be true
for some other tool sets.
2. Many applications already support exporting PDF files. OpenOffice is an
example and I think this is true for many other applications that require high
quality output. Even if the tool set they use does not support PDF as a
printer context like Qt it should be fairly simple for these applications to
use their PDF export code as part of the print work flow.
So OpenOffice is not be a good example for supporting Glen's argument but his
point may be more applicable to firefox and some other applications. At the
Open Printing Summit a significant part of one session was about issues with
apps not handling printing correctly or in a consistent way. Isn't this one
more thing to consider as part of that list of issues?
> > 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.
But this makes things for CUPS more complex. For example, setting up things
on the CPD side to color manage a PDF based preview using a color management
aware GhostScript or poppler would be fairly easy. In fact once there is a
color management aware way to render PDF files the code needed to make the CPD
do color managed previews is almost trivial (at most 20 lines of code) and
almost mandatory to have the rendering work correctly. I have played with
the poppler Qt demo app along with the CM code that was added to poppler a few
months ago. It took perhaps 20 or 30 lines of code to add the CM hooks to the
poppler Qt4 wrapper library which completed the Qt4 interface for this
functionality and then it took all of 14 lines of code to make the Qt4 demo
app color manage PDFs to the display and most of that was XOrg related code to
get the display profile to setup the transform.
But to do a color managed preview using the CUPS pipeline requires that CUPS
to get the display profile otherwise it has no way to know how to create the
needed color management transforms. The profile could conceivably be passed
to CUPS by the application or the CPD but there are issues with this. CUPS
will not use a profile that is not logically installed in the
<prefix>/share/cups/profiles directory of the CUPS server for security reasons
(at least this was the case - if I am wrong about this please correct me).
Since the application would need to pass the XOrg _ICC_PROFILE atom there is
no way currently to pass this to CUPS and even is this were possible CUPS
would reject it because it in not located in <prefix>/share/cups/profiles
since the _ICC_PROFILE atom is a memory blob.
More information about the Printing-architecture