Well, unless SGI is planning to produce some tools to enable this (on
multiple platforms), I think this will be a long, hard sell.
I have said before that I tend to be a ISO 10646 / UTF8 fan, and the
text node I outlined is admirably (possible even biased toward) using
it. One the other hand, I invite you to talk to someone like
Mr. M. Ohta, to see what response you get....
I prefer to avoid the conflict, and instead design an open-ended
system that will probably evolve along the desired direction. Despite
all the good reasons for simplification, one must take a wider view on
this: it is not a purely technical issue, because it affects the way
people can use the medium to *communicate*.
>2. Some parts of the proposal give duplicate information-- e.g. the
>MFOctet giving the number of characters to be parsed. Nuke those,
>too.
There is no duplicated information other than the fact that you can
calculate the number of characters from the data_length + encoding
pair. I included this for 2 reasons:
1) To allow one to validate that the text arrived whole
2) Systems that do not support an encoding will not know how many
characters are in the data stream. By adding this information,
they could display n questions marks or whatever.
>3. MFOctet should just be MFString, and we'll extend MFString to
This will only work for UTF8.
>5. Several of the fields that you specify as integers I think should be
>floats.
Fine with me.
>FormatSpec {
> SFFloat width # ??What's the default??
> SFFloat height # ??Default??
>Issue: Is there a way of saying "As big as it needs to be??"
I imagined that the text would be *scaled* to fit this, and so I do
not think there needs to be a way of saying "as big as necessary".
>Issue: Is text affected by the current material? Is text lit? Can it be
>textured?
Yes!
>Text {
+ coded_character_set = "ISO 10646"
+ encoding = "UTF8"
+ language = "en"
> data "Hello, World"
> FontSpecification {
> family "Times-Roman"
> size 7
> }
>}
A couple more issues:
>Inventor's hierarchical property model can be pretty useful in the
>context of VRML.
...
>Should you be able to do the same sort of thing with text properties?
This sounds reasonable to me.