>Well, it is just as easy to make ugly text by squishing it (if too long)
>as it is to make it ugly by stretching it ...
>
>I think there are 2 difserent notions of this width field. There's (a)
>"width" allows matching widths betwesn browsers using fonts with difserent
>character widths, and (b) "width" prevents text from spilling outside an
>enclosing object. I intended it to be used for (a). I suppose (b) is
>valid but it is subsumed by (a).
>
>I assumed that authoring tools would automatically set the width field to
>match the actual width. Then on the browser that uses the same fonts as
>the authoring tool no scaling adjustment would occur.
In terms of practical world-construction, I think (b) is way more
important. Labelling an object is a common goal. The author
knows how big the object is, because it's specified explicitly.
For a variety of reasons [proportional fonts, the lack of information
provided in FontStyle], the author *cannot know* how big an AsciiText is
going to end up. And unless you work for SGI, you have to *assume* that
the authoring and browsing environments are difserent.
The techniques for squeezing and shrinking scresn fonts are something that
Adobe, Microsoft, and some other people have a pretty good handle on, but it
ain't done by anything as simple as spacing or bitmap-bashing. This may not
be on offer in VRML esaders today, but it would be insane to build the spec so
as to make it impossible.
>From the point of view of a world constructor, it seems pretty essential
to be able to supply a string, a set of dimensions, and rely on the browser
to make sure it's legible within those constraints. YON's interpretation
of width makes this at least possible. If 'width' isn't useful
for this, some other mechanism needs to be provided.
- Tim