[Openicc] Linux printing

Kai-Uwe Behrmann ku.b at gmx.de
Wed Feb 29 00:39:38 PST 2012


Am 28.02.12, 22:43 -0700 schrieb Chris Murphy:
> On Feb 28, 2012, at 5:56 PM, Graeme Gill wrote:
>> Chris Murphy wrote:
>>> Nope. There are a number of tools that are specifically designed to fix this problem.
>>> Professionals use professional software, and this is in any number of pre-press capable
>>> applications on the market. Brute force hammers like this one in a RIP have a tendency to be
>>> turned on and left on. The problem is the file, not the RIP's interpretation of the file.
>>
>> It's not your prerogative to decide how I set up my RIP.

>> If you want to turn such a thing on in YOUR RIP, feel free,
>> but don't think you have some right to dictate my options.

There is a direction visible in many UI designs, that default behaviour 
is sane and non specialised users get not trapped.
Correct behaviour should be easy and the default and not harder than 
applying non standard tricks. For you and other specialists there 
could still be ways to do expert things. But thats merely a question of 
appropriately hiding these options from innocient users.

> I have no ability to dictate a single thing. I'm not a developer, let 
> alone a Ghostscript developer. I can't take away a feature that's 
> already in the thing, anymore than I can compel PNG viewers to honor 
> chrm and gama chunks (not that it really matters anymore now anyway now 
> that they use ICC profiles).
>
> I'm only opining that the RIP shouldn't even have the feature in the 
> first place, the problem is elsewhere. It was not a good idea to spend 
> the engineering resources on it. But some downstream customer who makes 
> a pre-press RIP, looking to sell a feature to hapless pre-press 
> companies they do not need, asks for upstream to fix the problem for the 
> whiny customer instead of being informed and telling them the proper way 
> to fix the PDF.

Agreed.

Generally the recommended default behaviour of applications and services 
should be standards conform as long as these standards make sense.
Specifically I see no sign that PDF/X-3 is faulty or out of scope 
especially for Linux and as we've read for osX printing.

Michael,
do you see a chance, that a good tutorial on how to strip a OutputIntent 
from a PDF using Ghostscript tools would help your customers in doing the 
expert things they want and maintaining a standards conforming behaviour 
for naive users inside Ghostscript?

kind regards
Kai-Uwe


More information about the openicc mailing list