Washington Apple Pi

E-Mail Droppings:

On The Trail Of The Wild Equals Sign

© 2001 Jon C. Thomason

Every once in a while I just spend so much time explaining something that I hope never to have to do so again. (Actually, I

So with that in mind, I offer you a transcript of e-mail with my father-in-law who's concerned that the sermons he's taken to e-mailing people aren't coming through correctly on the other end. I hope the effort is more broadly useful. As an aside, prior to our setting him up with a Power Mac 8600 a couple years ago, this man couldn't even type -- he wrote all his sermons by hand, and computers were for "other people." Now he plans his vacations online, installs software, and stays in touch with family and former parishioners around the globe.

The Letter

Kristen and Jon, here I think is an example of what happens to my sermons on email. Quotation marks get a long list of letters and symbols, the number 20 keeps appearing everywhere, contractions are also big problems, and the text is seperated in strange ways. I would sure appreciate any help you could be in allowing me to send these in a far friendlier way. This is what came back to ME from an undeliverable address. I don't know whether others get something even this good. Thanks, Marshall

The Response

Right. That's what's known as the "quoted-printable" encoding format.

Back at the dawn of time, computer screens were modeled after Teletypes, all data being text and all text being displayed in a grid. Each letter or numeral was the same width as all the others, and exactly 80 of them would fit side-by-side on a line. There were some 96 letters, numbers, symbols and punctuation marks to choose from. And that was sufficient to express U.S. English thoughts on those sorts of displays and printers.

Fast forward through to the Macintosh and its so-called Desktop Publishing Revolution. Now that everybody's a typographer, we have six different kinds of apostrophes and quotes to choose from (not counting French ones) and who knows how many kinds of hyphens and dashes. We have letters with accents, and symbols for foreign currencies, that we all use day-to-day before even mentioning non-Roman languages and their own symbol sets.

In this situation, we no longer express all our thoughts in 80 columns of ASCII text. It's unnatural to do so. But here's the catch: we still try to communicate using the tools put together 30 years ago by people who did. The worldwide Internet e-mail system deals solely with this simplified junk.

Sooo, we begin the process of extending the standards. First, we add all sorts of contortions and conversions to transmit arbitrary documents through this system. The actual word processing file you work on can be sent as an attachment -- in which case it gets broken down and reassembled into a completely unreadable sequence of those familiar ASCII letters and numbers. So long as the person on the other end a) knows how the file was converted, b) has software to convert it back, and c) has software that can interpret and display the document as you sent it (e.g. a straight WordPerfect file), then this is one way to get across a document that's arbitrarily complex.

But we don't want to lose our common denominator -- that universality that allows us to e-mail anyone anywhere, regardless of their equipment or ours. So we also define special backwards-compatible encodings that are said to "degrade gracefully" when the equipment or software isn't available to fully process the encoded document. If I write the word "resume" with proper aigu accents on the 'e's, even though the e-mail system can't cope with the accents themselves my software can write "r=8Esum=8E" (I believe) and make sure the other side knows to decode this back to the real deal.

Similarly, if I use typographers' curled quotation marks and apostrophes, my software can encode those before sending them through the e-mail system where they aren't welcome or meaningful as-is. And to deal with the weird 80-column thing, I can break down paragraphs into smaller parts and encode them with more equals signs so that the other side can decode/reassemble them back into their intended form.

As I suggested earlier, this is a gradual process. All software everywhere has to be updated, rewritten, or replaced in order to handle each new kind of encoding. The software developers and the international academic and business standards organizations all come along at their own paces. As you know, AOL's software understands all this stuff -- it was more or less born in a full graphical typography-friendly environment and lives worldwide. So AOL automatically decodes that stuff when it sees it, and automatically encodes that stuff when necessary. Netscape does too, as does Eudora, and pretty much all the popular e-mail software available for personal computers.

But some people still reach their e-mail through University accounts on the same honest-to-goodness 80-column ASCII terminals that they always did back when e-mail was just between schools, and worldwide e-mail was just a crazy futuristic idea. These people see the raw encoded text, and one could argue that they've made a conscious decision to continue to do so. At least we have graceful degradation, so that apart from a few extra equals signs for encoded symbols everything's still perfectly recognizable and readable.

OK, that's the history lesson, or maybe even the problem statement. The next question is what does one do about it. The folks who think this stuff up for a global audience might offer that you just shrug it off. People who expect careful presentation in e-mail sent to them simply have to decide to use any of the readily-available software that offers such presentation as a feature. But you as the publisher also have some options.

For one thing, you can go whole hog and send the actual document, bit-for-bit perfect, as an attachment. You could even convert it to an Internet-friendly (vendor neutral, or "platform-agnostic") standard interchange format such as a PDF document or even a GIF image. But don't. Let's not kid ourselves that the problem is worth losing the universality, where everybody can read our messages no matter what software they have -- where the message is conveyed regardless and the presentation is the only part that may fail to translate.

Instead, if you'd like to start writing your documents for the least common denominator 80-column ASCII terminals, you might switch for this purpose from AppleWorks to a text-only editor called BBEdit Lite. I work in these text-only environments all the time, and I swear by BBEdit. (I actually own the $129 full version with more gizmos and attachments than I could begin to use myself, let alone explain to anyone with any sense.)

But instead of switching over cold turkey, try this. Write your sermon in AppleWorks or whatever you feel comfortable. Then, instead of copying from there and pasting into AOL, run BBEdit Lite and paste into that instead. And use the BBEdit Lite menus to make the following quick conversions to your text.

Step one: convert all the dashes, quotation marks, apostrophes, etc.

Pull down "Convert to ASCII..." from the Tools menu and use the default settings.

Step two: convert all tabstops, if you've used tabs at all, to spaces.

Pull down "Detab..." from the Text menu and specify a tab width.

Step three: make sure paragraphs are separated by blank lines, like mine.

Pull down "Find..." from the Search menu, or press Command-F.

Search for "\r" (a backslash and a letter 'r', which is code for a return character) and Replace All with "\r\r" (two of them).

Step four: break all paragraphs into lines less than 80-columns apiece.

Pull down "Hard Wrap..." from the Text menu. Select Character Width and specify the maximum line width -- I recommend 72 for e-mail.

Take a look at what it's done. If you like it, select all, copy, and paste into AOL for delivery to everybody. Your original AppleWorks copy is still intact for printing and archiving; you just dumbed down a copy for e-mail.

And you've only scratched the surface of BBEdit Lite -- feel free to tinker with all the other options and features to match what you're working on. FWIW, I started writing this message on my archaic, 80-column, text-only, Apple II-based bulletin board system where I received your message. After a few paragraphs in I copied and pasted into BBEdit where I finished the rest of my thoughts. I didn't even think about it; it's second nature now.

Note that if you have an exceptionally long sermon, AOL will automatically break it off into a file attachment when sending it to people. There you don't have much control over the universality. But it won't be a problem.

Anyway, I'm always amazed how long it takes me to answer my mail…

Jon C. Thomason is a programmer who's written e-mail software for America Online as well as for Washington Apple Pi. He freely admits responsibility for the plain text-based e-mail on the Pi's bulletin board system the TCS. He added those features to that system in the late 1980's and early 1990's. But he strongly encourages everyone still using ZTerm for their e-mail to look into the TCS Easy Mail package, which is located on the Pi Fillings CD-ROM in the TCS Software folder.