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
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
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  (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.
Hoping my questions aren’t too stupid...
>> An inquiry on fop-users  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 ). 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.
>>  http://markmail.org/thread/r6etkcadyaahgyhe
>>  http://markmail.org/message/4cmbj5x3zkvflrax
> I read the FOPFontSubsystemDesign  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
>  http://wiki.apache.org/xmlgraphics-fop/FOPFontSubsystemDesign
> e-mail: alexanderk...@gmx.net
> web: www.alexanderkiel.net