Re: Fonts and Document
(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
Re: Fonts and Document
On Wed, Mar 17, 2004 at 09:21:03AM +0800, Manuel Mall wrote: Simon, tried the URL you gave (http://www.leverkruid.nl/FOP/documentation.xml) and got the error (IE 6): The system cannot locate the object specified. Error processing resource 'http://www.leverkruid.nl/FOP/docbookx.dtd'. The XML file is not meant to be viewed in the browser. If you try to do that, the browser searches for the DTD because the document lists one in its DOCTYPE declaration. And that DTD is not provided by my web page. If you would have the DTD that would not help you because there is no stylesheet associated with the XML file. The docbook stylesheets are too large and complicated to be applied by a browser. You can only save the XML file and apply XSL stylesheets to obtain an xhtml or pdf file. Mozilla Firefox fails as well. Same reason. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
Re: Fonts and Document
On Mon, Mar 15, 2004 at 01:40:59PM -0800, Clay Leeds wrote: On Mar 15, 2004, at 1:15 PM, Simon Pepping wrote: Looks good, Simon... I don't suppose you could create a PDF version? (I know a great XML = PDF conversion tool. :-)) Seriously though, this looks like a great potential addition to the Developer documentation we have on the FOP site. BTW, it looks like everything after Chapter 2, #3 is under PRE or CODE tags, so you've lost the formatting. I am glad you like it. I do not see your problem after Chapter 2, #3. In my browser, Mozilla and Mozilla FireBird viewing the local file (i.e. not via a server), everything looks as I expect. I will try this great conversion tool. If it can deal with the fo file that is produced by the Docbook XSL style sheets, it should be easy. You can try it yourself, because the DocBook XML file is also available from my web site, http://www.leverkruid.nl/FOP/documentation.xml. I am currently converting my raw notes to DocBook XML, and in the process rewrite those portions that do not seem good enough. I hope to finish this in two to four weeks. I would be pleased to add it to the developer documentation on the FOP web site if it is appreciated. I wonder if DocBook XML is the right format for the web site. For me it is the right format to write this kind of technical documentation. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
RE: Fonts and Document
Simon, tried the URL you gave (http://www.leverkruid.nl/FOP/documentation.xml) and got the error (IE 6): The system cannot locate the object specified. Error processing resource 'http://www.leverkruid.nl/FOP/docbookx.dtd'. Mozilla Firefox fails as well. Manuel
Re: Fonts and Document
Jeremias, 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
Re: Fonts and Document
On Mon, Mar 15, 2004 at 09:27:35AM +1000, Peter B. West wrote: Fops, What is the current situation with font information? I notice that the Document class now contains a lot of Font setup information, whilst a comprehensive set of font classes exists in ...fonts. I want to introduce font information into alt-design as compatibly as possible with HEAD. What do I need? I am completing my documentation on FOP code, see http://www.leverkruid.nl/FOP/index.html. I have a chapter on fonts. Maybe it helps you gain some quick insight. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
Re: Fonts and Document
On Mar 15, 2004, at 1:15 PM, Simon Pepping wrote: On Mon, Mar 15, 2004 at 09:27:35AM +1000, Peter B. West wrote: Fops, What is the current situation with font information? I notice that the Document class now contains a lot of Font setup information, whilst a comprehensive set of font classes exists in ...fonts. I want to introduce font information into alt-design as compatibly as possible with HEAD. What do I need? I am completing my documentation on FOP code, see http://www.leverkruid.nl/FOP/index.html. I have a chapter on fonts. Maybe it helps you gain some quick insight. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl Looks good, Simon... I don't suppose you could create a PDF version? (I know a great XML = PDF conversion tool. :-)) Seriously though, this looks like a great potential addition to the Developer documentation we have on the FOP site. BTW, it looks like everything after Chapter 2, #3 is under PRE or CODE tags, so you've lost the formatting. Cheers! Web Maestro Clay
Re: Fonts and Document
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. 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. 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. Just a quick write-up, but I hope it still helps a bit. On 15.03.2004 00:27:35 Peter B. West wrote: Fops, What is the current situation with font information? I notice that the Document class now contains a lot of Font setup information, whilst a comprehensive set of font classes exists in ...fonts. I want to introduce font information into alt-design as compatibly as possible with HEAD. What do I need? Jeremias Maerki
