Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!gillies
From: gillies@m.cs.uiuc.edu
Newsgroups: comp.sys.next
Subject: Re: Rich Text and comp.sys.next
Message-ID: <61300058@m.cs.uiuc.edu>
Date: 30 Nov 90 15:54:00 GMT
References: <4196@media-lab.MEDIA.MIT.EDU>
Lines: 34
Nf-ID: #R:media-lab.MEDIA.MIT.EDU:4196:m.cs.uiuc.edu:61300058:000:1486
Nf-From: m.cs.uiuc.edu!gillies    Nov 30 09:54:00 1990


As a first crack do not encode the RTF information at all.  Just put
the RTF information at the end of the message in plaintext, using
character ranges to specify formatting attributes.  This is similar to
the way Xerox PARC's Cedar WYSWYG editor works.  So for instance, put:

12,364 {/b  }

Where the {/b is logically inserted after the 12th character in the
text stream, and the } is logically inserted after the 364'th
character.  

If you do not compress this information, then you can put together a
pieces data structure (linked list of pointers to text fragments)
describing the entire message, in RTF, very fast.  This allows the
text stream to be treated as a read-only data structure in memory.
The RTF can then be read as a stream of characters by cdr'ing down the
pieces data structure.

Later on, you might compress/binhex the data.  By sorting the RTF
tokens in increasing appearance number, it might later be possible to
decompress & unpack the binhex at the same time the message is being
displayed, to get good performance.  All you need to do is show the
first page almost immediately (in most cases), and the user will
probably be happy.

This also facilitates fast searches on the text stream.

The overhead of sending both a plaintext and an RTFtext message
through UUCP is unacceptable

Don W. Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,harvard}!uiucdcs!gillies