1) I have already written a text/richtext parser. It
was easy to write and I have the funtionality I need.
That has not been a universal experience, Several of us found
the original spec to be quite ambiguous as to how certain
operators should be handled when nested and other things as
well, many of us were relectant to implement all that
featurism, I dont have the resources of Microsoft or
Claris---getting bold/italic/single underline and font
sizes out of a macintosh is trivial, doing tabs, sub/superscript,
indented paragraphs, headers and footers is not so easy,
especially when one wants to support foreign language display.
Other platforms have different difficultys, but the bottom line
is that RichText was overly ambitious.
I, and others, argued that it was beyond the resources of this
committee to attempt a general document markup scheme, and
since there were commercial alternatives (several with
poly-platform asperation) we should limit ourselves to
something more likely to get implemented.
All sorts of functionallity got discussed, even polylingual
content, and there is no point in rehashing the details here,
please see the archives from last spring and summer, then this
winter for details.
Nobody seemed able to come up with a solution to fix RichText.
When a rewrite was profered, it seemed to fill the bill, and
it was issued a distinct name to avoid confusion between the 2.
Neither is an ideal system, given the multiple platforms from
which people try to access mail it is unlikely that any one
scheme will be implemented universally unless it is formulated
by such a committe as this is, the result is likely to be the
proverbial camel, so please bear with it.
Oh, I dont think text/RichText is recomended anymore, so you
would only be expected to support text/enriched
7) The automatic linebreak caused by the formatting
commands (e.g. <center>) is unnecessary.
<P> text1 <nl><nl> <C> text2 </C> <nl><nl> text3 </P>.
----begin rhetorical example
<P>The scope of <lit><center></lit> is not intuitive. One
possible use is for text set off from the body of a paragraph
<nl>
<nl> <C> such as this </C>
<nl>
<nl>and for this a natural reading is appropriate---and yes,
here, implied newline(s) before and after is a bit much.</P>
----end rhetoric example
How should this display?
<P> text1 <C> text2 </C> text3 </P>
Obviously, the beginning lines of text1, and the trailing
lines of text3 should be left set and wrapped. The middle
lines of text2 would be wrapped and center set.
The trouble comes with the transitional lines, the tail of
text1 plus the beginning of text2, and the tail of text2
plus the beginning of text3. Because of line wrapping there
would be no real demarcation at the breaks. You can argue
that no sane composing agent would emit such a string, and
you might be right, but it is legal RichText, so it must
be considered.
if <Center>...</Center> implies something like
<nl><C> ... </C><nl>
then no question exists, which IMHO was the intention
(for good or ill) of the automatic linebreak(s).
I am not sure which is better for our purpose, midlevel
operators such as this <Center>, or primitive operators
from which they would be built. Its a bit like choosing
between Assembler and assembler with structured macros.
Another example of a midlevel operator is <Superscript>.
Some have argued that it should both displace the baseline
and reduce the size of the text. The primitive approach
would use <Super><smaller> text </s></S> instead.
--
dana s emery <de19(_at_)umail(_dot_)umd(_dot_)edu>