W3C home > Mailing lists > Public > www-style@w3.org > January 2011

Re: @font-face and slow downloading

From: David Singer <singer@apple.com>
Date: Mon, 17 Jan 2011 18:24:35 -0800
Cc: Yuzo Fujishima <yuzo@google.com>, www-style list <www-style@w3.org>
Message-Id: <00D5A1EB-C1E6-42BB-AB6D-EF64AB7C9024@apple.com>
To: John Daggett <jdaggett@mozilla.com>
Hi John

what I meant by 'as similar as possible' was not precise matching, but roughly 'gee if your custom font is monospace, at least choose a monospace font with about the same advance/font-size ratio as the fallback, and if your custom is condensed, try to find a condensed face as the fallback, and so on, so that text lays out roughly in the overall same-ish amount of space'.  Obviously matching all the metrics, line-breaks, word positioning etc. would mean, as you say, you've almost got the same font, so why bother with the custom one?

On Jan 17, 2011, at 18:13 , John Daggett wrote:

> 
> Hi Yuzo,
> 
>> John and other CSS Font people,
>> 
>> Can you update me on the status of the standardization for web font
>> tentative drawing behavior? What is the ETA?
> 
> I think your proposed wording looks fine.  Text display during font
> loading should be defined loosely enough to allow UA's flexibility.  But
> I would agree that the exact font metrics used should be those of normal
> fallback fonts, i.e. the first platform font in the font-family list or
> the font that would be used as part of normal system font fallback for a
> given set of characters. Using fallback fonts with similar metrics is
> actually problematic in practice, font metrics for non-monospace fonts
> vary widely and "similar metrics" requires a font explicitly designed to
> be similar (e.g. Arial was designed to mimic the metrics of Helvetica).
> As others have pointed out, the 'font-size-adjust' property can also
> help to some extent.  The spec should include a discussion of this, at
> which point we can review the exact wording.
> 
> A related issue is some form of event that fires on font loads.  This is
> needed for dealing with dynamically font loading and working with
> downloadable fonts in <canvas> elements.  An event like this would also
> allow more author-level control over visual display during font
> downloads.  If folks have ideas/proposals for this that would be good to
> discuss.
> 
> It's my task to edit the spec and I've been tied up with other tasks for
> the past few months.  I hope to work on these edits next month.
> 
> John Daggett
> 
> 
> On Tue, Nov 9, 2010 at 1:31 PM, Yuzo Fujishima <yuzo@google.com> wrote:
> 
>    I'd propose that we first agree on
>      Q1. whether the tentative drawing behavior is at UA's discretion or not
>    and then on
>      Q2. how the spec wording should be.
> 
>    As to Q1, I think it must be at UA's discretion (rather than document authors').
> 
>    Rationale:
>    1. Through the discussion so far, it seems to be very difficult to find a
>    common ground with that everyone is reasonably happy. Hence mandating
>    a behavior doesn't look reasonable.
>    2. Allowing authors to control this tentative and transitional behavior
>    seems to be an overcommitment for me, especially as a browser developer.
> 
>    As to Q2, I'd propose the following, deriving from David's:
> 
>    "when a downloadable font is used in a stylesheet, UA may, after waiting for download completion as long as it wants,
>    first use the fallback font for rendering as if all downloading have failed and then use the downloadable font
>    when the download completes.
>    It is recommended to the document author that the fallback font(s) have 'as similar metrics as possible'
>    to the downloadable font, so that, if the page is first rendered with a fallback and later with the downloadable font,
>    the degree of visual change, re-layout etc., is as small as possible."
> 
>    Yuzo
> 
>    On Sat, Oct 23, 2010 at 3:50 AM, David Singer <singer@apple.com> wrote:
> 
> 
>        On Oct 22, 2010, at 0:22 , Yuzo Fujishima wrote:
> 
>> 
>> Hi, David,
>> 
>> Sorry if I was unclear.
>> 
>> I think the temporary substitute and the permanent fallback should be the same if possible.
>> 
>> Put differently, I think the temporary substitute should be the same font as the font that
>> is used when all downloads failed.
>> 
>> Yuzo
> 
>        Hi, no problem.  We already have syntax for fallback, so we can document that it can also be used as a 'temporary' substitute (with no formal definition of how long temporary can be).
> 
>        So, should the specification say that "when a downloaded font is used in a stylesheet, a local fallback font must (should?) also be specified, and that the fallback font may be used by the UA when/while the downloaded font is unavailable.  It is (strongly?) recommended that the fallback font(s) have 'as similar metrics as possible' to the downloaded font, so that, if the page is first rendered with a fallback and later with the downloaded font, the degree of visual change, re-layout etc., is as small as possible."
> 
>        David Singer
>        Multimedia and Software Standards, Apple Inc.
> 
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 18 January 2011 02:25:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:36 GMT