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:
> http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/image/loader/util/ImageUtil.java?view=markup
> http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/image/loader/util/ImageInputStreamAdapter.java?view=markup
> 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).
> http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/image/loader/impl/AbstractImageSessionContext.java?view=markup
> That could might even be extracted to be useful to you.
> See also: http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/ImageIO.html
> (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

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

e-mail: alexanderk...@gmx.net
web:    www.alexanderkiel.net

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to