Hi,
Both offline and online versions of popular russian computers magazin "Computerra" now feature a review of Inkscape written by Sergey Tokarev:
http://www.computerra.ru/online/files/259519/
It looks like he did his best to present most actual and precise information, but unfortunately in some areas he failed (e.g. he stated that Inkscape's developers are already working on support for CMYK and CIE LAB colorspaces :)).
However, Inkscape is rated as best vector graphics editor for Linux that, in case of merging codebase with Xara, will have all chances to be the best free vector graphics editor on all platforms.
Btw, he also wrote that the same guy who introduced support for tablets is working on vector brushes now. Is that true?
Alexandre
On Mar 25, 2006, at 4:30 PM, Alexandre Prokoudine wrote:
It looks like he did his best to present most actual and precise information, but unfortunately in some areas he failed (e.g. he stated that Inkscape's developers are already working on support for CMYK and CIE LAB colorspaces :)).
Actually... he did give you correct information.
:-)
I've even verified our initial support approach with littleCMS's maintainer to be sure we're on the right track.
Also... we've coordintated a bit with the Scribus guys on how we'll go about getting things across properly for a managed workflow between the apps.
However, Inkscape is rated as best vector graphics editor for Linux that, in case of merging codebase with Xara, will have all chances to be the best free vector graphics editor on all platforms.
Perhaps...
But the main thing we got from interactions at LGM is that both Xara and Inkscape have their own space they each occupy, and that for many users both are needed to be around for some time to come.
The good news, though, is that there are no initial barriers between the two, and if anyone chooses to develop for one of the projects, they are welcome to develop for the other also. Not like some theoretical case of 'competition' where if someone works on project Foo, their contributions are conversations are not welcome in project Bar.
On 3/26/06, Jon A. Cruz wrote:
Actually... he did give you correct information.
:-)
I've even verified our initial support approach with littleCMS's maintainer to be sure we're on the right track.
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.".
Alexandre
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".
participants (2)
-
Alexandre Prokoudine
-
Jon A. Cruz