xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: [VOTE] Merge FOP color branch into trunk
Date Tue, 01 Feb 2011 18:40:38 GMT
On 01 Feb 2011, at 13:24, Jeremias Maerki wrote:

> Hmm, I don't see how any cruft can accumulate in there. Main and test
> classes are properly separated. jar-main only packs build/classes.
> Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?),
> we need to update the JAR anyway.

Sure, I can take care of the migration of ColorProfileUtil in the same go. Do we move it to
java2d.color.profile (similar to ColorUtil, which is placed under java2d.color)?

See attached patch XGC_ColorProfileUtil for the proposal. Just added a method to deal with
the getInstance(byte[]) variant used in XGC, and for the sake of completeness, provided one
for the String variant as well.

Additionally, looked up the places where one of the getInstance() methods was being used and
replaced them by a corresponding call to ColorProfileUtil.getICC_Profile(). 
As it turns out, there were only two occurrences: ImageLoaderRawJPEG and ImageLoaderImageIO.

Are there any special steps to be taken to replace the JAR in FOP, or do I just commit the
new '...1.5svn' JAR?

On FOP's end, after the JAR has been replaced, the changes then become as in attached patch
FOP_ColorProfileUtil. For now, I deprecated the class and redirected the existing methods.
The calls to getICC_Profile() are done directly against XGC, so no need to add those to FOP's
ColorProfileUtil anymore. I also cleaned up the remaining references to other methods (= basically
just replaced import statements in the affected classes), so fop.util.ColorProfileUtil is
actually unused. To be removed at a later date?

The harder part would be to come up with some test cases, in order to verify that this actually
fixes the behavior... Notoriously difficult in the case of race conditions, especially if
they are located in code that is outside of our control.



Mime
View raw message