Re: WebFonts

Bert Bos wrote:
> Yes, it is intended to become an integral part of CSS. But we do also
> want it to be applicable in other places where fonts are needed, even if
> they don't need the rest of CSS.
> 
> Although CSS is a single, internally consistent (I hope) system, it is
> not intended as an all-or-nothing specification. For example, a
> synchronized multimedia format[2] might use the positioning properties
> and backgrounds, but has probably no use for fonts. On the other hand,
> Java might want to use the Web Fonts, but doesn't need the other
> properties.

Modularity is good. The fact that it is all designed to be internally
consistent is also good. I don't understand, though, why it is all
"CSS"? WebFonts is "fonts for the Web". Java bindings should be as
central to the spec. as CSS bindings. Which is to say that in my opinion
a specific language binding should *not* be central to the spec.
 
> If you look at the Web Fonts as a black box with input and output, then
> the input consists of values for 5 properties: font-family, font-weight,
> font-variant, font-style, and font-size. The output is a font.

Right, but where can I find this description in the spec without a
syntax that is specific to CSS? The fact that this model is portable to
other systems is implicit, not explicit, in the normative text. Chapter
9 looks information for non-CSS implementors, but I don't see how it can
be considered normative text.

Let me use an example:

"1.The User Agent makes (or accesses) a database of relevant font-face
descriptors of all the fonts of which the UA is aware. If there are two
fonts with exactly the same descriptors, one of them is ignored. The UA
may be aware of a font because: 
    it has been installed locally 
    it is declared using an @font-face rule in one of the style sheets
linked to or contained in the current document 
    it has been previously downloaded over the web 
    it is used in the UA default style sheet, which conceptually exists
in all UAs and is considered to have full @font-face rules for all fonts
which the UA will use for default presentation, plus @font-face rules
for the five special generic families defined in CSS1"

Half of this information is generally useful, and half is specific to
CSS. I would prefer:

"1.The User Agent makes (or accesses) a database of relevant font-face
descriptors of all the fonts of which the UA is aware. If there are two
fonts with exactly the same descriptors, one of them is ignored. The UA
may be aware of a font because: 
    it has been installed locally 
    it is declared using the font agent's font declaration mechanism
    it has been previously downloaded over the web 
    it is built into the UA in some manner"

and then in another chapter:

"A formatter conforming to CSS may also be a font agent conforming to
WebFonts. If so, the font declaration mechanism is an @font-face rule in
CSS style sheets. @font-face rules have the following syntax. ... CSS
formatters may make available fonts used in the default style sheet."
 
> We have looked at how DSSSL characteristics could be mapped to these
> five properties, and the mapping is not very complicated. We will
> probably provide that mapping in some Note or other document. 

Right. I have no doubt that this is possible. If I didn't think that
your ideas were portable to other systems I wouldn't be asking you to
reexpress them.

> (Or if you want to do it? That'll save us some work...)

I'll leave that to James (if he's willing). He'll do a better job
integrating it with existing DSSSL features.

> As soon as it is part of DOM, you'll automatically have many new
> syntaxes (C, Java, Javascript, etc.), but I think it would be a bad idea
> to create alternative syntaxes just for Web Fonts. 

I'm not arguing that you should create new syntaxes, just that you
describe your five-point font generation and matching algorithm in terms
of an abstract syntax. You could even use CSS as your abstract syntax as
long as you are explicit that you are doing so, and do not build
normative references to the CSS specification into the portable parts of
the WebFonts specification. I think it would be a good idea to provide
at least one more language binding (in the spec or in another note) to
"check" that everything is really described generally enough. Java seems
like the most obvious choice. You would also get the push-back of the
Taligent and JavaSoft people as well as the rest of the development
community. Plus Java's font support could use work.

> Every new syntax
> means extra work for implementers, larger applications, less
> interoperability, more things for people to learn, and general
> confusion.

I don't really understand this last sentence. Clearly Java (etc.)
implementors of WebFonts are not going to implement it in terms of CSS
syntax. Doing so would create more work for implementors (Java CSS
parsers), larger applications (Java CSS parsers), more things for people
to learn (Java programmers must learn CSS) and general confusion. A Java
implementation would probably deal with font description objects rather
than CSS code snippets.

 Paul Prescod

Received on Saturday, 2 August 1997 02:33:09 UTC