xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hennebert <vhenneb...@gmail.com>
Subject Re: Status of the new color infrastructure
Date Wed, 07 Jul 2010 18:26:15 GMT
Jeremias Maerki wrote:
> On 01.07.2010 13:22:35 Vincent Hennebert wrote:
>> 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?
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.

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

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.


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

View raw message