Hi Alexander, Knowing just about nothing of font file formats and libraries, I’ll play the ignorant guy asking naive questions, hoping that it might give you good ideas.
Alexander Kiel wrote: > Hi Jeremias, > > On Fri, 2009-09-25 at 08:37 +0200, Jeremias Maerki wrote: >> 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 had a look at SeekableStream and I can imagine how the needs resulted > in the ImageInputStream interface. I haven't decided yet if I should use > ImageInputStream directly. Maybe someone else can throw it's two cents > in here. Here are my two cents: if you make use of classes in javax.imagio at only one place in your font library, then there’s no need to worry about creating a more neutral layer. If OTOH you need to use those classes everywhere, then it makes sense to use a simplified abstraction layer. That abstraction layer could be shipped as a separate module and evolve separately. An implementation could be based on imageIO, Apache Commons IO (?), your own implementation based on byte arrays for testing purpose, etc. And another bunch of thoughts and questions: - I think priority should be given to having a sound API that can be re-used by other projects than FOP, rather than memory optimization. - is memory consumption that much of a problem anyway? I mean, fonts are intrinsically big, complex objects and there’s not much we can do about that. Many scripts in the world can’t do without advanced features. Making the parsing of some tables optional doesn’t look to me like the right way to optimise things. That would unnecessarily complicate the code. - instead of seekable streams, what about a filter that would re-order the font stream, caching whatever is necessary before re-sending it to the consumer object? - what about giving the font library a “playground” directory by inversion of control, that it can use to cache things? And if no directory is given it would use the memory. Maybe a common interface could be used for that, targeting either the hard drive or the memory. - does the use of serializable objects make sense? What would be more efficient: re-parsing font data all the time or re-loading serializable object representation of them? - what about looking at how fontconfig [1] (a font configuration library for Linux systems) does things? I know it makes use of a cache to speed up things. Maybe there are good ideas to borrow from there. [1] http://www.fontconfig.org/wiki/ Hoping my questions aren’t too stupid... Vincent >> 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. >> >> [1] http://markmail.org/thread/r6etkcadyaahgyhe >> [2] http://markmail.org/message/4cmbj5x3zkvflrax > > I read the FOPFontSubsystemDesign [1] wiki page. At the moment I don't > understand the whole system good enough to see whats needed by the rest > of FOP. I think a more deeply discussion about the font subsystem would > be out of this discussions subject. So maybe we should start a new > thread on the list. But before this, I should get my OpenType reading > finished and submit the patch. > > Best Regards > Alex > > [1] http://wiki.apache.org/xmlgraphics-fop/FOPFontSubsystemDesign > > > e-mail: alexanderk...@gmx.net > web: www.alexanderkiel.net >
