Re: [css3-fonts] font descriptor default values

Michael Jansson wrote:

> I thought I mention a few caveat here. Browser needs to explicitly
> manage the name of installed web fonts. 

Indeed, but that's exactly what I mean. The way CSS @font-face is set up
is so that it serves as an intermediate abstraction layer for font
naming. As I just tested, this:

 @font-face {
 src: url("fonts/ItaliaMdTT.ttf") format("truetype");
 }
 BODY { font-family: "ItaliaMdTT" }

does not work at all in Safari 3.1/4.0 nor in Firefox 3.1. So the
browsers currently do not seem to parse the naming entries for web
fonts, and I don't necessarily consider it a bad thing -- for exactly
the reasons you mention. The API system calls WILL deliver different
results on Mac, Windows and Linux, and the localized name entries only
add to the confusion. So, perhaps by accident, the implementors of CSS
@font-face chose the path of requiring the web developer to explicitly
set up the naming scheme and style linking in the CSS, completely
disregarding the definitions in the font files themselves -- as those
are overly complex and not reliable in a cross-platform scenario.

As I just mentioned, what would be useful is a _guideline_ on how to
arrive at good _initial_ names when adding .ttf or .otf files into web
authoring applications (i.e. it would be the web authoring app that
would parse the font file's naming entries), and this guideline should
of course recommend that the "better" name table entries should be read,
i.e. the prefereed OpenType family names and style names etc. This would
allow the scheme to break free from GDI limitations -- but of course it
would require web authoring apps to have knowledge of the OpenType
structure, i.e. they would need to parse the "good" naming fields. This
could of course happen through their own code or through some shared
libraries or, if the OS is good enough to deliver the "good" names by
default, by some system API calls.

Of course the browser implementors of CSS @font-face might in a later
phase choose to provide a fallback mechanism, i.e. if the web developer
does not set up the naming scheme in the CSS explicitly, the browsers
could attempt to parse those themselves, so that the snippet I mentioned
above would, after all, work. In such case, the "guideline" would have a
more binding character.

Since you just mentioned that the browser makers should parse for other
things such as embedding bits, I guess one way or another, browsers will
need to natively parse the OpenType font format anyway. But this is no
different from browsers parsing PNG images or SVG files -- my
understanding is that they do not necessarily rely on system API calls
in such cases but rather prefer to handle the assets themselves.

A.

-- 

Adam Twardoch
| Language Typography Unicode Fonts OpenType
| twardoch.com | silesian.com | fontlab.net

I hate to advocate drugs, alcohol, violence, or
insanity to anyone, but they've always worked for me.
(Hunter S. Thompson)

Received on Wednesday, 4 March 2009 10:37:45 UTC