Re: Current Downloadable Font Status....
To: firstname.lastname@example.org, email@example.com
Subject: Re: Current Downloadable Font Status....
From: Clive Bruton <firstname.lastname@example.org>
Date: Fri, 22 Aug 97 14:36:30 +0100
From email@example.com Fri Aug 22 09: 52:48 1997
MMDF-Warning: Parse error in original version of preceding line at punt-2.mail.demon.net
X-Authentication-Warning: www10.w3.org: Host punt-2b.mail.demon.net [18.104.22.168] claimed to be punt-2.mail.demon.net
x-mailer: Claris Emailer 2.0, March 15, 1997
Todd Fahrner wrote at 22/8/97 5:15 am
>Leaving aesthetic and legal opinions aside for a moment, my main beef with
>Netscape's implementation of TrueDoc has to do with the introduction of the
>POINT-SIZE attribute to FONT. There's both a usability issue and a
>* As I can easily and amply demonstrate, points are a meaningless unit for
>on-screen type specification across platforms. I hear frequently that more
>than 60% of commercial web sites are designed on Macs, where 1 point is one
>pixel, regardless of real pixel density. Points specified in this
>environment will end up looking much larger most everywhere else, and in
>the opposite case text is often unreadably small for us Mac folk. Compare
>the screenshot referenced in your post (
>http://www.bitstream.com/world/screen.htm ) with the one I took of it on my
>Mac: http://www.verso.com/agitprop/truedoc/pointless.GIF . (Not only is the
>smaller in pixels, the GIF of the rendering is considerably smaller than
>the live TrueDoc data)
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
I also think you got the scale factor back to front, if we accept that
Mac screen run at 72dpi (this is false - mine is running at just under
100dpi, and there are other available that run in excess of 120dpi), and
PC screens run at some higher rate. 72pt = 72pixels on the Mac, 72pt =
either 72pixels (at a higher res) or n pixels where n=dpi of screen. So
PCs either see type at the same size or smaller than Macs, the exception
being Macs that run higher res screens.
The problem seems to be of the OS or the browser understanding what a
point is, and that screen resolutions are variable (therefore
compensating for that). Then everyone will get type the same size, but
with different resolutions (effectively different pixel per em values)
>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. TrueDoc may be a font
rendering technology (ie it has its own TrueType and Type 1 rasterisers),
but PFRs are fonts, they are referenced and used *exactly* as fonts.
So the background and colour matter as little to the PFR as they do to a
"real" font specified using the <FONT> set.
>That means no cascading: yet another stumbling
>block for the standardization of CSS. If you don't believe in cascading,
>chances are you're really impressed with flying layers and the z-axis,
>which means your background color or image is likely to change, either in
>time or in x/y space. Often. 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).
>And what's up with the character encoding? The test page at this address:
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?), which
you're failing to load for some reason, and I can't see at all since I'm
using Navigator 3.01.