Re: Current Downloadable Font Status....
Todd Fahrner wrote:
> 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.
This is not a requirement of TrueDoc, which works equally well with
relative or fixed sizes. Indeed, the data that TrueDoc uses to image the
font on the viewing system is fully scalable, so that the glyphs can be
imaged at any size. You can see this by going to a page that does not
use the POINT-SIZE attribute (for example the Eyeballs page) and using
ctrl-[ and ctrl-] with Communicator to scalle all the fonts on the page.
>From a usage point of view, I tend to agree with you- absolute point
sizes are a BAD thing. ;-)
> 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")?
This is not true. TrueDoc doesn't really care what colors you use. It
captures the glyph shapes for later rendering at whatever color is
specified at the time of rendering. (This of course is necessary to
support both user style sheets and Dynamic HTML.)
> And what's up with the character encoding? The test page at this
> ...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....
Once you have 100% of that 43K, you will see "Qu" instead of "X". You
are correct about the X invoking a Qu ligature (which just happens to
have the character ID associated with X). I agree that there is room for
improvement here. Bitstream would be happy to work with you (or anyone
else) to implement improvements.
Good questions. Thanks.