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 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."