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 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: alexanderk...@gmx.net web: www.alexanderkiel.net
signature.asc
Description: This is a digitally signed message part
