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!!).<div> </div><div>As always, if I can help in any way (short of coding :), don't hesitate to ask!</div><div> </div><div>Leonard Rosenthol</div><div>PDF Architect</div><div>Adobe Systems</div><div> <div class="gmail_quote"> On Sun, Jan 16, 2011 at 4:35 PM, Hal V. Engel <<a href="mailto:hvengel@gmail.com">hvengel@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">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?) </div>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? <div class="im"> > > Where to apply the color transformation from source profile to printer > profile ? > - colord ? </div>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. <div class="im"> > > Where is the rendering intent from source to printer profile specified ? > - colord ? > - CUPS ? > - OS ? > - Printer driver ? </div>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. <div class="im"> > > What kind of data format is supported to be colormanaged in the printing > stream ? > - raster only > - PDF ? </div>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. <div class="im"> > > If PDF, where are the color transformations for all PDF content parts > applied ? </div>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. <div class="im"> > > 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 ? </div>Good questions. <div class="im"> > > 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 <a href="http://gitorious.org/cups-colord" target="_blank">http://gitorious.org/cups-colord</a> 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 <a href="http://gitorious.org/colord" target="_blank">http://gitorious.org/colord</a> -- 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: > > <a href="http://gitorious.org/colord/master/blobs/master/doc/screenshot-devices.pn" target="_blank">http://gitorious.org/colord/master/blobs/master/doc/screenshot-devices.pn</a> </div>> > g -- note the admin tool is designed for developers and programmers, <div><div></div><div class="h5">> > *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 > > <a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a> > > <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a> _______________________________________________ openicc mailing list <a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a> </div></div></blockquote></div> </div>