[Openicc] colord 0.1.0 released!

Hal V. Engel hvengel at gmail.com
Sun Jan 16 15:59:04 PST 2011 

On Sunday, January 16, 2011 02:54:52 pm Leonard Rosenthol wrote:
> 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

This I do not know since I am not one of those working on the libraries that 
handle the rasterization although I have submitted some CM related patches for 
poppler.  I suspect that in the near term Ghostscript will have the more 
complete implementation.  With a little searching on the web I found that GS 
9.0 was released on Sept 17, 2010 and from the release announcement I see the 
following:

"This release includes a move to an ICC-based color rendering workflow.
The design allows easy integration of 3rd party color management modules
(CMMs) and management of DeviceN and spot source colors with ICC
profiles as well as with non-ICC proprietary methods. The default CMM is
the well known littleCMS. Postscript color objects and non-ICC CIE-based
PDF color spaces are converted to equivalent ICC profiles enabling
complete color management for all color spaces by an ICC-based CMM. New
command line options enable the specification of gray, rgb and cmyk
default ICC profiles as well as output device ICC profiles. The new work
flow provides performance improvements in the rendering of images,
shadings and transparencies. In addition, the color conversions are
designed to work efficiently in multithreaded display list (c-list)
rendering through the use of a shared link cache. Finally, proper ICC
based rendering now occurs for ALL XPS objects including Named colors,
N-Channel colors and images with internally embedded ICC profiles."

There are numerous (PDF) documents on the web that cover the CM architecture 
of GS 9.0.  But a quick search of these does not indicate which specific PDF 
standards are supported. 

The primary architect for the CM GS work is Dr. Michael Vrhel who works for 
Artifex the GS vendor.  In the past he has posted to this list and may still 
keep an eye on it.  Perhaps he can answer your questions.

I see that my distro has GS 9.0 as a test version with 8.71 as the stable 
version.  So it it is probably uncommon for distros to have GS 9.0 installed 
at this time.

Hal

> 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/47ec7068/attachment-0001.htm>

More information about the openicc mailing list