< While richtext has it's problems, it's not clear to me why it can't be
< fixed (by clarifying the ambiguity, dropping the unnecessary
< functionality, etc.) but instead has to be thrown out and redone from
< scratch.
<
< While I believe the miniscule complexity of <center> et al is adequately
< compensated for by its benefit, the ambiguity of <center> in richtext
< could have been dealt with in other ways. <center> et al could have been
< declared illegal in the middle of a line or their semantics in the middle
< of a line could have been clarified. <Center>ing a single word could mean
< the much same thing as <indent>ing a single word.
<
< As I've mentioned before on this list, text/enriched is significantly more
< complex than text/richtext. This is primarily caused by the <verbatim>
< command, which establishes a completely different lexical mode. The
< effect of <verbatim> is quite noticeable in the minimal parser and it will
< similarly affect real parsers. There is no practical benefit to
< compensate for the additional complexity.
It took me about 1 day to convert the metamail richtext program to handle
text/enriched as well as text/richtext. (Yes, Nat has the changes.) The code
to handle <verbatim> is tiny (~20 lines of code). Even then, there are
probably other ways of coding it which would be shorter. The so-called
complexity of <verbatim> is a red herring.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony