[Openicc] Printing Plans GhostScript

[edmund ronald]

I disagree. I vote we subject all apps creating untagged (but not really
device) data to Darwinian selection, and let their maintainers be subjected
to a rain of complaints. In the end a few decent apps with smart responsive
developers will be left standing - the Adobe monopoly shows that having one
app in each niche is amply sufficient.

Edmund

On Tue, Mar 1, 2011 at 8:11 PM, Michael Vrhel <michael.vrhel at artifex.com>wrote:

>   Hal,
>
> I agree, the reality of the world is that there are a lot of bad PDF files
> out there and Ghostscript has to robustly handle the good the bad and the
> ugly. [image: Smile]
>
> Michael
>
>  *From:* Hal V. Engel <hvengel at gmail.com>
> *Sent:* Tuesday, March 01, 2011 9:47 AM
> *To:* openicc at lists.freedesktop.org
> *Subject:* Re: [Openicc] Printing Plans GhostScript
>
>
> On Tuesday, March 01, 2011 02:15:32 AM Kai-Uwe Behrmann wrote:
>
> > Hello Michael,
>
> >
>
> > Am 28.02.11, 22:09 -0800 schrieb Michael Vrhel:
>
> > > Hi Jan-Peter,
>
> > >
>
> > > So yes, ghostscript does apply ICC base color transformations on
>
> > > Postscript files and this is true even for DeviceRGB and DeviceCMYK.
>
> > > I need to add in the interface for rendering intent and black point
>
> > > compensation. That will be coming shortly. In fact, I am also adding in
>
> > > the ability to specify different output profiles for graphics, images,
>
> > > and text as ghostscript keeps track of these objects during rendering,
>
> > > even through transparency blending. The specification for these
>
> > > options is primarily through the CLI but can be made through special
>
> > > configurations.
>
> >
>
> > Would it possible to pass those profiles along the PDF document itself?
>
> >
>
> > > As far as "turning off" transformations for DeviceRGB or DeviceCMYK,
> that
>
> > > will occur in cases where the source and destination profiles are the
>
> > > same.
>
> >
>
> > We came several time to the conclusion that this scheme is not realy
>
> > robust. So we would be happy you could point us to an other mechanism as
>
> > well.
>
>
>
> The reason that this is not robust is that the user app currently has no
> way to specify the source profiles to be used when the GS pdftoraster filter
> is called and no way to know what profile will be used by the print system
> so that it can specify a matching output color space.
>
>
>
> The reason that this whole DeviceXXX thing is an issue is because we have
> so many dumb apps and libraries that use DeviceRGB and DeviceGray for
> objects that really should be taged with either sRGB or an equivalent CalRGB
> tag for RGB images and generic gray ICC profile or a CalGray tag for
> monochrome images. Dealing with these malformed PDFs causes all sorts of
> headaches.
>
>
>
> >
>
> > > The obvious example occurs if I have a document that has an RGB image
> and
>
> > > a CMYK image and I am printing to a CMYK device. In this case, the RGB
>
> > > image will have to be transformed in some manner. That transformation
>
> > > is under your control by specifying the desired default RGB source
>
> > > profile to use. For the CMYK image, if you did not want the data
>
> > > touched, you should make sure that your default CMYK source profile is
>
> > > the same as your destination profile. The CMYK data will then pass
>
> > > through unmolested.
>
> >
>
> > Will adding a OutputIntent to a PDF/X (A/E) be honoured for DeviceXXX
>
> > objects by Ghostscript? Leonard pointed this requirement out [1].
>
> > It could then be used to pass through unmolested Cmyk or DeviceN to a
>
> > according configured printer.
>
>
>
> Why not unmolested RGB and Gray as well? Any app that is smart enough to
> create PDF spool files with the OutputIntent set should be assumed to be
> smart enough to know what it is doing and the PDF spec should be fully
> honered. The issue with assuming a color space for DeviceXXX objects should,
> if possible, be limited to apps that don't know better. At this point there
> do not appear to be any CM dumb apps that can create PDF spool files with
> the OutputIntent set. This is definitiely true for Qt apps that are using
> the standard Qt PDF printing chain.
>
>
>
> The issue here is retargeting. If the print system receives a spool file
> with an OutputIntent that is different from what the system would use
> normally that device and settings what should it do. One of the reasons for
> using DeviceXXX for objects along with an OutputIntent is to allow for
> retargeting. Under those conditions it is assumed that the DeviceXXX objects
> are in the OutputIntent color space. This is to allow for the output to be
> retargeted to a different device if needed using an OutputIntent --> new
> device color space transform for all DeviceXXX objects. This means that
> setting the OutputIntent is also not a robust solution unless there is some
> way for the app creating the spool file to query the system for the devices
> profile so that it can use that for the OutputIntent. This could be done
> using Oyranos or colord but this means that the app creating the PDF needs
> to be not only aware of color but also needs to knwo what printer is being
> targeted and how to get it's default profile for the print mode being used.
>
>
>
> The basic issue always come back to the fact that most of the apps on
> peoples machines are producing malformed PDF files that by default use
> DeviceXXX and do not set the OutputIntent. If we were following the PDF
> spec. and DeviceXXX data would be passed through to the printer unchanged
> with unpredictable results for many apps. In addition, if the DeviceXXX
> objects did not match the color mode of the printer (IE. DeviceRGB but
> printer is a CMYK only or is set to CMYK in CUPS) or if the PDF has more
> than one DeviceXXX type (like DeviceRGB and DeviceGray which is possible
> with the current Qt PDF code) then the print job would fail. The problems is
> users expect stuff to "just work" and following the specification will fail
> for some number of print jobs with most software currently being used. This
> means that we need to do things like get the Qt PDF code fixed to be inline
> with the PDF specification and work at getting good PDF code into other
> libraries that support printing like GTK+. This is going to take some
> effort.
>
>
>
> >
>
> > kind regards
>
> > Kai-Uwe Behrmann
>
>
>
> ------------------------------
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110301/8eed6353/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1041 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110301/8eed6353/attachment.png>