Re: AWEB; Enhanced Document Encoding

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

Sven Utcke wrote in message <36f04969.0@pfaff.ethz.ch>...
|"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
|
|> I have to agree that TeX -- to be completely blunt about it -- really
creaks
|> these days.
|
|Strange.  I usually refer to it as "TeX flys", especially when
|comparing it to the 8086 4.77MHz I used to use it on.


Oh no!  I _didn't_ mean to start a flame war!  Help!  I feel compelled
(maybe I shouldn't :-) to answer Sven's post, but from an objective point of
view I think, not a hostile one.

[...]
|Well, I'm mainly using TeX because it's ease of use and high-quality
|output is still unsurpassed.

TeX is easy to use, and very, very powerful, once you have learned how to
use it.  But, it is not easy to learn!  To find out if a particular command
works, or works as you expect, you have to go through the whole
process-and-view cycle.  With a WYSIWYG* program, you get a menu of
commands, and you can try them out immediately.  The same is true of LaTeX,
which is a little less flexible than plain TeX, but does have the benefit of
being (by an order of magnitude) easier to learn.

|I have never yet lost one of these two
|bets:
|a) given any moderately complicated formula, I can create a printout
|   of it (using LaTeX) faster than the other guy can using WinWord
|   (even though I'm batch-processing, while he's WYSIAYG).

Which (presumably) proves TeX is better than Word at formulae.  Fair enough,
but Word, I suspect, is better than TeX at a great many things!

Experiment (hypothetical).  Seat a young secretary in front of a computer
with: (A) LaTeX and (say) noweb; (B) Word 7.0.  Ask the secretary to
copy-type: (1) a letter to a disgruntled client; (2) some documentary notes
on a program I am writing, including copious mathematical formulae; (3) a
small literate program I have drafted.  Now consider the following
scenarios: (A1) the secretary resigns in tears; (B1) all done in half an
hour; (A2) after offering a raise, it still takes two half-day computer
courses and a week to complete; (B2) all done in five hours, with a certain
amount of swearing, and a (cosmetically) nasty result; (A3) after offering
another raise, it takes a further two half-day computer courses and another
week, but the result is fine; (B3) no chance.  In other words, horses for
courses.  (Bearing in mind that some courses are only used once a year.)
Oh, and the secretary likes the paperclip best (apparently).

|b) The typeset result produced by (La)TeX will look better (as in: ask
|   10 people, see what the majority will opt for).


Better than Word, maybe.  Better than _any_ document processing system?  Not
necessarily!

[...]
|> Add to that the coming of Unicode, which effectively solves (in theory
:-)
|> quite a few of the problems formatting languages grappled with in
|> the past,
|
|I think we should not confuse formatting (what should it look like)
|with _input_-encoding.  Two different things entirely.


Not entirely.  There are certain problems which had to be solved by
formatting languages or word processors in the past that are completely (or
partially) obviated by Unicode.  Unicode all but solves the problems of:
special characters and foreign scripts; combinative forms; code space for
user-defined characters or codes.

|> plus the fact that the reasons for having a plain-text source file format
|> have now pretty well gone away, and it all makes traditional formatting
|> languages look a bit obsolete.
|
|Hardly.  Using Emacs I can manipulate text in ways simply not possible
|with a word-processor (one of the simplest examples being that in this
|sentence I wrote word-processor only once, and wrote "Beispiel"
|instead of example.  Emacs wrote the second and third word-processor
|after I typed wo<shift><TAB>, and translated the German word Beispiel
|into it's English equivalent.  Erik Naggum once reported that he got
|functions to turn first person sentences into third person, or
|statements into questions and vice versa.)  Emacs also reminded me to
|close the parenthesis (bracket?) above...


Ridiculous!  How are any of these things not possible in a word processor?
Indeed, Word actually does most of these things.

What I was getting at was: in the past (thirty years ago?), special (rather
than plain-text) editors would rarely be a practical proposition, because
computers were time-shared, had little memory (and storage), and were slow;
communications very often assumed only 7-bit ASCII text was being sent.  By
comparison, nowadays nearly all computers are desktops, have oodles of
memory and storage, and are extremely fast, and have a GUI; nearly all
communications today is binary.  Thus, special editors (e.g. semi-WYSIWYG)
which use a non-ASCII character set are a much more practical proposition.

|And of course I can easily create (La)TeX from a program, so if I'm
|making 100 tests on something all I need to do is write a batch-file
|(see!) and go home, and the next morning I've got I typeset tabular
|plus graph of my measurements (using gnuplot).


With the high-level encoding I am suggesting, it would be easier still to do
the same thing.  Codes can be written by a program just as easily as visible
text.  My encoding would be high-level, so this technique would generally be
a whole load simpler than plain TeX, and simpler, even, than LaTeX.

|> However, there is, now more than ever, a need for a truly standard
|> 'enhanced' document format, that would provide for the standard encoding
of
|> a document's 'logical' structure (paragraphs, headings, list items,
|> (floating) table rows and columns, etc.).
|
|This sound pretty much like a description of LaTeX,

Yes, the idea is something similar to LaTeX, but slicker, and slightly
higher-level.  The trade-off would be that you would need a special,
hand-holding, editor to edit these files, but the encoding would be more
efficient (most commands carried out by a single 16-bit code), and errors
less likely (because the codes are generated by the editor, not directly by
the user).  The editor would probably be 'semi-WYSIWYG'.

|which somehow
|makes me doubt that:
|
|> (The fine details of the
|> implementation of that structure would, of necessity, be non-standard.)
|
|After all, LaTeX is pretty standard indeed...


My suggested encoding would be higher-level than LaTeX.  This would have the
benefit of simplifying the encoding, at the cost of de-standardising the
details of the implementation (e.g. fonts used, paragraph indentation and
spacing, numbering style, etc.).  The user would certainly be able to
specify these things, it's just that the way in which they would be
specified would be non-standard.  Again, this is a trade-off.

[...]
|> and redefine a lot of presently useless or
|> ambiguous control characters (BS, HT, LF, VT, FF, CR, ESC, DEL, and maybe
|> others) for useful purposes.
|
|Why?  It's not as if they really got any place in a decent text-file
|anyway...


An odd statement (or an apparently irrational one, at least).  These
character codes (and plenty of others, thinking about it) could be re-used
for useful and well-defined purposes, instead of being the total dead weight
most of them are now.

|Not that I know what all this has to do with litprog, never mind Ada...


It has to do with document processing, which is important to literate
programming, and literate programming is potentially of significance to Ada
(and most programming languages).

|Sven, who rather likes LaTeX and plain ASCII.
|--
| _       _   Lehrstuhl fuer Mustererkennung und Bildverarbeitung
|| |_ __ | |__                                                        Sven
Utcke
|| | '  \| '_ \   phone:      +49 761 203 8274                   Am
Flughafen 17
||_|_|_|_|_.__/   fax  :      +49 761 203 8262           79110 Freiburg i.
Brsg.
|mailto:utcke@informatik.uni-freiburg.de
www.informatik.uni-freiburg.de/~utcke

I hope nobody considers it too objectionable that I (again) cross-post this
article.

-------------------------------------
Nick Roberts
-------------------------------------

*Sven prefers the WYSIAYG alternative, as in "what you see is all you get",
a Kernighanism I believe.  This was to do with a different argument (about
WYSIWYG word processors not encoding information about the logical structure
of a document.  Of course, nowadays, they all do, or can do, this.)