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 [1].

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.

[1] 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)
--> ( id=20244&action=view)
Yet another try

I 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 will
lead to problems at some time...

In SVGReader, the input stream should be closed after the
createSVGDocument method has been called. Because if this method
terminates successfully, then the document actually is an SVG image and
the 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 a
generic DOM representing the input document, there is no reason why that
would fail. But IIUC you want to plug-in your own image reader instead
of relying on XMLReader? Which means that XMLReader shouldn't close the
stream. 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 any
sense? Thoughts, opinions?

There is still a lot of duplicated functionality in the Image Readers, which at
some 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.


Max Berger

PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http://

Attachment: PGP.sig
Description: Signierter Teil der Nachricht

Reply via email to