The focus of the Fonts class is to provide the facilities required by the Recommendation. The Rec and the CSS2 spec talk about the User Agent having a database of known fonts, and the new class is a sketch of this requirement. The work is far from complete, but out of the WIP the lines of an interface for such a fonts database start to emerge, for me at least.
The database must be able to match a font given family name style - normal, italic, oblique variant - normal, small-caps weight - normal, bold, lighter, bolder, 100 - 900 stretch - ultra-condensed - ultra-expanded size
Java font handling can match on family name, style and size directly and, with the fonts commonly available, on variant, weight and stretch only by constructing virtual fonts.
The database must be able to provide a complete set of selectors for each of the system-fonts caption, icon, menu, message-box, small-caption, status-bar.
Given the scope for the User Agent here, Java font handling can manage this.
The database must support the generic font families serif, sans-serif, monospace, cursive and fantasy.
This requirement is both system and installation dependent, but serif, sans-serif and monospace are available as logical fonts in Java. Cursive and fantasy fonts support will depend on available fonts, but individual renderers can check for the availability of a number of fonts known to fall into these categories.
I have read again the Wiki page on the font subsystem in the light of my current work with Java fonts. I'm afraid that I am still convinced that font handling is properly the preserve of the renderers. The layout engine needs only the font metrics, even for Java-based layout. As far as layout is concerned, the glyphs could all be Wingdings, as long as the metrics are right. The other required information is that relating to font selection, as discussed above. The logical home for font selection information is the renderer.
This is not to say that, once a clean fonts interface has been developed and implemented in all of the renderers, a further level of abstraction cannot be applied to bring all of the information under one umbrella. However, consider the problem of creating a new renderer. Fonts are inherently renderer specific. It may be that those fonts are shared between more that one renderer, but that fact is incidental to, e.g., the common ancestry of PS and PDF. Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry?
I'll try attaching the Javadoc description from org.apache.fop.render.awt.Fonts, as the included HTML may cause problems otherwise.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Java font selection is based on family names. It seems that Java
handles font mapping something like this:<br>
Given a set of physical fonts like, e.g., Arial, Java reports them as
<pre>
font face: Arial
logical:Arial
family:Arial
PSName:ArialMT
Style:
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
font face: Arial Cursiva
logical:Arial Cursiva
family:Arial
PSName:Arial-ItalicMT
Style:
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
font face: Arial Negreta
logical:Arial Negreta
family:Arial
PSName:Arial-BoldMT
Style:
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
font face: Arial Negreta cursiva
logical:Arial Negreta cursiva
family:Arial
PSName:Arial-BoldItalicMT
Style:
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
</pre>
There are other Arial forms, e.g. Arial Black and Arial Narrow, but
they fall into different families, as indicated by the font name.
java.awt.font.TextAttribute defines a number of TextAttribute
constants, and querying a Font object via getAvailableAttributes()
will provide an array of attributes available on the Font.
<p>It seems there is a common set available on both Type1 and TrueType
fonts in 1.4.2; viz FAMILY, WEIGHT, POSTURE, SIZE and TRANSFORM.
Note that style is reported as PLAIN on all fonts, irrespective of
the actual style according to the font name.
<p>SIZE works as one might expect. WEIGHT is supported directly only
for the weights provided in the set of family fonts. In the case of
Arial, only REGULAR and BOLD. The same is true of POSTURE: REGULAR
and OBLIQUE. There seems to be room here to experiment with
virtual fonts. A virtual Arial font might be constructed from the
Arial, Arial Narrow, Arial Black and Arial Black MT fonts.
Another area where virtual fonts might be handy is for small caps.
<p>In the case of the set of <i>logical</i> fonts defined for all Java
implementations, the characteristics are reported like this:
<pre>
font face: serif.plain
logical:serif
family:serif
PSName:serif
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
font face: serif.bold
logical:serif.bold
family:serif
PSName:serif.bold
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
font face: serif.bolditalic
logical:serif.bolditalic
family:serif
PSName:serif.bolditalic
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
font face: serif.italic
logical:serif.italic
family:serif
PSName:serif.italic
PLAIN
FAMILY
WEIGHT
POSTURE
SIZE
TRANSFORM
</pre>
Note that in this case, the logical name of the serif.plain font is
<i>serif</i>. This correspondence only seems to occur with the logical
fonts.
<p>Three names are available for each <code>Font</code> object:
<dl>
<dt>Font Face Name</dt>
<dd>Aka Font Name. Corresponds to a phsical font in the underlying
system.</dd>
<dt>Family Name</dt>
<dd>the name of the font family that determines the typographic design
across several faces.</dd>
<dt>Logical Name</dt>
<dd>The name that was used to construct the font. Each font has
such a name, irrespective of whether it is a <i>logical</i> or
<i>physical</i> font. The logical name only differs from the
font face name in the case of <i>logical</i> fonts. <i>E.g.</i>
the logical name of <code>serif.plain</code> is
<code>serif</code>, which is also the name of the pre-defined
logical font <i>serif</i>.</dd>
<dt>Postscript Name</dt>
<dd>The Postscript name of the font. Derivation and significance
unknown.<dd>
</dl>
Initial font mapping is based on the names available to the font.
<h4>XSL-FO/CSS2 system fonts</h4>
The CSS2 system fonts are:
<ul>
<li>caption</li>
<li>icon</li>
<li>menu</li>
<li>message-box</li>
<li>small-caption</li>
<li>status-bar</li>
</ul>
The situation on linux systems is that there are no system fonts as
such. Individual GUI environments like Gnome, KDE, CDE and the like
may define such fonts, but determining them will depend on the
individual system's GUI environment. The closest parallel in Java is
the set of <i>logical</i> fonts defined in every Java implementation,
<i>viz.</i>
<ul>
<li>Serif</li>
<li>SansSerif</li>
<li>Monospaced</li>
<li>Dialog</li>
<li>DialogInput</li>.
</ul>
The most obvious mapping from Java logical fonts to XSL-FO/CSS2
system fonts is
<dl>
<dt>caption</dt><dd>SansSerif at size A</dd>
<dt>icon</dt><dd>SansSerif at size B</dd>
<dt>menu</dt><dd>SansSerif at size C</dd>
<dt>message-box</dt><dd>Dialog</dd>
<dt>small-caption</dt><dd>caption at size A/1.2</dd>
<dt>status-bar</dt><dd>SansSerif at size D</dd>
</dl>
where sizes A, B, C and D are UserAgent prerogatives determined in
consultation with the underlying JVM font system. I.e., the fonts
must support fractional metrics and dynamic sizing, which, in default
Java implementations, they do, as far as I know.
<h4>XSL-FO/CSS2 Generic Font Families</h4>
The generic families in the Recommendation are:
<ul>
<li>serif</li>
<li>sans-serif</li>
<li>cursive</li>
<li>fantasy</li>
<li>monospace</li>.
</ul>
The mapping of the CSS2 generics <code>serif</code>,
<code>sans-serif</code> and <code>monospace</code> is a straightforward
name translation. There is no such convenient correspondence between
the Java font system and <code>cursive</code> and <code>fantasy</code>
fonts. This mapping must be determined by the UserAgent by
interrogating the JVM.
