xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Thinking about color
Date Fri, 18 Jun 2010 10:49:35 GMT
Hi Jeremias,

Jeremias Maerki <dev@jeremias-maerki.ch> wrote on 06/15/2010 02:02:25 PM:

> if you haven't seen it, yet, I've started to write down some notes on
> handling color on the Wiki which applies to both Batik and FOP:
> http://wiki.apache.org/xmlgraphics/ColorHandling

        I don't have a lot to say about the actual implementation, and I
think you did a good job of pointing out the major issues.  I would 
like to emphasize a few points.  First I think the ability to provide
multiple (ordered) fallbacks would be extremely useful in a print
context.  In the context of a document targeting a specific output it's
not so useful, but for things like Logo's (which companies get very
picky about the spot colors of) I am certain that in lots of cases people
would want to specify the sRGB (for screen), CMYK (for generic print) and
probably a Pantone (or some similar named spot color), perhaps hexachrome
etc...

        Second I think the most important feature of the implementation is
that it should make it easy to carry the extra color names through the
processing.  Ideally it would also avoid 'rasterizing' those colors until
absolutely necessary (i.e. for gradients, etc).  I'll say that avoiding
rasterization is in general _really_ hard (and often doesn't actually buy
you anything at the end), so it may not be worth it.

        On Tints I think the intention in SVG was to use opacity.  It 
think
this is a decent way to handle it and I think it simplifies the color 
stuff
a bit (a spot color maps to one sRGB color).  Obviously you could view it 
as
an opaque color as well, but I think I like modeling it as opacity.

        Another related issue (more for SVG than FOP perhaps) is the color 
space
that rendering operations should take place in.  SVG 1.2 had a new 
property
"rendering-color-space":
        
http://www.w3.org/TR/2004/WD-SVG12-20040318/#controlling-color-space

        This was primarily intended for extended photographic color 
spaces,
so I'm not certain how useful it would be for print contexts.

> I'm especially hoping for Thomas to chime in since
> her works for a color-phile company. ;-)
  ^^^ -> he ;)

        I hope the above helps.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message