Re: hyperRTF?

Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 1 Jul 1994 03:02:51 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199407010007.AA26741@kauri.vuw.ac.nz>
Errors-To: listmaster@www0.cern.ch
Reply-To: Nathan.Torkington@vuw.ac.nz
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: hyperRTF?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

Chris Lilley, Computer Graphics Unit writes:

> The point is not that a particular product has some suitable
> features, but that it would represent a move from one system to
> another, completely different one.

Ye gods, at what point did I suggest replacing HTML in all its various
incarnations?  For the same reason that most people don't use
Pagemaker to create e-mail messages, I can't see the vast majority of
people wanting to have the degree of control over presentation that
professional publishers want, simply for their home page or their list
of favourite links.

> By as well as structure I meant, while keeping the present and
> growing advantages of HTML, such as SGML compliance, availability of
> robot indexers, etc.

An interesting exercise would be to write a DTD for RTF.  It looks
like the structure is compatible, and it would be possible (easier,
even) to write a DTD that has the same functionality as RTF.

> How many internet robots are there that will deliver an index of all
> the top level titles of rtf documents available on the web? Quite.

Bogus argument alert :) You might as well have said when people were
suggesting using HTML ``bah, how many robots are there that will
delive an index of all the top level titles of HTML documents
available on the web''.

> According to some developers I spoke to who had done rtf to various
> things converters, successive revisions of RTF are often
> nearly-but-not-completely back compatible. The documentation that
> trickles out of Microsoft apparently lags what their products on the
> dealers shelves spit out.

Now *that* is a good argument against RTF.  That and the ``how does it
cope with font substitution'' argument are the best I've seen.  Let me
suggest that it could be just like HTML --- new versions aren't
necessarily going to be backward compatible, because things were done
dumb in the early versions.  It's no crisis --- just mark your
document as RTF 1.2 or HTML 3.0 or whatever, and let the browser take
care of it.

Fonts are more tricky.  Perhaps some standard aliases for fonts?
Times, Courier, ...

> Attempting to sideline groups from a widely used, open format to a
> little used (in the open systems networking arena) proprietary
> format just because you are not interested in their requirements is
> simply not on unless there is a very big win to compensate for
> making that move.

I'm only suggesting RTF for the publishing folks who want greater
control over presentation --- font changes, enhanced symbol sets,
multi columns, etc, etc.  I'd never suggest trashing the work that has
already been done --- maintaining archaic systems is the founding
principle of most of the communications on the Internet after all :).

Please identify the groups and their requirements you mention here ---
I'd be interested to know more about the people that RTF would
disadvantage.

Cheers;

Nat