Re: CSS3 Web Fonts issue with 'block on download'

On Thu, May 7, 2009 at 10:51 PM, Brad Kemper <> wrote:
> On May 7, 2009, at 10:31 PM, Oli wrote:
>> Is there anything else I can do to minimise this problem? If I include
>> other CSS3 Web Fonts properties (2.6 Descriptors for Matching, 2.7
>> Descriptors for Synthesis), are UAs planning to eventually use this data to
>> create on-the-fly substitute fonts, or will fouc issues mean
>> synthesised/matched fonts are only used as a last resort (rather than as an
>> intermediary stage)?
> The synthesized for intermediary is what I was trying to suggest. If there
> was a pre-installed font (shipping with the browser, perhaps) that had a
> wide axis from very condensed to very extended, then that could be used as a
> substitution until the rest of the downloaded font loaded, with each glyph's
> width chosen and/or stretched to match the size of the glyph in the
> downloading font. Then a repaint without reflow could occur when the font
> finished downloading, which wouldn't be so bad (it wouldn't interrupt
> reading).


To do that synthetic font substitution in a usable way would require a
multiple-master font and some very clever software using it...
certainly technically possible (as with Adobe and Apple's substitution
fonts for PDF), but a LOT of programming work compared to the rest of
the web fonts stuff.

> But maybe that still takes too much time to synthesize each width and
> position that way?

Performance might be an issue for doing this "live"... perhaps one of
the current Adobe or Apple fonts on the list can go consult one of
their engineers to get a reality check on that.

Also, AFAIK nobody has ever made a parametric substitution font for
anything other than Latin. As long as the font has been subset,
Latin-based languages are the least of my worries as far as download
times. Chinese and Japanese are normally monospaced, so reflow is a
non-issue there. But things like Arabic and the Indic languages can
involve fairly large fonts.



Received on Friday, 8 May 2009 06:11:46 UTC