Hi Adrian, I'm not really a specialist of the font handling stuff in FOP, but having worked a bit in this area I can drop a few ideas (and ask a few naive questions), in the hope they will be useful.
> In the process of looking at this bug > (http://issues.apache.org/bugzilla/show_bug.cgi?id=42861) I came to the > conclusion that I´m not really happy with the current font handling > implementation. There is quite a bit of duplicated effort between the > renderers with regards to font configuration. Can you give some examples? Not that I don't believe you, just to have some concrete things to discuss about. For example, IIRC, in PDFFactory there is some code to read the font stream for embedding it. I guess there is about the same code in the PS renderer for embedding TrueType fonts. That job should really be deferred to the font library which would directly provide the stream to those renderers that need it. Is that what you're thinking of? > I would very much like to see a shared ¨FontSource¨ implementation (e.g. > both the Postscript and PDF renderers could make use of a shared > Base14FontSource and CustomFontSource) instead of having their own > separate configurations. Any new implementation would of course What would a FontSource exactly correspond to? What would be the different kinds of FontSources? Would a Base14FontSource really make sense? I mean, base14 fonts are PDF- (and, to a certain extent, PS-) specific. Does a PDF renderer really need to know that it's manipulating a base14 font? Isn't it just enough to know whether the font should be embedded or not? Jeremias has been having some ideas regarding font handling for some time. You can probably find some of them by looking at the archives [1]. I hope he'll have time to speak up but, if I remember well, he wants to group fonts by kinds: Type1 fonts, TrueType fonts, AFP fonts, AWT fonts, SVG fonts, etc. Each kind would be usable by one or more renderers; for example the PDF renderer could use Type1, TrueType and AWT fonts (although it would not be possible to embed the latter). I think this all makes sense. Ideally we would define a common API that would be used by the renderers and hide as much as possible of the actual font manipulation. The renderers would keep only their format's specific code (e.g., creating a PDF font object). > (initially at least) remain backwards compatible with existing FOP font > configurations. I believe these ideas were spoken about a while ago and > I do not think it would be too much work and it should simplify font > configuration somewhat and should be more efficient in embedded > implementations that make use of more than one renderer. Its probably a > bit late in the day to make the 0.94 release, but in the longer term > does anybody have any initial thoughts on this proposal? I hope those few ideas will give you some things to think about. Anyway, I think there's still quite a bit of work to do in this area, even if the auto-detection stuff was a big step forward. Thanks for looking into this, Vincent [1] See, among others, the first thread about FOrayFont (hem, and please don't pay attention to the flame war!) http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200506.mbox/[EMAIL PROTECTED]
