Re: [css3-fonts] opentype font feature support

On 4 Mar 2010, at 13:30, Christoph Päper wrote:

> John Daggett:
>> http://dev.w3.org/csswg/css3-fonts/
>> 
>> Included are additional properties for supporting OpenType font features,
> 
> Yay! But, …
> 
> the draft properties are very close to OT features. That is not really a good thing, since those are not coherently or consistently designed. In many cases a more abstract approach is more author-friendly and also does not discriminate against AAT etc.

I agree that the design of the OT features are not always ideal; nevertheless, this is the dominant font technology in the market, now and for the foreseeable future, so I think we have little choice but to look primarily (not exclusively) at this if we hope to see these capabilities implemented broadly and consistently. Attempting to create some kind of "abstract" approach that does not rely heavily on the existing implementation technology seems to me a recipe for unending debate, and for confusion among font developers and users who will struggle to understand the complex mapping between CSS's abstract model and the actual fonts in their hands.

> 6.1 font-kerning: normal | inherit | enabled | disabled
> 
> There are few properties that use generic on/off state names like ‘enabled’ and ‘disabled’. I would prefer not to see more of them, but I do not know which pair of words would be better here, ‘kern’/? perhaps.

I'd be happy to hear alternative suggestions, although as the draft does not currently include font-kerning as one of the properties controllable via the font shorthand, I don't think the generic "enabled" and "disabled" are particularly problematic here.

> 6.2 font-variant-ligatures: normal | inherit | <ligature-values>
>    <ligature-values> = [ common-ligatures     | no-common-ligatures 
>                        | additional-ligatures | no-additional-ligatures 
>                        | historical-ligatures | no-historical-ligatures 
>                        ]+
> 
> This probably would be written better like this:
> 
>    <ligature-values> =  [ common-ligatures     | no-common-ligatures ] 
>                      || [ additional-ligatures | no-additional-ligatures ]
>                      || [ historical-ligatures | no-historical-ligatures ]
> 
> Is this grade of control really necessary or useful? In which cases does ‘hlig’ not imply ‘dlig’ and where does ‘dlig’ not imply ‘liga’? 
> I read Adobe Indesign(?) only allows the user to switch on and off “discretionary ligatures”, which combines ‘hlig’ and ‘dlig’.

It's interesting that earlier, you're asking for something more "abstract", divorced from the particular implementation technology; but now referring to a specific implementation for guidance. Personally, I think our first reference should be OT feature registry (not a particular application's interface to a subset of the registered features).

> Table: Usefulness of combinations
> R | L A H use   L A H use   L A H use
> ---+-----------+-----------+-----------     Legend
> o | + + + yes   o + + ?     - + + no     R required      (rlig)
> o | + + o yes   o + o ?     - + o no     L common        (liga)
> o | + + - yes   o + - ?     - + - no     A additional    (dlig)
> o | + o + ?     o o + ?     - o + no     H historic      (hlig)
> o | + o o yes   o o o yes   - o o ?      C contextual    (clig)
> o | + o - ?     o o - ?     - o - ?      D discretionary (dlig+hlig)
> o | + - + no    o - + no    - - + no     + enable
> o | + - o ?     o - o ?     - - o ?      o default, normal, inherit
> o | + - - yes   o - - ?     - - - yes    - disable
> 
> I believe we can fulfill the Pareto principle (80:20) with four values besides ‘normal’:
> 
>     + + +             ‘all-ligatures’
>     + + -  or  + + o  ‘additional-ligatures’
>     + - -  or  + o o  ‘common-ligatures’, ‘ligatures’
>     - - -             ‘no-ligatures’ 
>     o o o             ‘normal’
> 
>  font-variant-ligation: full | most | some/partial | none | normal
> 
> For finer control there still is‘font-feature-setting’.

I'd be interested to hear from font designers whether the ligature features they implement are viewed as always fitting into this kind of strict hierarchy, where each "level" is expected to imply the use of all lower levels as well. Or are "historical" and "discretionary" ligatures potentially orthogonal choices?

> 6.3 font-variant-alternates: normal | inherit | <alternates-values>
>    <alternates-values> = [ stylistic(<number>) 
>                          | styleset(<number> [,<number>]+) 
>                          | contextual        | no-contextual 
>                          | contextual-swash(<number>) 
>                          | swash(<number>) 
>                          | historical-forms 
>                          | ornament(<number>) 
>                          | alt-annotation(<number>) 
>                          | ruby
>                          ]+
> 
> Now this part I don’t like at all. It lumps too much together with too many numbers. CSS is not designed to allow modifications on a per character level. We should go with the usual OT suggestion and assume that the first alternative variant in a font is the preferred one.

I interpret this suggestion in the feature registry as just that: a suggestion, primarily aimed at applications that are unwilling to extend their user interface to allow explicit selection from a set. I don't think CSS need (or should) be limited in this way.

>  That means drop all “(<number>)” and ‘styleset’ altogether.

No; certainly in the case of styleset, it is essential to provide a number (this maps to any of the 20 registered ss## features; whether implementations should limit it to the range 1-20 is perhaps an interested topic for discussion). Styleset features are the primary way some designers provide access to various collections of alternate glyphs.

> 
> For finer control there still is ‘font-feature-setting’.
> 
> 6.3.1 Swashes
> 
> I would prefer to have swashes fallback to italics, therefore:
> 
>  font-style: normal | italic | oblique | swash | inherit
>  normal < upright < oblique/slanted < italic < swash < cursive < script
> 
> That is, unless I am mistaken and swashes also worked well with upright faces. After all, there are upright italic fonts.

And there are "roman" fonts that include optional swash glyphs; Hoefler Text as shipped with Mac OS X comes to mind. The use of swash variants is an option within a particular font face; the choice between "normal" and "italic" styles is a choice between two different faces. Swash does NOT belong here in font-style.

> Hm, what about broken scripts, i.e. “blackletter”, “gothic”, Fraktur.

These are separate font families.

> 
> 6.5.2 Numerals
> 
>    <numeral-style>  = <numeral-width> || <numeral-height>
>    <numeral-height> = lining | oldstyle
>    <numeral-width>  = proportional | tabular
> 
> In <numeral-height> ‘oldstyle' is a common, but not an adequate term.

Why is it not adequate? I think it is the most widely used/understood term for this design feature; why not use it?

> Wikipedia knows the synonyms in the antonym lists following this paragraph numerals or figures (why not ‘digits’?). Surprisingly the alternative does not feature the common antonyms ‘modern’, ‘new-style’, ‘uppercase’ etc., but only ‘lining’ and ‘titling’.
> 
> Height                               Width
>   text       <> (table, tabular)       proportional    <> (constant)
>  *non-lining <> lining                 (variable)      <> (fixed)
>   lowercase  <> (uppercase)            (text, textual) <> tabular
>   antique    <> (modern)
>   old-style  <> (new-style)
>   billing    <> titling
>   ranging    <> ?
>   hanging    <> ?           Keywords in parentheses not found on WP.
> 
> Since not all of the 4 <numeral-style> variants may be available, the last matched should probably be used – or should a mismatch reset to default ‘normal’?

Numeral "height" and "width" are independent axes; if a font provides some but not all of the possible combinations, then the result of any given pair of features is determined by the font designer, according to the priority given to the various lookups in the font. Except where features are defined as mutually exclusive (such as the two options for width), and so later settings override earlier ones, the user agent does not care about the order of specification; it simply builds a collection of features that are applied to the chosen font. How those features interact within the font is out of scope for CSS, it is the responsibility of the font developer.

> There seem to be several OT features related to Indian, Korean, Khmer and Syriac scripts, do none of them require exposure to CSS authors?


No. (Like 'init', 'medi', 'fina', 'isol' for Arabic script.) These "belong" to the script-specific shaping engine and are applied automatically to the relevant glyphs. The various script-specific specifications on the Microsoft typography site document how and where they are to be applied.

I suppose some implementations might allow font-feature-setting to override these, but this would only be relevant in highly exceptional situations where the author deliberately wishes to "break" the normal rendering of a script.

> 6.9 font-lang-sys: normal | inherit | <string>
> 
> This property currently uses OT language tags which are not really well designed or know as far as I know. It would be better for authors to use [BCP47] and let UAs do the mapping.

Normally, text should be tagged with its [BCP47] language code in the HTML, and the UA should map this to the appropriate OT language system, as stated in 6.9. However, the reality is that the mapping from BCP47 to OT language systems is not always clear or unambiguous, nor is the collection of language systems actually supported in fonts consistent. There will be cases where users need to select an alternative "best fit" language system according to what is actually available in their chosen fonts, and it is not possible for browsers to handle this reliably by mapping from BCP47 codes.

JK

Received on Thursday, 4 March 2010 17:26:02 UTC