[Openicc] [Per Queue] [GSOC] Making a color assignment in CUPS web interface?

Kai-Uwe Behrmann ku.b at gmx.de
Tue Feb 28 01:06:16 PST 2012


Am 27.02.12, 16:02 -0800 schrieb Michael Sweet:
> On Feb 27, 2012, at 3:07 PM, edmund ronald wrote:
>> Would you support adding the facilities below to CUPS functionality? My impression is that if they were available in the browser interface and via API calls, one could easily transition to color managed printing, at least in the case where the user agrees to use only one set of media settings per print queue.
>>
>>
>> - Load/save the whole PPD and profiles cleanly into and from user space to wherever CUPS like them.
>> - Associate a profile with a queue, possibly by writing the color keywords into the PPD,
>> - Switch of color management for a queue
>>
>>
>> Also, do you think this would be sufficient and provide a decent base for future more sophisticated work?
>
> At the CUPS level it only makes sense to register system-wide profiles in PPDs, pulling them from wherever the platform's CMS wants them. Aside from the web interface, CUPS already has all of the things needed to support this since cupsd will re-register profiles whenever the PPD is updated and you can easily edit a PPD using standard file I/O functions.
>
> As for a web interface, we'd need to work out the details (requirements, locations of files stored by cupsd, what to do for custom media types, etc.) and timeframe (certainly not for CUPS 1.6). I could see this going hand-in-hand with external access to ICC profiles defined in the PPD, which is something else we need to work on. And in the spirit of IPP Everywhere and the new APIs in CUPS 1.6 we would likely not expose this as a PPD feature but as printer capabilities to applications (or just leave it up to the CMS since that is how user and system profiles are chosen today, separate from CUPS...)

As a kind of canonical way, it would be good to have that as a reference.
This work is appreciated.

> In any case, I'd like to see how things work when the colord integration is more widely deployed so we can see really where the gaps are and then design plugs accordingly...

kind regards
Kai-Uwe


More information about the openicc mailing list