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? 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. Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
