Greetings List, I have recently joined - and am quite interested in the current conversation. As some of you may know, the ICC has a Workflow WG and we are currently working on writing down system level requirements for color management -  intentionally not of current implementations but rather "what it should be." Jan-Peter's comments point out some of the issues with color management in systems today. >Actually, we have four possibilities to apply and use profiles >during the printing process: > >- colormanagement in the application >- colormanagement with an ICC to CSA/CRD conversion during Ripping >- colormanagement as CUPS-Filter on rasterized data >- colormanagement as part of the printer-driver e.g. gutenprint Also in earlier posts I saw discussions about metadata carried with the content file, profiles carried with or referenced from the content file, etc. I have been thinking about this for some time - and the color space dependent policy approach does not appear robust to handle the variety of workflows and use cases that do exist and need to exist - even though I agree that such policy approaches are all we have to work with today.   Unfortunately, the caveat of  "if they know what they want, and if they organize their workflow properly" is large enough to drive a truck through. The current failures and unexpected results with mixed color type object documents are often due to incompatible 'policy' assumptions at various points in workflows and distributed image paths. What is needed to get beyond the limitations of color space dependent policies - and is becoming at least conceivably practical - is metadata that records what has been done to color objects - and is carried with those color objects. It is a fact that color management can and does occur in all of the above functional areas in a workflow.  It is a fact that in functional area X it is impossible to know the correct next color management operation without some information about what was done before - even if you know the color encoding. FYI - refer to 'image state' related papers on the ICC website and in ISO 22028. The equation should be: "what was done before" + "what the user wants to accomplish" => "small number of good options" In some cases the 'small number of good options' is one - in which case the user does not have to pick anything after having indicated what they want to accomplish. So for example: caseA: A digital camera image (initially encoded in camRGB) is converted to a working space-WS (e.g., LAB or a wide gamut RGB working space) using a combination of a  V4 camRGB profile - perceptual rendering intent - and a WS color space profile - relative colorimetric rendering intent.   In the near future (with new V4 profiles) - that will mean that the image in WS has been color-rendered to the ISO print-referred reference medium gamut.   caseB: On the other hand, if a digital camera image (initially encoded in camRGB) is converted to WS using a combination of a  V4 camRGB profile - relative colorimetric rendering intent - and a WS color space profile - relative colorimetric rendering intent -- then the image will still be referenced to the camRGB tbd~monitor shaped gamut. So -- the user wants to print to a wide gamut printer - if case A -- probably the relative colorimetric rendering intent of the printer profile will give good results. If case B - you will need to use the perceptual rendering intent of that printer profile. Note that - it sounds from the example as though V4 is adding complexity - this is not the case. Before version 4 and PRMG - the rendering conditions resulting from various profiles and their rendering intents were less predictable and so did not lend themselves to "do next" policies. So - actually - the policies can become: given the image state, cm history, and encoding - plus - what the user wants to do (in terms of the characteristics of the destination and certain preference aspects)  - recommend '2 -- N' number of options -or- just do the one right thing. The GUI presents the results of the under-the-hood policy assessment. I hope the above is not too far off topic.  If it is possible to move in the direction of such metadata, it seems practically conceivable to encode such metadata in something like xml, for example. Such file formats as VDX, and PDF now support such xml metadata - and there are probably others? Also, certain job control - such as JDF - allows for xml extensions. Regards, Ann McCarthy Chair, ICC Workflow WG Chair, ICC Developer Conference '05 Research Engineer, Imaging Sciences Lexmark International, Inc.