The folowing is my attempt to state various peoples opinions, as I presently
understand them. It is not my intention to misrepresent any one, but only to
set this down so that we can have a focus. I welcome corigenda and alternata.
The following people are cited:
(Dana) myself, Dana S Emery.
(Nate) Nathaniel Borenstein. (recent mail)
(Ned) Ned Freed. (recent mail)
I think a bottom up approach is called for so:
As I see it, the direct character styling commands are:
* <Bold> gets bolder (ignore where impossible).
<Italic>
* <Underline> get additional subset underlineing (ignore where imposible).
* <Smaller> cumulative effect, but for calculation, see below.
* <Bigger> "
x <Fixed>
* <Subscript> becomes lower.
* <Superscript> becomes higher.
x <ISO-8859-?>
x <US-ASCII>
-----------
* marks those which have the stated obvious meaning when nested.
x marks those which seem to have no meaning when nested.
For Italic, it has been proposed:
(Ned) toggle.
(Dana) ignore the redundancies (as with undefined commands).
For Smaller and Bigger the calculation is in dispute:
(Ned) proposes a formulaic cumulative: <S><S><B>...</B></S></S> would
have calculateable results, once a base size is determined (presumably
by the user).
(Dana) proposes hierarchically indexed user specified sizes st <S><S><B>
is deemed an error (avoiding </S> = <B>, and </B> = <S>).
For Sub/Superscript, I wonder if the traditional meaning of shift and shrink
should be rendered as conjoint primitives: <Subscript><Smaller>..., and
<Superscript><Smaller> rather than just <Subscript>... or <Superscript>. This
will allow the flexibility to do <Superscript><Bigger>... where that might make
sense.
---- My defense of the above positions:
Italic: I dont like the toggle concept. We already have this ability, and dont
need to usurp the possibility of degrees of italization. It seems inconsistant
with the rest of the usage.
Smaller/Bigger: Many GUI terminals cant display 11.333 point type, ATM/Truetype
are not universal standards (yet). Most gui's wont make a visible distinction
between 9.5 and 10.2, as both will render as 10. IMO, we should be addressing
the needs of casual mail, not attempting an alternative to LaTex. and should
provide a kinder, simpler mechanism. Perhaps an embeded indication of the size
(as composed) ala:
<Size-nnn>...</Size-nnn>
Barring that, I submit that toleration <S><S><B>...</B></S></S> is desirable,
but providing it with a calculated meaning is dangerous.
I leave the more complex commands to a later discourse, and remind you of Erik
Naggum's previous submission 'RichText and SGML', which addreses the question of
SGML interpretation of RT documents. (thank you for the copy Erik).
----
Dana S Emery <de19(_at_)umail(_dot_)umd(_dot_)edu>