Re: [css3-fonts] font descriptor default values

Thomas Phinney wrote:
> Windows Presentation Foundation has complex heuristics for getting
> from real font names to ones that have been munged to fit the CSS
> weight/width/slope model. It comes up with family and style names that
> fit the WWS model.
>
> This is needed because the CSS WWS model of families doesn't precisely
> match *any* real-world fields in fonts, despite there being so many
> font family names fields to choose from.
>   
Another way to look it is that WPF munges the name in order for the used 
family/weight/style information to select the right font with the font 
matching logic in GDI. Many apps do their own enumeration to work around 
this problem.

>   
>> For example, if a page asks for "900 12px Arial", then arguably the normal
>> weight of "Arial Black" would be a better font face to provide than the bold
>> weight of "Arial". But what kind of naming conventions would be necessary to
>> make this work, given the lack of API cooperation?
>>     
>
> Many/most font developers are already doing as much as they can in the
> font format. All the needed info is there. If OS APIs don't expose it,
> there's not much a font maker can do. Breaking GDI apps does not seem
> like a reasonable option.
>   
Indeed, although I wouldn't go as far as saying that GDI don't expose 
the needed information. Perhaps hides it :-) You have to do a bit extra 
work to get the right font.
>   
>> Could font authors and user-agent developers make an arrangement to work
>> around the limitations?
>>     
>
> Most font developers are already doing their part. If user-agent
> developers were willing to go the extra mile to look at other data in
> the font (at least, where platform APIs are inadequate), that could
> resolve the problem. But there would need to be a common spec about
> WHICH family field would be used in which font format (with
> appropriate fallback schemes).
>   
Indeed. I don't think anyone with a fair understanding of for example 
OpenType would have any problems in selecting the correct font based on 
family name though.
> That still doesn't resolve how one gets from real-world font family
> names to WWS font family names (or changes the latter to deal with the
> former). But it is the larger part of the problem.
>
>   
>> It doesn't seem like a good idea to complicate CSS to address an issue
>> currently affecting one platform,
>>     
>
> When cross-platform behavior is the desired result, anything that
> affects one platform (especially the biggest one) is just as much a
> cross-platform-consistency problem as a single-platform problem.
>   
Indeed.
> But in any case, the existing spec is inadequate because "family" is
> never defined in a way that actually relates to fonts or the real
> world.
>   
I'm a bit partial here. I think the notion of the "family" is clear 
w.r.t. the used font format. However, it's not spelled out in CSS, and 
browser vendors may not be experts on all the font formats that are used 
by a browsers. They rely on the platform. In cases, where the platform 
is inadequate, it would certainly help to amend the specification with 
implementation guidelines. I'm not sure if it is appropriate to have 
such platform and font format specific information in the CSS spec 
though. Perhaps a separate technical paper?
> In order to solve the problem, one also needs to know whether the
> possible string values of "family" need to be constrained to = [a
> family whose members all have unique WWS combinations] or not. If the
> answer is "yes" then one has to do something like the WPF approach. I
> don't much care for this Procrustean bed, but if it has to be done,
> then MS did a pretty good job of it.
>
> Basic info on this in a presentation of mine here:
> http://blogs.adobe.com/typblography/atypi2006/CSS%20&%20OT%2015.pdf
>
> There's a Microsoft white paper on the subject with much more detail,
> but I'm not immediately finding it online, and I need to get to bed
> now... maybe later.
>
> T
>
>   

Regards,
Em2 Solutions AB
Michael Jansson