From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,HEADER_SPAM autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1032a1,1a91c683b7703121 X-Google-Attributes: gid1032a1,public X-Google-Thread: 103376,8f0e2b9422a6e2f2 X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: AWEB; Enhanced Document Encoding Date: 1999/03/19 Message-ID: <36f1dd17.0@pfaff.ethz.ch> X-Deja-AN: 456374312 References: <7bv5nl$8vc$1@plug.news.pipex.net> <7c5up1$gf7$1@news-hrz.uni-duisburg.de> <7c8tir$nt0$1@murdoch.acc.Virginia.EDU> <36ed4e1c.0@pfaff.ethz.ch> <7cooqo$mdf$1@murdoch.acc.Virginia.EDU> <36f04969.0@pfaff.ethz.ch> X-Trace: 19 Mar 1999 06:13:59 +0100, gwaihir.ee.ethz.ch Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada,comp.programming.literate Originator: neeri@gwaihir.ee.ethz.ch Date: 1999-03-19T00:00:00+00:00 List-Id: Sven Utcke wrote in message <36f04969.0@pfaff.ethz.ch>... |"Nick Roberts" 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, 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.)