Re: [css3-fonts] comments on ED of 24 May 2013

Jonathan Kew wrote:

> # Font family names must either be given quoted as strings, or
> # unquoted as a sequence of one or more identifiers.
> 
> This seems a little confusing: just above this, you say that
> <generic-family> names, being keywords, must not be quoted; but
> then this section says that font family names (of which
> <generic-family> is one type) can be given "quoted as strings".

Hmmm, ok, I've added "family names that are not generics".

> # monospace
> # The sole criterion of a monospace font is that all glyphs have the
> # same fixed width. This is often used to render samples of computer code.
> 
> Is this intended to exclude fonts that support any combining
> diacritics (having zero width) from being considered "monospace"?

Umm, this is hand wavy wording from 2.1.  Not sure I see any value
talking about combining diacritics in this context, just as a strict
interpretation of "monospace" is silly for some scripts.

Translation: *punt*

> # Wildcard ranges specified with ‘?’ that lack an initial digit (e.g.
> # "U+???") are valid and equivalent to a wildcard range with an initial
> # zero digit (e.g. "U+0???" = "U+0000-0FFF"). Wildcard ranges that extend
> # beyond the range of valid Unicode codepoints are invalid. Because of
> # this, the maximum number of trailing ‘?’ wildcard characters is four,
> # even though the UNICODE-RANGE token accepts six.
> 
> Why?
> 
> This does not make it clear (to me, at least) whether a range
> "U+?????" (or equivalently "U+0?????") would be valid (it
> doesn't "extend beyond the range of valid Unicode codepoints")
> or invalid ("the maximum number of trailing ‘?’ wildcard
> characters is four").

Oops, that should be five, you're right.  So u+0????? would be
valid but u+1????? would be invalid (because the range extends
beyond u+10ffff).  Rather than clipping it, making it explicitly
invalid avoids the problem of dealing with null ranges.

> # If the desired weight is 500, 400 is checked first and then the rule
> # for desired weights less than 400 is used.
> 
> Looks copy-pasted from the preceding rule; I think you mean s/less
> than 400/greater than 500/ in this case.

No, 'less than 400' is correct, weights 500 and lower map to lower
weights. Only in the normal case (400) is the behavior slightly
different, first 500 is checked, then lower weights are searched.

> # This means that explicitly disabling the kern feature will not
> # affect the application of kerning data found in the ‘kern’ table
> # (as opposed to kerning data associated with the kern feature in
> # the ‘GPOS’ table).
> 
> This sounds like it was describing a now-obsolete state of the
> implementation in Firefox. For UAs that rely on HarfBuzz for text
> shaping, this is not currently true: if the UA asks HarfBuzz to
> disable the kern feature, this will disable *both* the kern feature
> in the ‘GPOS’ table *and* the application of the ‘kern’ table data.
> 
> The connection between ‘GPOS’ and ‘kern’ table kerning is a
> low-level implementation detail; I'm not sure CSS Fonts needs to
> deal with this, but the current text does not describe what actually
> happens - at least for Gecko, but likely for other UAs as well if
> they use the HarfBuzz shaping engine.

While the 'font-kerning' property defines behavior that covers
old-style kerning data (i.e. the 'kern' table), I explicitly
did not extend the same behavior to 'font-feature-settings: "kern" on'.
The 'font-feature-settings' property is a low-level way of passing
down specific OpenType parameter settings, so defining "extra"
behavior like this is sort of odd.

I guess making an exception in this one case is okay but I definitely
think CSS should *not* be extending the meaning of specific features
by adding behavior to them ("let's have feature xxx mean .... when
conditions yyy and zzz are true").

> # For boolean features, a value of 1 enables the feature.
> 
> What does a value greater than 1 do for boolean features?

Just to frame the question here, the question is what values
greater than 1 mean in the context of 'font-feature-settings':

Example:

  font-feature-settings: "smcp" 2; /* on or off? */

The unfortunate answer is that this depends upon the font design.  For
simple substitutions, values greater than 1 will enable the feature
but for alternate substitutions, values greater than the number of
substitutions supported by the font will be equivalent to a value of 0.

I've added this wording:

    When values greater than the range supported by the font are
    specified, the behavior is explicitly undefined.  For boolean
    features, in general these will enable the feature.  For
    non-boolean features, out of range values will in general be
    equivalent to a 0 value.  However, in both cases the exact
    behavior will depend upon the way the font is designed
    (specifically, which type of lookup is used to define the
    feature).

While this behavior is not ideal from an authoring standpoint, in
practice I doubt it will come up very often.  For boolean features,
using a non-zero value will enable the feature.  It's only for
features like 'nalt', where the lookup type may vary across fonts.

Cheers,

John

Received on Wednesday, 29 May 2013 01:01:58 UTC