If that is the case (a big if) might we not be better to move to a more generic form, with translation into each particular form of font specification?
I can't tell. I don't see much benefit because the current system already provides most of what FOP needs. A total rewrite may provide more flexibility on the long run but will mean a lot of work which is problematic in FOPs current state.
It should be fairly simple to add the two most important missing features to FOP font handling: on-the-fly font discovery and font aliases.
I was looking for the correspondence to the Rec (and CSS2) handling of fonts. The generic family set from the Rec includes serif, sans-serif, cursive, fantasy, and monospace. These are the fall-backs. The individual family-names are invoked by the user, possibly in blissful ignorance of what fonts are actually available to a particular renderer. According to the Rec, it is the User Agent's job to build a font database with a full set of information about the fonts it has available, including their family-name and the generic family to which they belong.
The parameters for font selection are
font-family (in both the broad and specific senses given above),
font-style (normal, italic, oblique, backslant),
font-variant (normal or small-caps),
font-weight (normal, bold, bolder, lighter, 100, 200, 300, 400, 500, 600, 700, 800, 900),
font-stretch (normal, wider, narrower, ultra-condensed, extra-condensed, condensed, semi-condensed, semi-expanded, expanded, extra-expanded, ultra-expanded) and
font-size (including xx-small, x-small, small, medium, large, x-large, xx-large).
It seems to me that, at some point, we have to map from this set of properties to the font characteristics of the renderer in question.
Is this what you mean by on-the-fly font discovery and font aliases?
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>