Re: font features in CSS

On Sun, Nov 1, 2009 at 8:28 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Mon, Nov 2, 2009 at 5:02 PM, Jonathan Kew <jonathan@jfkew.plus.com>
> wrote:
>>
>> It would also be wrong for us to try and divide features into two classes,
>> and insist that some can be specified only within the @font-face rule and
>> others within the content. It's true that if an author specifies certain
>> features in a context where the font is not known with any certainty --
>> e.g., system font fallback is happening -- then the results may be somewhat
>> arbitrary; but this is no worse than the unpredictability of using system
>> font fallback in the first place, when the exact glyphs that will appear are
>> not known, and depend on the fonts that happen to be on the user's system.
>
> Interpreting the alternates intended for one face in the context of a
> fallback face seems worse than normal fallback, to me. Normal fallback ---
> especially the language-based fallback with explicit per-language preferred
> fonts --- works because we've got a high chance of finding you a reasonably
> generic-looking glyph for your character. But with alternates and fallback,
> I think we've got a high chance of ending up with an alternate glyph that is
> stylized in a completely different way to what the author intended. So I
> suggest that on average, we'd be better off ignoring the alternates, if we
> have the "wrong" face.
>
> So another option would be to allow face-dependent options to be specified
> in content, but to ignore them wherever fallback occurs, i.e. whenever the
> font used for the text is not obtained from the first family in
> 'font-family'.

That makes a lot of sense to me. The rule for user agents would be:
turn off a few very specific features (notably stylistic alternates
and stylistic sets) when using fallback fonts.

T

Received on Monday, 2 November 2009 08:18:41 UTC