[Openicc] colord 0.1.0 released!

[Leonard Rosenthol]

On Tue, Jan 18, 2011 at 4:15 AM, Alastair M. Robinson <
blackfive at fakenhamweb.co.uk> wrote:

> On 18/01/11 02:46, Leonard Rosenthol wrote:
>
>  EXCEPT that in the case of PDF processing, there is NO SUCH THING as "no
>> color management".  The standard itself goes into detail about how
>> (ICC-based) color management is used as part of the rendering pipeline.
>>  For PDF/X (and PDF/A), this is even more significant.
>>
>
> Hmmmm, that's rather worrying actually.  Is there no "escape hatch" of any
> kind to ensure that, for instance, pure-black items don't get converted to a
> rich black by being run through a needless conversion? Profiling is far from
> the only situation where I need a printer to receive the *exact* CMYK value
> I specified in the application, and not some other CMYK combination that, in
> theory, amounts to the same thing.
>
>
Oh, it is certainly possible to produce documents that are explicitly
targeted to a specific device - that's exactly what PDF/X-1a is all about!
And in a pure PDF/X-1a workflow, you'd get what you want - device specific
values being sent as such to the device.  Only if the "Output Intent" of the
document is different (for some definition of different) than the actual
device profile does it need to be converted.   BUT that also assumes a
CMYK-only PDF/X-1a file - which isn't the norm coming out of your authoring
applications.

In addition, in a more modern PDF workflow, you no longer have PDF/X-1a with
CMYK+Spot colors and no transparency.  You have various color models and
profiles integrated together with the presence of transparency blending -
the end result, PDF/X-4 (for printing).  BUT if you could assume that all
incoming PDFs complied with PDF/X-4, then you could at least have consistent
output since everything is defined for the "output device".

In addition, you have a two pass workflow - first the rasterization of the
PDF AND THEN the printing system - and they don't talk to each other :(.
You need to (as discussed elsewhere in this thread) get much more
information being passed back and forth between the rasterizer and the
printer driver/system.


Leonard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110118/c2de9683/attachment.htm>