[Openicc] colord 0.1.0 released!

Sun Jan 16 14:54:52 PST 2011

If the work is going on with PDF (which, of course, I fully support!), then
will it support only PDF (ISO 32000) or also the various ISO subsets (PDF/A,
PDF/X, etc.)??   As you may know, there are significant differences in how
color management is to take place between the various standards - you can't
treat all PDF as equal!  I hope the team is working on handling all the
various scenarios - especially since the proprietary one in Mac OS X does
not (and I'd love to see that replaced that with one that does!!).

As always, if I can help in any way (short of coding :), don't hesitate to
ask!

Leonard Rosenthol
PDF Architect
Adobe Systems

On Sun, Jan 16, 2011 at 4:35 PM, Hal V. Engel <hvengel at gmail.com> wrote:

> On Sunday, January 16, 2011 12:18:18 pm Jan-Peter Homann wrote:
> > Hello Richard,
> > I´m not a developer, so may be my questions are in some cases a little
> > bit simple:
> >
> > What is a device ?
> > for colormanagement in the printing chain, the printer profile has to be
> > assigned to combination of device/ink, paper and driver settings. How do
> > you solve this with colord / CUPS ? (predifined CUPS queues for every
> > combination of (device/ink, paper and driver settings?)
>
> This is a good question.  When I looked at the colord admin interface
> screen
> shot I didn't see anyway to specify these things and was going to ask about
> it.  Oyranos has had a lot of work done on this part of the printing work
> flow
> and I think that whatever is being done should leverage that work.
>
> In the CUPS ppd it is possible to specify one or more ICC profile to
> printer
> mappings that allows for specifying three things.  By default these are:
>
> Media type (IE. paper type)
> Resolution
> Color Model (RGB, CYMK...)
>
> Color model is mandatory but the other two can be changed to reflect other
> things like specific driver settings (IE. ink settings for example).  I am
> not
> sure why Color Model is mandatory or even needed since this can be
> determined
> by looking at the profile.
>
> Clearly being able to specify three things is not enough and I don't see
> where
> this issue is addressed with colord.  Would it be possible to give us more
> information on this?
>
> >
> > Where to apply the color transformation from source profile to printer
> > profile ?
> > - colord ?
>
> No
>
> > - CUPS ?
>
> This is the current direction and the printing folks are working toward
> this.
> When this is in place it will happen in the CUPS *toraster filters.  The
> pdftoraster filter will be the first one with this capability.
>
> This is how things on OS/X are handled.  The main difference is that on
> OS/X
> there is a proprietary pdftoraster filter that is CM aware.  As a result
> there
> is a need to implement an open source CM aware pdftoraster filter.  This is
> being worked on at this time.
>
> > - OS ?
>
> No
>
> > - Printer driver ?
>
> No
>
> One other possibility is that this could be handled in the CPD on the
> client
> side (IE. early binding).  But there has not been any work done on this
> since
> the current focus is to make the whole CUPS back end CM aware.
>
> >
> > Where is the rendering intent from source to printer profile specified ?
> > - colord ?
> > - CUPS ?
> > - OS ?
> > - Printer driver ?
>
> Since the CUPS work flow is moving to a PDF based system this can be
> specified
> in the PDF file that is passed to CUPS.   This allows for this to be user
> configurable.  Rendering intents will then be applied when the pdftoraster
> filter rasterizes the print job.
>
> >
> > What kind of data format is supported to be colormanaged in the printing
> > stream ?
> > - raster only
> > - PDF ?
>
> PDF
>
> Raster based workflows (photos for example) can be embedded into a PDF on
> the
> client side before sending them to the print server.  This is simple to do
> and
> all of the needed hooks are in place on *nix systems now days.
>
> >
> > If PDF, where are the color transformations for all PDF content parts
> > applied ?
>
> In the CUPS pdftoraster filter.  Currently there are versions of this
> filter
> that use poppler and ghostscript to handle PDF rasterization.  Poppler has
> had
> CM support (using lcms 1) since version 0.12.0 (0.18.0 is about to be
> released) but it is not a very mature implementation yet although it works
> OK.
> Ghostscript has had CM support for some time based on the ArgyllCMS code
> base
> and is being worked on to make this more complete and more flexible.  When
> this
> work is complete it will have very advanced CM support that will allow for
> high levels of concurrency and will allow for pluggable CM back ends (IE.
> it
> should be possible to create a plugin for any CM like ArgyllCMS or ACE for
> example).  The current work on Ghostscript is based on an LCMS plugin which
> will be the default CM.
>
> >
> > Control slug possible ?
> > Is there any way to read, the current colord settings for a CUPS queue,
> > to create a control slug on the print out, to document the settings from
> > which the print has been created ?
>
> Good questions.
>
> >
> > Best regards
> > Jan-Peter
> >
> > Am 13.01.11 13:29, schrieb Richard Hughes:
> > > First, some background: colord is a project I've been working on since
> > > Christmas.
> > >
> > > It is a simple system daemon that will be used by GCM and CUPS to
> > > manage per-system device-profile mapping.
> > >
> > > If you want to try it out with CUPS right now, you'll have to use our
> > > development tree http://gitorious.org/cups-colord and be sure to
> > > switch to the 'icc' branch. When we've got all the different options
> > > and overrides worked out we'll of course push the patchset back to
> > > CUPS upstream. Tim Waugh has been doing most of the CUPS work, whilst
> > > I've been working on the colord project.
> > >
> > > colord works a lot like colorsync on OSX, so the CUPS changes are
> > > really quite small.
> > >
> > > Checkout the code from http://gitorious.org/colord -- test it, and try
> > > to break it. The included cd-self-test program gives you some examples
> > > of what we're testing already. Tim has also built the cups-icc patch
> > > into Fedora rawhide, which might be an easier way for some people
> > > rather than to build the whole of CUPS.
> > >
> > > If you're only interested in pretty things, there's a screenshot of
> > > the admin tool here:
> > >
> http://gitorious.org/colord/master/blobs/master/doc/screenshot-devices.pn
> > > g -- note the admin tool is designed for developers and programmers,
> > > *not* end users :-)
> > >
> > > Comments (and patches!) welcome, thanks.
> > >
> > > Richard.
> > >
> > > Version 0.1.0
> > > ~~~~~~~~~~~~~
> > > Released: 2011-01-13
> > >
> > > Notes:
> > >   - Colord is a simple system activated daemon that maps devices to
> color
> > >
> > >     profiles.
> > >
> > >   - It is used by gnome-color-manager for CUPS integration and is also
> > >
> > >     used when there are no users logged in.
> > >
> > >   - The only real user at the moment is CUPS, but GNOME Color Manager
> > >
> > >     will start depending on colord when it is included in most
> mainstream
> > >     distributions.
> > >
> > >   - The DBus interface is not set in stone, and the libcolord library
> > >
> > >     will have new API added to it as required. If colord needs to break
> > >     public API at this stage for a specific use case, it will.
> > >
> > >   - The persistent storage code is not written yet, but that will come
> > >
> > >     with the next colord version.
> > >
> > > New Features:
> > >   - Add a 'Kind' attribute to the device objects (Richard Hughes)
> > >   - Add a libcolord shared library that can be used in the client tools
> > >
> > > (Richard Hughes)
> > >
> > >   - Add an example spec file (Richard Hughes)
> > >   - Add a simple colormgr man page (Richard Hughes)
> > >   - Add a simple GTK test GUI for testing the DBus interfaces (Richard
> > >   Hughes) - Add a simple script to create a test device (Richard
> Hughes)
> > >   - Add basic DBus interface (Richard Hughes)
> > >   - Add code for the DeleteDevice method (Richard Hughes)
> > >   - Add DeleteProfile() on the main interface (Richard Hughes)
> > >   - Add GetProfileForQualifier() code (Richard Hughes)
> > >   - Add MakeProfileDefault() implementation to CdDevice (Richard
> Hughes)
> > >   - Add qualifiers to profiles (Richard Hughes)
> > >   - Allow clients to set properties on the objects using SetProperty
> > >
> > > (Richard Hughes)
> > >
> > >   - Expose the device created time (Richard Hughes)
> > >   - Fixed typo in ColorManager API description (Tim Waugh)
> > >   - Open the profile using lcms2 after we set the profile filename
> > >
> > > (Richard Hughes)
> > >
> > >   - Provide a method to assign an ICC profile to a profile object
> > >
> > > (Richard Hughes)
> > >
> > >   - Provide methods for mapping the device ID to the object path
> (Richard
> > >   Hughes) - Use seporate PolicyKit authorisations for each action type
> > >   (Richard Hughes)
> > >
> > > Richard.
> > > _______________________________________________
> > > openicc mailing list
> > > openicc at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/openicc
> _______________________________________________
> 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/20110116/1470e9a8/attachment-0001.htm>