W3C home > Mailing lists > Public > www-font@w3.org > July to September 2012

Re: [css3-fonts] default font features

From: John Daggett <jdaggett@mozilla.com>
Date: Sun, 8 Jul 2012 17:48:09 -0700 (PDT)
To: "Adam Twardoch (List)" <list.adam@twardoch.com>
Cc: www-style list <www-style@w3.org>, www-font@w3.org
Message-ID: <1072720518.6055937.1341794889630.JavaMail.root@mozilla.com>

Adam Twardoch wrote:

> It is known that WebKit tries to render text fast by disabling
> kerning and some other features by default. I can sympathize with
> that. After all, they do have their text-rendering:
> optimizeLegibility property. I would, however, expect that with that
> setting, WebKit should apply all the default features (for standard
> scripts: ccmp, locl, mark, mkmk, liga, kern, perhaps also rlig, clig
> and calt). If it does not, I'd consider this a bug.

This is precisely the problem, the model where kerning and ligatures
are off by default effectively creates a two-mode environment for text
rendering, a default "plain text" mode and a "typographic mode" with
no clear boundary between the two and no real advantage to users.
This is in effect letting the details of implementation dictate the
authoring model. The result is that a seemingly unrelated property
setting (e.g. font-feature-settings: "blah" on;) suddenly enables
other changes (e.g. ligatures, language-specific features) because,
unbeknown to the author, that change caused an implicit mode
switch.  What causes a mode switch?  Setting a non-default value of
font-feature-settings?  Using a script that requires shaping (e.g.
Arabic, Devanagari, Thai)?  Explicitly enabling kerning?  The use of
vertical text runs that require vertical alternates?

One of the underlying differences in text performance is not the
actual time needed to deal with kerning data for example, but the fact
that the "plain text" code uses a very simple API call that's been
tuned and the "typographic mode" code uses a catch-all API that
handles *all* complex text and hasn't been tuned nearly as much.  The
bottom line in the kerning case is that once you're pulling glyphs and
advances from font data, also pulling the kerning pairs is a very
small delta on top of that.  There's a bit of a catch-22 situation
here, since the complex text path is used infrequently there's much
less incentive to optimize it.  It also ends up generally having more
bugs, because certain features are tested with the "plain text" path
and not the complex text path (see [1] for an example).

> Alternatively, I'd recommend an additional value for
> font-feature-settings: default -- this would work differently from
> normal. The value normal should leave all the decisions to the
> browser whether to apply any features at all. The value default
> would apply all the default features, which should perhaps be
> enumerated by the spec.
> So the value default would be more restrictive: it would say "do
> apply features, whatever they might be". The value normal would just
> say "it's up to you whether to apply any features or none at all".

What you're describing here is the 'auto' value.  To allow for
two-mode behavior you'd need to make 'auto' the default value for all
properties that affect default feature settings:


When 'auto' is set for *all* of these, a user agent specific mode
(with unspecified defaults) would be used.  Any use of a value other
than 'auto' would kick in the defaults defined by specs like OpenType.

This model makes good text rendering an "opt-in" model.  I strongly
believe authors and users should have good text rendering by default
and not have to opt in to it.  The impetus should instead be on
browser vendors to optimize their text layout code so that performance
considerations aren't an issue here.  I think that's definitely
possible and much better for the web in the long run.


John Daggett

[1] https://bugs.webkit.org/show_bug.cgi?id=86071
Received on Monday, 9 July 2012 00:48:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:36 UTC