W3C home > Mailing lists > Public > www-style@w3.org > April 2008

RE: My solution of webfonts problem

From: Paul Nelson (ATC) <paulnel@winse.microsoft.com>
Date: Sat, 19 Apr 2008 19:59:38 -0700
To: Dave Crossland <dave@lab6.com>
CC: www-style <www-style@w3.org>
Message-ID: <D92F7E6A79E88B4684BFC067AE15477D28C95AC06A@NA-EXMSG-S702.segroup.winse.corp.microsoft.com>
PANOSE is a poor structure when considering international content as it is script specific in meaning an has definitions for very few scripts.

Paul

Sent from my Windows MobileĀ® phone.

-----Original Message-----
From: Dave Crossland <dave@lab6.com>
Sent: Sunday, April 20, 2008 8:18 AM
To: Paul Nelson (ATC) <paulnel@winse.microsoft.com>
Cc: www-style <www-style@w3.org>
Subject: Re: My solution of webfonts problem


On 19/04/2008, Paul Nelson (ATC) <paulnel@winse.microsoft.com> wrote:
>
> > If the font's name collide with system fonts, the @font-face font
> > has higher priority.
>
> Currently, if the @font-family name collides with the system, [IE]
> assume[s] that the font is already installed on the system and there is
> no need to install the font.
> ...
> One can raise the issue of versioning of the embedded font being
> newer and having more character support. Likewise, one could have
> just the opposite situation where the embedded font is older than
> the one installed.
>
> How complex do we want to make the system?

I'm not sure the system ought to be complex on this issue. There are
two ways of doing it, to prioritise local fonts or web fonts. I say
web fonts.

The date is available from the caching-related HTTP headers, and CSS2
has a "unicode-range" descriptor -
http://www.w3.org/TR/REC-CSS2/fonts.html#dataqual - to compare Unicode
coverage without downloading the font and spending time comparing the
number of charachters supported with that of the local font.

In both cases, using the one with the newest date or the largest
number isn't useful, because it is not what the designer intended,
which is always the web font, so that should always be the primary
choice. I say the rationale for IE's approach is presumptuous.

You raise an interesting issue with Unicode coverage, though, which
does bring up the possibility of complexity.

If a local font has the same name as a web font and has wider Unicode
coverage, and the page includes text that should be rendered by the
web font with Unicode values beyond its coverage but that are covered
by the local font, should the UA mix the two?

Yes, perhaps. But the name is not best piece of metadata to do this
with, IMO; the PANOSE-1 descriptor -
http://www.w3.org/TR/css3-webfonts/#panose-1 - if available, is much
better. The text engine of a UA might have some FontChameleon style
feature to generate an appropriate type design based on the PANOSE-1
number, or even download the web font and analyse the shapes of glyphs
to find a close match from the available fonts on the fly;
http://www.yanone.de/typedesign/autopsy/ hints at the possibility, as
does Bitstream's WhatTheFont webapp. However, if the name is the only
piece of metadata to do it with, that might be a good idea.

--
Regards,
Dave

Received on Sunday, 20 April 2008 03:01:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:05 GMT