xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Status of the new color infrastructure
Date Wed, 07 Jul 2010 20:00:03 GMT
On 07.07.2010 20:26:15 Vincent Hennebert wrote:
> Jeremias Maerki wrote:
> > On 01.07.2010 13:22:35 Vincent Hennebert wrote:
> <snip/>
> >> Also, I very much doubt that that class should extend Color, but this 
> >> is
> >> another topic.
> > 
> > IMO, there's one very VERY good reason for extending it from Color: An
> > implementation that doesn't support any of the color alternatives can
> > just live with the sRGB fallback which is also the color that both
> > XSL-FO and SVG specify to be the general fallback. No special code is
> > needed to support basic sRGB colors. I believe it would make the code a
> > lot more complicated if it were not descended from Color. Imagine only
> > our Graphics2D implementations which receive Color instances. I can't
> > even begin to imagine how this would be solved with a non-Color-based
> > color container.
> I may be wrong, but it seems to me that XGC defines its own Graphics2D
> implementation (o.a.x.java2d.AbstractGraphics2D) that is passed all over
> the XGC and FOP code. Couldn’t we imagine to associate to it a custom
> Color class that suits the need for a more elaborate colour handling?

It wouldn't be the Graphics2D contract anymore. I'd have to change Batik
in a number of places to support special colors so it calls the special
methods instead of the normal setColor(Color)/setPaint(Paint). I
definitely don't like that.

> Implementations that don’t support elaborate colours would simply call
> some getFallBack method returning a java.awt.Color. Implementations that
> do support them wouldn’t have to do ugly instanceof tests.

The fallback is already in place: Color.getRGB() returns the sRGB value
for every Color subclass. Working around instanceof tests in some places
will not be avoidable. Every output format knows which kinds of color it
supports and has to handle special colors it supports differently.

IMO, adding a parallel class hierarchy for colors only increases
complexity and adds a lot more code and effort. And all that potentially
only because of Color.equals()? Naaaaah.

> AFAIK, three of the major output formats supported by FOP do support
> elaborate colours: PDF, PostScript, AFP. Maybe also PCL.

Right. PCL only if we start implementing color support.

> Also, Peter has a point when pointing out that the equals method is not
> symmetric. The fundamental contract of the equals method is broken, and
> that can only result into hacky workarounds and subtle, hard to find
> bugs. IMO, if the equals method of Color doesn’t do what we want, then
> the whole class is not what we want, and relying on it will only result
> into a wobbly architecture.

Ok, that the Color.equals() contract is broken and the symmetry is lost,
that is right. The Javadocs say that a color is equal if the red, green,
blue and alpha component (sRGB is implied) are equal, it's the same
color. Not so in our case, where we also have to inspect the class and
some of the values added by subclasses. So it would actually be easy to
add a ColorUtil.equals(Color col1, Color col2) which first compares the
Class, the compares the Color's native components (because Color.equals
() doesn't) and finally calls col1's equals() method only if the Class
is the same for both. That reestablishes the symmetry and the required
functionality. How about that?

I don't think you can easily establish such an equals() symmetry as soon
as you compare different classes to each other which have the same
superclass. That's basically what happens here.

At any rate, calling equals() in both directions may be slightly
inefficient but already does the job right now.

What I have now in the branches works fine and is now much clearer (I
just have to update the Wiki). I even implemented the cielab() function
for Batik in 20 minutes after that and got the right color in PDF. That
tells me that at least some things are not as bad.

Jeremias Maerki

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

View raw message