W3C home > Mailing lists > Public > www-style@w3.org > August 1997

Re: Current Downloadable Font Status....

From: Todd Fahrner <fahrner@pobox.com>
Date: Fri, 22 Aug 1997 11:19:46 -0700
Message-Id: <v03102800b0237af6dd1a@[206.245.203.103]>
To: Clive Bruton <clive@typonaut.demon.co.uk>, www-font@w3.org, www-style@w3.org
At 2:36 PM +0100 8/22/97, Clive Bruton wrote:

>I'm not sure that I agree that a point is meaningless in this context, it
>is an absolute rather than relative unit (ie screen res cannot be relied
>on, so pixel based sizes will vary too), so would seem to give a better
>starting reference.

A point is a good starting reference in the physical world, and among
devices that respect absolute physical units. Printers worth their salt
know what a point is, but the display systems attached to 95+% of desktop
machines don't know a point from a pixel from a bit of sneeze-dew. Mac
users are generally out of luck unless they set their displays *physically*
to 72 dpi, as are most Windows folk unless their displays are 96 or 120 dpi
(hold a ruler up and count the dots...). I understand that some display
systems permit sophisticated users to map points to pixels however they
please. This will make points a good general unit as soon as 90% of users
have such a mapping as part of their personal profile, something that kicks
in when you enter a username and (network) password. Without rebooting -
perhaps even with a live point-to-pixel slider.... Let's say Windows 2002
is released in 2005, and reaches 90% penetration by 2009?

>So
>PCs either see type at the same size or smaller than Macs, the exception
>being Macs that run higher res screens.

More Macs run at higher than 72 dpi than Windows machines at higher than 96
or 120 dpi. So I stand by my assessment. Physical size is one thing, but
not really the most critical in low-res: pixels per glyph is more important
for legibility and typographical character than absolute size (within
reason, of course). Exhibit A: most Windows users have no trouble reading
7-point type on screen. Mac users? It's not primarily a question of big or
small, right or wrong, but of how how few points you can display before
your counters clog up.

Compare the exhibits here:

http://www.verso.com/agitprop/css/

Especially:

http://www.verso.com/agitprop/css/macns4.GIF

>>I may be ill-informed here, but is it not the case that one must specify
>>both a font color and background color when one "rolls" the non-font font
>>("portable font resource")?
>
>No, at least I don't think so, the "non-font" is a font as much as any
>other font as far as the browser is concerned.

irony intended.

>So the background and colour matter as little to the PFR as they do to a
>"real" font specified using the <FONT> set.

My suspicion comes from the HexMac PFR authoring tool for BBEdit, where
these values are solicited in the UI.

>> What happens to TrueDoc's anti-aliasing when
>>you're flying red text over a zebra-stripe background?
>
>It should anti-alias as any "real" font would (except the "real" font
>will maintain it's data integrity, ie the hints will work, stems will be
>straight, it'll look a thousand times better on screen).

The issue is whether the rendering engine or video system will be able to
compensate for the "real" background of the characters. If the
anti-aliasing is "hard-coded" to a single state or value, halos will appear
when the background varies in time or tonal geometry. The only way out I
know involves an alpha channel.

As for visual quality, I will expose my lack of discernment to the
typographical community by saying I don't think the anti-aliasing looks so
bad. Print fidelity may well be a different matter. I suspect that those
who hate TrueDoc on intellectual property grounds are experiencing a
certain synaesthetic distortion in their judgment of its visual quality. I
fear that such "thousand times better" rhetoric will discredit less
subjective objections to TrueDoc.

>>And what's up with the character encoding? The test page at this address:
>>http://www.bitstream.com/world/textest2.htm
>
>TrueDoc had in the past its own (randomised?) encoding vector, supposedly
>this was supposed to stop piracy:-). Looks in this case that the X
>represents the "Qu" glyph in Bernhard Modern Ext (expert set?)

Ah, yes: out with the new (Unicode), in with the old (Adobe's expert set
mappings)....


Todd Fahrner  mailto:fahrner@pobox.com  http://www.verso.com/

The printed page transcends space and time. The printed page, the
infinitude of books, must be transcended. THE ELECTRO-LIBRARY.
	- El Lissitzky, 1923
Received on Friday, 22 August 1997 14:09:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:51 GMT