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

[edmund ronald]

Yes, but in the same way profiles are very static and some apps need to be
able to dynamically create gamut mappings and render into devicespace.

Edmund

On Fri, May 13, 2011 at 8:48 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:

> Am 13.05.2011 11:46, schrieb Jan-Peter Homann:
> > Comments inline
> >
> > Am 13.05.11 16:35, schrieb Kai-Uwe Behrmann:
> >> Am 13.05.2011 07:09, schrieb Jan-Peter Homann:
> >>> 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#Printingfor
> >> 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?
> >
> > Jan-Peter
> > So far as I understand the mentioned documents, the Oyranos workflow
> > is based on the PPDs describing the available settings for the printer.
> > In the printing GUI (e.g. CPD) the PPD is parsed and the aviailable
> > options are presented to the end user.
>
> To actual my knowledge, this is all what can be obtained from the print
> configuration through CUPS.
>
> > Frm my experience, the PPD concept is a very static concept and it is
> > very hard to implement a workflow, where the use can download and
> > install ICC-printer profiles with assigned driver settings and sees
> > the result instantly in the printing GUI (e.g. CPD)
>
> We will just rely on the PPD for obtaining enough meta data and possibly
> adapt the PPD options to match the actual selected ICC profile.
>
> >>> 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.
> >>
> >
> > Jan-Peter
> > I currently see not a concept for Oyranos, if driver settings and
> > printer profiles are updated on print server application, that this
> > information can be routed to all Oaranos instances on clients for the
> > print server.
>
> Oyranos can have system settings for all users on a local host or a
> local network. The internet repository is targeted at sharing worldwide.
>
> >>> 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.
> >>
> >
> > Jan-Peter
> > If it works with vendor profiles / settings, it should work in the
> > same way for profiles / setting which are installed later on the print
> > server.
>
> This would need editing the CUPS server side PPD.
>
> > So far as I understand the IPP concepts from PWG, we already have a
> > dafted standard how a print server commicates the installed profiles
> > and settings to a client without the usage of a PPD.
>
> reads good
>
> >>> 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.
> > Jan-Peter
> > I want to get rid of the PPDs for color and media settings, because I
> > think they are not flexible enough
>
> Having the spool PDF completely self contained would be really great.
>
> kind regards
> Kai-Uwe
> --
> @LGM
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110513/8ec7d221/attachment.html>