1. Can we avoid I18N issues in the first version?
How can we *not* avoid it?
2. Should we accept the FontStyle node?
I'm worried that it encroaches on HTML functionality. Shouldn't we use HTML
to specify styles? However, I don't think it's fair to make browser
developers parse HTML at this stage.
The above reservation aside, we need to do *something* with text styles.
This proposal is simple and generic, while providing for a fair amount of
expressiveness.
Chris's original message follows:
----------------------------------------------------------------------------
Well, I'm off on sabattical for 6 weeks so here's my quickie text proposal
before I go:
Text3
Fields:
MFString string - array of strings to display. Each
string
is a new line.
SFFloat spacing - Multiply this by the height of the text
for base-to-base vertical line spacing
SFBitMask parts - ignored for now
SFEnum justification - CENTER, LEFT, RIGHT
This is just like the inventor version. "Parts" is included for later
implementation. Origin is at the baseline of the first line. Horizontal
positioning is done with "justification". LEFT puts the left edge of the
baseline at the origin, CENTER puts the horizontal center of each line at
the origin and RIGHT puts the right edge of each line at the origin.
Size of the text in object space is determined by the font node. It's up
to the implementation how text is rendered. Variable complexity based on
distance from the camera or some performance metric is valuable (text is
often very complex) but not necessary.
----------
FontStyle
Fields:
SFFloat size - height of the font in object space (also
determines base-to-base vertical line spacing)
SFEnum family - TYPEWRITER, SERIF, SANS: the general look of
the text.
SFBitMask style - BOLD, ITALIC: modifications to the look.
This is the simplest font implementation imaginable. TYPEWRITER is a
fixed pitch font, serif or sans-serif. SERIF is a serif font, like Times.
SANS is a sans-serif font, like Helvetica. It gives the author a choice
of 12 font styles and unlimited sizes without being tied to a particular
style of font description.
----------
I'd like to see this simple implementation before trying to get into
issues of font changes within a string, word wrapping or full HTML
support. It gives enough support so we can have compact text
representation with the ability to adjust the complexity of the text to
fit the scene.
Note, too, that I have not dealt with the issue of international text.
This is a baby step, but I think it's a very important one.
____________________________________________________________________________
Intervista Software
Internet Visualization
415 648-2749
Tony Parisi
President [email protected]
____________________________________________________________________________