I don't think that relying directly on the ImageIO API is a problem
since it's been part of the core Java class library since Java 1.4. It's
available in all JVMs that claim to be at least Java 1.4 compliant. I
don't really see the benefit in hiding the API behind an additional
layer. ImageIO is here to stay. But that's just my opinion.

Please note that SeekableStream is a predecessor of the ImageIO
ImageInputStream as the image codecs in XML Graphics Commons originally
came from JAI via Batik. It's not something we built specifically for
our project here.

I'm not aware of any implementation of ImageInputStream or
SeekableStream that takes a byte array as constructor parameter.

An inquiry on fop-users [1] reminded me to just briefly mention an
important point about the font subsystem: the fact that some font data
is loaded again and again for each rendering run. We've discussed this 
(and possible solution approaches: "font sources") in the past (see
mailing list archives, particularly [2]). Unfortunately, this hasn't
been realized, yet. Some improvements were made in the last couple of
years, but we're not quite there, yet. So I'm happy that you've started
working in this area. This will surely be at least a big step in the
right direction.


On 24.09.2009 22:18:21 Alexander Kiel wrote:
> Hi Jeremias,
> On Thu, 2009-09-24 at 21:06 +0200, Jeremias Maerki wrote:
> > Right, and that accounts for a pretty large portion of FOP's memory
> > consumption problem nowadays. With the use of OpenType fonts, this gets
> > worse as they can be quite big. I'm glad you noticed that.
> Yes, but currently I read all OpenType tables I'm aware of. The Java
> data structures are quite bigger than the original file. The biggest
> fonts I saw have a size of 400 kb. I don't know the Java structure size
> at the moment. If its really a problem, I can profile this later. So
> maybe I should add config options which select the tables to read.
> Currently the data is moved into a CustomFont and the TTFFile is thrown
> away (I hope so). But CustomFont doesn't have the power of advanced
> OpenType features. So I think we will end up with some interfaces
> instead which may be implemented by the TTFFile itself or by classes
> using the TTFFile in the background. That said, we will end up with some
> amount of data in memory anyway. 
> > May I suggest to use ImageIO's ImageInputStream? That already has an
> > implementation that buffers the stream in a temporary file (if allowed)
> > so you basically have random access. I've used that extensively in the
> > image loading framework in XML Graphics Commons and it seem to be
> > ideal for what you need to do. You even get the hierarchical mark/reset.
> Thanks for that! I did not know of ImageIO's ImageInputStream before.
> It's an interface, which is good. It is capable of all the stuff I need.
> The only thing to complain about is, that it has more functionality as
> needed and that its named a bit odd for fonts. Maybe I should specify an
> interface which is a subset of ImageInputStream and provide a simple
> wrapper to ImageInputStream so that I can use the implementations.
> > I don't think NIO will help much here. I'd really suggest
> > ImageInputStream which should have everything you need. You can probably
> > even reuse some utility code I've written for the image loading
> > framework:
> >
> >
> > 
> > The following class has some code to get an ImageInputStream from a URI.
> > If it's a file URL it tries to get an ImageInputStream with random
> > access. In all other cases, the content is buffered by ImageIO's default
> > buffering implementations (depending on the settings).
> >
> > That could might even be extracted to be useful to you.
> > 
> > See also:
> > (methods setUseCache() and setCacheDirectory)
> Thanks for that pointers. What would you think? Should I specify my own
> SeekableInputStream which isn't able to do all that bit operations and
> some of the DataInput operations I don't need, or should I use
> ImageInputStream directly? Is there a simple implementation on top of
> byte arrays for unit testing? Ok I could use ImageInputStreamImpl for
> that...
> If I think of it more deeply, it would not so clever for a font API to
> depend on javax.imageio. There is the "x" in javax and the "image" in
> imageio which I don't like.
> It's a pity that there is no common byte-only random access input source
> interface in Java, isn't it?
> Best Regards
> Alex
> -- 
> e-mail:
> web:

Jeremias Maerki

Reply via email to