We all know too many text features. Articulating them is an excellent
idea!!!
> 1. Single line of text of a given size/position/orientation in the 3D
> world,in a default font. Useful for labelling objects (anything else?).
Let's call this simple 3D "text", However, we should make sure we do not
mean anything more that Glyph lookup - NO i18n (internationalization).
> 2. A VRML equivalent of Inventor's Text3 object-- multiple lines of text,
> unformatted, left/right/center justification (without the arbitrary
> extrusion feature).
Adding text features. As soon as we are interpretting line breaks, we
might as well....
> 3. Multi-line, formatted text, specified as font size, width of
> rectangle to format into, and position/orientation of the rectangle
> in the 3D world.
This is great! I've always wanted this. Call it TextInRect? TextFill?
> 4. Multiple fonts/styles for 1 and/or 2.
> 5. Internationalized (non-ASCII) text-- Unicode?? (does HTML do
> something here?)
------------------- the line ---------------------------------------
> 6. Arbitrary HTML (with inline images, hyperlinks, the whole 11 yards)
> formatted into a rectangle in the 3D world (actually, we'd probably want
> to limit it to the HTML stuff that can appear between <BODY> and
</BODY>...).
I think we need to plan to support everything above the line, and in
addition, annotation text (perhaps Billboard is the same). The question
is when and how.
> All of these can be faked using the current VRML spec, either by
> generating a ton of polygons or generating texture-mapped rectangles.
> I agree, a better way of specifying text is needed to save network
> bandwidth when transferring VRML scenes, save disk space on servers,
> and to make authoring easier.
>
> Screen-space objects cause lots of implementation headaches, I'd strongly
> suggest leaving out 2D (screen-aligned or always-on-top) text.
I believe that "annotation text" is extremely useful.
> Inventor's Text3 can extrude itself along arbitrary (linear or NURBS)
> profiles, which is a cool feature but which is certainly not a critical
> feature and which relies on having outlines available. I suggest
> keeping the specification simple enough that low-end machines can
> just use simple stroke
> fonts instead of requiring text to be rendered as lots of polygons.
There has been enough discussion about this to make me think that it needs
to be fixed NOW (in VRML 1.01).
There are some big issues: font, rendering and charset interpretation.
Here are four possibilities:
1) Window system text. (like annotation text). The text is drawn using the
window system in the default font. The browser would have a resource that
controlled the font. Location would be derived from a transformed world
coordinate. (defers font & charset issues, rendering burden on browsers)
2) No spec changes. Create a VRML library of glyphs that people can use if
they need to have text now. (defers all issues, burden on VRML creators)
VRML files become huge (like .PS filkes that carry all of the fonts).
3) Simple 3D text, a few public fonts that are mandatory. Browsers can
either ensure the 3D rendering system has the right fonts or interpret
text and render it explicitly. (simplify all issues)
4) Real internationalized text with line breaks and extrusion. A system
of font metrics allowing the VRML creator enough control, but using the
system 3D fonts for performance. (or text in a rect feature).
YON, jch@oki.com, Jan C. Hardenbergh, Oki Advanced Products 508-460-8655
http://www.oki.com/people/jch/ =|= 100 Nickerson Rd. Marlborough, MA 01776
Imagination is more important than knowledge - Albert Einstein (1879-1955)