ietf-822
[Top] [All Lists]

Re: text/enriched

1993-08-05 15:49:10
Excerpts from mail: 4-Aug-93 text/enriched Chris Newman(_at_)cmu(_dot_)edu (2519)


1) I have already written a text/richtext parser. It was easy to
write and I have the funtionality I need. Adding another new
formatting type to my parser would double or triple the complexity
with no gain.

Well, "no gain" is certainly debatable. The changes from richtext to enriched are not that great, and are (for the most part) well-motivated. In particular, the change to the newline handling strikes me as a significant step forward in readability.

2) Here at CMU there are a number of richtext generating clients, as
well as a few non-MIME compliant readers. I've read large
text/richtext documents untranslated without problems. In particular,
the <nl> didn't bother me as much as the double-spacing effect would
in text/enriched (I can say this for a fact, since ATK textversion 12
uses the same line break algorithm as text/enriched, and I've read
lots of unprocessed ATK files).

Interesting. It is precisely the richtext generated by newer versions of Andrew that people have found so unreadable. I'm sending this message in that format as an example.

3) The <verbatim> command is awful. It creates an entirely different
document format nested within the enriched format -- something the
MIME multipart was designed to avoid. If you want "verbatim" text,
use a multipart with a text/plain part. Since the primary use of
"verbatim" would be including code samples, it would be desirable to
have those samples easily extractable -- which is an automatic bonus
with MIME multipart.

Well, you're the second person to weigh in that way, whereas several people seemed to really want this feature. My own position is largely one of wanting a consensus. If there are people who feel they can't live without vebatim, or otherwise really like it, would they please speak up?

4) Creating yet-another-richtext-format will just force smart clients
to be larger. If it isn't broken, don't "fix" it.

I really think the <nl> thing was "broken". I also think "<<" is more readable than "<lt>". I also think that many near-useless features in richtext were removed.

5) text/enriched does a poorer job of meeting it's first and primary
goal (that of simplicity) than text/richtext does. This is proven by
the fact that the text/enriched minimal parser is significantly longer
than the text/richtext one.

I don't think this proves it, but it's one bit of evidence in that direction. Removing verbatim would certainly remove this objection as well, though, wouldn't it?

6) The <nl> in text/richtext is an obviously unambiguous linebreak.
The double-newline convension in text/enriched is more confusing and
harder to implement on a line-based parser. (I know this from
experience having written a minimal ATK parser and a text/richtext
parser).

Come on, counting newlines is not really all that hard.....

7) The automatic linebreak caused by the formatting commands (e.g.
<center>) is unnecessary. The parser has to keep a "formatting state"
anyway because the formatting commands can be turned off at any time.
This only forces the minimal parser to recognize those commands, which
it might otherwise be able to ignore, and implement the appropriate
line break formula. I think this is a worse error than the minor
problem that "/paragraph" causes for text/richtext.

I think that a major motivation here is clarity. Nobody really knew the "right" thing to do with something like this in richtext:

<center>hello</center><flushright>goodbye</flushright>

At least in enriched, everybody should be treating it the same, i.e. putting hello & goodbye on separate lines....

I think that on balance text/enriched is a big improvement over text/richtext, but I'm not willing to stand up and be the sole person arguing for retaining verbatim, so I'm open to removing it if that seems to be the net consensus. Is there anyone out there who wants to argue for retaining verbatim? -- Nathaniel
<Prev in Thread] Current Thread [Next in Thread>