[Openicc] GoSoC 2011: CPD and ... Mike Sweet workflow
homann at colormanagement.de
Wed May 11 23:53:21 PDT 2011
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.
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
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
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
ICC-driver settings valid for the same global setting
"MyPrinter.CMYK.Glossypaper.720DpI" would be further qualified through e.g.
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
> 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...)
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.
> 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.
This could easily reached, when the "ICC-driversettings" are stored in
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
More information about the openicc