[Openicc] Linux printing

Chris Murphy lists at colorremedies.com
Tue Feb 28 11:36:12 PST 2012


On Feb 28, 2012, at 10:25 AM, Michael Vrhel wrote:

> 
> On Tue, Feb 28, 2012 at 9:08 AM, Chris Murphy <lists at colorremedies.com> wrote:
>> For what it's worth, the idea of overriding embedded profiles in a document is a big problem. If the wrong source profile is embedded, the PDF needs to print like crap, and the offending user or application that produced the PDF needs to fix their error.
> 
> The fact is that the world is a big place and there are software RIP vendors that use Ghostscript in their products and they need to have this capability.

This properly belongs in pre-press software, which in effect fixes the problem in the PDF. This is how it was done in the PostScript days too - either the original document or the PostScript was "fixed". Screwing up RIPs or their settings, to fix screwed up documents, is double screwed-up.

>   It is an option that one has available and requires a special command line option to invoke.  In its vanilla calling form, Ghostscript makes use of all the embedded ICC profiles in PDF.

Understood but we've been down this road numerous times in the past. There's always someone in the chain looking to pass the buck of responsibility to someone else. The problem is clearly with the PDF, that's where the tools to fix them need to be better developed. If we fix this with some big override substitution switch, we have rendered a major aspect of PDF workflows broken with a very big hammer and next to no granularity for control at the RIP stage.

> 
> 
> My comment on your analogy is to say that if one doesn't know the proper way to use a tool and fails to RTFM then you deserve what you get, which is cut and run over :) .

If the PDF is produced incorrectly, and the creator (user or developer of the app that produces the PDF) don't know what they're doing, they deserve what they get. Cut and run over.

I'd be curious to hear what Leonard Rosenthal thinks of this, from a spec standpoint. If something is /ICCBased, does the spec allow a version compliant interpreter to just ignore this? Let alone substitute something else in its place?

I think that's fraught with peril. It's like someone who sees a person in the freeway playing with razor blades, slamming on their brakes, getting out of their car to go rescue this mentally disordered person. Meanwhile all hell breaks loose on the freeway.

Chris Murphy


More information about the openicc mailing list