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...


>> 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

Reply via email to