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 [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] 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=20244action=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.
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
PGP.sig
Description: Signierter Teil der Nachricht
