Enriched Text Format -- A Primer

[UNDER CONSTRUCTION] This page is still under construction. Please email me with any suggestions you have for improving the content. Thanks in advance, and thanks in retrospect to the numerous people who have contributed to this page.
Eudora Pro 3.x for Macintosh and for 32-bit MS Windows (Windows 95 and NT) includes a feature called, among other things, Styled Text. This allows users to enhance the formatting of their text email message by defining fonts, colors, bold, italic, underlining, and a number of other attributes.

Eudora's implementation of Styled Text relies upon the Multipurpose Internet Mail Extensions (MIME), and specifically upon a MIME content-type known as text/enriched or Enriched Text Format (ETF).

ETF is widely misunderstood, and this document is an attempt to clear up some of these misunderstandings.

What ETF is NOT

ETF is not HTML
Some people mistakenly think that the coding Eudora uses is HTML, or some bastardized form of HTML. This is probably because both use sets of "tags" enclosed in angle brackets, like so: <Tag> </Tag>. In terms of substance, that is about as similar as the two languages get.

ETF is not RTF (Rich Text Format)
Others think that because Enriched Text Format sounds like Rich Text Format (RTF), the two are really the same thing, which couldn't be further from the truth. The fact that the letters E and R are so close on the keyboard makes some think that Qualcomm just made the same typographical error throughout the Eudora Pro 3.x documentation, or that they are trying to pull a fast one.

RTF was developed by Microsoft, and according to Microsoft it is "a method of encoding formatted text and graphics for easy transfer between MS-DOS, Windows, Windows 95, OS/2, and Apple Macintosh applications. The RTF standard provides a format for text and graphics interchange that can be used with different output devices, operating environments, and operating systems. RTF uses the ANSI, PC-8, Macintosh, or IBM PC character set to control the representation and formatting of a document, both on the screen and in print. With the RTF standard, you can transfer documents created under different operating systems and with different software."

Documents outlining the specifications of Rich Text Format can be found at various sites, including:

In fact, when ETF was introduced in the early 1990s the MIME-type was known as text/richtext (RFC 1341). It was later changed to Enriched Text Format to avoid confusion with Microsoft's RTF (change described in Appendix B, paragraph 0 of RFC 1523).

Top of page

What ETF Is

ETF is a MIME-type that is defined by a series of RFCs (Request for Comments). RFCs are the basis of ARPANet and InterNet standards, through some long, open collaborative process that I have never taken the time to understand.

Enriched Text Format, or MIME text/enriched content, is defined by the following RFCs:

Additional RFCs that reference MIME text/enriched include:
Top of page

Why ETF?

According to RFC 1896: 
   The text/enriched subtype was designed to meet the following
   criteria:

   1. The syntax must be extremely simple to parse, so that even
      teletype-oriented mail systems can easily strip away the
      formatting information and leave only the readable text.

   2. The syntax must be extensible to allow for new formatting
      commands that are deemed essential for some application.

   3. If the character set in use is ASCII or an 8-bit ASCII superset,
      then the raw form of the data must be readable enough to be
      largely unobjectionable in the event that it is displayed on the
      screen of the user of a non-MIME-conformant mail reader.

   4. The capabilities must be extremely limited, to ensure that it can
      represent no more than is likely to be representable by the
      user's primary word processor. While this limits what can be
      sent, it increases the likelihood that what is sent can be
      properly displayed.

   There are other text formatting standards which meet some of these
   criteria. In particular, HTML and SGML have come into widespread use
   on the Internet. However, there are two important reasons that this
   document further promotes the use of text/enriched in Internet mail
   over other such standards:

   1. Most MIME-aware Internet mail applications are already able to
      either properly format text/enriched mail or, at the very least,
      are able to strip out the formatting commands and display the
      readable text. The same is not true for HTML or SGML.

   2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML
      have many features which are not necessary for Internet mail, and
      are missing a few capabilities that text/enriched already has.

   For these reasons, this document is promoting the use of
   text/enriched until other Internet standards come into more
   widespread use. For those who will want to use HTML, Appendix B of
   this document [RFC-1896] contains a very simple C program that converts
   text/enriched to HTML 2.0 described in [RFC-1866].
Top of page

Who can read or write ETF messages?

I am sure that this is a moving target. For convenience, these are listed in four categories:

Mail clients

Clients that generate text/enriched documents

As of this writing (December 18, 1996), the following internet mail clients are capable of generating text/enriched documents: If your client is not listed here, you still might be able to send text/enriched documents using the workaround described below.

Clients that interpret text/enriched documents

The following internet mail clients support some or all of the formatting available through ETF. Those that support some ETF successfully ignore the code it cannot interpret and renders that text as plain text, so the reader does not get a screenful of ETF codes.

Clients that strip codes from text/enriched documents

I know that the following mail clients do not display any ETF, but are able to hide the formatting codes, and display ordinary text. This is generally considered to be acceptable behavior under RFC 1896, and other analagous situations (e.g., Lynx cannot display graphics on HTML pages, but does handle such content gracefully, without mucking up its display).

In the case of 16-bit Eudora Pro 3.x, when it saves the message to the local mailbox, it deletes text/enriched formatting codes, so they don't even appear when the raw text file is viewed. This may be the case with other mail programs, but I don't know -- please let me know if you have additional information.


Clients that cannot handle codes from text/enriched documents at all

I have received reports that the following mail clients are unable to display ETF, and also fail to hide the codes that they cannot interpret. Technically, they are still MIME-compliant, as RFC 1521 says that for minimal MIME-compliance the software should "show or offer to show the user the 'raw' version of the data after conversion of the content from canonical form to local form." (Thanks to Anthony Humphrey for pointing out my earlier misstatement on this.)

Web browsers

This is written up in my sample text/enriched page. That link has a description of how various browsers handle ETF (I only tested/reported Netscape Navigator 3.x (Windows 16-bit and AIX), Netscape Navigator 2.02 (16-bit), MS IE 3.x (32-bit), MS IE 3.xb1 (16-bit), and Lynx on a Sun OS). Better yet, following that link gives you a personal demonstration of how your current browser handles MIME text/enriched (ETF).

This accounting is certainly not complete, and I cannot even guarantee the accuracy of what is presented here, because I am relying in part upon information provided by others. Further information on these and other email clients is appreciated, including complete version numbers of the software, and whether the client displays the formatting, doesn't display the formatting but hides the codes, or shows the codes in the middle of the text (i.e., garbage).

Top of page

Want to send ETF messages with Eudora Pro other than 3.x (32)?

I can't imagine that anyone would want to do this, except to confirm that it can be done, but here goes. This method can probably be adapted to other MIME-compliant mail clients besides Eudora.
  1. Close Eudora, and edit the [Mappings] section of eudora.ini to include a line like the following: 
    out=etf,,,text,enriched
  2. Create the ETF message, entering all of the formatting codes manually (what fun!), or use an ETF editor, if any exist besides Eudora Pro 3.x (32). Save it as a normal text file with an extension of .etf, or whatever other extension you specified just to the right of the equals sign in Step 1.
  3. Open Eudora and prepare your mail message (To:, Subject:, etc.).
  4. Make the ETF file an attachment.
  5. De-select "Text as Attachment" using the toolbar button in the Compose window (just to the right of the QP button). If you have already selected "Put text attachments in the body of message" under the Tools / Options / Attachments menu, this is already de-selected for you.
  6. Select MIME as the encoding method.
  7. Send the message. Unless you are planning to annoy someone, it is probably best to send it to someone whom you know has a mail client that can interpret the codes, or at least hide them.
HINT: If you ever wanted to use Eudora to send a web page or other HTML document to someone who uses a mail program that reads HTML (like Netscape), you can do the same thing with a file that has an .htm or .html extension. The necessary eudora.ini entry in Step 1 is probably already done for you. Yes, you could just send it as an attachment, but this method avoids requiring the recipient to click on the "Attachment" link when he/she reads the message.

Top of page

TopReturn to top of this page                   Return to Ken's Eudora Resources Page
--------------------------------------------------------------------
W3C Wilbur Checked! This page written by Ken Simler on November 5, 1996.
Last updated on October 23, 1997.
HTML source copyright © Kenneth Simler, 1996 1997.
Comments and suggestions for new links welcomed.
This page has had hits since November 5, 1996.
Counter courtesy of George Burgyan