No, this can't be addressed, since java.awt.Color only checks its sRGB values, but not the actual color components if it's based on a non-sRGB color space. And we can't change java.awt.Color. I've had to change FOP in a few places in the color branch to test equals() in both directions to detect color state changes. These collisions will not happen very often but they are possible even in today's code. One thing that can be done is to make sure FOP always uses a subclass of Color with a better equals() method but that may not always work, for example, when barcodes, PDF or WMF files are painted via Graphics2D.
I mentioned the equals() problem here: http://wiki.apache.org/xmlgraphics/ColorHandling On 01.07.2010 16:09:08 Peter Hancock wrote: > I have noticed that the equals method of ColorExt is not reflexive, e.g.: > > Color c = .. > ColorExt ce = ColorExt.createFromFoRgbIcc(.. ,c.getColorSpace(), > c.getColorComponents(), ..) > > c.equals(ce) == true != ce.equals(c) > > Could this be addressed now? > > Pete > > On Thu, Jul 1, 2010 at 2:00 PM, Jeremias Maerki <[email protected]> > wrote: > > OK, I see. As you can see, I feel the pretty much way but the current > > ColorExt is an abomination when it comes to extending it with additional > > functionality. I guess, Simon can just cut the release and I'll replace > > ColorExt with ColorWithAlternatives (or so). I just think it's a shame > > to release something we know has to change drastically anyway for the > > next release. > > > > On 01.07.2010 13:39:36 Peter Hancock wrote: > >> > Not sure I understand what you wanted to say. > >> I was trying to say that I felt that moving color utility code up to > >> XGC was generally desirable and having to reverting back was a shame. > >> By 'water down' I really meant reduce, which actually means the > >> opposite! Sorry :-) . > >> > >> On Thu, Jul 1, 2010 at 12:19 PM, Jeremias Maerki <[email protected]> > >> wrote: > >> > > >> > On 01.07.2010 13:03:43 Peter Hancock wrote: > >> > > Hi guys, > >> > > > >> > > > But I've just thought of a better alternative: > >> > > > Moving (!) ColorExt back to FOP where it was and moving > >> > > > GrayScaleConverter to FOP solves the whole problem with minimal > >> > > > effort > >> > > > in FOP Trunk. > >> > > Do you intend to refactor the static ColorUtil.toCMYKGrayColor method > >> > > to a member of GrayScaleConverter? > >> > > >> > I planned to move the toCMYKGrayColor method back to FOP's ColorUtil > >> > until things are resolved. > >> > > >> > > I think this move makes sense for this release but it is a shame to > >> > > water down the color package in XGC. > >> > > >> > Not sure I understand what you wanted to say. > >> > > >> > > Pete > >> > <snip/> > >> > > >> > > >> > Jeremias Maerki > >> > > > > > > > Jeremias Maerki > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
