| I'm not suggesting that HTML got everything right, but if I don't like the
| way HTML does things then I'll argue it there, rather than trying to rehash
| the same arguments here. The transition from 2-space to 3-space should be
| as smooth as possible, and it would make like a lot nicer if we could use
| the same text representation in both.
| Some of our worlds have reasonably complex formatted text which is going to
| be tricky to do with the existing Text nodes, if we don't have a full rich
| text formatting language then we'll probably see the same thing that
| happens on the Web when HTML isn't up to the task, i.e. complex text will
| get shipped around as Bitmaps, dramatically increasing download times.
Understood, but your post to G. Nicol seemed a lament for not adopting
the HTML approach. HTML remains uninteresting to me but is a
fact of life for many, so I treat it as *yet_another_SGML_app* that chooses
to go its own way on certain issues.
I concur that VR can use a more complex formatting language.
I may be familiar with KA worlds as my son spends a lot of time
in Knowledge Adventures. Same group? Nice work, BTW and yes,
its requirements would be greater. But an external stylesheet
is a better solution for such requirements. A stylesheet should not
be included in VRML, but pointed to by it. Bound apps such
as are delivered commercially on CD-ROM can hide this
from the user easily enough. Isolate the issues that compel
a commercial VR system for standalone use to comply
completely with the public systems for the Internet.
The transition from 2-space to 3-space is an enchanting red herring.
Text is not 2-space in any meaningful sense and vrml only provides a
rendition of a 3-space. IMO, that issue is philosophical and not applicable
to the design.
The HTML group was looking at DSSSL-Lite last time I checked.
Perhaps this solution is amenable to VRML, but the size of the
solution and its complexity may be more than this group wants to handle.
Like HyTime, another steep learning curve is involved and is a matter for
application system designers to consider.
For the moment, I think Gavin Nicol has presented a good place
to start. For complex text formatting, the requirements
will be much more difficult and will involve non-VR disciplines.
If text is not a "vital" part of VRML, a simple extensible approach
should suffice until more complex requirements are defined.
The defaults should be set clearly and should be the "best
case". That all browsers cannot support all fonts is not
a difficult issue as long as the common defaults are supported.
This issue has already been resolved in word processor
applications. The results are sometimes *surprising* but
never *showstoppers*. Bitmaps are a kluge but
useful. Otherwise, when one needs a complex
mathematical formula, yet another set of definitions is
needed. VRML applied to say, training applications,
might need such facilties. VRML used to play games
on the Web might not. Acceptance notwithstanding,
we are patient when we really want the files. That was
longstanding tradition even when all we had was ftp get.
Len Bullard