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

Erik Dahlström wrote:

>  From http://dev.w3.org/csswg/css3-fonts/#ltfont-face-namegt :
> [[
> The notation for a <font-face-name> is the unique font face name
> enclosed by "local(" and ")". The name can optionally be enclosed in
> quotes. This also allows for referencing faces that belong to larger
> families that cannot otherwise be referenced.
> ]]
> 
> What characters are allowed to occur between "local(" and ")"?
> Postscript font-face-names have some restrictions, and I'm sure CSS
> does too.

The name is a string, there are no restrictions beyond that.  Obviously
for it to match the Postscript name of a given face, it will need to use
that name and hence the restrictions involved with Postscript names.  I
don't think there's a need here to document character limitations of
Postscript names in the CSS3 Fonts spec.
 
> In a local(...) declaration, if it is to mean a font face name as
> opposed to a font family name, should UA:s be allowed to apply
> font-weight and font-style to the resolved local font face?

Yes, for faces referenced via either a url() or local(), style matching
is done within a family using *only* the defined style descriptors and
not the font data.  If an author defines a single normal face for a
given family then it should be considered a family with just one face,
there are no "magic" links to bold or italic faces simply because
local() is used to define a face.  

> There are a couple of problem areas where it's really unclear what is
> to be expected. For example, what's the expected result of:
> 
>     @font-face { font-family: MyNormalWebfont; src: local(mnwf.ttf); }
>     .localfont { font-family: MyNormalWebfont; }
> ...
>     <p class="localfont">normal text. <b>bold text</b>.</p>
> 
> assuming localfont hasn't got a bold @font-face blend, what font
> should be used for the text in the b tag? the same font as if the <b>
> tag had been outside the <p> tag?

So the syntax here is wrong, local() doesn't match with font filenames. I
think what you're getting at is "what's the behavior when only a single
face is defined?"  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.

Here's an example:

http://people.mozilla.org/~jdaggett/webfonts/droidserif-direct.html

The first paragraph shows text using all four faces (regular, bold,
italic, bold italic).  The second uses a family with only the regular
face defined.  Note the difference in the way the 'y' in the italic
'rarely' renders.  Or the way the 'u' in 'surmount' loses definition
near the baseline because of double striking.  The third paragraph
should render exactly like the first paragraph but it uses an "inverted"
family, the styles are all reversed and the fonts are defined in reverse
(i.e. the regular face is defined with font-weight: bold, font-style:
italic). The style matching is done with style information in the
@font-face rule, not based on style information in the font data (which
might be on the other side of the wire when font matching occurs).

Other style matching tests:

http://people.mozilla.org/~jdaggett/font-face/synthetic-variations.html
http://people.mozilla.org/~jdaggett/font-face/synthetic-weight-style.html

These should match the reference pages:

http://people.mozilla.org/~jdaggett/font-face/synthetic-variations-ref.html
http://people.mozilla.org/~jdaggett/font-face/synthetic-weight-style-ref.html

> If UA:s are allowed to synthesize bold/italic on local font faces that
> is bad, since it is not always possible due to platform differences
> and since the results may not be what the author intended - it will
> look visually different/worse than a proper bold/italic font face. In
> testing it seems that UA:s differ in what they synthesize as well,
> which is yet another pain for authors.

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!!

> (the exception being FF352win, that doesn't apply bold to fonts with
> normal weight though it does apply italic to fonts with normal style).

That's a bug, fixed in our latest nightlies:
https://bugzilla.mozilla.org/show_bug.cgi?id=499621

> Moreover, in the spec there's an example like this:
> 
> @font-face {
>      font-family: Gentium;
>      src: local(Gentium), url(/fonts/Gentium.ttf);
> }
> 
> Now, if we wanted to use the (local) system Gentium font (which has
> italic and bold) we'd need to have explicit @-rules for these, which
> is a bit more work. This is sort of contrary to the idea of having
> local() mean a font face name. Should there be another way of saying
> "Please use a system font with this family-name if you have it"? A UA
> that didn't support @font-face would select the Gentium systemfont if
> the content said e.g <div style="font-family: Gentium">, ignoring all
> @font-face rules. If a UA that supported webfonts ran across the same
> testcase then the behaviour would be different.

The spec only includes the normal face for brevity.  If using an italic
face, define another @font-face rule:

@font-face {
     font-family: Gentium;
     src: local(Gentium Italic), url(/fonts/GentiumItalic.ttf);
     font-style: italic;
}

Mixing in references to local font *family* names makes style matching
*more* complicated, not less.

Regards,

John

Received on Tuesday, 18 August 2009 07:57:38 UTC