xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Thinking about color
Date Fri, 18 Jun 2010 12:05:11 GMT
Hi Thomas

Thanks a lot for your reply!

On 18.06.2010 12:49:35 thomas.deweese wrote:
> 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...

I think choosing the right color for a certain context is probably the
output handler's job and is probably dependent on configuration if we
ever want to go that far. In that sense, I think the simple list should

>         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.

Right. If the target format supports named colors, for example, they
should be carried through if in any way possible. Only if thing like SVG
filters need to be applied, another color variant needs to be chosen.
But at any rate, people picky about spot colors will avoid the case
where that happens. ;-)

>         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.

That's about what Chris Lilley suggested on the www-svg@w3.org list. I
guess that makes most sense. Still, commercial FO implementations
support it in their proprietary color extensions so we might support it,
too, in FOP at least, since we don't have transparency support in XSL-FO.

>         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

I guess that's going to be a tough one.

>         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 ;)

Sorry, a typo. My fingers are often faster than my eyes. ;-)

>         I hope the above helps.

Absolutely, and I appreciate it.

I'll continue along the lines outlined in the Wiki and probably create a
little branch for XGC until I've got it fully working. I will then
move on to FOP and finally to Batik. Feedback along the way is always

Jeremias Maerki

To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message