Re: Named colors in SVG

Thanks for your reply, Chris!

On 15.06.2010 22:08:47 Chris Lilley wrote:
> On Tuesday, June 8, 2010, 2:31:39 PM, Jeremias wrote:
> 
> JM> Hi folks,
> 
> JM> I'm looking into adding support for named colors to Apache Batik and
> JM> I've got a few observations/comments concerning the current working
> JM> draft of SVG Color 1.2
> JM> (http://www.w3.org/TR/2009/WD-SVGColor12-20091001/).
> 
> Jeremias, very happy to hear that you are working in this area.
> 
> JM> --- ICC named color profiles in general
> 
> Some background here
> http://www.colorwiki.com/wiki/The_7_ICC_Profile_Types#Named_Color_Profiles

I stumbled over that during my research. Not very encouraging.

> JM> I've just spent about 3 hours looking around on the internet, trying to
> JM> find example ICC named color profiles or some freely available tool to
> JM> create such color profiles. I haven't found anything. Does anyone have
> JM> something in this direction for me? I'm almost at the point where I have
> JM> to think about writing such a tool myself.
> 
> commercial
> http://www.tglc.com/english/01_1_num_recettes.html
> 
> free
> LittleCMS2 (lcms2)
> http://littlecms2.blogspot.com/
> 
> lcms can build and read such profiles but does not ship with them in the samples area unfortunately.
> 
> swatchbooker reads (now) and writes (in future) ICC named profiles along with other swatch formats
> http://www.selapa.net/swatchbooker/
> 
> 
> sampleicc has some sample code of named icc profiles
> http://sampleicc.sourceforge.net/
> but does not ship  with such samples. The code looks as if it can read and write them.

Thanks for those links. I had found some of them already. I was
surprised, though, to learn about all those different swatch file
formats. A little surprising given that there is an open standard for it.

I'm still thinking that I may actually need to write a little tool to
create an NCP myself, but I'll keep an eye on SwatchBooker which looks
most promising.

> 
> JM> My main goal is to produce PDF. But like PostScript, PDF doesn't support
> JM> ICC named color profiles.
> 
> Really?
> 
> You mean, the latest PDF specification does not? Or an older, but widely implemented PDF spec does not? Or that PDF does but tools do not?

I've checked PDF 1.4 and PDF 32000-1:2008 (aka PDF 1.7). Also, when spot
colors are mentioned the references are to the Separation and DeviceN
color spaces with no apparent link to ICC profiles.

> Copying Leonard Rosenthol <lrosenth@adobe.com> on this email, since he knows far more about PDF than I do and represents Adobe on the ICC committee.

Interesting how Leonard Rosenthol pops up on my radar every now and then.
Last time it was about PDF/A. I'm curious about his input.

> JM>  You have to resort to the "Separation" color
> JM> space which requires a PostScript function which transforms the tint
> JM> value to an alternative color space (be that CMYK, RGB or CIElab).
> 
> I'm not sure separations are the same. Separations are, well, separate;
> they don't interact except on the final printed page. They include
> corrections for blocking and trapping. For separations, the SVG
> 'device-color' concept seems more appropriate.

Well, the Separation color space is what I found in the sample PDF I got
from the print shop where the final documents are going to be printed.
They've got an HP Indigo 5000 and the head of printing set up the named
colors on that machine and just gave me the name I have to use as part
of the Separation color space. So I'm looking to make a connection
between what's available in SVG Color (and XSL 2) and PDF. And on the
way I'm trying to see if I can also support other color spaces.

> JM> So I'm trying to figure out the best way to implement this. In the
> JM> absence of an easy way to create and consume ICC named color profiles,
> JM> it seems easiest to define abstract URIs used on the svg:color-profile
> JM> element to define a set of named colors (defined by some means other
> JM> than an ICC profile which could be considered a hack).
> 
> It is a bit of a hack, yes :) 

But apparently not that far off track if I see that many color swatch
formats. That approach above would simply be another one of those. ;-)

> If you want to support legacy swatch formats, such as
> http://www.selapa.net/couleurs/fileformats.php
>  or create (another) new one (for example to allow easy creation with a
> text editor) then making a tool which reads one or more such formats
> and outputs ICC named profiles looks like the way to go.

It certainly looks that way. But of course, I'd still have to map an NCP
to colors in PDF.

> Two good contacts would be Kai-Uwe Behrmann, who develops the Oyranos and ICC-Examin tools
> http://www.behrmann.name/
> and Marti Maria, lead developer of lcms2
> http://littlecms2.blogspot.com/
> 
> One or other of those would be able to get you started on a tool to
> write named ICC profiles, using their existing libraries to do the
> heavy lifting.

Thanks. However, I have to stay in Java as much as possible. Native
libraries written in C (or such) will complicate matters a lot for
platform dependencies. But the ICC spec is quite understandable so I
should be fine reading and writing those few records necessary for an
NCP. It's just that it costs time which is limited.

> JM> In my particular case I need to support, there's no color profile. The
> JM> print service provider has defined the named color directly on the RIP
> JM> using a mixture of the 6 inks available in the printer. So I just need a
> JM> way to get the color name and an sRGB value (for the tint transform
> JM> function) into the PDF using the "Separation" color space.
> 
> That doesn't sound like named ICC profiles; it sounds like device-n.

Right. I guess it's the other possibility that I get my hands on the
actual device Hexachrome values they determined for that machine and try
it that way. But I actually like the concept of named colors.

> JM> --- tint support
> 
> JM> The PDF and PostScript specifications allow for a "tint" value for
> JM> Separation colors. I was wondering if it made sense to add an optional
> JM> tint value to the icc-named-color function. The spec would then be:
> 
> JM> <fallback> icc-named-color(<name>, <namedColor>[, tint])
> 
> JM> Valid values for the parameter "tint" are in the range 0.0 to 1.0. The
> JM> value 0.0 represents the minimum amount of colorant that can be applied;
> JM> 1.0 represents the maximum. In the absence of the tint parameter, the
> JM> initial value is 1.0.
> 
> JM> Example:
> JM> <circle fill="#8080FF" icc-named-color(MyColors, SpecialBlue, 0.5)"/>
> 
> That is an interesting suggestion. However, would the result be an
> actual, colorimetrically defined color? Or would it be a recipie, which
> only results in a visible color on the output device?
> 
> In other words if SpecialBlue has LAAB coordinates Lb ab wb and the
> current white has LAB coordinates Lw aw bw, is there an equation that
> gives the LAB coordinates of thre 50% tint? Or does that require press
> characterisation?

You lost me a bit on the terms (I'm still learning). But essentially,
that's the problem I've also stumbled across: how to calculate the Lab
or XYZ coordinates for values between the spot color and the white point?
I really don't know just yet. I've simply seen that PDF offers that tint
value when using a Separation color space. I don't need it myself, but I
found no equivalent (other than the alpha/transparency/opacity value) in
the color functions of the SVG Color WD. Maybe the tint is simply used
for half-toning. But on modern digital printers the matter is different
since the colors are still mixed for spot colors.

> This for example does result in a color:
> 
> <circle fill="#8080FF" icc-named-color(MyColors, SpecialBlue)" 
>   fill-opacity="0.5"/>

I have no idea if it's the same as tint. Transparency is usually handled
in PDF in a different place (i.e. in addition to the tint). Anyway, this
is really out of my league right now and I'm trying to catch up.

> JM> --- typos
> 
> JM> BTW, there's a little typo in the existing example: the closing
> JM> paranthesis is missing.
> 
> Thanks, will fix.
> 
> JM> Thanks,
> JM> Jeremias Maerki (not yet a color specialist)
> 
> 
> 
> 
> 
> 
> -- 
>  Chris Lilley                    mailto:chris@w3.org
>  Technical Director, Interaction Domain
>  W3C Graphics Activity Lead
>  Co-Chair, W3C Hypertext CG
> 



Thanks a lot!
Jeremias Maerki

Received on Wednesday, 16 June 2010 07:54:13 UTC