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

[Kai-Uwe Behrmann]

Am 13.05.2011 07:09, schrieb Jan-Peter Homann:
>
> 3) Do such use cases make it necessary to create PPDs ,where all color
> related entries are stripped off, because the PPD concept is too
> inflexible for the described use cases ?
>
> Jan-Peter:
> Yes, there is no more need for color related options in the PPD file.
> The necessary informations for e.g. rastertogutenprint or
> rastertovendorXY are just read from the ICC-driversettings, which is
> embedded into the rsaterfile send to rastertogutenprint or
> rastertovendorXY

How then to create new calibrations? They would require colour options
to be setable and not stripped away.

> 4) What are the roles of Colormanagement Frameworks like e.g. Oyranos
> or g-c-m / colord when it comes to the creation, exchange, download
> and GUI representation of printing presets with assigned ICC-profiles ?
>
> Jan-Peter:
> So far as I now, both Oyranos and g-c-m / colord have till today not
> published a concept for a direct interface to the printing GUI
> concerning media and color options. (Please correct me, if I´m wrong..)

Hmm
http://www.freedesktop.org/wiki/OpenIcc#PPDcolouring was proposed to
mark colour options as is now supported by Gutenprint and used by the
Oyranos CUPS module,
the ICC meta tag, which among others I reviewed, It's part of the
specification since a while and Oyranos makes extensive use of that
since quite a while,
http://www.oyranos.org/wiki/index.php?title=Device_Settings#Printing for
architecture plans including usability constraints and schemes
a GSoC project to distribute the ICC device profiles over the internet and
an other one to integrate these concepts into CPD, both are mentored by me

What else do you miss?

> We have to consider, that both Oyranos and g-c-m/colord are mainly
> "color management per computer" concepts. Printing is often a "color
> management in the network" process, where e.g.

How does you come to this impression?
I have always prefered existing standards and usage of the actual
systems capabilities.
For Xorg it means that by using Xatoms we preserve network transparency.
For PDF printing by adhering to PDF/X3 we are in theory not bound to a
single host.
These decisions where specially considered to preserve network capabilities.

> printer-settings with assigned ICC-profiles ("ICC-driversettings") are
> installed at the print server side and should be available to all
> printing clients without the need for manual installation.
> On the other hand, we have often the case, that print client and print
> server are running only on one local machine.
> For handling both use cases, I would recommend, that installation and
> management of "ICC-driversettings" are made always at the print server
> side.

While that sounds at first not that bad, it brings a lot of requirements
and makes that not easy except for vendor profiles.

> The role of CPD is to create a GUI for the media and color options
> build from "ICC-driversettings" available at the print server and to
> connect to Oyaranos or g-c-m/colord for communicating the choosen
> "ICC-driversetting.

The server options are generated typically from the PPD. The local
interaction is mainly for per user interaction and ICC settings.

> Oyranos or g-cm-/colord can now communicate the choosen
> "ICC-driversetting" to applications are toolkits, which could use:
> - setting the ICC-driversetting as target profile in pdftoraster
> - calculating a color maged print preview for CPD or inside an
> application with direct pinter interface.

kind regards
Kai-Uwe
-- 
@LGM