Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!pacbell.com!ames!uakari.primate.wisc.edu!aplcen!aplpy.jhuapl.edu!cfw From: cfw@aplpy.jhuapl.edu (Chuck Waltrip) Newsgroups: comp.sys.next Subject: Re: 2.0: Initial Reactions Message-ID: <1990Dec18.203700.5065@aplcen.apl.jhu.edu> Date: 18 Dec 90 20:37:00 GMT References: <4490@media-lab.MEDIA.MIT.EDU> <371@heaven.woodside.ca.us> Sender: news@aplcen.apl.jhu.edu (USENET News System) Organization: Johns Hopkins University Applied Physics Lab Lines: 80 In article <371@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >In article <4490@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: [.... some discussion deleted ....] >>In other news, I've gotten my News reader to the same level of >>completion that Will Shipley's is. Oh, I've got posting almost >>working too, Rich Text and all! The idea that I like best about >>dealing with the Rich Text / non-rich-text problem was suggested by >>Will: do a writeRichText: and a writeText:. Post the normal text, a >>^l, and then a uuencoded, compressed, binary diff of the two. >> >>The only problem is that, well, I've done testing, and the overhead of >>doing a uudecode, an uncompress, and a binary ed is just, well, too >>high. So I think that well just post both the rich text. It's not >>*that* unreadable. If you can't read RichText on your Sun, buy a >>NeXT. Or I'll give you a copy of my Rich Text spec, and *you* can >>implement all of the tools from scratch that come as part of the >>package on the NeXT platform. > >I think that the best idea about Rich Text got lost in the shuffle. >I think it was from Mike Dixon at PARCplace. The idea was to put the >plain text first, then have a trailer with the RTF commands and some >byte offsets into the plain text where they should be applied. This >enables a single post of length equivalent to an RTF file that can be >read as plain text by normal people, but software could pick up and >apply the RTF commands from the end of the file before the file is >viewed. Give that some thought; I think it's an excellent idea. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I agree. >There >is one glitch I can think of, though, which is what you do when you >want to include somebody else's post in yours, and you add > characters >and all the offsets change. I guess you just generate a completely >new RTF file with only a single trailer at the bottom. Hmmmm. Will Usenet let you insert some unprintable character in the text to be replaced by a corresponding RTF command in the trailer? By corresponding, I mean the first instance of the unprintable character would be replaced by the first RTF command in the trailer, the second instance of the unprintable character would be replaced by the second RTF command in the trailer, etc. I don't know if there are any unprintable characters (e.g., ) which have special signifi- cance to any Usenet mailers and therefore have to be avoided. My guess is that you probably can't get away with using any unprintable characters since translation tables on the various Usenet nodes aren't even all that consistent about the full set of printable characters. In which case it may be that some printable character sequence may have to be used which may not be much less obtrusive than just inserting the RTF commands themselves. If it turns out that you can insert an unprintable character, then, to avoid the translation table problem, you will have to place that character in a known place in the RTF trailer so that the RTF mail reader can find it and know what the unprintable character was received as. This is the same principle used in uuencoded files which contain a header with the list of those characters which get translated differently by different nodes. I hope some workable solution for posting RTF can be found as I believe it would be a nice touch. And I agree with Glenn that the scheme for keeping the RTF commands confined to a trailer is a good approach. > >Anyway, I think that is the perfect solution for the RTF newsreader, >and it will hardly add any bandwidth. Anybody else remember that posting? >Could its original author amplify the volume and perhaps give us another >example? I think it would work perfectly, with a little software thrown >at it. > >/Glenn > >-- > Glenn Reid RightBrain Software > glenn@heaven.woodside.ca.us PostScript/NeXT developers > ..{adobe,next}!heaven!glenn 415-851-1785 c.f.waltrip Opinions expressed are strictly my own.