ietf-822
[Top] [All Lists]

Re: applicability of Rich Text Format for e-mail

1991-06-05 14:20:22
In addition to the online stuff about RTF, I've come up with another
reference:

    Walden, Jeff. 1987, More File Formats for Popular PC Software : A 
    Programmer's Reference (John Wiley and Sons), ISBN 0-471-8507702.

I have no idea if this reference is up-to-date. It is also not very 
well-written or self-consistent. What follows may, as a result, contain
all sorts of errors.

Syntactically, RTF is somewhat like TeX. Control words are preceeded by \.
Control words accept parameters, either a string of digits rammed up
against the word or the "text" that follows the control word (terminated
by some non-alphabetic character, usally a semicolon ;).

There are a bunch of special control symbols, like \~, which is what TeX
calls a tie-space (it cannot be broken across a line.

The special characters \, {, and } can be written literally as \\, \{, and
\}.

Grouping of material is done with curly braces {}.

RTF is extensible and anyone can add the control words they like to it.

I won't bore the list with a enumeration of the various control words that
are defined (which no application is required to support, incidentally)
except to say that they are more oriented towards layout and detailed
font selection than they are towards simple specification of a presentation
style. I will say that the control words are cryptic and inobvious.

My preliminary impression is that RTF is totally unsuitable as a substitute
for Richmail. It is far to complex to start with. It is not well-defined.
It contains capabilities that are not appropriate for Richmail and will be
difficult to deal with on a variety of platforms.

It would be feasible to adopt a subset of RTF for use as Richmail. This
would involve defining a set of control words that are appropriate for
Richmail and then using RTF syntax. However, this would have no advantages
over the present Richmail specification that I can see - RTF does not
guarantee interoperability, and doing the syntax conversion is fairly
trivial; getting the semantics right is the hardest part.

                                        Ned



<Prev in Thread] Current Thread [Next in Thread>