[Openicc] [argyllcms] Re: Re: OT: PDF frustration

[Graeme Gill]

Leonard Rosenthol wrote:

>     That's fine - which is why there are various options to choose 
> from.  BUT if a user (or developer or ...) has chosen to use a specific 
> standard, then they had a good reason and it needs to be adhered to.  A 
> LOT of time and effort went into the development of those standards by 
> experts in the industry for which they are built...

Sure, but so what ? They aren't immune from criticism or comment, and I
think I've been involved enough in the practice of creating and selling
printing and proofing systems into the industry to be justified in
offering an opinion on the practicalities of using such standards.

>     So, you have made an ASSUMPTION about the purpose of the 
> OutputIntent that isn't true (though is understandable given the name of 
> the object).  The OutputIntent is really more of an "Output 
> Characterization" - in that it specifies the profile for which the 
> Device dependent colors in the file (of the same number of colorants as 
> the profile) should be considered.  As such, it is more of an "input 
> profile" than an "output profile".

I don't think you're correct here. Page 141: "An array of output intent
dictionaries describing the color characteristics of output devices on
which the document might be rendered". Section 10.10.4 talks about
OutputIntent being to "allow the production process to be customized
to the expected workflow and the specific tools available", and it's clear
from chapter 4 that the way of defining what the DeviceGray/RGB/CMYK spaces
should be, is to specify a default color space. There is no mention
of OutputIntent in this context. I guess you're right that it could
be used in the manner to imply an input device color space specification,
but it seems like a rather obscure way of doing it, and leaves plenty
of room for different results due to different interpretations, particularly
given that there is a list to choose from, and some RIPs may take device
space to mean the actual device space.
In contrast, setting a default color space leaves no room for interpretation.

>     Processing it post-RIP, with a DeviceLink or other profile is just 
> fine...The PDF standards are only concerned about how the original 
> RIPping takes place..once RIPped, you can do whatever you want (rightly 
> or wrongly so, it's your workflow).

It's just a matter of implementation detail though, as to whether such
processing is in RIP or post RIP. A RIP formatting and driving a printer
could be expected to do the whole lot in one hit, minimizing processing
overhead.

>     In the case of proofer - the proofer would first render the colors 
> according to the OutputIntent and then transform to the proofing profile 
> - basicaly turning the OI profile into a "simulation profile".  No muss 
> - no fuss.

Right, exactly the point I was making. So slavishly following the spec.
and transforming to an inkjet profile put in the OutputIntent by a driver
is not what you'd want at all.

Graeme Gill.