xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Color design snag
Date Mon, 05 Jul 2010 16:40:52 GMT
After re-reading the specs and starting code changes in Batik, I had to
realize that my initial idea for the color infrastructure design is not
quite right. I was assuming that the explicit sRGB fallback is to be
used whenever the actual primary color is not supported. But it's
actually so that a calibrated primary color is always to be used. It is
converted to sRGB (via CIE XYZ) if necessary in which case the explicit
sRGB fallback is not used at all. Only if the associated color profile
is unavailable (and the color can therefore not be calibrated), the sRGB
fallback is used.

I've started to implement it as such in Batik. Only one color instance 
(without any alternatives) is really necessary. And in FOP it would be
the same if not for our two intermediate formats where we have to
serialize the color back to a textual representation. And that means we
have to preserve the sRGB value even though there's only a slim chance
that the sRGB fallback is ever needed (an unavailable color profile will
be a rare event in the FO context).

The concrete problem I have with my initial design idea is that I'd have
to change the code for all non-color-managed output formats to use the
alternatives' derived sRGB colors instead of the main color's sRGB value
which is currently the explicit sRGB fallback. That's obviously not

Remembering Thomas' comments, it does indeed look like the simple list
of alternatives is not very helpful. I end up thinking about priorities
and roles for alternative colors to handle all sorts of combinations and
that is unreasonably complex. Since both SVG and FO don't offer to
specify more than 2 colors (optional primary + sRGB fallback), it
probably doesn't make much sense trying to anticipate what might (!)
come in a future spec. And more, when a calibrated color is available
(be that sRGB, ICC, ICC named (spot) or Lab), it can always be converted
to a close approximation for the required output device (gamut problems
aside). If someone has to cater for different output devices, a
stylesheet can always set different colors. At least for FO, that is the
reasonable thing to do. Maybe less so for SVG since it's more of an
exchange format than FO is. FO is almost always just a short-lived
intermediate format. But even SVG has the ability to be associated with
a stylesheet (CSS or XSLT).

Somehow I end up with a simplified ColorExt without the profile name and
source and without the colorValues array. Just a Color subclass that
adds a float array (or Color instance) for the explicit sRGB fallback.
And that class will only be used by FOP since Batik probably doesn't
need it. That's for most use cases. ColorWithAlternatives with the
ordered list of alternatives is still useful, but only for the cases
where device-specific colors need to be specified. Any color
calculations would be made off the sRGB fallback and output formats
supporting device-specific colors would pick them from the alternatives

That would then be:

class ColorWithAlternatives extends Color {
  Color[] alternativeColors; //may be null
} //located in XGC

class ColorWithFallback extends ColorWithAlternatives {
  float[] (or Color) srgbFallback;
} //located in FOP

Well, the sRGB fallback is essentially an alternative color, too, but
not in the original sense of ColorWithAlternatives where the alternative
colors take precedence over the main color. That's why I started
thinking about roles in the alternative list. Just too complicated.

Just to play through all possibilities:


* sRGB -> use sRGB
* ICC (profile available) -> use ICC color (sRGB calculated from ICC color on demand)
* ICC (profile not available) -> use sRGB fallback
* ICC named (profile available --> use ICC color (sRGB calculated from ICC color on demand)
* ICC named (profile not available) -> use sRGB fallback
* Lab/LCHab -> use Lab color directly (sRGB calculated from Lab color on demand)
* device color -> sRGB is primary color with device color attached to ColorWithAlternatives

Except in the case of device color, ColorWithAlternatives is used with
null as argument for the alternative color array. It is used because of
its advanced equals() method only.


Essentially the same as Batik except that FOP uses ColorWithFallback
instead of ColorWithAlternatives storing the explicit sRGB fallback
exclusively for serializing the color as string value. The sRGB fallback
is not used otherwise.

This is much harder that I thought, as if the color theory is not
already tricky enough by itself. Maybe this is not the most elegant
solution but at least it should work and match the specs. I will rework
the branches in that direction tomorrow. In the meantime, your thoughts
are certainly welcome. I will also update the Wiki in due time.

Jeremias Maerki

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

View raw message