Here's my take on this "controversy" for what its worth:
Richtext was developed because there are existing mail composing agents that
support word-processing style features. These include "multimedia mail"
products like Andrew, Slate, Aster*x, Clarity, all the various PC mail variants
and the PC "mail-enabled" applications. When sending simple ASCII mail (vs
message with attachment) these applications convert their output to a simple
ASCII-only format. Wouldn't it be wonderful if these applications could just
as easily generate a readable format that maintains some of the formatting
information and that could be correctly interpreted between heterogeneous
systems? RTF was deemed too complex, not because most of these applications
can't handle it (most of them can, at least on the import side), but because
simple text-only systems can't handle it.
So, why not design a format that is:
1. Simple
2. Readable.
3. Rigorously specified
4. Has concepts that map well to EXISTING word processors.
and then jump away while the bandwagon rolls?
Well, the problem is that richtext as defined doesn't really meet these
requirements. It clearly shows it's Andrew heritage, and is both
under-specified and over-ambitious.
Specific problems:
1. Nesting of font information isn't completely specified. This includes
nesting of multiple underlining, super and subscripting, etc.
2. Nesting of indenting isn't well defined. Amount of indenting should also
be concrete.
3. Justification is separated from both line and paragraph markings (what
does it mean to center a word in the middle of a line of text?). This
also gives problems for applications that require that justification be
specfiied on a paragraph basis.
4. There is confusion about the meaning of/difference between multiple
<nl> vs <paragraph> markers.
5. Mixes generic (e.g. excerpt) and non-generic (e.g. bold) concepts. While
everyone knows that generic mark-up is wonderful, the vast majority of
your applications for both reading and composing this stuff won't support
it. Therefore, it doesn't belong here.
6. No way to turn wrapping of lines off.
7. Tries a little too hard - what the heck is samepage doing here? For that
matter, why bother putting heading and footing? How about page
numbers, landscape, multicolumn? Can't do it here - the spec shouldn't
bother trying to specify any of this stuff. Know your limitations.
Frankly, I think the whole concept of this tiny formatting language has a
pretty small chance of success - it doesn't buy you much. I've got some pretty
good experience that people want/need either simple text or complex documents -
there's not much call for something in the middle. If I get it, great - that's
kind of neat that a couple of your words showed up in bold. Would I make a
purchasing decision based on whether a system supported this feature? I
doubt it.
So, it's only chance for success is if Lotus, Microsoft, Novell, etc decide -
sure its simple enough to import/export - let's do it. In that case, I think
it needs to be MUCH simpler. Maybe just simple font changes (face, family,
size, underline) and line break information so you can get automatic wrapping.
Terry