J.Pietschmann wrote: > I believe we should just define a fop.Font interface which is > the same as awt.Font, then provide implementations fop.AWTFont, > fop.PDFFont (well all the variations), fop.Type1Font etc. A > configurable selector (an Avalon selector) could selcet them. > This way people could use AWT fonts without a hassle, with the > small disadvantage that they can't be embedded. > > Jeremias, as the resident font guru, what do you think?
I am confused by the distinction that you make between fop.PDFFont and fop.Type1Font. In my mind, there is no such concept as a fop.PDFFont, unless it is a renderer-specific class for getting a Type1Font (for example) into the PDF output. But I think that should be a method in the Type1Font class. I have spent more time than I should have trying to figure out why fonts are (or were) renderer-specific. I may still be missing something important. (I *do* understand why they are renderer-context specific, i.e the difference between the AWT context and the others). Another idea on the AWT font issue is to allow the user to register the location of the AWT font just like they would any other font. This would be equivalent to saying "use the AWT metrics for this font, but get the physical font from a certain file". The problem there is, of course, that you introduce another possible layer of errors (can find the AWT metrics but not the physical file, or vice versa), but I think that would be quite managable. I think the approach that you are recommending is roughly what Jeremias has suggested for fonts in general, and which I can live with as long as we essentially make everything but the interface protected. I think you still need to have a third class that sits between awt.Font and fop.Font, because there is no way to tell awt.Font to implement the fop.Font interface. I favored a concrete class with a method that did the selection, which seemed cleaner to my mind, but I see the benefits to the other approach. Victor Mote
