See below...
Jeremias Maerki wrote:
The font subsystem is still far from finished. It's still quite complex to understand, unnecessarily so IMO. My font source idea still need to be implemented... Let's see if I can pull together some connectors.
I agree that it is complex to understand.
As you've seen the Document class is a central class in font handling.
It currently (not in my ideas) provides direct access to font metric
information and to the list of fonts actually used in a rendering run (we don't always want to embedd them all). The setup of all fonts is
done in the FontSetup class where the base 14 fonts are defined.
Additionally, custom fonts are added there. But the custom fonts are
mostly renderer-dependant, so at the moment, some font setup also takes
place in PDFRenderer for example. See PDFRenderer.configure (which
can build custom font information using an Avalon Configuration object
using a helper method from FontSetup) and PrintRenderer.setupFontInfo
which actually triggers the font setup. The fonts get registered with
the Document object and subsequently is available to the layout engine.
One of the complications is that Document wears so many hats. I see a Document object referred to by the variable fontInfo in one place, and by the variable foTreeControl in another. Document implements FOTreeControl, FOTreeListener and AreaTreeControl, so the foTreeControl variable looks deliberate, but the fontInfo may be a hangover. In any case, wouldn't it be clearer to have such functions realized in separate objects which are created and managed by Document?
Most font classes in the fonts package deal with the different font formats (single byte und unicode, base und custom...). There's also a difference in audience: The layout needs different information (metrics in particular) than the renderers (primarily information for using and embedding the font in the target format.
This is my first close look at fonts, and I have browsed the java.awt.Font and java.awt.FontMetrics classes and the java.awt.font package. In itself, this bundle of interfaces and classes is complex, but the nub of it seems to be the 2D font classes. At first glance, there is a close connection between fonts, glyphs, strings, text attributes and line layout, all covered in these classes.
I am wondering if we cannot use the Java model as a basis for FOP's line area layout API. The discussion in http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-fonts.html#wp66677 contains a discussion of implementing a custom text layout mechanism to enable features like kerning and ligatures.
My intention is to develop the initial alt-design layout using AWT rendering. I assumed that I could get usable testing output more quickly that way, without having to delve into PDF. My comments may simply be conditioned by that perception. I'm not talking about adopting 1.4 (and 1.5 when it is stable), but using the API model where it provides appropriate methods for laying out text. One implication of that would be a fairly intricate interaction between all the phases of FOP, involving the font details provided by the renderer.
However, I recall that Hansuli Anderegg has been working along these lines for some time now.
Btw, what search keys should I use to recover details of your font model from the archive, assuming there are differences between your model and the wiki?
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
