I agree that "RichText" is confusable with RTF, and I concur that spliting it
off is a good idea.
I should like to propose "LeanText" as an alternative name, and a more
appropriate concept.
Quite frankly, I submit that mail which requires sub/superscript or outdent
formating is better transported via a format which would be supported by an
external viewing agent (WordPerfect/FrameMaker etal).
I began a Mac-based implementation of a subset of RT last summer, and had to
shelve it for lack of clear semantics on several points, not the least of which
was the meaning of
<Smaller><Smaller>....<Bigger>...</Bigger></Smaller>...</Smaller>...
Given a size table of 6,8,9,10,12,14,16 with 12 as a norm, one could have
either <10><9>....<10>...<9><10>...<12>...
or <10><9>....<14>...<9><10>...<12>...
^^
even
<Underline><Underline>...
<Bold><Bold> ...
make sense, given the capabilitys of multiple-master fonts, and assuming double
underlineing.
All of which require not just a stack machine, but a level-counting stack
machine.
Another problem arose when I considered using a private verb for specifying
actual font names (necessary for symbolic fonts such as Dingbats/Carta/Sonata).
Since verbs are expresed with a limited number of characters drawn from a
restricted character set, it is not possible to use a
<X-MacFONT_Sonata> ... </X-MacFONT_Sonata>
approach, especially when one considers that real font names are not constrained
to 7-bit ascii content. Instead I considered useing a
<X-MacFONT> 12345 "Sonata" </X-MacFONT>...
approach, but am unhappy about both the verboseness and the violation of the
stack concept that it implies. (To the curious, the font number is useful, tho
non-specific --- it helps the knowledgable to distinguish between similarly
named fonts of different makers, and also indicates the language script
implicitly associated to the font.)
I would hope that any reworked version of RT would establish more definate
semantics, and possibly even punt <Smaller><Bigger> for explicit sizes (ie,
<Size-999> ... </Size-999>).
--
dana s emery <de19(_at_)umail(_dot_)umd(_dot_)edu>