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).
I'm fuzzy with this stuff, but isn't renderer-context a new notion? What you are calling renderer-context was previously only associated with the renderer as such, wasn't it? I'm assuming that the renderer-context is something that amalgamates font metrics. Renderers share a context if, among other things, their fonts share common metrics. Is this what you mean?
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.
Speaking of errors: can find the AWT metrics, but they don't match the metrics of the font file.
p -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
