Re: [css3-fonts] Comments on @font-face: local(...)

I am of course a broken record on this issue, but...

Why deal with locale-based differences in font family and style names,
but not platform-based differences?

I am still perturbed that a font is family = "Glurbish Light" and
style = "Bold" in Windows GDI but family = "Glurbish" and style =
"Semibold" on Mac OS X, and I think it's a problem. It can be solved
either partially or completely (depending on how ambitious and complex
one wants to be) if there's a spec for what user agents are supposed
to do across platforms.



2009/8/20 John Daggett <>:
> Erik Dahlstrom wrote:
>> Yes I see from the definition of <family-name> that there are special
>> rules for how to parse it when it's unquoted. I'm simply wondering if
>> that has any nasty consequences, take for example a family-name like
>> "}; * display: none;". That would be fine and wouldn't need either
>> escaping nor quotemarks?
>> Allowing the string to contain ")" can probably also be confusing. Let
>> me rephrase my question: would allowing the unquoted and more-or-less
>> unrestricted strings cause problems for user agents that don't support
>> @font-face or would the error-handling rules of CSS take care of it?
> I see your point, I think it makes sense to define the syntax of the
> single name enclosed within local() to follow the rules for a single
> name within a font-family list, since font-family has the same set of
> problems with characters like }, ;, etc and since the whole reason for
> allowing quotes to be omitted is to match the use of font family names.
> It makes sense to explicitly define characters that need to be quoted to
> prevent problems on older platforms.
> There's still one very tricky internationalization issue here, more
> clearly defining non-English font name lookup, both for font family
> names and for names used in local().  Support for localized family name
> lookup across browsers is sketchy currently. With most Latin fonts this
> isn't an issue since the font data doesn't contain localizations of
> family names, Arial uses the same family name across locales.  But this
> is an issue for CJK fonts, some platforms only match localized family
> names when the OS and/or user locale is set to that locale, which leads
> to inconsistency across browsers/platforms.
> There's a similar issue with local() because style names are localized
> in *lots* of languages and the set of localized names often changes with
> font version (e.g. the font data for "Arial Bold" has localized
> fullnames "Arial Negreta", "Arial Gras", etc. and set of names is
> different on Win XP, Vista, Win7).  I think it makes sense to simply use
> the English name as the "canonical name" for local() lookup, since
> Microsoft suggests that OpenType fonts always contain this and allows
> English name lookup under all localized versions of Windows. This was
> discussed briefly at the CSS March F2F but I still haven't put clear
> wording into the spec.  Not the ideal from an internalization standpoint
> and it would be somewhat inconsistent with localized font family name
> usage but it would assure fewer hiccups across implementations/platforms.
>> Minor nit: I'd like it very much if all the definitions had id's and
>> were linked to from where they were used in the spec, one example is
>> the <family-name> production which is used from a bunch of different
>> places.
> Makes sense, I've been meaning to clean up internal links in the spec.
>> What about a case like this:
>>    @font-face { src: local(foo) }
>> Does the spec forbid conforming UA:s from using that font since it
>> doesn't have a defined family-name in the @font-face rule? I couldn't
>> find such wording, though it is implied that that's the desired
>> behavior.
> Right, both font-family and src descriptors are required in @font-face
> rules; without properly formed font-family and src descriptors an
> @font-face rule is omitted completely.  The spec should state that more
> clearly.
> One ever so subtle ripple here is that even if the loading of all fonts
> listed in the src list fails, the font matching behavior does *not* match
> a situation where the @font-face rule is omitted.
>  @font-face {
>    font-family: BodyTextFont;
>    src: local(RegularFont), url(fonts/RegularFont.ttf);
>  }
>  body { font-family: BodyTextFont, Times, Georgia, serif; }
> If a given user happens to have a font with a family name "BodyTextFont"
> on their system it should *never* be used in the example above; either a
> locally available RegularFont or a downloaded version of Regular font
> will be used.  If both of these are available or fail to load, fallback
> to "Times, Georgia, serif" should occur.  The locally available version
> of BodyTextFont should *not* be used unless it is defined as the local
> version of serif or as a general default font.  Conversely, the use of
> BodyTextFont should not affect default font display except in cases
> where a user agent explicitly allows definition of serif and sans-serif
> via @font-face rules.
> Testcases for this:
> No user agent currently does this correctly. :(  And the spec should
> probably have better wording and an example to illustrate this.
>>> Whether a local face or a downloaded face is used, this is a family
>>> with a single face, the style matching is the same in either case.
>> That sounds good. Are you saying that it's fully defined by the font
>> matching algorithm in section 5? IMHO the wording is quite loose for
>> step 3, nothing there says how a font is "labeled" with particular
>> properties, would be nice if that could be made more explicit.
> Agreed, the font matching algorithm wording is definitely too loose
> currently and should explicitly note how synthetic rendering affects
> matching behavior.
>>> Fake slanting, double striking, these are all hacks. Synthetic faces
>>> suck, I take that as a given.  This is not confined to @font-face
>>> fonts, either local or downloaded, it's the same for normal platform
>>> fonts; they don't render the same across browsers.  Saying it's "not
>>> always possible" is wrong, it's just not always easy to coax API's to
>>> do what you want (oh I do so love Windows GDI). But I think
>>> differences in synthetic rendering of @font-face defined faces is
>>> completely under author control; define four faces for a given family
>>> and you'll never see synthetic rendering!!
>> That's acceptable, how about adding an (informative) authoring note to
>> that effect in the spec?
> That sounds like a great idea.
> John Daggett
> Mozilla Japan

"Men occasionally stumble over the truth, but most of them pick themselves up
and hurry off as if nothing ever happened."
- Sir Winston Churchill

Received on Friday, 21 August 2009 04:02:13 UTC