Re: Embedding fonts

Thus spake Lawrance Family Member:
 
> I haven't seen a standard for embedding fonts, but I've seen Microsoft's
> CSS implementation of it:
>
> src: url(insert-font-here);
>
> Is this where CSS is headed in terms of embedding fonts?

It seems to be where CSS is heading, yes. The more controversial issue is
font format. There are two contenders.

Microsoft has implemented support for "OpenType" fonts, recognizable by the
.eot extension. Netscape has implemented support for "TrueDoc" fonts,
recognizable by the .pfr extension.

I haven't heard anything to suggest that Netscape will be supporting
OpenType anytime soon. However, TrueDoc is now usable in Internet Explorer
through an ActiveX control.[1] How do you and your readers like ActiveX?
You have to embed the control in the HTML of every page you want to use
TrueDoc in - can't specify it in the stylesheet and have done.

Technical and political issues aside (and there are many), I like TrueDoc
better from a designer's POV because it does not limit me to what will
always be a comparatively small set of well-hinted OpenType/TrueType fonts,
and because I despise the way these fonts have arbitrary, hard-coded
point-size ranges at which anti-aliasing may not occur. In Microsoft's
implementation, as you increase the size of an OpenType/TrueType font from,
say, 10 to 16 point, you suddenly hit a threshold where anti-aliasing kicks
in, and the shelf in perceived font weight and character destroys any sense
of continuous, graduated heirarchy you may have been trying to achieve.
Worse, if you let users pick the base font size through CSS (always a good
idea IMO), there's no telling where in the document heirarchy this
discontinuity will occur, so no way to compensate.[2]

Truedoc fonts get anti-aliasing at all sizes. Some people don't like this.
I think this is because they have become inured to the coarse bitmappy look
through years of primitive technological conditioning, or just haven't
spent enough time with really high-quality anti-aliased body copy. It can
take months for typographical famine victims to be able to digest solid
food again, and see real letterforms through the pixelly fuzz.

Unfortunately, Netscape (the TrueDoc implementor) doesn't implement enough
CSS to let you embed fonts through CSS. You still have to muck around in
the HTML, against the recommendations of the HTML 4.0 Specification.

I hope this will be fixed in an upcoming 5.0/Mozilla release. It's a little
late, but I'd also like to see some way to specify a list of fonts in
different formats in CSS @font-face rules, for UAs to sort out, so CSS
authors aren't forced to take sides in a proprietary font format war.
Today, if you use OpenType, you cast your vote for Microsoft and their
errant (IMO) type rendering. If you use TrueDoc, you can be browser-neutral
and pro-anti-aliasing,but only by means of ActiveX and deprecated HTML in
place of CSS.

I'm sitting this one out.


[1] http://www.truedoc.com/
[2] I think the argument for hard-coded "no anti-alias" point-size ranges
is that the type designer retains control of type rendering, which is
arguably a good thing, especially when you've got some expensive hinting to
show off. But I'll wager that these point-size ranges (not pixel-size
ranges) were chosen based on a logical resolution of 96 ppi (the Windows
default). At different logical resolutions, the range is out-of-kilter. I
fear that canonizing 96 ppi this way will inhibit the deployment of higher
resolution displays.

As usual, I welcome correction if I've got any facts wrong.


__________________
Todd Fahrner
mailto:todd@lowbrow.com
http://www.verso.com/agitprop/

Received on Sunday, 10 May 1998 23:15:17 UTC