Re: [css3-fonts] font descriptor default values

Hi Thomas,

> If the notion of "family" is platform-defined means that CSS font
> definitions based on family+style are inherently not cross-platform
> for any family more sophisticated than four members, and trying to
> deal with such families is likely to lead to frustration. Only because
> the available/usable fonts have been so restricted has it not surfaced
> as a "real" issue.

The underlying problem here is the way TrueType/OpenType defines family
groupings, the problem is not one specific to CSS; developers of
applications that attempt to create cross-platform documents with font
settings will run into the exact same problem.

For background, the TrueType spec defines a family name and a style name
for a font but allows for multiple versions of these by platform (i.e.
Apple or Microsoft) and language/encoding so that style names like
"Bold" can be localized.  For compatibility with applications that only
have bold/italic controls, Microsoft declared that only four faces
should be grouped under a single family (regular/bold/italic/bold
italic) and GDI font api's group fonts together this way.  For larger
font families, Microsoft introduced a second family name, "Preferred
Family", to be used by applications wishing to group together large sets
of font faces into a single family.  There is no support for this in
GDI, applications need to poke around in the font tables to do this. 
Fine for Adobe, kinda sucky for the rest of the world.  Cocoa apps on
Mac OS X group by the *Mac* flavor of family name for which no such four
face restriction exists.

So the question boils down to "how do we get richer font family
groupings on Windows?".  I think the answer to that is that user agents
on Windows need to move towards grouping font faces by "Preferred
Family" if it exists, which means pulling data out of font tables. 
Current versions of Windows don't ship with extended font families so
this really only affects folks who have installed fonts or use Adobe
apps that install extended font families.

The other thing to note here is that the CSS font selection model was
originally meant to be somewhat font-format agnostic with the assumption
that platforms would do what's appropriate.  My intent with the CSS3
Fonts spec is to include a non-normative appendix that would describe
some of these issues with respect to TrueType/OpenType.

> > > Or the lack of font properties to sufficiently delineate full font
> > > families?
> > 
> > That's also a problem. The notion of properties only goes so far: in
> > the real world, some members of font families are distinguished by
> > arbitrary design variations that don't necessarily match the simple
> > weight/width/slope model. Optical size is the obvious and most
> > common one, and could be done as a property, but there are plenty of
> > simply arbitrary differences that are not amenable to a "property"
> > approach, and are best dealt with as an additional string.
> 
> That being said, weight/width/slope handles maybe 95% of the fonts out
> there, and is a great advance over just bold and italic.

Optical size as a separate axis of variation is interesting.  I know
Adobe ships with font families that include optical size variations but
is this commonly used by other font vendors?

> > It would be helpful to hear solutions you think might solve this
> > "fundamentally broken" model.
> 
> Two things need to be done:
> 
> - clearly define what version of "family" name should be used
> 
> - define appropriate means to disambiguate fonts which are not
> distinguished by weight/width/slope alone. Perhaps add a property for
> optical size, and the ability to specify an arbitrary string for part
> of the name.

Interesting, so the arbitrary string would map to what exactly?  You're
thinking of something WPF-ish where you try and match this against some
part of the style name?  Style name localizations are a big headache
here.  If only there were named variation axes... ;)

Regards,

John

Received on Wednesday, 4 March 2009 20:45:52 UTC