RE: font features in CSS

See comments inline below.

Steve Zilles


> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of
> Håkon Wium Lie
> Sent: Monday, October 26, 2009 7:46 AM
> To: www-style; www-font
> Subject: font features in CSS
> 
> Prince 7.0 has been released with experimental support for OpenType
> font "features". This means that glyph alternates present in the font
> can be selected by way of CSS. Here's a sample document that uses
> alternates found in Adobe's "Arno Pro" font:
> 
>   http://www.princexml.com/howcome/2009/magic/prince7.pdf

>   http://www.princexml.com/howcome/2009/magic/prince7.html

> 
> The preliminary syntax for selecting various features is:
> 
>   font-variant: prince-opentype(<feature name>);
> 
> Mozilla is also working on supporting font features:
> 
>   http://hacks.mozilla.org/2009/10/font-control-for-designers/

> 
> Their preliminary syntax is:
> 
>   -moz-font-feature-opentype: "<feature-name>=<value>";
> 
> (Comma-separted lists are supported in both implementations.)
> 
> So, it seems font "features" could be a useful CSS feature. However,
> some issues have come up:
> 
>   - the current implementations only support arbitrary features. The
>     names of these features are buried deep down within the fonts and
>     are hard to find. Another approach is to standardize a set of
>     common features. There have been several such proposals in the
>     past:
> 
>       http://lists.w3.org/Archives/Public/www-style/2008Jan/0380.html

>       http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html

> 
>     I personally think standardized names will be better, but it may
>     still be hard to avoid cryptic names like "alt" and "salt".
[SZ] My understanding from Adobe font guys is that the 4 letter feature names were never intended for human use. They are indeed cryptic. Adobe products that support those features only offer long names which map to the 4 letter codes, sometimes singly and other times to a combination of 4 letter codes when that makes more sense. For example, the long name, "All Small Caps" maps to the two features, "smcp" which converts lower case letters to small caps and "c2sc" which converts capital letters to small caps. (One might figure out that "smcp" stands for small caps, but I doubt that many will decipher "c2sc".)

So, I do not propose, as the above prior proposals did, that we add a bunch of properties. I do, however, propose that we add a registry that gives long names (understandable and suggestive names) that map to one or more 4 letter codes. For example, the OpenType Spec
  http://www.microsoft.com/typography/otspec/featurelist.htm

has a set of "friendly names" that might be used. Adobe InDesign also has a set of "user oriented" names. This would likely make the features more usable.
> 
> 
>   - Are features binary or do they need integer values? It seems that
>     Prince has implemented features as binary switches, e.g.:
> 
>       font-variant: prince-opentype(salt2);
> 
>     while Mozilla uses integer values:
> 
>       -moz-font-feature-opentype: "salt=2";
> 
>     Personally, I hope to avoid numbers altogeter; they seem even more
>     arbitrary than the alt/salt/ss names we're currently seeing.

[SZ] I would agree that numeric values are, in most cases, not necessary, but there are cases, such as "alternate glyphs" (a.k.a Stylistic Alternates) where more than one alternate may exist. For example, Adobe Poetica has multiple alternates for the ampersand "&" glyph. In this case, a numeric argument makes sense.

So, one approach would be to make the "=number" part optional. If omitted, the feature would simply be toggled. Why "toggled" you ask. Because it makes sense for some of the features to be, by default, enabled. And, it is also necessary to be able to turn off a feature. If an author were in doubt about the state of a feature (whether enabled or disabled), then the author could always use the "=number" form of the setting to set it to an explicit state.
> 
> 
>   - Here's a reformulated version of Mozilla's demo document that
>     contains both the Prince and Mozilla syntax, along with Prince's
>     rendering:
> 
>       http://www.princexml.com/howcome/2009/megalopolis/sample.html

>       http://www.princexml.com/howcome/2009/megalopolis/sample.pdf

>       http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.png

> 
>     The page has been carefully designed so that all lines should have
>     the same length. However, in Prince's renering, lines stick out.
>     This is, I believe, due to Prince applying the named feature
>     (ss05) in the case of the "Beua.." line) to all characters in the
>     element, while Mozilla only applys it to the last character of a
>     word. Mozilla's solution is convenient; it avoids having <span>
>     elements around the last charater in order to give it a special
>     feature. However, how do one decide that a certain feature should
>     only be applied to the last characters? Does the feature itself
>     indicate this in any way?

[SZ] I strongly dislike "magic" because it is hard to remember and it is hard to interpret. I would therefore suggest as set of keywords that could be added to the setting of the basic property value. There are two sets of these keywords: the first set consists of "block" and "word"; the second set consists of "all", "first" and "last". (I do not believe that this is an exhaustive set of possible keywords, only a set sufficient to describe the Mozilla behavior.)

The meaning of the key words is that the enabled feature applies to either the first character, the last character or all the characters in a given block or all the words in a block. We can see from the MEgalopolis.png and the associated .html file that Mozilla is applying the "ss05" feature to the "last" of every "word" (see "Beau Grand & Fort") This might have been written (in the stylesheet) as

.ss05 { 
  -moz-font-feature-opentype: "ss05=1" word last; 
  font-variant: prince-opentype(ss05); 
}

Using the keywords that I proposed. (Note that since one can have a comma sepearated list of features as the value of -moz-font-feature-opentype it is necessary to allow the point of application of the feature to be separately specified for each feature in the list.)

> 
>   - personal peeve: I don't like the term "font feature". The term
>     "feature" seems much to generic to be used for a very specific
>     feature (ouch): alternate glyphs.

[SZ] Ouch indeed. Using "font feature" does allow one to correlate with the OpenType specification and "alternate glyph" is just one of the features in that collection. Perhaps one should say "typographic feature" to point out that it is the style of typography being selected (and the role of the font is just to provide the tables that allow that style of typography to be realized). I am not, however, very attached to this suggestion.

[SZ] Steve Zilles

Received on Thursday, 29 October 2009 04:28:45 UTC