[Openicc] What is exactly needed: Embedded Profile in CUPS raster !!
lists at colorremedies.com
Thu Jun 2 19:48:39 PDT 2011
On Jun 2, 2011, at 4:19 AM, Richard Hughes wrote:
> On 2 June 2011 10:58, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> I dont say " Choose Profile -> Implies Printer Settings paradigm" should
>> be the only one. Its just important to have in the toolbox.
> In my opinion it's fundamentally flawed. An ICC profile is not a
> user-visible preset, it's just an implementation detail of the color
I would not be bothered by seeing direct access to them vanish entirely. All I care about as a user are results. All I care about as an expert user is an architecture that is straightforward enough, and properly documented enough, that I can customize it with custom profiles, and associate them to the proper driver settings.
Otherwise, I don't need to directly choose ICC profiles at all. They are merely a means to an end. ICC is a highly consequentialist workflow. I don't understand excessive amount of deontological or virtue ethics being applied to ICC workflow, which suggest that somehow the user must regularly touch or have access to the actual ICC profile in order for it to be either an ICC workflow or a legitimate workflow. If it turns out that way - fine, no different than today's workflows. But I refuse the premise that this is the only way to look at it, at least on Linux.
What if the driver Media Types were simply a means of choosing a behind-the-scenes sRGB to deviceN device-link profile? (or sRGB to RGB, or sRGB to CMYK, or Adobe RGB to CMYK - whatever the combination would necessarily be that produce the best out of box experience that the driver manufacturer/bundler is willing to produce).
More information about the openicc