On Apr 12, 2004, at 5:55 AM, Peter B. West wrote:
Jeremias Maerki wrote:
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.

To take this a step further, it would be nice(tm) ;-) to be able to pass an argument to FOP (e.g., ./fop.sh -fontlist), which lists FONTs available to FOP. This enables FOP users to quickly identify which fonts are accessible, as well as their exact spelling. If we wanted to be really helpful, we could even improve the tool to output (once we found the 'spelling' of each font name) the XML needed to add a particular font:


clay# >./fop.sh -fontconfigaddxml "Courier New"

<font metrics-file="courier_new.xml" kerning="yes" embed-file="courierNew.ttf">
<font-triplet name="CourierNew" style="normal" weight="normal"/>
<font-triplet name="CourierNewMT" style="normal" weight="normal"/>
</font>


We could also add 'help' information indicating how to add/specify the information necessary to further configure font-metrics file for as many of the following parameters as possible (or at least identify which of these parameters are available).

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>



Reply via email to