(disclaimer: Due to lack of time and a hardware failure, I haven't read everything, yet)
I don't think we can rely on java.awt.Font. A FOP-defined Font interfaces is necessary to really make sure FOP gets what it need. What we came up with on the Wiki pretty much shows my ideas for the font support: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign Basic parts of that are: - Font metric providing interfaces to hide the various font sources (AWT, Type1, TrueType) (There's no PDFFont in my view) - Renderers announce which font sources they support -> rendering run (Document) holds the available font sources subset. - Font adapters provided by the renderers that know how to register/use/put a particular font in the output. Since I have too little time to really participate ATM I can't care too much how it is done, i.e. with a Avalon selector or with something else. I failed to give Avalon in FOP a good enough punch. My only concern is the separation of font sources from the renderers, so that a uniform way of making fonts available in FOP is possible. I'm sorry that I can't be more of a help right now. I'd love to help, but have other priorities. On 22.11.2003 15:18:25 J.Pietschmann wrote: > Victor Mote wrote: > > Same general concept, except I think there is a separate class for font > > metrics in that system. If I can ever find a way to get to the physical file > > (or some representation of it) through java.awt.Font (for embedding), we > > would use it along with our other font scheme. > > 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? Jeremias Märki
