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

[Leonard Rosenthol]

On Oct 7, 2008, at 5:04 PM, Graeme Gill wrote:

> Leonard Rosenthol wrote:
>
>> If the PDF in question is compliant with any of the ISO PDF "subset
>> standards" (PDF/X, PDF/A or PDF/E), then a conforming reader (aka
>> rasterizer) is REQUIRED to process the embedded OutputIntent and  
>> you can
>> NOT do any substitution...
>>
>> If the PDF is just a "generic PDF", then according to ISO 32000 (ISO
>> PDF 1.7), the conforming reader may ignore the OutputIntent and/or
>> substitute...
>
> I don't think there is any point in getting carried away with such
> standards if it doesn't make sense in a particular situation,
> or following with such slavishness that you end up not producing
> what the user actually wants.

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


> I haven't got a copy of the ISO standards, so it's a bit hard
> to comment,

	Might be worth a read then, to avoid this type of discussion in the  
future...


> but it makes no sense to me that something like
> PDF/X, which is aimed at being a pre-press interchange format,
> and therefore will probably be created remote from the point
> it is RIPed, possibly weeks ahead of it being printed,
> should have any knowledge of the actual output device characteristics,

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


> *unless* it is being used in a manner in which it specifies the output
> space (ie. it specifies a standard industry press condition that
> the press is to be adjusted to).

	The PDF/X-1a variant allows you to specify an actual characterization  
data set (eg. TR001) instead of a real ICC profile - but the industry  
has found that to be extremely unreliable so it isn't recommend for  
X-1a and isn't supported in X-2, X-3, X-4 or X-5.


> I have my own thoughts as to how well this type of arrangement
> works (ie. most standard industry press conditions are
> fairly loose in a colorimetric sense), but this type
> of usage is not really something that is going to be applicable
> to printing to home or office printers,

	I wasn't putting forth a position about whether any of the subset  
standards were appropriate for Linux printing...I was simply stating  
some facts about the various standards (including ISO 32000, which  
WILL be supported).


> and even some of
> the smart press operators don't operate this way - they
> may RIP the document to the industry standard profile,
> but then re-process it with a device link to match
> it to their actual press colorspace.
>

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


> Another thing to keep in mind is that a PDF/X capable proofing
> device that uses (say) and inkjet printer is not going to
> follow such a rule

	If it does not - then it is NOT a conforming PDF/X device...


> - it is going to emulate the printing
> press it is setup to emulate, because that is what the
> user wants it to do. To do anything else would defeat the
> purposes of it being a proofer!
>


	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.

Leonard