Jeremias Maerki: > I've started looking into the com.sun problem, i.e. the problem with > the Sun-private JPEG codec that is not available in OpenJDK and other > JVMs. > > I've already removed the JPEG compression support from the TIFF codec > fork in XGC. I'm tempted to do the same in Batik. The TIFFTranscoder > can't generate TIFFs with JPEG compression anyway (apparently, there > were NPEs). Removing this means that Batik won't be able to load TIFFs > with JPEG compression anymore unless the user switches over to the > ImageIO codec. However, a TIFF ImageIO codec is only available with the > JAI ImageIO Tools in the classpath.
I have no idea how widely JPEG-compressed TIFFs are processed with Batik. I think it might make sense to do as you suggest, and if users need to process such TIFFs to get them to use JAI. > I've also locally deleted the com.sun-based JPEG ImageWriter and enabled > the ImageIO-based one. I've compared the generated JPEGs on a low level > and they are basically identical (especially the pixel data). Good. :-) > Next on the list is making sure the ImageIO-based JPEG support can fully > replace the com.sun JPEG codec. When I have that, we basically are > completely rid of of the com.sun classes with only the restriction > indicated above. > > If anyone thinks that removing JPEG decoding support from the internal > TIFF codec is unacceptable, please let me know. If necessary, I can try > to make sure there is a fallback to ImageIO if the internal codec cannot > load a particular TIFF. I think that is worth doing. It should not be hard, right? > From my experience, the TIFF codec from JAI ImageIO Tools is superior to > the internal one. So personally, I'd actually love to remove that one > from Batik and XGC altogether. But I guess that's not very popular. >From my perspective, TIFF support seems kind of niche in the first place, so I don’t feel too strongly either way for it. > An alternative to my approach above is to conditionally compile the > com.sun-"tainted" classes but I'd rather put something together that > works on all JVMs in a consistent way (or as consistent as possible). Yeah, if possible it would be good to avoid that. > BTW, after the build improvements (in the new branch), the XGC > dependency comes in. I plan to slowly synchronize and then phase out the > Batik-duplicates. And I may be tempted to plug in the XGC image loading > framework as additional image source so Batik can support MUCH more > image formats. But first things first... Sounds good. -- Cameron McCormack ≝ http://mcc.id.au/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
