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

On Tue, 18 Aug 2009 09:56:54 +0200, John Daggett <jdaggett@mozilla.com> wrote:

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

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?

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.

[1] http://www.w3.org/TR/CSS21/syndata.html#strings

> I don't think there's a need here to document character limitations of
> Postscript names in the CSS3 Fonts spec.

Agreed, that was just an example of one possible limitation.

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

Right you are, should have been something like @font-face { src: local(MyNormalInstalledFont) } there I guess. Was just trying to explain what I meant, the syntax wasn't really important here.

> I think what you're getting at is "what's the behavior when only a single
> face is defined?"

Yes, that's pretty much what I was asking.

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.

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

...
> 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?

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 18 August 2009 16:37:15 UTC