[Openicc] profile-configuration, application, CUPS, Ghostscript, Gutenprint

Hal V Engel hvengel at astound.net
Thu Apr 21 02:45:03 EST 2005


On Tuesday 19 April 2005 05:16 pm, Robert L Krawitz wrote:
snip
>
> So are you advocating doing the color management in CUPS, and just
> having the linearization done in Gutenprint?  In that case, we need a
> 16-bit path between CUPS and Gutenprint (which I gather is on the way).
>

I am not convinced that this is the best way to do this.  But we are only 
weeks away from seeing a beta version of CUPS with most of the basic 
functionality to implement this.  

There are other options that could result in a more flexible and perhaps 
better overall result.  But as everyone here knows the devil is in the 
details and if all of the other parts of the printer work flow were properly 
designed and perhaps with a few adjustments to how CUPS will handle CM it 
could come very close to the flexibility of other possible approaches.  So I 
think we need to consider the CUPS approach as a major contender.  I also 
think we need to think about how this will mature over time  and how CM 
functionality will be phased in.  If it is decided that long term CUPS is not 
the right approach it still may be the best approach to use until the better 
long term solution can be implemented.


snip

>
> What about the Print plugin generating raw printer-specific data?  In
> that case, presumably the color management has to take place in the
> plugin?

This is another possible approach that I am open to.  It is a variation on the 
app doing the CM work but it makes it accessable to all apps not just CM 
aware apps.  It also places it close to the user which could have both good 
and bad points.   I am used to doing CM at the application level because none 
of the current systems I run have a properly functioning CMS at the system 
level.  That is I am currently forced to do this at the application level.  
All of the current user interfaces for this are easy enough for experts and 
well train users but are beyond casual users.  Perhaps with a well thought 
out design the plug in approach could avoid these problems.   Again the devil 
is in the details and we need to settle on our approach before we can delve 
into the details deep enough to know for sure.



More information about the openicc mailing list