[Openicc] GoSoC 2011: CPD and ... Mike Sweet workflow

[Jan-Peter Homann]

Am 12.05.11 05:51, wrote Michael Sweet:
> I am still of the opinion that controls in the print dialog are the 
> wrong approach - you go through significant effort to print a target, 
> wait some amount of time for the target print to stabilize, then 
> generate a profile from that target. This isn't a one-off process, and 
> you have (very likely) carefully chosen print settings when printing 
> the target. Not associating those settings with the profile will lead 
> to frustration since you will get bad output if the settings don't 
> match the profile.
Jan-Peter
Associating driver settings with printer profiles is a must !
My preferred solution to reach this, is to integrate the drivers setting 
via ICC dict type directly into the ICC profile.

In the concept at 
http://www.freedesktop.org/wiki/OpenIcc/ColorMangedPrintingPath
I use the term "ICC-driversetting" for such a combination.

Such approach is not only targeted to make profiling by the enduser more 
reliable. Much more important is, that the exchange and installation of 
ICC-profiles with embedded driver settings is very much simplified.

As ICC profile and driver settings are one file, this solution is more 
foolproof than the current cupsICC approach, where the matching 
information from profile to driver settings is stored in an independent 
file.

Especially downloading and managing ICC-profiles with integrated driver 
setting valid for the same type of general setting like e.g. 
"MyPrinter.CMYK.Glossypaper.720DpI" can be handled more transparent and 
is easier to be automated. The GUI interface in the print chooser 
application could be generated by parsing the settings of the installed 
ICC-driver settings, which the user has may downloaded from different 
sources.
ICC-driver settings valid for the same global setting 
"MyPrinter.CMYK.Glossypaper.720DpI" would be further qualified through e.g.
- GlossypaperVendorA
- GlossypaperVendorB


In comparison, cupsICC works nice with static PPDs and pre installed set 
of profiles matching the PPD.
But it is quite tricky to imagine a solution, where endusers can 
download ICC profiles from different sources for general settting and 
handle




> The workflow I would like to see is this:
>
> 1. The profiling app handles printing targets, reading targets, generating profiles, and registering profiles with their associated settings (call the combination a "preset" for lack of a better word).  The same kind of application could create new presets using existing profiles (i.e. this is where you would be able to choose an alternate profile, even if it wasn't qualified for use with the settings you want...)
Jan-Peter
Sure we can extend a profiling app with such functionalities. But we 
also could implement it in the "expert options" of a high end printer 
driver and call intermediately a profiling application.

> 2. The print dialog allows the user to select presets. When no preset is chosen, the print dialog will choose a profile based on the vendor rules.
Jan-Peter
agreed
> 3. The printing system and/or color management system provide API to query and store preset information. Ideally this API allows for user, system, network, and vendor presets.
>
Jan-Peter
This could easily reached, when the "ICC-driversettings" are stored in 
different folders:
user, system, network, and vendor presets

-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de