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.

Regards,

T

2009/8/20 John Daggett <jdaggett@mozilla.com>:
> 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:
> http://people.mozilla.org/~jdaggett/font-face/name-collision.html
> http://people.mozilla.org/~jdaggett/font-face/name-collision-bad-url.html
>
> 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:07 UTC