Re: [css3-fonts] font-feature-settings syntax

On 19/4/12 08:33, John Daggett wrote:
> The font-feature-settings in CSS3 Fonts currently has a relatively
> simple syntax, it takes a comma-delimited list of strings with an
> optional value or on/off keyword [1].  The strings represent OpenType
> tags which are defined to be 4-character ASCII strings.
>
> Example:
>
>    /* enable small caps and use second swash alternate */
>    font-feature-settings: "smcp", "swsh" 2;
>
> The spec contains the following wording:
>
>    The<string>  is a case-sensitive OpenType feature tag. For it to
>    match an OpenType feature contained in a font, it must follow the
>    syntax rules for tags. As specified in the OpenType specification,
>    feature tags contain four characters. Tag strings longer than four
>    characters must be ignored, user agents must not use a feature tag
>    created by truncating the string to four characters.
>
> This doesn't define clearly the behavior for smaller strings and
> strings containing non-ASCII codepoints.  I'd like to tighten this up
> to make it so that only four-character ASCII strings are considered
> valid, since shorter strings or strings with non-ASCII characters
> won't ever match an OpenType font feature and are most likely a typo.
>
> I propose changing the wording above to:
>
>    The<string>  is a case-sensitive OpenType feature tag. For it to
>    match an OpenType feature contained in a font, it must follow the
>    syntax rules for these tags. As specified in the OpenType
>    specification, feature tags contain four ASCII characters. Tag
>    strings longer or shorter than four characters, or containing
>    characters outside the U+20-7E codepoint range must be treated as
>    invalid.  User agents must not use a feature tag created by
>    truncating or padding the string to four characters.
>

Whether this is a good thing to do depends, it seems to me, on whether 
we want font-feature-settings to be explicitly targeted at the OpenType 
model, or to be a more general property that could, at least in 
principle, be used to control other font-rendering backends that might 
take a different approach to identifying features that the user may want 
to control.

For example, in the AAT font model, features are not identified by 
4-character tags; they use pairs of integer values (feature, selector), 
but also provide human-readable names for features; users would not be 
expected to have any awareness of the exact numeric values involved, and 
font designers are not constrained by any registry of possible features. 
In a hypothetical (but hardly far-fetched) UA that provided support for 
user control of AAT features, I'd expect to be able to say something 
along the lines of

     font-family: "Hoefler Text";
     font-feature-settings: "Style options=Engraved Text";

or

     font-family: "Charis SIL";
     font-feature-settings: "Alternate forms=Literacy 
alternates,Barred-bowl forms",
                            "Uppercase Eng alternates=Capital N with tail";

where the font-feature-settings values are a list of strings that the 
font system will map to the font's internal feature/selector codes, but 
do not at all resemble OpenType tags.

If we expect that font-feature-settings might some day be used for 
systems other than OpenType, then, perhaps we shouldn't try to enforce 
the specific form of OpenType tags at the CSS syntax level, but rather 
say that syntactically, any <string> is valid. A <string> that does not 
conform to the requirements of an OpenType feature tag will of course be 
ignored by the font-rendering backend, just as a valid OpenType tag that 
doesn't happen to be supported in the current font will be ignored; but 
it would not be a CSS error that leads to the entire rule being discarded.

Alternatively, if we want to define the CSS syntax here to enforce 
OpenType tag rules as strictly as possible, perhaps the property name 
should make it explicit that it's addressing OpenType; 
font-feature-settings-opentype or something like that. (Leaving room for 
font-feature-settings-aat with different syntax, or other 
font-feature-settings-* properties designed for other, as-yet-unknown 
technologies.)

JK

Received on Friday, 20 April 2012 08:14:06 UTC