- From: Todd Fahrner <fahrner@pobox.com>
- Date: Thu, 21 Aug 1997 21:08:16 -0700
- To: bchase@bitstream.com (Brad Chase), www-font@w3.org
- Cc: www-style@w3.org
At 6:10 PM -0400 8/21/97, Brad Chase wrote: >TrueDoc is an enabling technology for remotely imaging fonts used in >electronic documents. It is designed to be able image fonts used in >creating publications on any supported authoring environment on any >TrueDoc aware client. 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://pdf.verso.com/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) * Because TrueDoc will not work with other/older browsers anyway, and Netscape 4 partially implements CSS1, Netscape's introduction of a new way to specify font size in HTML is either an ignorant or a calculated way to confuse and retard the deployment of CSS as the standard presentation language for HTML. *gulp* 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")? 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? And what's up with the character encoding? The test page at this address: http://www.bitstream.com/world/textest2.htm ...still looks like this after downloading "98% of 43K": http://pdf.verso.com/truedoc/Xality.GIF .* I thought a major strength of live text/fonts over artwork was that the former could be searched, cut-and-pasted, etc. Yet here you've got "X" invoking a "Qu" ligature. Perhaps Netscape should introduce an ALT attribute to the FONT element.... TrueDoc strikes me as a 60% solution to a large set of hard problems. It may be the first to arrive at the party, but it's missing pants. * the screwed-up text below the "Xality" line is an artifact of SmoothType, not of TrueDoc. ____________________ For let us suppose, e.g., that someone makes a number of marks on paper quite at random, as do those who practice the ridiculous art of geomancy [web design - ed]. I say that it is possible to find a geometrical line, the notion of which is constant & uniform according to a certain rule, such that this line passes through all these points, and in the same order as the hand had marked them. --Leibniz, the other calculus guy
Received on Thursday, 21 August 1997 23:57:03 UTC