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: Tue, 17 Jul 2012 12:41:32 -0700 (PDT)
To: www-style list <www-style@w3.org>
Cc: www-font@w3.org
Message-ID: <2094559548.23241999.1342554092720.JavaMail.root@mozilla.com>

Hi Sergey,

Thanks for the detailed response.

> Pulling shaping data like kerning from the font is not expensive.
> Expensive is finding right line break, and this can’t be achieved
> easily at the same speed as simple text layout pass. I just made
> quick measurements and Firefox is about 3 times slower than IE’s
> simple mode. As I understand, Firefox takes shortcut by interrupting
> shaping words independently, breaking context between them. This
> definitely can speed up layout, but will break highly contextual
> fonts. IE with default features enabled is 3 times slower than
> Firefox. Of course, this is simple text micro-benchmark, so
> difference in real life sites will be smaller.  

It would be interesting to see the test you're using here.  I don't
doubt the numbers you give but it's tricky to use an IE/Firefox
comparison as a representation of the difference between optimized
text rendering with and without default OpenType features enabled.  In
some of the profiling I've seen for the text-rendering case, Firefox
spends a lot of time doing the frame construction, the amount of time
spent doing the shaping is under 20%.  In other words, the 3x
difference you're seeing isn't necessarily due to a huge difference in
laying out text with and without features enabled.  Even in the mobile
case, in most cases text rendering time is *not* what gates

> I don’t say IE can’t be optimized, I know we can make it much faster
> even without changing public Windows APIs (my understanding is the
> Firefox uses Harfbuzz and have flexibility of using and optimizing
> functionality on very low level). But reality now is that
> performance is not something we can ignore. It is very high priority
> for IE, and management will expect convincing arguments to accept
> this performance hit out of the box. Especially if there is a
> trivial way to turn feature on through CSS. With many  system fonts
> getting OpenType treatment in Windows8, this will affect lots of Web
> pages.
> So, my preference is to have ‘auto’ as default, to use UA preferred
> rendering and ‘normal’ value, to give author control over better
> quality text without going into details of what is involved.
> Features like <ccmp> or <locl> would be turned on automatically
> under ‘normal’ or explicit feature settings because they are
> mandatory for script behavior, much like init/medi/fina for Arabic.
> So they can’t be disabled by using any CSS property.

As I mentioned before there are two big downsides to this approach.
First, it makes good typography an "opt in" model such that authors
must explicitly enable not because we think this is a good authoring
model but simply to make the authoring model conform to the existing
implementation structure of some user agents.

The other reason is because the auto / anything-but-auto switch leads
to really incongruent behavior where setting a property or using
complex script content results in unexpected side effects due to the
fact that default features are suddenly enabled.  With the Webkit
implmentation today, setting 'font-feature-settings' to 'blah' means
that suddenly kerning and ligatures are enabled.  The same sort of
thing would happen with other properties that affect feature use,
using a complex script such as Arabic, using vertical text, etc. 
Enabling the common features by default produces a much more
consistent user model.

I realize there's a performance cost to this but I think we should put
the burden on user agents to optimize this rather than trying to
define the model in such a way as to avoid the need to optimize.


John Daggett
Received on Tuesday, 17 July 2012 19:52:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 20:16:59 UTC