(comments inline) On 17.03.2004 04:53:46 Peter B. West wrote: <snip/> > > 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?
I agree 100%. I don't particularly like the Document class right now. I'm still dreaming of font source services and an Avalon container but I don't see it happen in the near future. > > 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. We probably could, but I'm stating again that the whole AWT thing has its quirks and it has already grown over a few JDK versions. I'd rather have a clean cut tailored to our need with adapters for AWT fonts (the AWT font source) and a chance to support whatever fonts we want. Especially for embedding fonts (an important feature), last time I looked, AWT fonts did not provide the necessary infrastructure. > 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. Good idea but I'd like to point out something: If you look at Batik's Javadocs you'll see that there are several packages dealing with extending AWT infrastructure in order to meet the projects needs. Maybe we need to find out how we can profit from the Batik team's findings concerning AWT. Maybe parts of Batik could be used to work around some of AWT's problems when they show up. There it is again, the XML Graphics umbrella. Now, if you base your layout on AWT APIs and find out later that for PDF and PS the infrastructure is not good enough, you'll have a problem but I don't think that's dramatic. It shouldn't be all to hard to rewrite the necessary parts then, to draw in a adapterish abstraction layer. > 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. Right, I've done some investigation myself in this area by creating proof-of-concept JPS output handlers to create PDF and PS (using parts of our transcoders, i.e. the Graphics2D implementations). However, I still don't buy the idea, yet, as the way to go. With separate PDF and PS renderers I have everything under control. More code, granted. It would certainly be interesting to have both models and compare them more closely. I have once looked at Hansuli's code which seemed to me a modified copy of the AWT renderer which is not such a good thing to do. It should be possible to reuse code as much as possible even if it means changing the original AWT, sorry, Java2D renderer. But that's already many months in the past. Now we can start on the green field. Maybe Hansuli chimes in again and helps us go into this direction. > 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? Interesting threads: http://marc.theaimsgroup.com/?t=104209837400001&r=1&w=2 http://marc.theaimsgroup.com/?t=98099184600003&r=1&w=2 I think the Wiki holds most of my view of things. Victor added a lot of additional content I was unfortunately never able to completely follow-up on. http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign Jeremias Maerki
