>7 bit ASCII is the only currently defined encoding of VRML files so
>supporting anything more than this would require escaped characters
>in text strings.
This should be fixed, and certainly should not be used to justify
limiting text string support to only the character set and encoding
least in need of a compact representation! I would suggest one of:
1) Add a charset and encoding parameter to the MIME type for VRML
files.
2) Specify Unicode as the character set and UTF-7 or UTF-8 as the
encoding.
3) Provide some way for the character set and encoding to be
specified on a per-node basis.
I prefer number 3, personally. This means that the syntax of VRML must
require that the character set and encoding be specified *before* the
text field.
>AsciiText
OK. If you label the node AsciiText, I can accept this simple
proposal, though it seems wasteful to define multiple text node
types... below I'll discuss the fields you define and point out why
they are not really suitable.
>MFString string
We have no idea what the character set of encoding of these are. Even
if we assume ASCII, can you assume an encoding of 1 code point per
byte? What if I used a 6 bit encoding, or a 24 bit encoding?
There should be a character set and encoding field on each node that
*precedes* the string node (possibly better named "text").
>MFFloat width
Width is a rather strange thing to specify for text, and is usually
calculated using font dimension information. It is better
to either not specify the size, and let the object figure out it's
optimum size, or specify the bounding box, and let it figure out how
best to fit itself into the box. Ahh, but below height is specified
based on an assumption of writing direction and layout....
>SFFloat spacing - Multiply this by the height of the text for
>base-to-base vertical line spacing
This assumes a single writing direction, and layout. What if I wanted
to do vertical text? Also, "spacing" is probably a very bad name as it
conflists with some accepted terminology from the text processing
world (have a look at some books on typography for the correct terms),
and again, this is usually calculated from font information, rather
than being specified directly.
>SFEnum justification - CENTER, LEFT, RIGHT
Well, LEFT, CENTER, AND RIGHT have little meaning for vertical writing
systems, or bidi systems.
So, again:
Text
Fields:
SFFloat width
SFFloat height
MFString coded_character_set
MFString encoding
MFString text
is not too bad for the moment. Other fields can be haggled over in the
future (for example, how to specify alignment etc.)
>FontStyle
Thinking again about this, I think more typographically correct node
type is required.
>As I have said before text not representable in this node can always be
>included as polygons.
This is interesting. I can imagine fonts and font servers where the
glyph images are defined using VRML. This seems to argue for wide
adoption of Unicode...
>Does this seem like a good form for inclusion in VRML 1.0?
In a word, no.
-- PS. I noticed your signature has reappeared. I often read mail via an 80x25 terminal... Internet rules of courtesy call for 4 lines..