On Mar 25, 2006, at 6:00 PM, Alexandre Prokoudine wrote:

I've heard about upcoming support for color management via LittleCMS, but I'm not quite sure how you can have everything in place having no support for mentioned above colorspaces in SVG spec.

Sure, we have 4 types of rendering intent in SVG 1.1 (+ auto), but according to the spec "The source profile is the sRGB color space." At the same time the spec says "'rendering-intent' is applicable primarily to color profiles corresponding to CMYK color spaces.".

Well...

First of all, Marti has pointed out that base use of LittleCMS only requires 3 function calls. And actual correct display is orthogonal to the rest of the effort.

all we need to do at first is change from

"fill: #ff0000;" to "fill:#ff0000 icc-color(myRGB,0.35294,0,0);" or "fill:#ff0000 icc-color(fooPrinterCMYK01, 0.5, 0.0, .25, .75);"

Oh, and a L*a*b profile is one of the built-in ones. Here's some code snippets from their examples to show how some of it may work:

----------------------------------------- hsRGB = cmsCreate_sRGBProfile(); hLab = cmsCreateLabProfile()

xform = cmsCreateTransform(hSRGB, TYPE_RGB_DBL, hLab, TYPE_Lab_DBL, INTENT_PERCEPTUAL, cmsFLAGS_NOTPRECALC); ...

double RGB[3]; cmsCIELab Lab;

RGB[0] = 0.1; RGB[1] = 0.2 RGB[2] = 0.3; cmsDoTransform(xform, RGB, &Lab, 1); -----------------------------------------

At one point, a transform call like that will be used to get sRGB representations of colors specified in other spaces. Then a transform like that will be done from sRGB to display-specific. Placed images will be another location to hook in a proper transform, but that's about it. And... for a large portion of people going to print, being able to specify the icc-color() of everything is more important then even how things display on screen. A solid Pantone color, for example, needs to match the paint chip the designer is holding in his hand, not the RGB glow coming from the monitor. Preserving names for spot colors will allow for that.

As we move on, then we can add better support for named colors, dealing with things like better UI interaction for spot or process colors. But the main thing is that one can just add the "icc-color()" part onto all color specifications of an SVG and things will "work out" fairly well. Data will be transformed from your accurate color specifications for display purposes, but if you have a proper display profile in the standard places, things will look close. Then when your data goes into Scribus, you'll be able to get accurate output, as Inkscape will preserve all the detailed icc-color() specifications of things, be it CIEL*a*b, named spot colors, some specific CMYK profile, etc.

Now, SVG itself does have a limitation of doing all interpolation in sRGB... however for most people's needs just being able to specify colors accurately is the key. As SVG 1.2 adds more, we might look into some enhancements, but the near term needs for most people who need to go to print will be served fairly well. And being able to specify spot colors and have those organized in a way that's very friendly for Scribus to do separations of will cover more.

Oh, and among other things, the planned approach will allow CMYK colors to be used and adjusted in the color pickers while preserving K. Little niceties like that will help the majority of people who've been asking for features to support more than just "web work".