Re: [css3-fonts] font descriptor default values

On Tue, Mar 3, 2009 at 9:12 PM, Michael Day <mikeday@yeslogic.com> wrote:
> Hi Thomas,
>
>> In OpenType and TrueType, there are a variety of name fields
>> available, and font developers can express the "real" family grouping
>> just fine alongside the GDI-friendly one. But that's not what gets
>> shown to GDI apps, including browsers AFAIK. Mac OS doesn't have these
>> restrictions, but as long as any major OS API does, there's an issue.
>
> Given that Linux with Fontconfig does not have these restrictions either, it
> seems that the issue here is one of Windows-specific hackery necessary to
> compensate for its broken font support, until the platform itself can be
> improved in future versions.

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.

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

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

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.

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.

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

-- 
"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 Wednesday, 4 March 2009 07:37:10 UTC