Re: Current Downloadable Font Status....

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
>standards issue:
>
>* 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
>type 25%
>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 
starting reference.

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:
>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?), which 
you're failing to load for some reason, and I can't see at all since I'm 
using Navigator 3.01.


-- Clive

Received on Friday, 22 August 1997 09:52:48 UTC