Vincent,the problem with the current XML Reader is that it closes the stream in all cases. Even though it is the last image reader, it is bad because this means there can be no additional ImageReader.
First, let me tell you why I wanted this functionality: I am currently working on updating the fop-mathml plugin to work with the current version of JEuclid. The work can be found at .
Therefore, I would like to add support for two additional Image Types: ODF (OpenDocument Formula, basically a .ZIP file with MathML in it), and MathML (XML-based).
The plugin registers additional imagereaders, which will run after the default image readers.
When the current XMLReader is run with an ODF file, it just spits out an error message, but still closes the stream. Any additional image reader, such as the ODFReader then has no chance of detecting the format, which is bad (and violates the contract stated in the interface).
The workaround for this in the SVGReader was the UnclosableInputStream (which was declared inline), so what I did was externalized it, and also used it in XMLReader. The trick here is to use the UncloseableInputStream when passed to external functions (such as the SAXReader), and the original input stream when actually closing it.
You are absolutely right, there is a .close() now missing when XMLReader has recognized the image. But also, ImageReaderFactory is missing a .close() if the image is not recognized. I have added this and will submit yet another patch.
 http://jeuclid.svn.sourceforge.net/svnroot/jeuclid/trunk/jeuclid- fop/
Am 26.05.2007 um 17:59 schrieb Vincent Hennebert:
Hi Max,------- Additional Comments From [EMAIL PROTECTED] 2007-05-23 02:07 -------Created an attachment (id=20244)--> (http://issues.apache.org/bugzilla/attachment.cgi? id=20244&action=view)Yet another tryI was about to hit return after having entered the svn commit command...when I decided not to.This isn't as simple as it seems to be. IIUC, with this change you will end up with InputStreams which will /never/ be closed! I guess this willlead to problems at some time... In SVGReader, the input stream should be closed after the createSVGDocument method has been called. Because if this methodterminates successfully, then the document actually is an SVG image andthe stream can be closed. Otherwise this method will throw an IOException, and the following line won't be reached anyway. In XMLReader we can't really do the same. This class will create ageneric DOM representing the input document, there is no reason why thatwould fail. But IIUC you want to plug-in your own image reader insteadof relying on XMLReader? Which means that XMLReader shouldn't close thestream. Or do it only if a converter is found for the corresponding namespace? Probably that.I'm not a specialist of the image handling area. Does all that make anysense? Thoughts, opinions?There is still a lot of duplicated functionality in the Image Readers, which atsome point should be cleaned up.You are welcome to work on this if you are willing to. Note that Jeremias has been having some ideas about refactoring the image handling, maybe you two will want to synchronize on this. Thanks, Vincent
Max Berger e-mail: [EMAIL PROTECTED] --PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http:// max.berger.name
Description: Signierter Teil der Nachricht