Newsgroups: comp.text.tex
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!stowe.cs.washington.edu!pauld
From: pauld@stowe.cs.washington.edu (Paul Barton-Davis)
Subject: Re: Why use TeX if ...
Message-ID: <1991May10.155142.14490@beaver.cs.washington.edu>
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <1991May9.164341.14084@csrd.uiuc.edu> <1991May9.204113.17636@beaver.cs.washington.edu> <1991May10.065219.23433@agate.berkeley.edu>
Date: Fri, 10 May 91 15:51:42 GMT

In article <1991May10.065219.23433@agate.berkeley.edu> edward@priam.Berkeley.EDU (Edward Wang) writes:
>In article <1991May9.204113.17636@beaver.cs.washington.edu> pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes:
>
>>...
>
>>The primary difference
>>was the internal model - we were going to change it from "boxes+glue"
>>to something a little more PostScript like, and rather more reflective
>>of digital typesetting than the model Knuth picked.  We liked to think
>>that were writing the TeX Knuth would have written if PageMaker had
>
>Surely the box-and-glue model is a superset of the Postscript
>(positioning by coordinate) model.  

In prinicple, I would agree with this. However, in practice, it
doesn't function as a superset. TeX's model is based on
ignoring the contents of each box, which works for general text, where
each set character can be accurately described by a box along with a
few extra details to handle areas where it is not contained by the
box. However, this doesn't work for images, and is very difficult to
work with when curves are heavily in use. You can make boxes+glue have
the same flexibility as a completely generic imaging model like
PostScript, but to do you have to use boxes that are point equivalents.
This makes TeX run like a dog ...
				     
				     I agree that most of the glue
>features wouldn't be necessary if Tex had a more complete programming
>language, but I don't think it really gets in the way.
>

Its not the glue that's the problem - its the idea that you image a
page by building up a list of boxes, arranged in some coordinate
system.  There's no easy way to get TeX to add something that isn't
adequately described by a box to its vertical list - to do so, you
have to use so many sub-boxes that, as I said above, it kills
performance.

>The parshape problem is not an effect of using boxes and glue.
>In fact, I think it's possible (within the Tex line-breaking
>model) to specify paragraph shapes by the actual shapes,
>rather than by list of line lengths (\parshape).
>Some suitable shape-description language has to be designed, however.
>

Exactly. And TeX has no primitives that are not based on a box
model. Suppose you wanted to specifiy something that looked like
this:

			XXXXXXXXX
	             XXXXXXXXXXXXXXXXXXX
				XXXXXXXXXXX
	XXXXXXXXXXXXXXXXXXXXXXXXXXX
		XXXXXXXXXXXXXXX
			XXXXXXXXXXXXXXXXXXXX
	XXXXXXXXXXXXXXXXXXXXXX
			XXXXXXXXXXXXXXXXXXXXx

where the resolution of the above cartoon is about 1 pixel (its a
small shape :-). TeX gices you no constructs to do this with, and even
if you had them, how would you tell TeX "now construct a parshape that
flows around this" ? The data you've somehow given TeX has to be
processed to give "per-line" widths for the line-breaking algorithm to
work. If TeX had this as an internal feature, it might work in
reasonable time (the Mac stuff shows that it can), but trying to do
this with macros, whilst possible, is not my idea of a "good thing".

>>The hacking problem is primarily caused by the fact that the TeX
>>extension language was designed (apparently) as a macro replacement
>>language. If TeX has a "normal" or "proper" programming language, then
>>it would a lot easier to extend, without getting used to its
>>arcane grammar.
>
>I agree.  I can think of three things wrong with the Tex language:
>textual substitution macros (rather than functions or even
>Lisp-like macros), dynamic scoping (lexical is better, both is best),
>lack of a programmer-visible representation of text (boxes are not enough).
>On the last point, it would be sufficient to have a side-effectless
>way to map text (strings as in the input document) into typeset text.
>As it is, the result is inconsistencies like Latex's fragile commands.

Add to that - too many primitives. Even Common Lisp, perhaps the most
burdened common language when it comes to primitives, doesn't come
close to TeX (this is a top-of-the-head assertion that I should really
check). Things like vbox and hbox should, in my opinion, be some way
above the primitive level. Knuth didn't think so, it appears, but I'm
guessing that this is largely because of when TeX was written. He
didn't have pagemaker to look at, only traditional typesetting
systems. TeX's language is a pretty good model of that process, but
doesn't reflect the much more powerful models that PostScript and
other PDL's have given us.

-- 
Paul Barton-Davis <pauld@cs.washington.edu> UW Computer Science Lab	 

"People cannot cooperate towards common goals if they are forced to
 compete with each other in order to guarantee their own survival."
