From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 1 05:07:02 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28548; Mon, 1 Jun 92 05:07:00 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 1 Jun 1992 05:06 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5050; Mon, 01 Jun 92 04:06:01 PDT Date: Mon, 1 Jun 92 11:33:41 +0200 From: N.POPPELIER@ELSEVIER.NL Subject: RE: TeX is perfect In-Reply-To: <48771FB76009B459@HEARNVAX.nic.SURFnet.nl> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU >Lots of things in this world are perfect: >bicycles, fudge, Mozart's clarinet concerto. > >TeX belongs in this class, IMHO. >It is perfect {\em at what it is supposed to do}. >It wasn't designed for printing Newsweek. >It was designed for printing mathematics. If I show you one definite, real, undeniable flaw in TeX's math handling, Timothy, will you stop proclaiming that TeX is perfect? Please? Nico Poppelier From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 1 05:07:15 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28552; Mon, 1 Jun 92 05:07:14 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 1 Jun 1992 05:07 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5068; Mon, 01 Jun 92 04:06:17 PDT Date: Mon, 1 Jun 92 11:36:19 +0200 From: N.POPPELIER@ELSEVIER.NL Subject: RE: What should we discuss? In-Reply-To: <543DE5A34007FA80@HEARNVAX.nic.SURFnet.nl> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU I agree with Karl: we should TeX 3.14/METAFONT 2.7 as starting point, and consider extensions to them. Nico From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 1 06:14:40 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28686; Mon, 1 Jun 92 06:14:36 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 1 Jun 1992 06:14 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6150; Mon, 01 Jun 92 05:13:14 PDT Date: Mon, 1 Jun 92 01:45:44 -0400 From: laurent@MATH.TORONTO.EDU Subject: OOPS CORRECTION: Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU OOPS CORRECTION: REPLACE : ------- I want NTS to be able to optionally offer to the baseline separation: max{.6cm, .8cm} + (\the\lineskip) = .8cm + (\the\lineskip) ------- BY ------- I want NTS to be able to optionally offer to the baseline separation: max{.6cm + ht(n+1), .8cm + dp(n)} + (\the\lineskip) where ht(n+1) is the height of the prose (non math) part of line n+1 and dp(n) is the depth of the prose (non math) part of line n. ------- Usually (\the\lineskip) would be big enough that the difference between these two formulas would not be too important. But it is certainly the second formula that expresses what I have been saying from the outset. Laurent Siebenmann From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 1 07:44:19 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28885; Mon, 1 Jun 92 07:44:17 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 1 Jun 1992 07:44 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0648; Mon, 01 Jun 92 06:43:09 PDT Date: Mon, 1 Jun 92 00:56:47 -0400 From: laurent@MATH.TORONTO.EDU Subject: LINESPACING EXAMPLE. Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <07881B3C44028E5A@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU LINESPACING EXAMPLE. Time for an example. Suppose that on line n I have just a few big math symbols and the greatest depth is .6cm. Suppose that on line n+1 I have just a few big math symbols and the greatest height is is .8cm. (In practice "just a few" most often means "one or maybe two".) Tex will normally give baseline separation .6cm + .8cm + (\the\lineskip) This is about .6 cm too much except in the rare case when the big symbols are vertically aligned, in which case it is the best we can do avoiding collision. I want NTS to be able to optionally offer to the baseline separation: max{.6cm, .8cm} + (\the\lineskip) = .8cm + (\the\lineskip) This will assure that the ink of the two lines is at least (\the\lineskip) apart EXCEPT for RARE vertical alignments, which I propose to deal with by hand (for example by puting colliding chunks of math in \hbox's or by using \vadjust{\vskip??}). Victor has shown how to suppress the height and depth of all math using \everymath. This (with high probability) gives baseline separation (\the\baselineskip) surely << .6in and horendous collisions obviously result. One has then to hand set all interlines spacing when big math occurs. Is this clearer? The notion of finding simple algorithms that are ALMOST ALWAYS valid together with a framework for man-machine cooperation to handle the exceptional cases seems to me the best way to approach high quality composition. I hope Don Knuth is not the only one out there interested in high quality composition, because I doubt he is going to be available to help us out. Laurent Siebenmann PS. > If you increase \lineskiplimit, you get too much space > most of the time instead of not enough occasionally. No. Look at the definition of \offinterlineskip. If there is really a problem here, give me an example. From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 1 08:03:13 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28949; Mon, 1 Jun 92 08:03:12 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 1 Jun 1992 08:03 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1415; Mon, 01 Jun 92 07:02:09 PDT Date: Mon, 1 Jun 92 00:55:25 -0400 From: laurent@MATH.TORONTO.EDU Subject: VICTOR ON THE SKYLINE Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0A2D2C8CF4028B69@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU VICTOR ON THE SKYLINE You will all be lost if I don't repeat the original message: > BETTER LINE SPACING IN PROSE WITH MATH > > Here is one problem that is preventing TeX from achieving > "professional quality" in ordinary mathematical typesetting. > > Suppose that big symbols (with excess depth and height) occur > on successive lines. The current mechanisms of TeX involving the > \baselineskip, \lineskip, and \lineskiplimit normally lead to > excessive separation of the lines. This is because the two successive > rectangular line boxes are forced \lineskip apart. This is "necessary" > only when the oversize symbols happen to be aligned one above the > other, a fairly rare occurrence. A more pleasing result is almost > always obtained by a different formula which assures that each line > box is \lineskip from the a "standard prose core" of the the lines > above and below. Can such a rule already be implemented with TeX? I > would also like a marginal warning to help me check that no accidental > collision of big symbols has occurred; when it occasionally does, I > could quickly fix it with a \vadjust{\vskip??}. And of course in case > there are many big symbols I would like to be able to revert > gracefully to Knuth's regime. > > (Texperts please forgive me for ignoring the subtlties of > \lineskiplimit, which are not very relevant here.) > > Classical typesetters managed in the above circumstances to > separate the lines just enough that there be \lineskip distance from > the ink of the one to the ink of the next. What I am asking is that > TeX be able to achieve something like this fairly automatically. It > is not doing so currently and the quality of its mathematical output > is suffering. It is wonderfully unclear whether Victor has tried to understand what I want to accomplish. I know very well he could. This list is going to have to rationally discuss a lot of real problems big and small to make significant progress. But I am sure that Michael Barr understood because he came up with the wonderfully vivid term "skyline". An important concept that TeX will probably never fully grasp! Nevertheless I am suggesting TeX make a small but useful step in that direction --- because books are (yea!) for people, and people see skylines and not the boxes and glue that TeX sees. My reply to Michael does clarify what I meant by the prose core --- not a very good term that one. > Yes, this [marginal warning] would be nice, but it would be > substantial addition to TeX. Marginal notes are discussed in the TeXbook. Incidentally I would like a solid primitive for marginal notes since the \vadjust approach there seems slightly fragile. Overfull rules are another sort of marginal note, so I see no reason to reject a priori the idea that TeX should give other visual warnings in the printed (preliminary) output, nor do I see why such things would be hard to implement. My suggestion was vague because there are several interesting possibilities to explore. > Fixing it by hand? Tsk. Contrary to the TeX philosphy that > everything can be automated. Such apocryphal nonsense is just plausible enough to be a dangerous Charybdis on the way to TeX's avowed aim to produce print "whose typographical quality is comparable to the world's finest printers" (TeXbook preface). Happily both Victor and I agree that one should try to make such specific new abilities easy corollaries of more general changes. Laurent Siebenmann From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 1 08:04:06 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28954; Mon, 1 Jun 92 08:04:05 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 1 Jun 1992 08:03 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1459; Mon, 01 Jun 92 07:03:02 PDT Date: Mon, 1 Jun 92 11:58:35 BST From: Timothy Murphy Subject: RE: TeX is perfect In-Reply-To: N.POPPELIER@ELSEVIER.NL's message of Mon, 1 Jun 92 11:33:41 +0200 Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0A4A3B35D402436B@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU > If I show you one definite, real, undeniable flaw in TeX's math handling, > Timothy, will you stop proclaiming that TeX is perfect? Please? I don't "keep proclaiming" it. I only said it once. It obviously struck a chord as many people have repeated the phrase. So you don't need to tell me the 'flaw' in TeX to stop me. But why not tell us anyway? We should be told (as Private Eye says). On the notion of perfection: I am not (TG) a computer scientist, and do not share the general belief of computer scientists in "truth by successive approximation" -- that if only you keep adding strokes to the picture you will finish up with a perfect portrait. Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 1 12:32:08 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01554; Mon, 1 Jun 92 12:32:05 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 1 Jun 1992 12:30 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9358; Mon, 01 Jun 92 09:55:57 PDT Date: Mon, 1 Jun 92 17:40:14 BST From: Timothy Murphy Subject: Re: LINESPACING EXAMPLE. In-Reply-To: laurent@MATH.TORONTO.EDU's message of Mon, 1 Jun 92 00:56:47 -0400 Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <2F94505C24024D21@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU > The notion of finding simple algorithms that are ALMOST > ALWAYS valid together with a framework for man-machine cooperation > to handle the exceptional cases seems to me the best way to > approach high quality composition. I hope Don Knuth is not the > only one out there interested in high quality composition, because > I doubt he is going to be available to help us out. With respect, what you are attempting is incompatible with high quality composition. You want to use formulae within text that are much larger than the text. Whatever way you do this the result will look ugly. Why don't you display the formulae? Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 2 04:34:28 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07849; Tue, 2 Jun 92 04:34:25 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Jun 1992 04:34 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6517; Tue, 02 Jun 92 03:33:27 PDT Date: Tue, 2 Jun 92 08:10:00 GMT From: malcolm Subject: RE: TeX is not perfect! Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU although my gut position is that i do not wish TeX to be changed, modified, cleaned up etc, i offer one very small suggestion to those brave enough to consider creating a new public domain typesetting system of greater power and elegance, dedicated to the pursuit of excellence. please acknowledge that we do not read uindividual pages, but instead view spreads. thus TeX's page breaking is actually slightly inappropriate. a widow or club is considered much worse when the occur between spreads, rather than between pages. my publisher is uninterested in inter-spread clubs and widows (they've been going about 500 years, so they may have some insight into the business). this also seems, to me to simplify some of the problems of figure placement, without increasing complexity too much. no-one has mentioned rivers and torrents yet. although knuth & glass claim that TeX's line building will tend to minimise these unsightly features, rubinstein in digital typography seems to think that they may not. i have no empirical evidence either way, but it does seem a feature that should be considered (of course perhaps newsweek doesn't mind rivers?). malcolm clark ps how long do you think books are going to last? From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 2 11:49:23 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11388; Tue, 2 Jun 92 11:49:21 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Jun 1992 11:48 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3177; Tue, 02 Jun 92 10:47:38 PDT Date: Tue, 2 Jun 92 16:50:13 BST From: Timothy Murphy Subject: RE: TeX is not perfect! In-Reply-To: malcolm's message of Tue, 2 Jun 92 08:10:00 GMT Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU > please acknowledge that we do not read uindividual pages, > but instead view spreads. What is a 'view spread'? (Sounds like some sort of soft porn.) > ps how long do you think books are going to last? But does this matter, as long as information is going to enter us (I speak as a human being) through the eye? Does reading from the screen raise different typographical issues? (Perhaps MC is planning to attach electrodes directly into the brain.) Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 2 12:07:52 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11571; Tue, 2 Jun 92 12:07:49 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Jun 1992 12:07 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3798; Tue, 02 Jun 92 11:06:36 PDT Date: Tue, 2 Jun 92 14:02:36 EDT From: Michael Barr Subject: RE: TeX is not perfect! Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU I'd be willing to put up $100 that books will still be the dominant mode of publication in 20 years. For me to give up books, I will have to be able to view written material anywhere I am now. In the john, in my La-Z-Boy, in the train I use (one of whose electric locomitives was built in 1912 and some of whose cars in the 1920s) and so on. I don't see this happening. Just ask what in your house wasn't there 20 years. The only thing I can think of is the VCR and the computer. I think TeX right now has the capability to deal with facing spreads. Whatever mechanism is used for 2 columns now can be used in that way. Memory was a limitation, but with the new big TeXs that is less of a consideration. In effect, the two page spread would be treated by Tex as a single large page of two columns. Michael Barr From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 2 12:48:23 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11939; Tue, 2 Jun 92 12:48:20 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Jun 1992 12:47 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5436; Tue, 02 Jun 92 11:46:51 PDT Date: Tue, 2 Jun 92 19:46:53 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: RE: TeX is not perfect! Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU I'd like to have another go at initiating some discussion on the actual deficiencies of TeX {\italic per se}. Nico has alluded to one, in that he knows of a serious defect in TeX's mathematical setting in certain circumstances [Nico: could you elaborate, svp?] Malcolm has referred to another, in pointing out that TeX fails to regard a verso-recto spread as an entity in its own right, thereby immensely complicating certain layup issues. He also refers to the lack of any explicit attention to the problem of rivers. Could I ask others to contribute their own examples of genuine [or perceived] TeX deficiencies (and, of course, others to rebut them, if they feel that the contributor has genuinely underestimated the power of TeX). By so doing, we can safely defer the vexed question of whether NTS should truly be a `New Typesetting System', or whether it should simply an enhanced TeX-based system, in that identification of fundamental deficiencies in the present system will enable us (at least, the cognoscenti such as CET1 & FMi) to pronounce on whether such deficiencies could be rectified within the current model, or whether a new model would actually be required. In trying to stimulate this discussion, I do feel obliged to say that answers such as `its graphics facilities are far too elementary, if they can be said to exist at all' are really going beyond what I believe to be our initial objective; it is surely (oh, what an abused word) clear to all of us what Don set out to achieve with TeX, and what he regarded as being without its remit, and it seems to me that we should take this as in some sense approximating the limits of our initial investigations. [If I can draw a geometrical analogy, let Don's design specification be represented as a circle bounded by a square; then our initial remit might be confined to the limits of the circle which circumscribes the square.] I realise that this may seem grossly unsatisfactory to many, who will legitimately say that by limiting our investigations to a fifteen-year old design specification, we are ignoring the vast progress made in both computer hardware and computer software during that period, and that we should be considering now a system which will lead the field for the next ten years (as TeX did in 1978); and I have enormous sympathy with this point of view. But I do feel that until we have identified exactly what are the deficiencies of the present system, we are not really in a position to postulate on what might be required of a new one. Philip Taylor, RHBNC From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 2 13:24:10 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12270; Tue, 2 Jun 92 13:24:04 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Jun 1992 13:23 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6915; Tue, 02 Jun 92 12:22:53 PDT Date: Tue, 2 Jun 92 21:21:08 CET From: Michael Downes Subject: Imperfections of TeX 3 In-Reply-To: <01GKQQXX7746ELNYPI@MATH.AMS.COM> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0028D491B4027E4E@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Philip Taylor wrote: > I'd like to have another go at initiating some discussion on the > actual deficiencies of TeX {\italic per se}.... Could I ask others to > contribute their own examples of genuine [or perceived] TeX > deficiencies (and, of course, others to rebut them, if they feel that > the contributor has genuinely underestimated the power of TeX). I'll append below a copy of a message that I originally sent to the tex-euro mail list, February 20, in response to Joachim Lammarsch's announcement about the intent of Dante e.V. to set up a working group on `Future Developments of TeX'. Since the message was rather long I will mark only the mail header with "> ". Michael Downes Technical Support Dept. American Mathematical Society > Date: Thu, 20 Feb 1992 09:16:53 -0500 (EST) > From: Michael Downes > Subject: Re: Future Developments of TeX > In-reply-to: <01GGCSYZIW28A23QHK@MATH.AMS.COM> > To: tex-euro <@cunyvm.cuny.edu:tex-euro@dhdurz1.bitnet> .. Of course many different possible changes were considered in Frank Mittelbach's article `E-TeX: Guidelines for future TeX' from the 1990 TUG meeting (published in TUGboat vol 11 no 3, September 1990). From what others have said, it seems to be agreed that the single most important change among those Frank mentioned was the change to fixed-point arithmetic. First a couple of comments about that, and then some other proposals that I think are also fairly significant. 1. ``Change from floating-point to fixed-point arithmetic'' which would ``permit the removal of arbitrary items in a constructed list'' (E-TeX, p. 343). Example (1a). Consider user commands \pagebreak and \nopagebreak (defined as in LaTeX or AMSTeX). The sequence $$...$$\pagebreak will cause the \belowdisplayskip glue to remain at the bottom of the page. A \removelastskip can be used to offset the \belowdisplayskip glue but this is awkward and somewhat inefficient. A general-purpose \pagebreak macro cannot indiscriminately use \removelastskip in all cases. And if anything intervenes after the \belowdisplayskip (\write or \mark or \insert or another vskip or \hrule or ...) then a \removelastskip cannot be applied to \belowdisplayskip anyway. The sequence $$...$$\nopagebreak cannot prevent a page break following the display if \postdisplaypenalty is less than 10000. If it were possible to use \unskip and \unpenalty on the main vertical list, then it would be possible to remove the \belowdisplayskip and the \postdisplaypenalty, add a penalty of 10000, and then reinsert the \belowdisplayskip. Complication (1a): If you remove something from the main vertical list, then \pagetotal, \pagestretch, \pageshrink, ... (perhaps even \pagegoal) need to be updated accordingly. This is not the same for horizontal lists because line breaking is postponed until the end of the paragraph. Complication (1b): Currently you cannot remove a \write or \mark or \insert or rule from any list at all. If we allow them to removed, how will the commands appear to the user? If we have \lastmark like \lastbox, then perhaps we need a mark data type so that we can say something like \setmark0=\lastmark. It will probably be difficult in the case of \insert's to think of a good command syntax. Complication (1c): Perhaps \lastpenalty, \lastkern, \lastskip should remove the penalty, kern, skip, ... so that they are consistent with \lastbox. Then \unpenalty, \unkern, and \unskip would be unnecessary. (Of course most macro packages would probably want to reimplement them, as macros: \def\unpenalty{\count@\lastpenalty}, \def\unkern{\dimen@\lastkern}, \def\unskip{\skip@\lastskip}.) 2. It appears that many complications in TeX's handling of math formulas can be traced back to one design flaw: the fact that \over, \atop, \above, and their ...withdelims variants can change the math style of PRECEDING elements of the current math list. The advantages >From getting rid of this flaw turn out to be far-reaching. It is then possible to always know the current math style, anywhere in a math formula; therefore (i) \textfont, \scriptfont, \scriptscriptfont for each math \fam can be changed locally within the formula, thus allowing many more than 16 choices within a single formula; (ii) the proper branch of a \mathchoice can be computed immediately, so that it is unnecessary to typeset all four possibilities and wait until the end of the formula to select one; (iii) the proper value of a muskip can be computed immediately instead of waiting for the end of the formula; (iv) \vrule's (and hence struts) can use mu dimensions. The form \frac{...}{...} used by AMSTeX and LaTeX is one possible alternate syntax, but not the only one. (For example: \frac ...\over...\endfrac.) Example (2a) Once upon a time I needed to construct a simple math symbol: a `half box' consisting of the left and top sides of a square. Since TeX can draw vertical and horizontal rules, it seemed that it would not be necessary to use Metafont for this. Because I wanted the symbol to scale down appropriately if used in a subscript, I decided to define it like this: \def\halfbox{\mathord{\vrule width 1mu height9mu \vrule width 8mu height9mu depth-8mu}} However this produced an error message because mu units cannot be used with rules. Example (2b) The definition of \boldsymbol in AMSLaTeX (using Mittelbach and Sch"opf's `New Font Selection Scheme') is stupendously complicated only because of the math flaw caused by \over etc. If (i) and (ii) above were true in TeX, then the definition of \boldsymbol could be greatly simplified. 3. It would be better if ^ (category 7) did not serve two functions (math superscript and special notation ^^xx for input characters). I guess this means a separate catcode exclusively for the latter function. One possibility would be to use category 15 for this instead of `invalid'. Now that TeX reads eight-bit characters it is questionable whether making some character invalid has any use. You can make the character category 13 (active) and define it to give an error message if you like. 4. Since the display structure is useful also for non-math items (with above and below skips, automatic centering, \predisplaysize, \displaywidth, \displayindent, interaction with \parshape, ...) it might be better to have two separate structures, one for math and one for non-math. They could of course share a great deal of WEB code, but they should be available separately at the TeX command level, with separate variables for example \premathdisplaypenalty and \pretextdisplaypenalty. Motivation: $$\vbox{...}$$ doesn't allow page breaks. Therefore there is no way to use the display structure for, say a ten-line quotation, and allow a page break in the middle of the quotation. I guess this implies that the nonmath display structure should be OUTER vertical mode (?). It's curious, actually, that an \halign inside a display currently allows page breaks between lines; I haven't looked at the programming, but I have an impression that the situation <\halign inside display> might be one of the weirder parts of TeX: The Program. Other related ideas, however, might make a nonmath display structure unnecessary: (i) Make a \predisplaypar like \par that is inserted automatically by TeX when reading $$ but can also be inserted explicitly. It should not reset \parshape, and it should give \predisplaysize, \displaywidth, and \displayindent their proper values. Then you would need a matching \enddisplay that would finish up a preceding paragraph, but not reset \parshape, and would leave you in horizontal mode. (ii) Make the value of the last line of the previous paragraph available in a variable \prevwidth (like \prevdepth). This idea could be combined with \predisplaysize. 5. Make a \betweenskip to be used instead of \baselineskip outside of paragraphs (between \vbox's and \hbox's, or between a \hbox and the first line of a paragraph, or between paragraphs). Similarly, \betweenlineskip and \betweenlineskiplimit. Example (5a) In the sequence \vbox{...} \vskip N pt \par suppose that you want to find a value for N so that the base-to-base distance from the vbox to the first line of the paragraph is exactly 24pt. It is impossible to determine N until the entire paragraph has been read. This is because the value of \baselineskip or \lineskip applied between the \vbox and the first line of the paragraph is dependent on the values in effect when the \par is reached. This makes it impossible to achieve accurate spacing after certain kinds of macros (like a section head) that might be followed by arbitrary kinds of text and the \baselineskip that will be applied is not known in advance. Example (5b) The spacing above and below a display has some anomalies. If the display contents are tall and deep, then the space above the display (apart from abovedisplayskip) is the \lineskip value from within the display, but the space below the display (apart from belowdisplayskip) is the \lineskip value from outside the display. Consequently, if you want the visual space above and below the display to be the same in all circumstances, you cannot achieve this. The hackish nature of the \displ@y macro of plain.tex is evidence that something better needs to be done here. Setting \betweenskip/lineskip/lineskiplimit properly at the beginning and end of a display might suffice for this purpose. (Then \par would need to restore the normal value of \betweenskip/lineskip/lineskiplimit.) Actually I'm not sure that \betweenskip as described above is the best idea; but it seems clear that the current baselineskip handling needs improvement in some way. 6. Make \topaccent and \botaccent primitives instead of having just \accent which will only put something on top of another symbol, not below it. Perhaps it would also be better if the font dimensions of an accent symbol are (more or less) the actual measurements of the glyph, instead of including blank space below the glyph equal to x-height. Then the same symbol could be placed above or below as needed. Similarly \topmathaccent and \botmathaccent, and here the need to omit the compensation for the blank space of x-height is more important because mathematicians might want to use just about any symbol in an accent position whereas text accents are limited to a few special cases in Latin-alphabet languages (well, not counting Vietnamese!) The good thing about \mathaccent is that it takes care of shifting the accent according to the italic correction of the character underneath, as well as the kern with respect to \skewchar. For putting an accent under, let's say, the tail of an italic f, you need similar compensations. It might be a better alternative to extend the syntax of \accent so that it could place a top accent and a bottom accent simultaneously. Example (6a) The \overset and \underset macros of AMSTeX (which use \mathop internally) are typically used for placing symbols on top of other symbols in constructions that are logically speaking more closely related to a \mathaccent operation. But \mathaccent only accepts actual font characters as the accent character, not compound symbols, and it assumes that the font character has blank space below it for x-height. 7. Horizontal spacing between characters. Example (7a) The superscript 2 in the following display is too far away from the right parenthesis. Making TeX AUTOMATICALLY move such subscripts closer without adding explicit spacing adjustments is just about impossible. $$\left({\sum A_i\over\sum B_i}\right)^2$$ This raises an extremely important larger question: is it feasible to use information about character outlines to determine the spacing between two characters? (In an article in Seybold's Report on Publishing a couple of years ago, it was reported that the commercial firm Penta has developed a system that does this, at least for text.) Even assuming that rasterization complications can be avoided, there remains the question of how much information about the character outlines would be minimally necessary in TeX's computations. Probably the amount of information is far too much for a program that we would like to be able to run on little PCs and Macs and Ataris. (Ask yourself this question: how will it affect me if all my TFM files increase from 1K to 250K?) If it were feasible to use character outline information in adjusting the space between characters, it would affect many things: kern information in fonts, italic corrections, handling of subscripts and superscripts, ... Analogously, the outline of two consecutive lines of text in a paragraph might be used to better fit the lines. (The bottom edge of the first line and the top edge of the second line.) In text with a high proportion of mathematics, it sometimes happen that two lines are moved further apart by TeX because low subscripts in the first one and high superscripts in the second one cause \lineskip to be applied instead of \baselineskip; but strictly speaking it is only necessary to apply \lineskip if a high superscript falls directly below a low subscript, not if they are at different places in the line. In American Mathematical Society publications, which have a high proportion of mathematics, this unnecessary extra line spacing is very frequent, from five to ten percent of all nondisplay line pairs. 8. Recategorizing a token list. In processing a document, certain kinds of information are used more than once: the title text may be used also in running heads; section titles may be used also in a table of contents, as well as in running heads. Or it may be desirable to allow certain pieces of information to appear in arbitrary order but rearrange them before printing according to an order dictated by a documentstyle. In all of these cases, where reading the information and typesetting the information do not coincide, it is impossible to change catcodes of characters inside the information after the reading and before the typesetting. The only way around this problem is to write the information to an external file and re-read it every time it needs to be typeset. A way to avoid the use of an external file would be preferable. Suppose you read the information initially with all characters having category 12 (yes, even spaces), perhaps into a token register. Then it should be possible to re-apply TeX's reading operations to the characters in the list, perhaps by dumping the character codes into TeX's input buffer and rereading them. From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 2 20:29:34 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15548; Tue, 2 Jun 92 20:29:33 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Jun 1992 20:29 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1953; Tue, 02 Jun 92 19:28:35 PDT Date: Tue, 2 Jun 92 22:27:40 -0400 From: laurent@MATH.TORONTO.EDU Subject: Downes on line spacing. Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <3B9A3E873402BD7C@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Downes on line spacing. Michael Downes presentation makes direct hits on many important problems, and I am impressed with the helpful explanations he has provided. All of these points deserve further discussion. It appears that I have been suggesting ways to attack a line spacing problem he describes in his seventh section. > In text with a high proportion of mathematics, it > sometimes happen that two lines are moved further apart by > TeX because low subscripts in the first one and high > superscripts in the second one cause \lineskip to be applied > instead of \baselineskip; but strictly speaking it is only > necessary to apply \lineskip if a high superscript falls > directly below a low subscript, not if they are at different > places in the line. In American Mathematical Society > publications, which have a high proportion of mathematics, > this unnecessary extra line spacing is very frequent, from > five to ten percent of all nondisplay line pairs. Admittedly I focused on on cases where the effects were particularly dramatic, and not necessarily caused by subscripts and superscripts, but say by other biggish things like 2-by-2 matrices or by integral signs. Even I am surprised to hear that 5-10% of non-display line pairs are spoiled by this phenomenon. My recollection is that where _major_ disruption is involved the problem occurs in bursts; one article is reduced to a shambles and another poses almost no problems. Tim Murphy asks me: > With respect, what you are attempting is incompatible > with high quality composition. You want to use formulae > within text that are much larger than the text. Whatever way > you do this the result will look ugly. Why don't you display > the formulae? Michael Downes has provided one answer; namely that with the baselineskips as tight as AMS attempts, even subs and supers cause exactly the same trouble. Another is that display is inappropriate when the object involved is not particularly big or important. Finally, is approximately one display per line of text a high quality solution?? I feel that Michael is too pessimistic about needing a lot of extra space for .tfm's that say enough about character shape to let one place subs and supers better. Why not just a sub and a super (horizontal) correction for each character (if nonzero). I have an innocent question (I do not know the answer.) What facilities does one have in TeX for tuning the level of (all) sub and superscripts? Such facilities are much in evidence in other word processors. Laurent Siebenmann From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 2 22:04:19 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15976; Tue, 2 Jun 92 22:04:17 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Jun 1992 22:04 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3489; Tue, 02 Jun 92 21:03:12 PDT Date: Wed, 3 Jun 92 06:01:40 CET From: bbeeton Subject: Re: Downes on line spacing. In-Reply-To: <01GKR738CXO2ELNXY2@MATH.AMS.COM> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <48D3EB29E402EA20@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de i hesitate to get involved in this discussion, given the precision evident in some of the contributions so far, but i have some observations on the effects of glyph shape and placement of sub- and superscripts. (i'm using the term "glyph" to denote a shape rendered on paper or some other display surface; to me, "character" is the input or internal code, and mapping between the two isn't always one-to-one.) larry siebenmann asks why aren't just two horizontal adjustments for each glyph, one for sub- and the other for superscripts, adequate. he also asks what facilities tex has for tuning the placement of (all) subs and sups. let's take the second question first. i believe the various fontdimens are the key here. see the texbook, p 433 and all of appendix g; unfortunately, there is no concise, easily understood summary of these elements. the basic values of the fontdimens are established through input to metafont; these values can be reset via instructions input to tex. (it's the absence of values for the fontdimens beyond the seven required for text that makes it very difficult, if not impossible, to set math competently with most postscript fonts.) as far as i know, there is no clear set of instructions for how to determine what values should be assigned. in any event, most of the fontdimens apply to vertical positioning, not horizontal; horizontal positioning depends on glyph width, side bearings, italic correction, and (for accent positioning) skewchar. regarding horizontal positioning of sups and subs, tex is not totally devoid of shape information (though it's admittedly minimal). the italic correction provides some shape information, as it affects positioning of subs and sups; for example, a cap "L" has minimal correction, while the correction for "f" is quite substantial, even in cmr* (to see this in action, set the phrase "of TeX" in an hbox with and without \/ after the "f"). nonetheless, this isn't fine enough, and there are some conditions under which the results are quite unsatisfactory; i suspect this is one of the reasons that the codes for thinspace and negative thinspace are so much shorter in math mode. one shape-description technique that i've seen used in other composition systems is known as sectored kerning, and it is often used to adjust intra-word spacing, or kerning, in text. this is based on selecting some small number of positions (sectors) along the vertical axis of a glyph and giving the distance at each sector >From a vertical through the origin (assume it's at the left) to the leftmost edge of the glyph at that height (or to the centerline of the glyph where that sector is empty, say at descender depth for a cap "A" or at cap height for an "x"), and similarly on the right relative to the escapement. by evaluating the neighboring sector extents of two consecutive glyphs, they can be moved closer as long as no sectors overlap; this can be seen in such pairs as "Te" in systems using this technique. the principle is similarly applied to subs and sups (remember that there can also be subs and sups to the *left* of some symbols, and tex's italic correction does nothing useful in such a situation), taking into account the fact that corners are the locations where adjustments must be made, and sectors can't be matched exactly because of the size difference. 4 or 5 sectors have been typical in the systems i've encountered. however, the values assigned to fonts in those systems were provided manually, and doing so was a *lot* of work; clearly it would be preferable to have the values calculated automatically >From an electronic outline, and there may be tools now to do this. actually, this reminds me of a flaw in tex that i would like to see corrected. set a series of lines of the same length with the same text, but with some lines all upright and some all italic. look carefully at the left margin. all the italic lines will begin just a bit to the right of the upright lines. and they will extend just a bit further to the right. fortunately, this doesn't happen too often, but when it does, it's disconcerting. -- bb From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 02:36:20 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17218; Wed, 3 Jun 92 02:36:18 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 02:36 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8773; Wed, 03 Jun 92 01:35:13 PDT Date: Wed, 3 Jun 92 09:11:51 LCL From: spqr@MINSTER.YORK.AC.UK Subject: how do you spot TeX? Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <6ED5A1E554030E57@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@VM.URZ.Uni-Heidelberg.De "Paul Barton-Davis" writes: > Virtually all mathematical publishers seem to be using TeX. > I 'challenge' you to tell me one mathematical publisher > who is _not_ using TeX. > > This is where I bow in deference to my obvious mis-location. I did not > consider the domain of mathematical publishing to be that large. If > there are really that many books published using TeX, then Joachim's > question seems reasonable. > > I'm sorry - I just tried not to look only at math publishing, and > other than a few token CS textbooks, TeX is rare, and getting rarer. i find it curious that Tim and Paul assume they can look at a book and tell if it has been produced using TeX. Most books don't say what software the typesetter used (why should they?). If anyone cares to look at a copy of Reilly & Rahtz (eds) Archaeology in the Information Age Routledge 1992 (plug plug), and find one unequivocal demonstration that it was produced using LaTeX, I'd be interested. I was given a spec by the publisher and implemented it using LaTeX. How should one be able to tell? sebastian ------- End of forwarded message ------- From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 05:48:05 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19429; Wed, 3 Jun 92 05:48:04 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 05:47 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1118; Wed, 03 Jun 92 04:47:06 PDT Date: Wed, 3 Jun 92 15:39:37 +0200 From: N.POPPELIER@ELSEVIER.NL Subject: RE: Imperfections of TeX 3 In-Reply-To: <442F7262000A107F@HEARNVAX.nic.SURFnet.nl> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <89A0EDF7C401B378@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU I'll add just one more to Michael's list, which together with Frank Mittelbach's article on E-TeX covers quite a lot of the perceived flaws in TeX 3. Things like under accent and multiple accents, both in text and math, were already mentioned there. Here's my addition: -------------------------------------------------------------------------- The spacing in formulas is given by the table on page 170 of the TeX book. The spacing for the 64-8=56 possible entries is not parametrized. Well, these parameters are 0, \thinmuskip, \medmuskip and \thickmuskip, and the latter three can be changed. The matrix itself, with its 0, 1, 2 and 3 is hard-wired into TeX. Hence, it is impossible to have Op-Inner spacing (2) instead of (1). By contrast, (almost) all parameters of the paragraph builder are available to the user. I said almost, since also the paragraph builder has some built-in things that would be useful in the form of parameters. --------------------------------------------------------------------------- Nico From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 06:14:54 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19543; Wed, 3 Jun 92 06:14:51 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 06:14 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 2040; Wed, 03 Jun 92 05:13:49 PDT Date: Wed, 3 Jun 92 14:11:56 CET From: Michael Downes Subject: Re: Downes on line spacing. In-Reply-To: <01GKR73COBT2ELNXY2@MATH.AMS.COM> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8D5DC3C43402E180@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de > Even I am surprised to hear that > 5-10% of non-display line pairs are spoiled by this phenomenon. > My recollection is that where _major_ disruption > is involved the problem occurs in bursts; one article is > reduced to a shambles and another poses almost no problems. The 5--10 % should not be regarded as a precise statistic, it was just a guess derived by looking at 10 or 20 articles in some of the primary AMS journals such as `Proceedings of the AMS', `Transactions of the AMS', and `Journal of the AMS'. > I feel that Michael is too pessimistic about needing a lot of > extra space for .tfm's that say enough about character shape to > let one place subs and supers better. Why not just a sub and a > super (horizontal) correction for each character (if nonzero). > > I have an innocent question (I do not know the answer.) What > facilities does one have in TeX for tuning the level of (all) sub > and superscripts? Such facilities are much in evidence in other > word processors. These two questions can be answered together. The (rough estimate) 5--10% of lines affected by \lineskip in AMS publications is larger than it might be otherwise because subscripts and superscripts are placed lower and higher (respectively) than the normal placement, by changing \fontdimen's 13--17 of math family 2 (cmsy font). The editors were dissatisfied with the sub and superscript placement provided by the default values of these fontdimens. If I recall correctly, they observed in some combinations like $C'$ that the *top* of the superscript fell below the top of the preceding character. And clearly, the possibility of changing sub and superscript vertical placement means that is not sufficient to have just two horizontal corrections per character for sub and superscript placement. Furthermore, the horizontal correction might vary even given a fixed placement height: a lowercase subscript letter and a capital subscript letter might need different horizontal corrections if the preceding character is something with a slanted right profile, e.g. V or W. My estimate for potential size increase in TFM files should anyway be regarded as rhetorical rather than precise. However, I had in mind a general algorithmic scheme that would provide automatically not only good placement of sub and superscripts but also good kerning between letters in a font. The examples AV and TV indicate that this can be done in full generality only by considering the full right and left profiles of the adjacent characters. From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 10:24:56 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21022; Wed, 3 Jun 92 10:24:52 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 10:20 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3451; Wed, 03 Jun 92 09:12:27 PDT Date: Wed, 3 Jun 92 17:37:51 MEZ From: Mike Dowling Subject: Eradicating artificial limitations in NTS Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU I mentioned this point once before, but suspect that I was too brief. I think that today there is general agreement that one should not introduce artificial limits to a program where they are not logically necessary. TeX is riddled with them. For example, there can be at most 16 font families, there can be at most 255 dimension registers, the memory available for character strings and hyphenation patterns etc are all limited in TeX. I have not chosen these examples at random; they are all examples where, at one time or another, I have pushed TeX to its limits. I contend that such limits should not exist in any future successor to TeX. Examples. (1) AMSTeX uses 10 of the 16 font families. If one were merely to load all the fonts that are supplied with AMSTeX, then one would exceed the number of permissible font families. (It can be useful to preload all the fonts you are ever likely to use in the interests of efficiency; this is not possible.) (2) Without any frills or macro programming on my part, using AMSLaTeX, I have exceeded the size of the memory set aside for storing character strings. The latest version of emTeX has remedied this. I contend that it should not be necessary to recompile TeX to reset such limits. (3) If I were merely to load the hyphenation patterns of the languages I speak, then I would exceed the memory allocated for hyphenation patterns on every TeX implementation available to me. (In actual fact, this is no real hardship as I do not really use more that 2 languages. The point I am making is that it is conceivable that such needs could indeed arise.) (4) Using AMSLaTeX together with PiCTeX for graphics and xypic for commutative diagrams exceeds the maximal permissible number of dimension registers. The solution, of course, is to flush PICTeX, and to use POSTSCRIPT for the graphics. Under DOS, this results in a new problem The DVIPS program wants to open more files simultaneously than are permitted by DOS. The solution is to reduce the number of font libraries used by emTeX to a bare minimum. That works, but the problem is, in principle, the same as the problems I have experienced in TeX, namely the built-in design limitations that are quite artificial. The solution in my opinion is to have TeX allocate all the memory it needs dynamicly. If you get the message, "TeX's capacity exceeded...", the solution aught to be to buy more memory. Of course, there may be problems involved of which I, as a mere user, am not aware, but which prohibit such notions. if this is the case, then I apologize for wasting all of your time. A prerequisite for implementing programs that allocate memory dynamically is the availability of a suitable compiler. For TeX or its successor, the first requirement is that such a compiler should be available of virtually every computer architecture. In my opinion, a useful second requirement aught to be that such a compiler is available as a *usable* *standard*. (Emphasize both these attibutes.) It seems to me that, firstly, there are innumerable additional advantages accruing from the use of ANSI or ISO standards, and, secondly, that C is about the only language that fulfils these requirements. Mike Dowling From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 12:22:22 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22721; Wed, 3 Jun 92 12:22:20 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 12:21 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0445; Wed, 03 Jun 92 11:20:39 PDT Date: Wed, 3 Jun 92 12:19:34 -0600 From: "Jonathan M. Gilligan" Subject: Eradicating artificial limitations in NTS In-Reply-To: Mike Dowling's message of Wed, 3 Jun 92 17:37:51 MEZ <9206031615.AA05318@lilac.csd.bldrdoc.gov> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de Mike Dowling writes: I think that today there is general agreement that one should not introduce artificial limits to a program where they are not logically necessary. TeX is riddled with them. For example, there can be at most 16 font families, there can be at most 255 dimension registers, the memory available for character strings and hyphenation patterns etc are all limited in TeX. I have not chosen these examples at random; they are all examples where, at one time or another, I have pushed TeX to its limits. I contend that such limits should not exist in any future successor to TeX. [many examples deleted ...] A prerequisite for implementing programs that allocate memory dynamically is the availability of a suitable compiler. For TeX or its successor, the first requirement is that such a compiler should be available of virtually every computer architecture. In my opinion, a useful second requirement aught to be that such a compiler is available as a *usable* *standard*. (Emphasize both these attibutes.) It seems to me that, firstly, there are innumerable additional advantages accruing from the use of ANSI or ISO standards, and, secondly, that C is about the only language that fulfils these requirements. Mike Dowling First, I don't see the advantage of C over Pascal. Pascal supports dynamic allocation, it has an ISO standard, and it is strongly typed, which C is not. I think C is just great --- no language flame wars, please --- but I don't believe that there is one best language in which to write NTS. As well, I have spent enough time trying to port abominable C code from UNIX to DOS to have been disabused forever of the idea that C is automatically or easily portable. WEB could presumably be extended rather simply to support dynamic allocation. For that matter, no one has decided whether NTS should be written in WEB, although TeX's success is a persuasive argument in favor. However, you seem to miss the relation of memory use and performance. If you want NTS to run on DOS, then extending the number of font families, dimension registers, etc. increases both the memory necessary to hold them and the memory necessary to hold references to them. I don't know the guts of TeX too well, but I'd guess that going >From one nibble/byte to two or three to index such things would increase the memory requirements and slow down processing significantly, even if you don't actually allocate lots of registers or families. Also, on many machines, you will quickly use up available RAM by cavalierly allocating lots of strings and registers and then start thrashing the disk with page faults. Also, since you seem to be a DOS maven, realize that page faulting is not supported by DOS, so you need to build it into your software at a huge performance penalty. Similarly, huge pointers also exact a great penalty. Try comparing the performance of emTeX's tex and btex for an example. This is not to say that you don't make important points. Only that there is no free lunch. On my DOS box at work (16 MHz 386Sx, 640K Ram) I don't use several large macro packages (such as NFSS) that I'd like to use because they'd require me to use bigTeX, which runs too slowly. Thus, my major problem is not the limits of TeX, but the limits of my patience waiting for bigTeX to run. On the other hand, by the time NTS is written, DOS may well be obselete, and it may be reasonable to assume 32-bit integers, OS support for page-faulting, etc. However, nothing will ever run as fast as we want it to, so we can't blindly extend systems with no regard for performance. Jon ------------------------------------------------------------------------------ Jonathan M. Gilligan Time and Frequency Division National Institute of Standards and Technology Boulder, Colorado, USA Disclaimer --- The government probably disagrees with my opinions. From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 12:51:52 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23031; Wed, 3 Jun 92 12:51:50 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 12:51 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1849; Wed, 03 Jun 92 11:50:02 PDT Date: Wed, 3 Jun 92 14:46:05 -0500 From: jsmith@MCS.DREXEL.EDU Subject: Re: Eradicating artificial limitations in NTS Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" >Mike Dowling writes: > I think that today there is general agreement that one should not > introduce artificial limits to a program where they are not logically > necessary. TeX is riddled with them. For example, there can be at most > 16 font families, there can be at most 255 dimension registers, the > memory available for character strings and hyphenation patterns etc > are all limited in TeX. I have not chosen these examples at random; > they are all examples where, at one time or another, I have pushed TeX > to its limits. I contend that such limits should not exist in any > future successor to TeX. > >[many examples deleted ...] > > A prerequisite for implementing programs that allocate memory > dynamically is the availability of a suitable compiler. For TeX or its > successor, the first requirement is that such a compiler should be > available of virtually every computer architecture. In my opinion, a > useful second requirement aught to be that such a compiler is > available as a *usable* *standard*. (Emphasize both these attibutes.) > It seems to me that, firstly, there are innumerable additional > advantages accruing from the use of ANSI or ISO standards, and, > secondly, that C is about the only language that fulfils these > requirements. > > Mike Dowling > >First, I don't see the advantage of C over Pascal. Pascal supports >dynamic allocation, it has an ISO standard, and it is strongly typed, >which C is not. I think C is just great --- no language flame wars, >please --- but I don't believe that there is one best language in >which to write NTS. As well, I have spent enough time trying to port >abominable C code from UNIX to DOS to have been disabused forever of >the idea that C is automatically or easily portable. WEB could >presumably be extended rather simply to support dynamic allocation. >For that matter, no one has decided whether NTS should be written in >WEB, although TeX's success is a persuasive argument in favor. > >However, you seem to miss the relation of memory use and performance. >If you want NTS to run on DOS, then extending the number of font >families, dimension registers, etc. increases both the memory >necessary to hold them and the memory necessary to hold references to >them. I don't know the guts of TeX too well, but I'd guess that going >from one nibble/byte to two or three to index such things would >increase the memory requirements and slow down processing >significantly, even if you don't actually allocate lots of registers >or families. Also, on many machines, you will quickly use up available >RAM by cavalierly allocating lots of strings and registers and then >start thrashing the disk with page faults. > >Also, since you seem to be a DOS maven, realize that page faulting is >not supported by DOS, so you need to build it into your software at a >huge performance penalty. Similarly, huge pointers also exact a great >penalty. Try comparing the performance of emTeX's tex and btex for an >example. > >This is not to say that you don't make important points. Only that >there is no free lunch. On my DOS box at work (16 MHz 386Sx, 640K Ram) >I don't use several large macro packages (such as NFSS) that I'd like >to use because they'd require me to use bigTeX, which runs too slowly. >Thus, my major problem is not the limits of TeX, but the limits of my >patience waiting for bigTeX to run. > >On the other hand, by the time NTS is written, DOS may well be >obselete, and it may be reasonable to assume 32-bit integers, OS >support for page-faulting, etc. However, nothing will ever run as fast >as we want it to, so we can't blindly extend systems with no regard >for performance. > >Jon > >------------------------------------------------------------------------------ >Jonathan M. Gilligan Time and Frequency Division > National Institute of Standards and Technology > Boulder, Colorado, USA > >Disclaimer --- The government probably disagrees with my opinions. I agree strongly. NTS shouldn't have any artificial limitations, and should be written using data-structures that optimize usage of memory (i.e., never allocate more than is actually used, etc.) For instance, linked lists or b-trees could be used for the table-lookup operations, rather than hashed flat arrays. I would also like to register my disapproval of WEB as a programming language. It was originally designed to solve problems that no longer exist in most programming languages (i.e. lack of external procedures in the early release of Pascal that Knuth had, etc.). It has never (to my knowledge) been widely used for anything but TeX and related software. The use of complex data-structures provides some motivation for using an object-oriented language like C++ or Object Pascal. Justin R. Smith Department of Mathematics and Computer Science Drexel University Philadelphia, PA 19104 From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 16:04:30 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24717; Wed, 3 Jun 92 16:04:28 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 16:04 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1297; Wed, 03 Jun 92 15:03:20 PDT Date: Wed, 3 Jun 92 17:59:06 EDT From: Karl Berry Subject: Imperfections of TeX 3 In-Reply-To: Michael Downes's message of Tue, 2 Jun 92 21:21:08 CET <199206021923.AA15100@cs.umb.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de 3. It would be better if ^ (category 7) did not serve two functions (math superscript and special notation ^^xx for input characters). What practical difficulties has this caused? (I don't necessarily object to such a change, I'm just curious.) From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 16:34:31 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24984; Wed, 3 Jun 92 16:34:29 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 16:34 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 2168; Wed, 03 Jun 92 15:33:28 PDT Date: Wed, 3 Jun 92 18:28:38 EDT From: Karl Berry Subject: Eradicating artificial limitations in NTS In-Reply-To: Mike Dowling's message of Wed, 3 Jun 92 17:37:51 MEZ <199206031613.AA02364@cs.umb.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de where [arbitrary limits] are not logically necessary. They must be practically unnecessary, as well as logically. In principle, I'm sure we all agree. In practice, allowing arbitrarily sized data structures would mean (I suspect) completely rewriting tex.web. Almost all of DEK's code uses arrays. Changing it all would be too big a change, I fear. there can be at most 16 font families, there can be at most 255 dimension registers, the memory available for character strings and hyphenation patterns The limit of 16 font families is notorious. I would say that that is the worst fixed limit in TeX. Unfortunately, changing it also changes the way TeX appears to the user: if you increase it to 32 (say), you must now allow base 32 numbers in specifying families. However, this change may be worthwhile, despite the amount of reprogramming involved. ? Character string and hyphenation pattern space can be increased by recompiling, as you point out later: I contend that it should not be necessary to recompile TeX to reset such limits. Well, it can be probably be implemented so that you just have to change an environment variable (but .fmt files will not typically work with different values for most table sizes). I was sent changes to do this for web2c a long time, but I haven't managed to incorporate them yet. The DVIPS program wants to open more files simultaneously than are permitted by DOS This seems like a bug in dvips. Why must so many files be open simultaneously? You can read entire fonts into memory. In fact, I thought it did this. But never mind, this is off the subject. A prerequisite for implementing programs that allocate memory dynamically is the availability of a suitable compiler. It's too soon to talk about compilers or implementation languages, I think. First we have to decide what to implement. karl@cs.umb.edu From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 18:47:39 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25978; Wed, 3 Jun 92 18:47:37 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 16:18 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1686; Wed, 03 Jun 92 15:16:49 PDT Date: Wed, 3 Jun 92 18:15:45 EDT From: Karl Berry Subject: Imperfections of TeX 3 In-Reply-To: Michael Downes's message of Tue, 2 Jun 92 21:21:08 CET <199206021923.AA15100@cs.umb.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de is it feasible to use information about character outlines to determine the spacing between two characters? I would guess this a ``research project''. (Probably a Ph.D., at least.) Therefore, I wouldn't want succ (TeX) to try to implement it. Details below. There is another reason why such a thing may be inappropriate: TeX now knows nothing at all about character shapes, only dimensions. It would be a radical change -- tantamount to eliminating bitmap fonts altogether, it seems; certainly changing TFM files quite a bit -- to make it know about shapes. I think this is too big a change. In fact, although this hasn't been mentioned yet, and may not be feasible, I think we should strive at all costs to not change the TFM format (except perhaps upward-compatibly). Having to have completely new fonts simultanously with a completely new TeX would make changing over even more difficult. (In an article in Seybold's Report on Publishing a couple of years ago, it was reported that the commercial firm Penta has developed a system that does this, at least for text.) I never heard of Penta, but I got some blurbs from URW recently saying that they had implemented such an ``optical letterspacing'' system. They had lots of examples of how wonderful their system was, but no details on how it worked, of course. I remain skeptical. I (and my partner Kathy Hargreaves) implemented (or tried to) an optical letterspacing program for our work on making fonts for GNU: the specimens we have available to scan don't have sidebearing information, so we thought ``Wouldn't it be nice if we could generate a first approximation to the sidebearings automatically, so we didn't have to handspace several (hundred) thousand characters?''. We knew of the work on optical letterspacing by David Kindersley (references at the end), and, a little later, by Kathleen Carter, who worked with Kindersley and others. However, in Kindersley's article and Carter's thesis, there was little hard information on exactly what the system for optical letterspacing was. There were also no convincing examples. There were a lot of vague analogies to ``gravity'', and mutterings about ``sums of squares'', but not a formula in sight. We implemented things as best we could, worked on it for several months (off and on), and never got any kind of consistent results. We finally shelved it in favor of a less automatic (but still better than doing things entirely by hand) system described in Tracy's book. My conclusion: optical letterspacing isn't developed in the literature (as far as I know), goes beyond the state of the art, and shouldn't be considered for succ(TeX). @Misc{Kindersley:LS-27266/77, author = "David G. Kindersley and Neil E. Wiseman", title = "Letter Spacing", howpublished = "British Patent Application 27266/77", } @Book{Tracy:LC86, author = "Walter Tracy", title = "Letters of Credit", publisher = pub-godine, year = 1986, address = pub-godine:adr, price = "$27.50", annote = "Two parts: the first on general history and principles of type design, the second a critical discussion of the work of Jan van Krimpen, Frederic Goudy, Rudolf Koch, W.A. Dwiggins, and Stanley Morison. Tracy was head of type design for Linotype in Britain.", acknowledgement = "justin@iros1.iro.umontreal.ca (Justin Bur)" } @Booklet{URW:kerning, title = "Kerning on the Fly", howpublished = "In URW Non-Plus-Ultra Typography series", address = inst-urw:adr, year = 1991 } @book{Kindersley:OLS76, title = "Optical Letter Spacing for New Printing Systems", author = "David Kindersley", year = 1976, publisher = "Wynkyn de Worde Society", address = "distributed by Lund Humphries Publishers Ltd., 26 Litchfield St. London WC2", comments = "This discusses a piece of hardware Kindersley (with help) invented to do optical letterspacing. He claims the results are as good as being spaced by hand, but we haven't been able to reproduce them. Regardless, though, it's some pretty good ideas." } @phdthesis{Carter:CTD86, title = "Computer-Aided Typeface Design", author = "Kathleen Anne Carter", year = 1986, month = may, number = 87, school = inst-u-cambridge, address = inst-u-cambridge:adr, comments = "The system uses a polygon representation for the outlines. She implements Kindersley's letterspacing algorithm, although she never really shows pictures of the results." } From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 18:47:41 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB25978; Wed, 3 Jun 92 18:47:40 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 16:18 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1696; Wed, 03 Jun 92 15:17:13 PDT Date: Wed, 3 Jun 92 18:16:31 EDT From: Karl Berry Subject: Imperfections of TeX 3 In-Reply-To: Michael Downes's message of Tue, 2 Jun 92 21:21:08 CET <199206021923.AA15100@cs.umb.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de 8. Recategorizing a token list. Yes! Do you have a possible syntax/primitives to suggest? K From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 19:44:56 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26182; Wed, 3 Jun 92 19:44:54 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 19:44 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7327; Wed, 03 Jun 92 18:43:50 PDT Date: Thu, 4 Jun 92 02:21:29 BST From: Timothy Murphy Subject: Re: Eradicating artificial limitations in NTS In-Reply-To: Karl Berry's message of Wed, 3 Jun 92 18:28:38 EDT Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU > In practice, allowing arbitrarily sized data structures would mean (I > suspect) completely rewriting tex.web. Almost all of DEK's code uses > arrays. Changing it all would be too big a change, I fear. I'm surprised to disagree with Karl over this. Maybe I misunderstand what he is saying. But it is easy to convert arrays to pointers within Karl's web2c by a simple change like @x @!byte_mem: packed array [0..ww-1,0..max_bytes] of ASCII_code; {characters of names} @!tok_mem: packed array [0..zz-1,0..max_toks] of eight_bits; {tokens} @!byte_start: array [0..max_names] of sixteen_bits; {directory into |byte_mem|} @!tok_start: array [0..max_texts] of sixteen_bits; {directory into |tok_mem|} @y @!byte_mem: packed array [0..ww-1] of ^ASCII_code; {characters of names} @!tok_mem: packed array [0..zz-1] of ^eight_bits; {tokens} @!byte_start: ^sixteen_bits; {directory into |byte_mem|} @!tok_start: ^sixteen_bits; {directory into |tok_mem|} @z The only other change needed is to malloc the space required. My point is that it can all be done within web2c (which I take to be as standard a part of TeX as dvips) -- no extension to TeX is required. Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 3 20:03:08 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26247; Wed, 3 Jun 92 20:03:07 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 3 Jun 1992 20:02 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7645; Wed, 03 Jun 92 19:02:07 PDT Date: Wed, 3 Jun 92 22:00:10 EDT From: Karl Berry Subject: Eradicating artificial limitations in NTS In-Reply-To: Timothy Murphy's message of Thu, 4 Jun 92 02:21:29 BST <199206040144.AA09009@cs.umb.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: <0112DF2764032124@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de > In practice, allowing arbitrarily sized data structures would mean (I > suspect) completely rewriting tex.web. Almost all of DEK's code uses > arrays. Changing it all would be too big a change, I fear. I'm surprised to disagree with Karl over this. Maybe I misunderstand what he is saying. No, I think you're right, I'm wrong. Sorry. within Karl's web2c by a simple change like The credit for web2c belongs to Tim Morgan a hell of a lot more than it does to me. K From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 03:53:07 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28192; Thu, 4 Jun 92 03:53:05 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 03:52 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6966; Thu, 04 Jun 92 02:52:04 PDT Date: Thu, 4 Jun 92 10:44:56 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: Eradicating artificial limitations in NTS Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: <42BAB4A28403521E@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Timothy --- >>> My point is that it can all be done within web2c >>> (which I take to be as standard a part of TeX as dvips) -- In a sense, I agree with you; but not in the sense you intended. Neither DVIPS nor WEB2C are a `standard part of TeX'; they may well be useful adjuncts, the latter particularly for those who are unable to use a good Pascal compiler, but they are in no sense integral to TeX (for example, neither is used at this site: we use Arbortext's DVILASER/PS and the standard VAX/VMS Pascal compiler). I believe it would be a great mistake to assume that one can implement certain features solely through adjunct programs. Philip Taylor, RHBNC From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 05:26:00 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00240; Thu, 4 Jun 92 05:25:59 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 05:25 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8543; Thu, 04 Jun 92 04:24:59 PDT Date: Thu, 4 Jun 92 12:56:56 MEZ From: Mike Dowling Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <4FB4C56554034C27@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Subject:Eradicating arbitrary limits in TeX (1) I did not realize that Pascal has the necessary features. The versions available to me are obviously very limited. I therefore agree that the choice of programming language is irrelevant. (2) If many of the changes can be implemented at the WEB2xx level, then all the better. I agree that one should not make more changes than are strictly necessary. (3) I like many others am aflicted with DOS. I would not recommend that NTS should make any concessions to DOS or 16 bit machines. By the time that any successor to TeX becomes publicly available, 16 bit machines will be obsolete, if they are not already so. Mike Dowling From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 11:55:38 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02298; Thu, 4 Jun 92 11:55:37 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 11:55 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0964; Thu, 04 Jun 92 10:51:46 PDT Date: Thu, 4 Jun 92 08:47:21 EDT From: Michael Barr Subject: Re: Eradicating limits Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8621CD2B74034038@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU If succ(TeX) refuses to make any concessions to DOS, it can close up shop right now, as far as I am concerned. Actually, the concession is implicit in the whole font-naming controversy. As for 16 bit machines, it is unclear to me what the bit-size of the machine can possibly have to do with the capabilities of TeX. I think some people may be mixing up questions of capability with those of implementation. Michael Barr From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 12:38:48 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB02630; Thu, 4 Jun 92 12:38:46 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 12:37 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3560; Thu, 04 Jun 92 11:14:09 PDT Date: Thu, 4 Jun 92 12:01:27 EDT From: Charles Wells Subject: TeX as a programming language Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8C0104791402F14C@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de This forum has addressed many of the deficiencies of TeX as a typesetting system. Even taking those into account, TeX produces much better output than any other publishing system available on personal computers. On the other hand, it is _not_ well-designed as a programming language. The bare minimum would be the basic structures available in structured programming languages -- besides if-then-else, we should have while loops and procedures with local variables as primitives. Even better would be to turn it into a decent list-based functional programming language. Such a language might have efficiency problems, however. There are problems with local variables in a language that works by repeated rewriting as TeX does. Mathematica also works by repeated rewriting and it took Wolfram two tries to get local variables in shape. TeX would do well to imitate some of the methods used in Mathematica. TeX could learn from Mathematica in other respects, too. Every expression in Mathematica is a list with a head; for example the expression x+y is stored as Plus[x,y]. Mathematica has preprocessing that allows the user much freedom to use infix and postfix syntax, but there is always a canonical form underneath and all rules and operations are defined in terms of that canonical form. TeX would do well to emulate this. TeX's ability to defined commands with weird delimiters, etc, is great, but there is no standard form underneath to resort to when needed. My general complaint is that TeX as a language is not _clean_. A comment on a statement by Mike Dowling: > (3) I like many others am aflicted with DOS. I would not recommend that > NTS should make any concessions to DOS or 16 bit machines. By the time > that any successor to TeX becomes publicly available, 16 bit machines > will be obsolete, if they are not already so. You won't have to make concessions to Dos, just compile it using a DOS extender such as Phar Lap. No conceivable extension of TeX could require as much in the way of resources as Mathematica 2.0, and that runs under DOS (it needs 8 meg -- the Windows version requires 12!) It would be very very foolish for TeX innovators to ignore DOS. It has a huge installed base. I am not really obsessed with Mathematica, it's just that I keep noticing contrasts between mma and TeX. It's not "fair" to compare them since TeX is so much older and designed for running under conditions of tight memory and slow processors, but the TeX people can _learn_ from mma since it operates in a similar way. --Charles Wells -- Charles Wells 216 368 2893 From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 12:39:19 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02647; Thu, 4 Jun 92 12:39:17 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 12:38 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3613; Thu, 04 Jun 92 11:14:36 PDT Date: Thu, 4 Jun 92 13:22:33 -0500 From: jsmith@MCS.DREXEL.EDU Subject: Re: TeX as a programming language Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8C14D2F7F4034A51@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" >This forum has addressed many of the deficiencies of TeX as a >typesetting system. Even taking those into account, TeX >produces much better output than any other publishing system >available on personal computers. > >On the other hand, it is _not_ well-designed as a programming >language. The bare minimum would be the basic structures >available in structured programming languages -- besides >if-then-else, we should have while loops and procedures with >local variables as primitives. Even better would be to turn it >into a decent list-based functional programming language. Such >a language might have efficiency problems, however. > >There are problems with local variables in a language that works >by repeated rewriting as TeX does. Mathematica also works by >repeated rewriting and it took Wolfram two tries to get local >variables in shape. TeX would do well to imitate some of the >methods used in Mathematica. > >TeX could learn from Mathematica in other respects, too. Every >expression in Mathematica is a list with a head; for example the >expression x+y is stored as Plus[x,y]. Mathematica has >preprocessing that allows the user much freedom to use infix and >postfix syntax, but there is always a canonical form underneath >and all rules and operations are defined in terms of that >canonical form. TeX would do well to emulate this. TeX's >ability to defined commands with weird delimiters, etc, is >great, but there is no standard form underneath to resort to >when needed. > >My general complaint is that TeX as a language is not _clean_. > >A comment on a statement by Mike Dowling: >> (3) I like many others am aflicted with DOS. I would not recommend that >> NTS should make any concessions to DOS or 16 bit machines. By the time >> that any successor to TeX becomes publicly available, 16 bit machines >> will be obsolete, if they are not already so. > >You won't have to make concessions to Dos, just compile it using >a DOS extender such as Phar Lap. No conceivable extension of >TeX could require as much in the way of resources as Mathematica >2.0, and that runs under DOS (it needs 8 meg -- the Windows >version requires 12!) It would be very very foolish for TeX >innovators to ignore DOS. It has a huge installed base. > >I am not really obsessed with Mathematica, it's just that I keep >noticing contrasts between mma and TeX. It's not "fair" to >compare them since TeX is so much older and designed for running >under conditions of tight memory and slow processors, but the >TeX people can _learn_ from mma since it operates in a similar >way. > >--Charles Wells > > > >-- >Charles Wells >216 368 2893 I agree: if we are going to redesign TeX, we should do so from scratch. We can still use Knuth's excellent algorithms for formatting text and mathematical equations, but we should CONSIDER (at least) completely re-designing the underlying programming language. Justin R. Smith Department of Mathematics and Computer Science Drexel University Philadelphia, PA 19104 From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 13:40:06 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03077; Thu, 4 Jun 92 13:40:04 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 13:34 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9809; Thu, 04 Jun 92 12:31:06 PDT Date: Thu, 4 Jun 92 19:53:00 GMT From: malcolm Subject: Re: TeX as a programming language Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <93F8632D84037B5A@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU let me float a ludicrous concept that flitted through my conscious whilst ina receptive (frink sodden) state: re-write TeX in lisp: inorporate it as part of emacs: what then is impossible? i might have the beginnings of a bright idea. if i don't please elucidate. malcolm clark (sometime prez, tug {what's that?}) From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 13:40:06 1992 Flags: 000000000011 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03077; Thu, 4 Jun 92 13:40:04 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 13:34 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9809; Thu, 04 Jun 92 12:31:06 PDT Date: Thu, 4 Jun 92 19:53:00 GMT From: malcolm Subject: Re: TeX as a programming language Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <93F8632D84037B5A@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU let me float a ludicrous concept that flitted through my conscious whilst ina receptive (frink sodden) state: re-write TeX in lisp: inorporate it as part of emacs: what then is impossible? i might have the beginnings of a bright idea. if i don't please elucidate. malcolm clark (sometime prez, tug {what's that?}) From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 13:49:05 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03192; Thu, 4 Jun 92 13:49:00 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 13:46 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1645; Thu, 04 Jun 92 12:40:30 PDT Date: Thu, 4 Jun 92 20:05:46 BST From: Tim Bradshaw Subject: Re: TeX as a programming language In-Reply-To: malcolm's message of Thu, 4 Jun 92 19:53:00 GMT <9206041857.aa11657@uk.ac.ed.festival> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <959743FAA4032249@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU >>>>> On Thu, 4 Jun 92 19:53:00 GMT, malcolm said: > > let me float a ludicrous concept that flitted through > my conscious whilst ina receptive (frink sodden) state: > re-write TeX in lisp: inorporate it as part of emacs: > what then is impossible? i might have the beginnings of > a bright idea. if i don't please elucidate. [Assuming this isn't a joke!]. Emacs lisp is really not a language to write something as big and complex as a typesetting system in -- a fixed few data structures & dynamic scope don't help for a start. Emacs itself is running up against problems which are due to large packages being written in what is basically a toy language. But a typesetting system in a Lisp dialect is certainly interesting. I suppose Scheme is the obvious candidate, especially for DOS people. More generally, a typesetting system in a high-level language is interesting. --tim From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 4 14:24:38 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00313; Thu, 4 Jun 92 14:24:35 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Jun 1992 14:11 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 2444; Thu, 04 Jun 92 12:44:41 PDT Date: Thu, 4 Jun 92 14:24:42 EDT From: Charles Wells Subject: Re: TeX as a programming language In-Reply-To: MALCOLMC@MOLE.PCL.AC.UK Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <991801B6C4037C6F@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" > re-write TeX in lisp: incorporate it as part of emacs: > what then is impossible? i might have the beginnings of > a bright idea. if i don't please elucidate. Well, I had the same idea except that I wanted to implement TeX in Mathematica. It's perfectly possible, but it would run s.l.o.w.ly. What we need are self-standing programs that do the following tasks, and other similar ones: 1) A program that will take a formula in TeX form and output postscript (or dvi) code for typesetting that formula. 2) Ditto for a paragraph of text. 3) A program that will typeset a complete TeX input, fitting it into pages of specified arbitrary shapes (with each page possibly different), the way a desktop publishing program can do. These programs could call .tex files to set parameters. The idea behind (1) and (2) is that the program will perform LOCAL TeX typesetting, but not the page breaks or the other global stuff. These remarks are related to what I said in the first paragraph, because they would enable me to call these little sub-TeX (pun definitely intended) programs from Mathematica (rather than implementing them in Mathematica) to do local typesetting for placing in mma notebooks. --Charles Wells -- Charles Wells 216 368 2893 From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 00:58:13 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04439; Fri, 5 Jun 92 00:58:12 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 00:58 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0715; Thu, 04 Jun 92 23:57:26 PDT Date: Fri, 5 Jun 92 00:59:03 BST From: Timothy Murphy Subject: Re: Eradicating artificial limitations in NTS In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Thu, 4 Jun 92 10:44:56 BST Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU Philip Taylor writes: > In a sense, I agree with you; but not in the sense you intended. Neither > DVIPS nor WEB2C are a `standard part of TeX'; they may well be useful > adjuncts, the latter particularly for those who are unable to use a good > Pascal compiler, but they are in no sense integral to TeX (for example, > neither is used at this site: we use Arbortext's DVILASER/PS and the > standard VAX/VMS Pascal compiler). I believe it would be a great mistake > to assume that one can implement certain features solely through adjunct > programs. I'm surprised to find myself disagreeing with my betters for the second time in 2 days -- it must be the bad influence of those naughty, naughty Danes. I simply pointed out that large arrays can be allocated dynamically within the present web2c version of TeX. Actually, large arrays _have_ to be allocated dynamically on some, if not all, 16-bit systems. Personally, I wouldn't regard this as a 'feature' of TeX at all. It's just a matter of implementation. Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 00:58:31 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04444; Fri, 5 Jun 92 00:58:29 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 00:58 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0743; Thu, 04 Jun 92 23:57:50 PDT Date: Fri, 5 Jun 92 12:35:58 EST From: Anthony Shipman Subject: Re: TeX as a programming language In-Reply-To: <199206041926.AA16611@yarra.pyramid.com.au>; from "Charles Wells" at Jun 4, 92 2:24 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de > > What we need are self-standing programs that do the following > tasks, and other similar ones: > > 1) A program that will take a formula in TeX form and output > postscript (or dvi) code for typesetting that formula. > > 2) Ditto for a paragraph of text. > > 3) A program that will typeset a complete TeX input, fitting it > into pages of specified arbitrary shapes (with each page > possibly different), the way a desktop publishing program > can do. > > These programs could call .tex files to set parameters. > > The idea behind (1) and (2) is that the program will perform > LOCAL TeX typesetting, but not the page breaks or the other > global stuff. > But a .dvi is not in a form to be reimported into a larger document. You need an intermediate file format with a capabilities like Encapsulated Postscript eg be page-position independent. If we had an intermediate form like this then NTS could be/include a collection of modules for different tasks like table setting or equations. The results could then be joined together by an incremental document compiler. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 01:00:46 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04455; Fri, 5 Jun 92 01:00:45 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 01:00 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0774; Fri, 05 Jun 92 00:00:07 PDT Date: Thu, 4 Jun 92 19:18:41 -0700 From: Arthur Ogawa Subject: Imperfections of TeX 3 In-Reply-To: Michael Downes's message of Tue, 2 Jun 92 21:21:08 CET <9206021924.AA24480@orion.arc.nasa.gov> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de Once again Michael has hit the nail on the head. I may not agree with his proposed fixes, but I can say that I've encountered many of the same problems in dealing with TeX. I will add the following: 1. Space above and below displayed math. Many a typespec that I've had to work with dictated a fixed space baseline-to-baseline from the last line of text above the display to the baseline of the top element in the display, and from the baseline of the bottom element in the display to the first line of text following the math. I can fulfill this specification in cases where there is no buildup (e.g., fraction or the like) in the display math, but otherwise not. TeX's display math is a single box with sometimes great height and depth. The baseline of the expression as a whole is remembered by TeX, but it is not possible to reference the baseline of, say, the numerator or denominator. Another typespec that I've found hard to implement is for fixed glue above and below display math, i.e., suppression of baselineskip glue at these two junctures. Exactly why this is very hard is due to something that Michael Downes pointed out in his posting: the group begun by the $$ is ended before the baselineskip mechanism is invoked at the end of the display math. THere's more to this situation than can be thoroughly discussed in this short note: Try doing Foo$$b=r$$\showlists You'll see that TeX is now in horizontal mode. The situation is by no means simple. 2. Change bars. I know that there are macro packages that implement change bars, and that there is at least one DVI translator that supports changebars. But change bars are a specific case of a more general structure that appears in book design, namely text with a vertical rule to the left, right or both, extending to the full height of the text block. Or text set on top of a colored screen, extending the full height of the text block. The problem arises when pagebreaking is taken into account. In many cases one would want to break the page in the middle of such an element, at some appropriate place. The natural thing to do is to handle this in the output routine, but these side rules are very difficult to execute in this way. The solution I've thought of is \everyline{}, which would be set within \hbox to 0pt at the beginning of every \hbox that TeX spits out of the paragrapher. 3. Consecutive hyphenation, limits on. A typespec reads "no more than three consecutive lines to be hyphenated". TeX's \doublehyphendemerits can be used to statistically reduce the incidence of four consecutive lines hyphenated, but there is no direct way to fulfill this spec. Another spec may read "no more than two consecutive lines to be hyphenated". I'd like a way to simply specify, e.g., \hyphenationlimit=3 to allow no more than three consecutive lines. 4. Color. I know that color capabilities exist in several drivers, but there is a situation that can arise demonstrating that color and font are basically the same sort of attribute. The situation is this: the text is primarily in black, with some text in red. Suppose that TeX choses a pagebreak within a paragraph, indeed within some red type. Here's the problem: how does one ensure that the remainder of the type actually be set in red? In TeX, each letter is set in a specific font; you can see this when you do \tracingoutput. By the same token, each letter's color must in principle be remembered. TeX has a means of remembering the font within each individual \hbox that a paragraph is broken into. Color must be treated the same way, otherwise it is inevitable that the color of the type will be lost under some circumstance or other. I favor having color be an attribute independent of type (I do not wish to have, say cmr10-red, cmr10-blue, and cmr10-black). There is really no need to tie the two together. In fact, if Knuth (or any other intelligent TeX implementor) were to reexamine this issue today, I think he or she would possibly see the "font of the type" and "the color of the ink" to be two aspects of the output stream that could be conceived in a more general way. Knuth's technique of handling font attributes through a font metric file, and its natural extension of handling color attributes through a color metric file, and even the virtual font extension (virtual color extension) could be seen as just two orthogonal dimensions; others may need to be added in future. I favor a method that allows the introduction of yet further dimensions when the need arises. In 1989, Knuth asked me what TeX should do about color. At the time, I was just beginning my work in color, and had not yet seen the above situation. He came away from the conversation thinking that color could be handled by the DVI translator. At present, I am convinced otherwise. My work in color has in fact not encountered the above conundrum, but I'm afraid that it's just a matter of time before this happens. I might mention that TeX's capabiliities WRT color, when properly supported at the DVI translator, are competetive with those of any typesetting (or page layout) package I know. Yet typographic practice does not stop here; we must give TeX well-integrated color capabilities, or see it fall by the wayside in time. Arthur Ogawa Internet: ogawa@orion.arc.nasa.gov Ph: 1/415/691-1126 TeX consultant AppleLink: ogawa FAX:1/415/962-1969 STEPS Project 1101 San Antonio Rd. #413, MOUNTAIN VIEW, CA 94043-1002 From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 05:10:37 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06809; Fri, 5 Jun 92 05:10:36 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 05:10 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4615; Fri, 05 Jun 92 04:10:02 PDT Date: Fri, 5 Jun 92 13:03:06 MEZ From: Peter Schmitt Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <16BAA1EA84038C6D@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU set nts-l ack Peter Schmitt a8131dal@awiuni11.bitnet schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 05:30:05 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06836; Fri, 5 Jun 92 05:30:04 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 05:29 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4808; Fri, 05 Jun 92 04:29:23 PDT Date: Fri, 5 Jun 92 13:09:26 MEZ From: Peter Schmitt Subject: Sorry - I used the wrong nickname Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <197210C4F403B22F@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU As in the subject: Sorry - I used the wrong nickname Peter Schmitt a8131dal@awiuni11.bitnet schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 06:23:29 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07005; Fri, 5 Jun 92 06:23:28 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 06:23 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6087; Fri, 05 Jun 92 05:22:50 PDT Date: Fri, 5 Jun 92 05:08:58 -0700 From: Arthur Ogawa Subject: TeX as a programming language In-Reply-To: Anthony Shipman's message of Fri, 5 Jun 92 12:35:58 EST <9206050704.AA01171@orion.arc.nasa.gov> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <20E75FE18403A41D@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de >>Charles Wells wrote: >> What we need are self-standing programs that do the following >> tasks, and other similar ones: >> >> 1) A program that will take a formula in TeX form and output >> postscript (or dvi) code for typesetting that formula. >> >--lines deleted-- >> The idea behind (1) and (2) is that the program will perform >> LOCAL TeX typesetting, but not the page breaks or the other >> global stuff. >> > >Anthony Shipman responded: > >But a .dvi is not in a form to be reimported into a larger document. >You need an intermediate file format with a capabilities like >Encapsulated Postscript eg be page-position independent. In fact, I do this already, and I use EPS as the intermediate language, so I can say that it is a useful capability indeed. My vehicle is Textures (a TeX for Macintosh), and the EPS is actually editable (it is Adobe Illustrator format), so I can fine-tune aspects of the typeset document if needed. My setup (which is not proprietary) is not a batch process, however, so I'm not (yet) driving it from, say, Mathematica. I find this capability especially handy when preparing graphics that have typeset maths within (used as, say, axis labels). I prepare the math fragments in TeX (usually very quickly), then export them to Illustrator and paste them into the larger graphic. I know this makes me a nerd, but the thing I love is what comes next: I place the resulting graphic in a TeX document (wheels within wheels). I think NTS would well possess powerful interoperability protocols that make such a process more automatic. There's a precedent for this: Rokicki's dvips calls metafont through a (Unix) popen call, to calculate needed bitmaps. It's great. Arthur Ogawa Internet: ogawa@orion.arc.nasa.gov Ph: 1/415/691-1126 TeX consultant AppleLink: ogawa FAX:1/415/962-1969 STEPS Project 1101 San Antonio Rd. #413, MOUNTAIN VIEW, CA 94043-1002 From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 06:25:13 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07009; Fri, 5 Jun 92 06:25:12 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 06:24 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6174; Fri, 05 Jun 92 05:24:07 PDT Date: Fri, 5 Jun 92 14:10:35 +0200 From: "J.J. Winnink" Subject: Re: TeX as a programming language Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <211BBB0C74028F25@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Although i think it is good to redesign TeX the task should not be REINVENTING TeX. Consider the way N. Wirth worked from PASCAL via MODULA(2) to OBERON. OBERON is definitively a "better" programming language but in many respects "smaller" than its predecessors. Jos Winnink, Central Planning Bureau, Applied Mathematics & Computers Science Department The Hague, The Netherlands From @aifh.edinburgh.ac.uk:tim.bradshaw@edinburgh.ac.uk Fri Jun 5 08:34:12 1992 Flags: 000000000001 Return-Path: <@aifh.edinburgh.ac.uk:tim.bradshaw@edinburgh.ac.uk> Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07440; Fri, 5 Jun 92 08:34:08 MDT Via: aifh.edinburgh.ac.uk; Fri, 5 Jun 1992 15:33:33 +0100 Date: Fri, 5 Jun 92 15:29:40 BST Message-Id: <13850.9206051429@aisb.ed.ac.uk> From: Tim Bradshaw To: beebe@math.utah.edu In-Reply-To: "Nelson H. F. Beebe"'s message of Thu, 4 Jun 92 17:36:29 MDT <9206051246.aa06032@uk.ac.ed.festival> Subject: Re: TeX as a programming language >>>>> On Thu, 4 Jun 92 17:36:29 MDT, "Nelson H. F. Beebe" said: > GNU Emacs has demonstrated the power of having an underlying program > implementation written in a efficiently compilable language (C), > together with a sizable overlay written in an extensible interpreted > language (Lisp). The compilable language implements the interfaces to > the operating system, file system, and window system, as well as the > interpreter for the extensible language. Thus, only one language is > needed to bootstrap the system. > Lisp is an efficiently compilable language nowadays too! I used to think that the emacs solution -- hard wire all the grotty low-level stuff in C / whatever and have a fairly lightwight high-level language to do essentially customization in -- was the right thing, but I think one lesson of emacs is that it would be better to do the smallest possible amount in the low-level language and everything possible in the high-level one. Of course this depends on good compiler technology for the high-level language which may make the `smallest possible amount' bigger than one might like -- but then again there's no particular reason why the fancy compiler should have to be in the run-time system, witness Scheme-to-C. Otherwise you'll end up where emacs (and TeX) is now, doing all sorts of huge programs rather badly and slowly in some terribly restricted and unpleasant language, and having to work around all sorts of policy decisions which have been wired in -- for instance TeX's page-breaking, Emacs's comment syntax. --tim From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 10:40:29 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08506; Fri, 5 Jun 92 10:40:25 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 10:39 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9772; Fri, 05 Jun 92 09:39:02 PDT Date: Fri, 5 Jun 92 12:28:09 -0500 From: jsmith@MCS.DREXEL.EDU Subject: Re: TeX as a programming language Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <44BDA3A2E4032D4C@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" >Malcolm Clark suggests that we ``re-write TeX in lisp: incorporate it >as part of emacs''. > >I believe that it is premature to speculate about implementation >details like this, but there nevertheless is some merit to the idea. >For background, last summer's TeX91 meeting had the following talk: > >@Article{Semenzato:TB12-3+4-434-441, > author = "Luigi Semenzato and Edward Wang", > title = "{{A text processing language should be first a > programming language}}", > journal = TUGboat, > year = "1991", > volume = "12", > number = "3+4", > pages = "434--441", > month = Nov, >} > >The authors are Computer Science graduate students at Berkeley, and I >had the pleasure of lunching with them a couple of times and >discussing their very interesting work. > >GNU Emacs has demonstrated the power of having an underlying program >implementation written in a efficiently compilable language (C), >together with a sizable overlay written in an extensible interpreted >language (Lisp). The compilable language implements the interfaces to >the operating system, file system, and window system, as well as the >interpreter for the extensible language. Thus, only one language is >needed to bootstrap the system. > >Other language pairs have been used; the original DEC-10 Emacs used >PDP-10 assembly code and TECO. > >In our copy of Emacs version 18.58, the code line counts are as >follows: > > C: 77274 40% > Lisp: 116261 60% > >For comparison, TeX and Metafont are each about 20K lines of >prettyprinted Pascal or C. > >The C part should not be modified by users, but the Lisp part can be >without compromise of portability. The analogy with TeX and Metafont >is Web (compilable) and macros and other language structures in .tex >or .mf files (extensible). > >The advantage of putting much of the structure of the program into the >user-extensible part is flexibility and power; customization with >Emacs Lisp code can produce {\em portable} versions tuned for a >specific task. > >TeX of course is also extensible, in that any control sequence can be >redefined; however, I contend that its macro language is much harder >than Lisp. > >Devotees of structured markup would likely have little trouble >accepting a Lisp-like syntax, but since Lisp is powerful enough to >write compilers in, almost any desired syntax could be presented to >the end user, including the Plain TeX style. What is critical for >extensibility is that absolutely (well, almost) nothing be hardwired >into the fixed part of the program; all variables, data structures, >and typesetting algorithms need to be accessible for alteration and >enhancement. I agree that the semantics of macro expansion in Tex is much more complex than in, say Common Lisp. The question arises: is this additional complexity absolutely necessary? I know that many macro packages make use of it, but it isn't obvious that they couldn't have been coded in a language that didn't support these features. (Here is an example of what I mean by `complex' features: \expandafter and the ability to assign something to \next. These two commands alone allow macros to affect tokens that follow them --- in other words macros have side-effects that are not confined to assigning values to global variables). Other suggestions: 1. font naming schemes like that of Mittelbach and Schoepf built into the language (or the ability to define general data-structures that can contain these attributes). 2. The ability to break boxes (i.e. to subdivide them so they fit on a page) in output routines in some cases (maybe involving "breakable boxes" as well as the ones currently implemented). Justin R. Smith Department of Mathematics and Computer Science Drexel University Philadelphia, PA 19104 From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 11:10:27 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08830; Fri, 5 Jun 92 11:10:26 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 11:10 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0902; Fri, 05 Jun 92 10:09:36 PDT Date: Fri, 5 Jun 92 13:01:46 -0400 From: PMW Matheson Subject: \onpage and .tfm modifications? Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <48FA92675403996A@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Some ideas on NTS: One of the difficulties for me with TeX is arranging for specific things to happen on specific pages, easy with DTP packages. E.g.: I want pp254--255 to be a longspread, or I need a hairline rule over a split footnote on p362. I am never sure where in the text I need to put the command for this, because of the way TeX reads ahead. Could there not be a page primive of some sort so that you could put a list of special things for specific pages at the beginning of a file, \onpage{256}{\advance\vsize by12pt} \onpage{257}{\advance\vsize by12pt} \onpage{263}{\footnoterule} I have macros that do both these -- the output routine checks for these 2 possible instructions -- but it would be nice to have a simpler and more generic way of doing it. I use two different kinds of PS font: ones Arbortext has remapped for me in the PostScript prolog that comes with their dvips (i.e., Palatino can be declared as PostScript-ordered pspalr, or re-mapped-to-TeX psmpalr) and fonts I have bought, for which I use a set of redefinitions of TeX accent chars. They don't mix easily. And I have Greek and Cyrillic Type 1 fonts which I have had to remap in PostScript and/or write filters for in order to be able to type the chars I want with the key-board equivalents I want (and can see on the screen in the appropriate font in my word-processor). If TeX could only remap chars in the .tfm file --- with, i.e., a "MAPTABLE" list like the current "LIGTABLE" --- it could do all the adapting without having to alter either the font itself or the TeX codes used with it, which would make it much easier to mix different types of font. I haven't used the virtual font method yet, but it seems an extra palaver just to remap a few characters. Perhaps this is just a state-of-knowledge problem peculiar to me... PS: I whole-heartedly agree about the consecutive hyphens and \everyline{} suggestions of Arthur Ogawa. -- Philippa MW Matheson AMPHORAS amphoras@epas.utoronto.ca From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 5 14:51:52 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10859; Fri, 5 Jun 92 14:51:50 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 5 Jun 1992 14:51 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1960; Fri, 05 Jun 92 13:50:21 PDT Date: Fri, 5 Jun 92 21:42:18 BST From: Tim Bradshaw Subject: Re: TeX as a programming language In-Reply-To: jsmith@edu.drexel.mcs's message of Fri, 5 Jun 92 12:28:09 -0500 <9206052030.aa18922@uk.ac.ed.festival> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <67DC6B317403A347@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU >>>>> On Fri, 5 Jun 92 12:28:09 -0500, jsmith@edu.drexel.mcs said: > I agree that the semantics of macro expansion in Tex is much more complex > than in, say Common Lisp. The question arises: is this additional > complexity absolutely necessary? [...] I don't know, but it may well be. In Lisp you also have function application and more-or-less sophisticated control constructs -- macros are just a useful extra (some Lisps don't even have them). In TeX you don't have any of that, so you need this extremely gory macro stuff. Of course if one was to build a language which *did* have other constructs then you could probably do away with most or all of it. --tim From NTS-L@DHDURZ1.Berkeley.EDU Sun Jun 7 17:06:23 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21651; Sun, 7 Jun 92 17:06:22 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Sun, 7 Jun 1992 17:06 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4054; Sun, 07 Jun 92 16:05:42 PDT Date: Mon, 8 Jun 92 10:46:42 +1200 From: jeremy@CS.AUKUNI.AC.NZ Subject: Re: [\onpage and] .tfm modifications? Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0D0C0B3F04042356@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" Philippa MW Matheson writes: >Some ideas on NTS: > >And I >have Greek and Cyrillic Type 1 fonts which I have had to remap in >PostScript and/or write filters for in order to be able to type the >chars I want with the key-board equivalents I want (and can see on the >screen in the appropriate font in my word-processor). If TeX could >only remap chars in the .tfm file --- with, i.e., a "MAPTABLE" list >like the current "LIGTABLE" --- it could do all the adapting without >having to alter either the font itself or the TeX codes used with it, >which would make it much easier to mix different types of font. I >haven't used the virtual font method yet, but it seems an extra >palaver just to remap a few characters. Perhaps this is just a >state-of-knowledge problem peculiar to me... 'Fraid so. Virtual fonts do all you want, and more. There's no need to build the facility in in two different places. Jeremy *---------------------------------------------------------------------* | Jeremy Gibbons CS Dept, Auckland Univ, NZ | *---------------------------------------------------------------------* From NTS-L@DHDURZ1.Berkeley.EDU Sun Jun 7 17:31:56 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21707; Sun, 7 Jun 92 17:31:54 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Sun, 7 Jun 1992 17:31 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4189; Sun, 07 Jun 92 16:31:17 PDT Date: Mon, 8 Jun 92 11:16:58 +1200 From: jeremy@CS.AUKUNI.AC.NZ Subject: Re: TeX as a programming language Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <109DC1EBD403B81F@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" Arthur Ogawa writes: >I prepare the >math fragments in TeX (usually very quickly), then export them to >Illustrator and paste them into the larger graphic. I know this makes me >a nerd, but the thing I love is what comes next: I place the resulting >graphic in a TeX document (wheels within wheels). > >I think NTS would well possess powerful interoperability protocols that >make such a process more automatic. There's a precedent for this: Rokicki's >dvips calls metafont through a (Unix) popen call, to calculate needed bitmaps. >It's great. It's already possible to do this sort of thing (almost) automatically. Better yet: your diagram can change according to the labels. Arthur, what do you do if you want to draw an ellipse round an equation? Is the sizing of the ellipse done automatically? Alan Jeffrey's diagramf package allows you to use Metafont to draw the diagrams. In the Metafont code, you can put down "labels" which consist of bits of TeX. MF writes these out to a file, you run TeX to find out the sizes of the labels, then when MF runs again it can adjust the drawing to reflect the sizes. If you suddenly decide to run all the labels in small italics, perhaps requiring different-shaped diagrams, you need only run TeX and MF again for your diagrams to change accordingly. All nicely portable and automatic! Jeremy *---------------------------------------------------------------------* | Jeremy Gibbons CS Dept, Auckland Univ, NZ | *---------------------------------------------------------------------* From NTS-L@DHDURZ1.Berkeley.EDU Mon Jun 8 18:42:02 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29425; Mon, 8 Jun 92 18:42:01 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 8 Jun 1992 17:48 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8533; Mon, 08 Jun 92 16:48:11 PDT Date: Mon, 8 Jun 92 16:44:29 -0700 From: Arthur Ogawa Subject: TeX exported (was: TeX as a programming language) In-Reply-To: jeremy@CS.AUKUNI.AC.NZ's message of Mon, 8 Jun 92 11:16:58 +1200 <9206072332.AA20583@orion.arc.nasa.gov> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de >Arthur Ogawa writes: > >>I prepare the >>math fragments in TeX (usually very quickly), then export them to >>Illustrator and paste them into the larger graphic. > >It's already possible to do this sort of thing (almost) automatically. >Better yet: your diagram can change according to the labels. Arthur, what >do you do if you want to draw an ellipse round an equation? Is the sizing >of the ellipse done automatically? > >Alan Jeffrey's diagramf package allows you to use Metafont to draw the >diagrams. In the Metafont code, you can put down "labels" which consist of 'Fraid not. I am speaking of high-end publishing here (I must remember to stipulate this in future posts), so metafont's bitmap-based approach won't do. Also, metafont's output is problematic to export to other applications; it would have to conform to the Adobe Encapsulation Standard of PostScript in order to be useful to me. I very much like metafont's basic approach to graphics (script-based), and am therefore interested in metaPost (Hobby), but (and here I am attempting to refocus the discussion on NTS) in the typesetting systems of interest to me and my clients, text and graphics are to be generated by the writer or artist. How many people are out there who can use metafont to generate the graphics for a book? One such group would be those analyzing data for publication. With an appropriate front-end of macros, metafont would be quite capable of serving as a data visualization tool of impressive power and expressiveness. The diagramf package seems to be such a front-end, but who is interested in completing the work of creating a PostScript back-end for metafont? This are the challenges that I perceive. Art Ogawa From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 9 04:03:48 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02009; Tue, 9 Jun 92 04:03:45 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 9 Jun 1992 04:03 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0095; Tue, 09 Jun 92 03:02:58 PDT Date: Tue, 9 Jun 92 10:44:14 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: RE: TeX exported (was: TeX as a programming language) Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: <320BB363E4040772@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Art --- >>> 'Fraid not. I am speaking of high-end publishing here (I must remember >>> to stipulate this in future posts), so metafont's bitmap-based >>> approach won't do. I cannot understand your reservation(s) here: if we assume that no matter how `high-end' your publishing is, you are still constrained to the use of some sort of image setter (even if it achieves 25400 dpi rather than the mere 2540 that I am constrained to), then your final camera-ready copy is _still_ ultimately composed of individual pixels, and therefore MetaFont's `bitmap-based approach' is still applicable. What am I missing, please? Philip Taylor, RHBNC From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 9 09:04:33 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03478; Tue, 9 Jun 92 09:04:30 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 9 Jun 1992 09:02 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1490; Tue, 09 Jun 92 04:38:52 PDT Date: Tue, 9 Jun 92 13:30:45 +0200 From: yannis Subject: my own small list of wishes Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <5BCA5E4934043068@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Here is what I would expect an extension of TeX to have. Number zero is TeXXeT primitives. This extension is already there, made by Don (so there is no counterargument on its validity). I would like it to be standard, if possible in Peter Breitenlohner's TeX--XeT version, which outputs regular DVI files so that there is strictly no incompability with usual TeX if bidirectional features have not been used. And here are my real wishes: 1. Real control over POP and PUSH in the DVI file. I would like to be able to move arbitrarily on my page, and then POP! and back I am on my *exact* starting point. 2. \uccode and \lccode tables inside each font. What's the use of having virtual fonts when the uppercase primitive is so inflexible? Or ---at least--- the ability to change the \uccodes *inside* the argument of \uppercase 3. An \accent primitive capable of accenting ligatures and more generally boxes 4. Vertical kerning. This may sound exotic to you, but the AFM format can do it. And I desperately need it for non-Latin alphabets (everytime I need a character in a ligature raised or lowered, I have to reserve a position in the font for it). 5. Ligatures pointing to other fonts!! Yes, imagine for example that your 256 chars are full, you could still access characters by ligatures...but they have to be in the same font. 6. An extended DVI format, that includes Bezier curves, gray shades and color (and the appropriate primitives to handle them). If that is possible, then we can at last write PStoDVI programs and make DVI a permanent standard (and not a temporary one, just before the ``DVI-to-PS stage'') with no need for \specials anymore. Compatibility of this SuperDVI with the current DVI could be obtained, either by forgetting curves, grays and colors (the easy way) or by converting them to \specials. As you can see, my wishes go rather in the direction of making TeX's perfect machinery even more perfect --- than in the direction of an entirely new machinery. By this occasion I would like to remind you that in the domain of exotic alphabet languages TeX can do things that other programs can't even dream of, even ---and especially--- WYSIAYG ones. Apple prepares a new technology (called World-Ready) which will allow you to use any script of the world at the same time, in the same document (mixing Arabic, Hebrew and Chinese for example, in the original glyphs well understood). This feature used in a TeX source can show TeX's superiority: no other program has the ability to handle correctly all these scripts at the same time. Bottom line: make NTS multilingual, multiscript, multidirectional, enhance the VF and TFM format, and give DVI the same possibilities as PostScript. Cheers Yannis From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 9 09:14:39 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03569; Tue, 9 Jun 92 09:14:36 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 9 Jun 1992 09:11 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7694; Tue, 09 Jun 92 07:37:16 PDT Date: Tue, 9 Jun 92 14:54:27 LCL From: spqr@MINSTER.YORK.AC.UK Subject: Re: my own small list of wishes Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <5D17F72264042B41@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@VM.URZ.Uni-Heidelberg.De yannis writes: > > Here is what I would expect an extension of TeX to have. i like all of them except > 6. An extended DVI format, that includes Bezier curves, gray shades > and color > (and the appropriate primitives to handle them). If > that is possible, then we can at last write PStoDVI programs and > make DVI a permanent standard (and not a temporary one, just before > the ``DVI-to-PS stage'') with no need for \specials anymore. I am not sure I see the point, other than backward compatibility. why not just have NTS write out PostScript, and encourage the effort being made to write PostScript interpreter for all sorts of systems? if you have SuperDVI, then everyone has to write dvi readers for all future devices, as well as PostScript ones. even if PS as is is not the right language, why not target NTS to write out whatever the standards people endorse as the page description language for us all? > Bottom line: make NTS multilingual, multiscript, multidirectional, > enhance the VF and TFM format maybe Rainer, since he owns the list, should decide to hold a ballot. how many people agree with Yannis (as the most recent exponent) who wants `the TeX that Knuth would have written if he had not moved on', as opposed to those who want a completely new system according to all known scientific principles of the 90s? I must say I'd vote for the former, because I want the tool! The problem would be, who is to do it? *someone* has to volunteer or be paid to sit down solidly for (say) a year and produce a program. discussion is all very well, but this list cant write software s From NTS-L@DHDURZ1.Berkeley.EDU Tue Jun 9 19:38:13 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07801; Tue, 9 Jun 92 19:38:11 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 9 Jun 1992 19:38 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4060; Tue, 09 Jun 92 18:37:30 PDT Date: Tue, 9 Jun 92 21:34:59 EDT From: Michael Barr Subject: Yannis' post Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: nts-l@vm.urz.uni-heidelberg.de I would like to say that I agree with him (at least for the part that I need). In particular, the point about bezier curves, gray scales, etc. is, IMHO, very important. I would take strong exception to making TeX device dependent as fixing on PS would do. From what I have seen, PS is far from a standard and has other problems besides. Michael Barr From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 10 05:26:30 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10488; Wed, 10 Jun 92 05:26:29 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 10 Jun 1992 05:26 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5106; Wed, 10 Jun 92 04:25:33 PDT Date: Wed, 10 Jun 92 12:06:30 +0100 From: Robin Fairbairns Subject: Character sets vs. fonts Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <06BDFF1456002C67@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: nts-l@vm.urz.uni-heidelberg.de I am bothered by a conflict between the nomenclature used by two groups of people I regularly converse with. In the standards `community', there are two strongly distinguished ideas, the "character set" and the "font". In the TeX community (note, no quotes here...), the two ideas are combined in the concept of a font. No doubt, many of the members of the TeX community are aware of standards like ASCII (or its post-hoc `parent' ISO 646), ISO 8859 and ISO 10646 (aka, now, as Unicode). These are all standards for character sets. That is, they say nothing about the glyphs that are to be used to represent the characters they talk about. So, one of the parts of 8859 may talk about a "character" Aacute, and may allocate it a place in its code table. What it doesn't do is say what Aacute _means_ (that is left as an exercise to the reader, as with so much of so many standards). The way in which you define the relationship between a font and the character codes it contains is specified in ISO 9541, which also tells you how to do font metrics and all sorts of jolly things like that. Mapping this into the (present) terminology of TeXery, I think we find that pretty much everything is wrapped up into Knuth's concept of font. The nearest one comes to a character set (in the standards sense) is the virtual font (with its confusing name), whose job is to match character codes to glyphs (when one gets past the mechanisms...). I believe that design of a replacement for TeX would be clarified by separating the two (standards) concepts in our discussions. Note: I was moved to post this by Yannis' post about uc/lccodes (inter alia). In my view, these a property of the character set, _not_ of the font. (Yannis is surely right in asserting that their place is _not_ in the format file!) -- Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 10 07:07:42 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10770; Wed, 10 Jun 92 07:07:40 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 10 Jun 1992 07:07 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7761; Wed, 10 Jun 92 06:06:49 PDT Date: Wed, 10 Jun 92 15:04:02 CET From: bbeeton Subject: Re: Character sets vs. fonts In-Reply-To: <01GL1HV3QS6QEO5OE5@MATH.AMS.COM> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <14E35F1206002F1B@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1.BITNET@vm.gmd.de robin fairbairns has given a good summary of the dichotomy between character codes and glyphs as considered by the standards world, and he's quite right that these two concepts are combined (and thereby mixed up) in tex's fonts. (font-related information is mixed up in other parts of tex as well, in ways that aren't always obvious.) just for information, i'm editor of part 4 of iso 9541, application specific extensions, the specific application being "math" (under construction). the intent is that when this part of the standard is complete, "standard" font information structure will be capable of providing everything that tex (the present version) requires; whether or not values will actually be provided for the relevant properties is another, open question, but we can hope. in any event, if there are seen to be gaps in the present tex font information that should be addressed by 9541, please let me know -- it's not too late to make additions and other improvements. (i'll also point out that, though i think by now i have a clear understanding of what is character- and what glyph-related, i haven't got a lot of time to be really active in the discussion, but will try to clarify anything that i think is taking a wrong turn.) -- bb From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 10 11:15:11 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12226; Wed, 10 Jun 92 11:15:09 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 10 Jun 1992 11:04 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8458; Wed, 10 Jun 92 09:50:22 PDT Date: Wed, 10 Jun 92 12:43:38 EDT From: Karl Berry Subject: more possibilities for succ(TeX) Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: <35FDC4B7F6003E14@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@VM.URZ.Uni-Heidelberg.De I sent the following message to a few people before nts-l existed. I guess it's time to bring it up here. Here are some things that others have proposed that I think would be useful, somewhat in order of importance (I find it hard to prioritize these, since, naturally, I think they're all good ideas or I wouldn't bring them up). I've marked the sources in brackets, where I know them. The ones labeled `Frank' are from Frank Mittelbach's article in the 1990 TUG Proceedings TUGboat 11(3). I think virtually everything in that article is worthwhile, but I recapitulate the most important points (drastically abbreviated) here just to have them out in the open. The biggest problem, in my mind, is page layout. But I don't have any concrete suggestions (i.e., what new primitives to add, or existing ones to change) for what to change, nor have I seen any. Line-breaking parameters to avoid rivers and consecutive hyphenations [Frank]. Use fixed-point instead of floating-point arithmetic. [Frank] \fontreadable{fontname} to set \ifeof according to whether \font\foo = fontname would work. I think it's silly for the error message to be mandatory in this case. \showcatcode to tell you the category code of a token; \tracingtokens to show you what TeX is finding for tokens. I've wanted this whenever I debug any macros that play catcode games. Perhaps there could also be some way to reassign category codes to tokens. It's a real pain to have to read things from an input file to have new category codes take effect. Allow more than 16 heights and depths in TFM files. I don't think this can be upward-compatible, but maybe. Box rotation. This is clearly not upward-compatible. [Frank] Make TeX get more information from TFM files, and pay attention to it: the default rule thickness, instead of making it always be .4pt; the ``leadingheight'' and ``leadingdepth'' for struts; the design size of the font; the face information, so TeX can know whether a font is bold or compressed or whatever. Frank suggests access to the lig_kern table as well. Dynamically load characters from TFM files, to conserve memory. Perhaps a scheme for autoloading fonts could also be introduced, so that the TFM file is only loaded when a character is actually typeset from it. Right now this requires hairy macros. Better math formatting of, e.g., double accents. [Frank] Classes of marks analogous to classes of insertions. I've found the business of ``packing more information into the marks'' to be a real pain, and not always able to do what I need. [tex82.bug] An \elseif command, to avoid having a million \fi's stack up. Generalize \leftskip and \rightskip to token lists. If this can be implemented cleanly, it would be a real win. Many people have wanted to do arbitrary things at the beginnings and ends of lines. [tex82.bug] In logging, output the register that corresponds to each quantity, the way it does for primitive glues now. Maybe the symbolic name could even become known somehow. \format{foo} to say ``load foo.fmt''. Then documents wouldn't have to rely on people invoking them with the right program. [Laurence Yaffe] \defaultfileextension{foo} to change TeX to look for file.foo instead of file.tex. \host{name}, \host{type}, \host{os} to provide basic environment information. \getenv to access environment variables. \timelastwritten on a file. \systemcommand to provide a ``shell escape''. Sure, it's system-dependent, but it would be awfully useful, and could make a TeX document be closer to self-contained. [Chris Torek] \TeXversion, so programs can know what they're running on. \usertime a la PostScript, so people can do at least rudimentary timing. \everyeof to insert tokens before an \input file ends [tex82.bug]. An \ifskip primitive. Some syntax for boolean expressions to the \if commands. Generalize \widowline and \clubline to go further into a paragraph, at least two lines. Some typographic styles feel just one line below a section heading at the bottom of a page looks poor. I tend to agree. [tex82.bug] Allow ``implicit letters'' (as in \let\foo=b) in \csname constructions or keywords, etc. I think this is more orthogonal, and it would make \let more useful. Also, I can't see any good reason for not allowing them. From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 10 12:56:14 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12861; Wed, 10 Jun 92 12:56:12 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 10 Jun 1992 12:55 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4591; Wed, 10 Jun 92 11:53:25 PDT Date: Wed, 10 Jun 92 14:50:36 EDT From: Karl Berry Subject: my own small list of wishes In-Reply-To: spqr@MINSTER.YORK.AC.UK's message of Tue, 9 Jun 92 14:54:27 LCL <199206091437.AA09516@cs.umb.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: <458E59F8C6003E80@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de I am not sure I see the point, other than backward compatibility. why not just have NTS write out PostScript I don't think NTS should write PostScript. 1) It's less efficient. 2) There will always be zillions of other page description formats, if only because companies are susceptible to the ``not-invented-here'' syndrome. 3) There are lots of deficiencies in PS (starting with its being a *page* description language, not a *document* description language). This lead to the horrible practice of putting useful -- almost critical -- information into, of all places, comments. PostScript can't change that now (although why they didn't do so in Level 2 is beyond me), but we can at least not help to perpetuate it. encourage the effort being made to write PostScript interpreter for all sorts of systems? This is off the subject, but Ghostscript is a freely available PostScript interpreter which runs on DOS, VMS, and Unix (at least). (ftp prep.ai.mit.edu:pub/gnu/ghostscript*) how many people agree with Yannis (as the most recent exponent) who wants `the TeX that Knuth would have written if he had not moved on', vs. [a new TeX] There's no need to only do one or the other, but it might be useful to have two lists. I, as I said before, also think we should be concentrating on improving the existing TeX, not starting over. discussion is all very well, but this list cant write software Specification before implementation. I agree in principle with lots of the ideas that have been floating past, but usually they are lacking in specific suggestions as to what primitives to add, or existing ones to modify, or other such functional changes. (My own changes are no exception to this, I'm doing at least as poorly as everyone else in this regard.) From NTS-L@DHDURZ1.Berkeley.EDU Wed Jun 10 19:26:45 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15367; Wed, 10 Jun 92 19:26:43 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 10 Jun 1992 19:12 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6908; Wed, 10 Jun 92 16:46:17 PDT Date: Thu, 11 Jun 92 11:40:26 +1200 From: jeremy@CS.AUKUNI.AC.NZ Subject: Re: my own small list of wishes Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <7A212D69F6005506@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" While we're on the subject... Here is a wish I have had several times. It fits into the "continuation to TeX" list, rather than the "new typesetting system" one. TeX allows you to construct a (vertical) box by the usual methods, and then take it apart again using the primitives \lastbox, \lastpenalty, \lastkern and \lastskip. This is vital for getting at the results of TeX's line-breaking---for example, if you want to attach line numbers to the lines of a paragraph. The problem is that the given primitives lose information. For example, boxes in a vertical list can be \moveleft'ed and \moveright'ed; this is how hanging indentation, and hence LaTeX lists, are implemented. This information is lost when disassembling the box, so as far as I can see, there's no easy way to number the lines of a paragraph that may contain a list. (There's another problem in that more things than just boxes, penalties, kerns and skips---viz, specials, marks and insertions---can appear in vertical boxes. I'm not sure what happens when trying to disassemble a box containing these, but I suspect the process just gets "stuck".) The solution to this would be to provide primitives that allow you to disassemble and reassemble an arbitrary box: a \lastwhatsit, \lastmark, and \lastinsert, and perhaps a parameter \lastboxdisplacement which is assigned by \lastbox. (I presume "\moveright" is "equivalent" to "\moveleft<-d>", and that "\moveright<0>" is "equivalent" to "".) Jeremy *---------------------------------------------------------------------* | Jeremy Gibbons CS Dept, Auckland Univ, NZ | *---------------------------------------------------------------------* From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 07:41:02 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18245; Thu, 11 Jun 92 07:41:01 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 07:40 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5582; Thu, 11 Jun 92 06:40:17 PDT Date: Thu, 11 Jun 92 09:31:08 EDT From: Henning Schulzrinne Subject: Output format for NTS In-Reply-To: <9206091139.AA06036@unix1.CS.UMASS.EDU>; from "yannis" at Jun 9, 921:30 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1@vm.gmd.de Some thoughts on the output format for "NTS" -------------------------------------------- The current dvi format has three major disadvantages: 1) it's binary. While compact, this creates major hassles when trying to mail it. Also, transfer of these files from, for example, a VMS system to a Unix system is non-trivial since we have to worry about how VMS blocked binary ends up on the Unix side. 2) It's an extra file to keep around. 3) Graphics inclusion is painful and about as non-standard and non-portable as it can get, despite ten years of use. Some contributors object to PostScript output on a number of grounds: 1) ``it's device dependent'' Not any more or less than dvi. As long as it does not contain font bitmaps, it does not depend on the resolution of the output device, its printing mechanism (laser, ink jet, dot matrix, film, etc.) or the manufacturer of the printer. If there were printers that could interpret dvi files without intermediate file, would that make DVI device dependent? 2) ``it has flaws'' Clearly. There are some issues regarding pixel placement (the PostScript experts will know more about that) and several slightly incompatible implementations. 3) ``it's not standardized'' True, but it's a de-facto standard, with more and more printer manufacturers supporting it. I believe it is even in the process of being formally standardized. Given the difficulties of standardizing DVI \special usage after a decade, that's hardly an argument in favor of DVI. 4) ``the file size is larger than for dvi output'' The differences seem to be marginal. I ran a quick test with /usr/dict/words as input. The results are: -rw-r--r-- 1 hgschulz 227324 Jun 11 09:04 trial.dvi -rw-r--r-- 1 hgschulz 285380 Jun 11 09:05 trial.ps -rw-r--r-- 1 hgschulz 201156 Jun 11 09:03 trial.tex and compressed: -rw-r--r-- 1 hgschulz 119641 Jun 11 09:04 trial.dvi.Z -rw-r--r-- 1 hgschulz 133195 Jun 11 09:05 trial.ps.Z -rw-r--r-- 1 hgschulz 102775 Jun 11 09:03 trial.tex.Z Thus, about 10%-20% difference, hardly earth shattering. Some argue for the extension of DVI with graphics primitives. I'm not quite sure what the advantage of creating yet another page description language is. I'm sure the implementors will avoid some of the pitfalls of PostScript, but just as sure that others will be introduced. Plus, there is the real problem of getting all the printer drivers updated with a non-trivial graphics programming task (translating bezier curves and such into good-looking graphics on devices that don't already support this requires a lot more work than placing characters). The PostScript implementors, both software (GhostScript and Power of the Press and other commercial products) and hardware producers have made the effort already. I see no point in duplicating it ever so slowly one printer at a time. Given that both current DVI file and an extended version have difficulties particularly in distributing typeset documents that include graphics, I suggest a ``hybrid'' approach: Define a PostScript dictionary (probably very similar to the ones used by dvips and brethren) that is both easily parsable by translators (so that a translator of this output format does not have to implement a full PostScript interpreter) and can be directly printed on PostScript printers (by prefixing the file with the appropriate dictionary). This would have several advantages: 1) Graphics primitives and color would be trivial to add in an upward-compatible manner as long as each function defines the number of arguments it expects to pop off the stack as its first argument. Earlier versions could then simply ignore unknown functions. 2) The file is easily transfered using mail, kermit, etc. and readily portable between most operating systems, as long as text files are portable. 3) Only one output file is needed, reducing space needs significantly. 4) The work of the GhostScript project would immediately make a large array of printers available as output devices. 5) The existing PostScript previewers supplied with workstations (pageview, dxpsview) and ghostview for others would make previewing possible without additional software development. 6) The output could be defined to be maximally portable PostScript, using the experience obtained by, say, dvips. If necessary, local changes should be limited to the dictionary, for example to emulate features not supported in the printer. -- --- Henning Schulzrinne (hgschulz@cs.umass.edu) [MIME mail welcome] Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249 From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 09:18:30 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18847; Thu, 11 Jun 92 09:18:28 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 09:18 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9741; Thu, 11 Jun 92 08:16:58 PDT Date: Thu, 11 Jun 92 10:57:22 EST From: Jacques_Gelinas@CMR001.BITNET Subject: PostScript output format for NTS Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU My vote also supports adopting PostScript as standard NTS output. This would free my disk from some of the fonts and transfer part of the work to the intelligent (MC68000) printer. But the main advantage would be the possible links with other typesetting systems. If the secretary wants to use WordPerfect for part of a document (perhaps the abstract, refs) while i do the part involving mathematics... Notes: 1) All systems have bugs. Those of PostScript are at least known. 2) To get text output instead of binary dvi, dvitype exists. If you prefer to write a driver accepting dvitype output as input, it is possible and you will not lose information. 3) Does dvips lose information in translating dvi to PostScript? 4) PostScript (tm) printers are expensive, and Ghostscript output is not perfect (please correct me if i am wrong). From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 09:18:33 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18852; Thu, 11 Jun 92 09:18:32 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 09:18 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9768; Thu, 11 Jun 92 08:17:30 PDT Date: Thu, 11 Jun 92 10:17:06 EDT From: Michael Barr Subject: PS output Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: nts-l@vm.urz.uni-heidelberg.de there is a certain type of writer to this list, mostly from CS departments where they seem not to be limited by finances, who feel that succ(TeX) should be written only for people who have the most expensive equipment and write off the rest. When I said that PS was device dependent, I meant that for the majority of output devices that exist, including most HPLJ printers, most previewers, all dot matrix printers and probably most or all inkjet printers (I am unsure of that) there simply are no PS drivers. Yes, at the price of considerable cost and, I think, speed, I can probably get a PS emulator for my HPLJ IIP, but I very much doubt that it will produce satisfactory output. Someone gave me a copy of ghostscript, but I could not get it working. Also, along with 3/4 of the computing world (at least), I am using MS-DOS and likely to keep on doing so for the forseeable future. I simply do not have the funds to buy the computer with the speed and memory to use OS/2, NT or one of the variouses *nix'es. If succ(TeX) is going to leave me behind, it will leave a lot of others too. If that happens, succ(TeX) will coexist with a large backlog of TeX users and that does not seem to me the way to insure long term viability of the system. One other point. Already device drivers are slower than TeX. If the dvi format were replaced by a text-based one, then I think they would get to be an order of magnitude slower yet. Some encoding standard would obviously solve the transportability problem. I know that is being worked on. Michael Barr From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 09:20:17 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18857; Thu, 11 Jun 92 09:20:14 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 09:19 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9833; Thu, 11 Jun 92 08:19:18 PDT Date: Thu, 11 Jun 92 17:05:30 +0200 From: Rainer Schoepf Subject: The prupose of this discussion list Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: Schoepf@sc.ZIB-Berlin.DE Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@vm.urz.uni-heidelberg.de In the last four weeks a lot of messages were distributed over this list. Unfortunately, most of them did not address the important question: What will NTS be about? Karl Berry and Art Ogawa, among others, have expressed their feeling that we should talk about a successor to TeX that is enhanced by what is ``missing at the moment''. OK so far, only that I feel that this limits the scope of the discussion too much. But if the majority of the members of this discussion group feel the same, I don't want to force you to follow my opinion. However, then we should start be identify the things that we need, but TeX doesn't offer. Up to now, there were mostly lists of details. I want to see named the real problems in TeX's current model. To be more specific: Malcolm Clark mentioned TeX's inability to consider spreads instead of pages; I will go one step further and call TeX's simple locally optimizing page break algorithm insufficient. I'd like to see here: - more of these fundamental flaws - what has already been done to get around them (remember that the typesetting world is tremendously larger than the TeX world). Has anybody on this list already an overview of the literature on this subject? If so, please write down some of it. Only if we know what has already been done (and what is clearly a subset of what can be done) we should discuss things like the implementation environment. I close by quoting a list of questions Jost Krieger brought forward during the discussion at Hamburg, and which should be answered before the first line of code written down: Who will (or should) use TeX? What is the user interface to be? Is backward compatibility essential, and if so, at the DVI or \TeX{} level? The legal status; An implementation environment. Rainer Sch"opf From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 09:51:28 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19118; Thu, 11 Jun 92 09:51:26 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 09:51 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1621; Thu, 11 Jun 92 08:50:38 PDT Date: Thu, 11 Jun 92 11:45:47 EDT From: Henning Schulzrinne Subject: Re: PostScript output format for NTS In-Reply-To: <9206111517.AA10351@unix1.CS.UMASS.EDU>; from"Jacques_Gelinas%CMR001.BITNET@vm.gmd.de" at Jun 11, 92 10:57 am Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1.BITNET@vm.gmd.de Jacques_Gelinas%CMR001.BITNET@vm.gmd.de writes: > Notes: > 2) To get text output instead of binary dvi, dvitype exists. > If you prefer to write a driver accepting dvitype output > as input, it is possible and you will not lose information. Why have two different file formats, plus the difficulty of telling the receiver what to do with the result, if one format will serve both purposes? > 3) Does dvips lose information in translating dvi to PostScript? I'm not advocating using the dvips output. I'm advocating designing a set of PostScript functions that provides a superset of the capabilities of DVI (including graphics primitives), but no control flow (as in plain PostScript). Thus, to write a translator providing today's functionality (text and rules) should be no more difficult than writing a dvi translator, possibly easier, since reading text files is typically easier than reading binary files (at least code is more portable so that the interpreter part that parses the input file should be runable on any operating system with a C compiler). > 4) PostScript (tm) printers are expensive, and Ghostscript output is > not perfect (please correct me if i am wrong). The point about PS printers being expensive is true, but less so every year. GhostScript output is only 'not perfect' because of the lack of real PS fonts. Thus, combined with metafont (or sucessor) generated fonts, there is no reason why it should be any worse than any native PS interpreter. Commercial PostScript interpreters are on the order of $250, thus also not completely impossible. -- --- Henning Schulzrinne (hgschulz@cs.umass.edu) [MIME mail welcome] Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249 From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 10:11:00 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19278; Thu, 11 Jun 92 10:10:57 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 10:10 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 2634; Thu, 11 Jun 92 09:09:15 PDT Date: Thu, 11 Jun 92 12:03:20 EDT From: Henning Schulzrinne Subject: Re: PS output In-Reply-To: <9206111519.AA10375@unix1.CS.UMASS.EDU>; from "Michael Barr" at Jun11, 92 10:17 am Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1.BITNET@vm.gmd.de Michael Barr writes: > > there is a certain type of writer to this list, mostly from CS > departments where they seem not to be limited by finances, who feel > that succ(TeX) should be written only for people who have the most > expensive equipment and write off the rest. When I said that PS was > device dependent, I meant that for the majority of output devices > that exist, including most HPLJ printers, most previewers, all dot > matrix printers and probably most or all inkjet printers (I am > unsure of that) there simply are no PS drivers. Yes, at the price > of considerable cost and, I think, speed, I can probably get a PS > emulator for my HPLJ IIP, but I very much doubt that it will produce > satisfactory output. Have you asked anybody who actually uses it? I have seen output from Freedom of the Press on an HP inkjet printer and it looked very impressive to me. > Someone gave me a copy of ghostscript, but I > could not get it working. As far as I know, GhostScript and the commercial equivalents exist for at least as many printers as there are dvi drivers. I know that GhostScript is being used by many people on MS-DOS systems. > > Also, along with 3/4 of the computing world (at least), I am using > MS-DOS and likely to keep on doing so for the forseeable future. I > simply do not have the funds to buy the computer with the speed and > memory to use OS/2, NT or one of the variouses *nix'es. If > succ(TeX) is going to leave me behind, it will leave a lot of others > too. If that happens, succ(TeX) will coexist with a large backlog > of TeX users and that does not seem to me the way to insure long > term viability of the system. I agree that succ(TeX) should run on a wide variety of systems, but I have yet to be convinced that the suggestion of using the PostScript- hybrid I described earlier will make that any more difficult. > > One other point. Already device drivers are slower than TeX. If > the dvi format were replaced by a text-based one, then I think they > would get to be an order of magnitude slower yet. Again, before claiming things, it might be useful to do a few experiments. A quick test using the same large TeX file (48 pages of output) I used in my earlier message showed that TeX needed 41 seconds of CPU time (0.5 seconds system time), while dvips used 5 seconds (all this on a DECstation 5000). Your mileage will vary, but your statement is at least not true in general. Of the 5 second dvips CPU time, only 0.3 seconds are system time (i.e., spent largely reading and writing). This certainly makes it seem unlikely that a text-based format, which would only affect the file reading part, would seriously affect performance, let alone make drivers an order of magnitude slower. I'll gladly be convinced otherwise by a profiler run on dvips. > Some encoding > standard would obviously solve the transportability problem. I know > that is being worked on. Yes, you can use uuencode or similar systems. Thus, there is no need to create a new encoding standard. But again, I don't see the disadvantages of starting out with a text-based format. Any encoding standard would require en/decoding software that's available on every target system, plus it introduces yet one more step where things can go wrong. -- --- Henning Schulzrinne (hgschulz@cs.umass.edu) [MIME mail welcome] Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249 From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 10:39:25 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19484; Thu, 11 Jun 92 10:39:23 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 10:39 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4852; Thu, 11 Jun 92 09:38:24 PDT Date: Thu, 11 Jun 92 17:29:51 BST From: Tim Bradshaw Subject: Re: Output format for NTS In-Reply-To: Henning Schulzrinne's message of Thu, 11 Jun 92 09:31:08 EDT <9206111414.aa22061@uk.ac.ed.festival> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU >>>>> On Thu, 11 Jun 92 09:31:08 EDT, Henning Schulzrinne said: > 4) ``the file size is larger than for dvi output'' > The differences seem to be marginal. I ran a quick test with > /usr/dict/words as input. The results are: > -rw-r--r-- 1 hgschulz 227324 Jun 11 09:04 trial.dvi > -rw-r--r-- 1 hgschulz 285380 Jun 11 09:05 trial.ps > -rw-r--r-- 1 hgschulz 201156 Jun 11 09:03 trial.tex > and compressed: > -rw-r--r-- 1 hgschulz 119641 Jun 11 09:04 trial.dvi.Z > -rw-r--r-- 1 hgschulz 133195 Jun 11 09:05 trial.ps.Z > -rw-r--r-- 1 hgschulz 102775 Jun 11 09:03 trial.tex.Z > > Thus, about 10%-20% difference, hardly earth shattering. > I think this may be a bad test. Try it on some document reasonably dense with maths and/or tables. --tim From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 11:05:02 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19726; Thu, 11 Jun 92 11:05:00 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 11:03 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6132; Thu, 11 Jun 92 10:02:45 PDT Date: Thu, 11 Jun 92 12:58:19 EDT From: HenningLeidecker Subject: Re: Output sizes for *.tex, *.dvi, and *.dvi Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" Tim Bradshaw suggests that the dvi-PS file size ratio might be influenced by the amount of math. Here are some results for two short files, and a longish one, all dense with math: Hmwk01.tex 10,537 100% .dvi 17,232 164% .ps 99,199 941% Hmwk02.tex 10,613 100% .dvi 15,712 148% .ps 101,095 953% Dis01.tex 43,690 100% .dvi 66,384 152% .ps 391,177 895% Looks like a good suggestion, Tom. My '040 NeXT Cube ran LateX on these files at about 3 (8.5x11 inch) pages per second. It took about 3 seconds to produce the 391,177 Kbyte PS file from the dvi file. Henning Leidecker From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 11:22:39 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19873; Thu, 11 Jun 92 11:22:37 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 11:20 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6774; Thu, 11 Jun 92 10:17:22 PDT Date: Thu, 11 Jun 92 13:13:46 EDT From: HenningLeidecker Subject: Re: NTS and computer-text management? Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0162DED006006F6D@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" ========================================= General thesis, and --> a question <--: Producing a beautifully formatted printed document is immensely desirable. But also desirable is the ability to computer-manage a growing library of files to carry out searches, to quote excerpts into new documents, to insert "hyperlinks", to prepare word lists, and so on. Unfortunately, some ways of producing "beautifully formatted printed documents" leave the text <> within the formatting methods --- it is prohibitively hard to extract the text from the formatting mark-ups. This is immensely undesirable. --> Is it possible for NTS to support both purposes? Are these so different that it would require NTS to "serve two masters" and necessarily fail? <-- I don't know. But I do know that my growing collection of files is such an important resource to me that I will not imprison them within a system that supports "beautifully printed pages" at the sacrifice of ease of access and ease of re-use of the text in the files. ========================================= Particular examples: Files must include (at least some) structure information to fully support common computer-management tasks. For example, search engines currently allow one to specify a "hit" as occurring when some number of targets-items are found within a given structural unit, which can be a word, a phrase, a sentence, a paragraph, etc --- provided the structural unit can be recognized by the search-engine. And the searches can be restricted to certain structures, like Tables of Contents, or Footnotes. This strategy (a form of "key-term in context") can be superior to one which specifies a "hit" based upon the file-distance in bytes between target-items, directed indiscriminately at the entire file. And (at least some) format information must also be available. For example, the preparation of a *page-referenced* index, concordance, or "scholar's notes" requires this. I can do some work with the tex-files thanks to "detex", and some other work using the dvi-files. This is not ideal, but is workable. And philosophically not totally objectionable, I think: (1) questions that involve mainly the text are well-addressed by working with the text-file that results from applying "detex" to *.tex or "dvitype" to *.dvi; (2) questions that involve location-on-page information can use the dvi-file, rather than build and run the entire TeX-engine all over again. Extracting the text from a PostScript-encoded document is possible, but with an amount of work that increases steeply with increasing use of PS formatting features. It has usually been more practical for me to OCR-scan PS output to extract its text, than to de-PScode the file. Adobe is hard at work on a kind of "text-object" that will improve the status of text-as-text within the PS language. Acknowledgement is given to Henning Schulzrinne's thoughtful posting "Output format for NTS" for stimulating me to write this. Henning Leidecker From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 11:53:27 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20049; Thu, 11 Jun 92 11:53:23 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 11:52 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8587; Thu, 11 Jun 92 10:52:18 PDT Date: Thu, 11 Jun 92 13:48:46 EDT From: Henning Schulzrinne Subject: Re: Output sizes for *.tex, *.dvi, and *.dvi In-Reply-To: <9206111702.AA11714@unix1.CS.UMASS.EDU>; from "HenningLeidecker" atJun 11, 92 12:58 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <05F1B4AE9600766F@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1.BITNET@vm.gmd.de HenningLeidecker writes: > > Tim Bradshaw suggests that the dvi-PS file size ratio might be > influenced by the amount of math. Here are some results for two > short files, and a longish one, all dense with math: .. omitted, showing that .ps files are several times larger than dvi files ... Good point. One item should not be overlooked, however: the PostScript files contain the bit maps for all the fonts - hardly a fair comparison. This is clearly more noticeable with smaller tex files than with larger ones. One example: a 12 K TeX file heavy on math produces a .ps file that consists to 70% of bitmaps and dictionary. Space comparisons should also take the compressed size into consideration, as long term storage for space-constrained systems could easily use compress or something similar. Typically, PostScript output is more redundant and thus achieves a higher compression ratio. I'm not really concerned with the relative sizes of output from dvips and the .dvi file itself. My suggestion was to come up with a PostScript-interpretable output file that could employ similar space-saving techniques as used by the DVI format (saving of current location, pre-defined movements instead of absolute coordinates, etc.) if that were deemed important. The only major difference in space would be that coordinates would be encoded in text form rather than as binary coordinates and that text arguments have to be enclosed in parentheses. For the same reason, it shouldn't be any more difficult to extract the unformatted text from this ``constrained PostScript'' file than from a DVI file. As far as text processing goes, I would argue that any method that tries to do semantic processing should be applied to the structural markup (SGML, LaTeX), not the page layout stage (``raw'' TeX, DVI, PS), whichever format or abstraction is used. To combine both in one file is in my opinion a bad idea, particularly if one structural markup is to have several representations (say, printed manual, hypertext, ASCII output, etc.). Again, to avoid further ``space wars'': I readily concede that dvips output can be drastically larger than the dvi file, but that's not the point in developing a new output format. I hope we can agree that the current DVI format combined with \special kludges is not exactly an elegant way to do page layout in the 21st century. -- --- Henning Schulzrinne (hgschulz@cs.umass.edu) [MIME mail welcome] Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249 From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 11:53:46 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20064; Thu, 11 Jun 92 11:53:44 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 11:53 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8600; Thu, 11 Jun 92 10:52:53 PDT Date: Thu, 11 Jun 92 13:46:48 EDT From: "David M. Jones" Subject: Output sizes for *.tex, *.dvi, and *.dvi In-Reply-To: HenningLeidecker's message of Thu, 11 Jun 92 12:58:19 EDT <199206111702.AA18891@theory.lcs.mit.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0606AF9F86007978@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU >Tim Bradshaw suggests that the dvi-PS file size ratio might be >influenced by the amount of math. Here are some results for two >short files, and a longish one, all dense with math: There are still a couple of problems with this methodology. The most important is that the PS file contains a rather large number of fonts in bitmap form. Similarly, the PS file has a PostScript dictionary prepended. In the limit as the document gets very large, this won't matter, but for small files it gives rather biased numbers. Of course, in real-life situations, the fonts and header wouldn't have be kept in every file; they'd be kept in a separate library and added when necessary. To give you some ideas of the numbers, here's what I get when I TeX some rather math-intensive documents and convert them to PS with dvips. The .cor files are the PS files without headers. First some small files (2-7 pages each): ps1.tex 11961 ps1.dvi 19724 ps1.cor 29431 (1.49 times as big as dvi file) ps1.ps 82989 ps2.tex 23592 ps2.dvi 35824 ps2.cor 55640 (1.55) ps2.ps 14876 ps3.tex 15389 ps3.dvi 16428 ps3.cor 27042 (1.65) ps3.ps 76058 ps4.tex 27112 ps4.dvi 39132 ps4.cor 62682 (1.60) ps4.ps 13620 ps5.tex 9572 ps5.dvi 15768 ps5.cor 22966 (1.45) ps5.ps 70265 ps6.tex 11516 ps6.dvi 22556 ps6.cor 32693 (1.45) ps6.ps 81460 ps7.tex 9648 ps7.dvi 15880 ps7.cor 23335 (1.46) ps7.ps 72136 ps8.tex 14913 ps8.dvi 25828 ps8.cor 39699 (1.53) ps8.ps 94669 ps9.tex 3991 ps9.dvi 6696 ps9.cor 9351 (1.40) ps9.ps 49524 And then a 260+ page book I'm working on: *.tex 488774 Root.dvi 791000 Root.cor 1056394 (1.33) Root.ps 1263486 David M. Jones "Trifles! Trifles light as air!" dmjones@theory.lcs.mit.edu -- the Hystricide From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 12:10:53 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20190; Thu, 11 Jun 92 12:10:48 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 12:10 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9383; Thu, 11 Jun 92 11:09:18 PDT Date: Thu, 11 Jun 92 18:46:48 BST From: Tim Bradshaw Subject: Re: Output sizes for *.tex, *.dvi, and *.dvi In-Reply-To: HenningLeidecker's message of Thu, 11 Jun 92 12:58:19 EDT <9206111729.aa27772@uk.ac.ed.festival> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0857256476007633@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU >>>>> On Thu, 11 Jun 92 12:58:19 EDT, HenningLeidecker said: > > Tim Bradshaw suggests that the dvi-PS file size ratio might be > influenced by the amount of math. Here are some results for two > short files, and a longish one, all dense with math: > > [and this turns out to be true] Well I'm sorry to generate yet more traffic on this, but I think I probably wasn't right: DVI includes no glyph bitmaps, the PS does and with maths there may be very many more bitmaps. The small size of the DVI file is really misleading here since it's relying on a common culture of fonts. I wonder how compact one could get a PS representation? I mean presumably you could write a dvi interpreter in PS? Of course this completely defeats the object, but it's not clear that the existing drivers produce code that's anywhere near optimal. For the record, I think that it might be fruitful to think about these -- basically interface -- problems at a level one step back from DVI. What I mean is that it might be interesting to think about what *operations* an NTS should want to do to produce output. This is the same approach that compilers seem to take now -- of working in terms of a operations on a virtual machine which can then be translated to real machine code quite simply. If this level is sufficiently carefully specified then it is a rather small amount of work to generate real output in any one of several languages. I think until we know what operations are useful then it's a waste of time worrying about file sizes. The same probably goes for input languages too. --tim From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 12:11:51 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20225; Thu, 11 Jun 92 12:11:49 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 12:11 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9467; Thu, 11 Jun 92 11:09:52 PDT Date: Thu, 11 Jun 92 14:03:19 EDT From: "David M. Jones" Subject: OOPS: Output sizes for *.tex, *.dvi, and *.dvi In-Reply-To: HenningLeidecker's message of Thu, 11 Jun 92 12:58:19 EDT <199206111702.AA18891@theory.lcs.mit.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <087DA66AE600863B@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU A couple of my numbers for .ps files were truncated. Here are the correct numbers: ps2.tex 23592 ps2.dvi 35824 ps2.cor 55640 (1.55) ps2.ps 114876 ****** ps4.tex 27112 ps4.dvi 39132 ps4.cor 62682 (1.60) ps4.ps 113620 ****** And just for the record, here are the compressed file sizes: ps1.dvi.Z 12396 ps1.cor.Z 13754 (1.11) ps2.dvi.Z 19967 ps2.cor.Z 23206 (1.16) ps3.dvi.Z 9549 ps3.cor.Z 11757 (1.23) ps4.dvi.Z 21012 ps4.cor.Z 25808 (1.23) ps5.dvi.Z 9822 ps5.cor.Z 10800 (1.10) ps6.dvi.Z 12472 ps6.cor.Z 14510 (1.16) ps7.dvi.Z 9578 ps7.cor.Z 10472 (1.10) ps8.dvi.Z 15471 ps8.cor.Z 17314 (1.12) ps9.dvi.Z 4619 ps9.cor.Z 4774 (1.03) Root.dvi.Z 369129 Root.cor.Z 412764 (1.12) David M. Jones "Trifles! Trifles light as air!" dmjones@theory.lcs.mit.edu -- the Hystricide From NTS-L@DHDURZ1.Berkeley.EDU Thu Jun 11 21:59:35 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23930; Thu, 11 Jun 92 21:59:34 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 11 Jun 1992 21:59 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9334; Thu, 11 Jun 92 20:58:54 PDT Date: Fri, 12 Jun 92 13:34:13 EST From: Anthony Shipman Subject: Re: Output sizes for *.tex, *.dvi, and *.dvi In-Reply-To: <199206111809.AA05241@yarra.pyramid.com.au>; from "Tim Bradshaw" atJun 11, 92 6:46 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <5AABAC5D86009933@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > For the record, I think that it might be fruitful to think about these > -- basically interface -- problems at a level one step back from DVI. > What I mean is that it might be interesting to think about what > *operations* an NTS should want to do to produce output. This is the > same approach that compilers seem to take now -- of working in terms > of a operations on a virtual machine which can then be translated to > real machine code quite simply. If this level is sufficiently > carefully specified then it is a rather small amount of work to > generate real output in any one of several languages. I think until > we know what operations are useful then it's a waste of time worrying > about file sizes. > > The same probably goes for input languages too. > > --tim > It has been suggested that we generate a Postscript output and that this would be easier to manipulate than the present .dvi files. The argument that it is easier to parse text files than decode binary files is false in my opinion. In the .dvi files we have pointers to the various sections that make it easy to jump around and locate the sections eg pages in the .dvi files, bitmaps in the .pk files etc. I find reading commands in binary format easier than having to build a lexical scanner and parser for some text format which can only be read sequentially anyway. It has been suggested that the output file format be a specially "constrained" Postscript to make it easy to interpret for non-Postscript printers. I believe this suggestion argues against itself. Having to define a set of constraints to make Postscript do what you want is a sign that you are using the wrong tool for the job. Also there will always be the possibility of changes in Postscript will require changes in the NTS output file format. The message above talks about defining operations for a virtual machine that NTS compiles source files to. These operations should be what is in the output file in a format that NTS has under its control. The operations can be oriented towards Postscript so that translation to Postscript is easy. The format will be more maintainable in the long term in my opinion. Also it will still be meaningful after Postscript is obsolete! As a design principle here I believe in monotonic flow from the specific to the general. The document text starts in a format specific to TeX then gets converted into a more general .dvi file. (It is more general in that you could have .dvi files that could never be generated by TeX). Then this gets converted into the even more general PostScript and finally into the most general bitmap on page. Any attempt to reverse this flow creates problems. "Constrained Postscript" is a reverse of this flow in my opinion. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 01:10:15 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25066; Fri, 12 Jun 92 01:10:14 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 01:10 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3794; Fri, 12 Jun 92 00:09:30 PDT Date: Fri, 12 Jun 92 08:03:00 GMT From: malcolm Subject: RE: Output format for NTS Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <754C954D56007649@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU dvi/device dependence. there have been at least two printers which can interpret dvi directly (not that this really affects the arguments). what's wrong with pcl5? just an idle thought.... malcolm clark From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 02:56:59 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25308; Fri, 12 Jun 92 02:56:58 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 02:56 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5579; Fri, 12 Jun 92 01:56:08 PDT Date: Fri, 12 Jun 92 09:34:34 BST From: Martin Ward Subject: PostScript is not device independant. Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <84320CDC5600AC7E@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU The point of having TeX (or NTS) output a dvi file is that the dvi file is device independant---hence the name! Dvi files contain no glyph bitmaps: in fact they know nothing about the shapes of the characters (apart from what is in the tfm files) or the resolution of the output device. If you use anything other than the "standard" PostScript fonts (and I am sure none of us wants to place _that_ restriction on NTS!) then a PostScript file has to contain the glyph bitmaps for some particular printing engine at a particular resolution. Try printing dvips output intended for a "write-white" engine on a "write-black" engine (at the same resolution) and you'll see what I mean. If you don't include the glyph bitmaps in the ps output of NTS then you need an extra process (a pstops program) which adds the bitmaps to a special format PostScript file - which is not directly interpretable by any PostScript device! What then is the advantage of PostScript output? Conclusion: typesetting should produce device independant output which necessarily implies a dvi to device-dependant-format translator. PostScript seems a poor choice for the device independant output especially when compared to the dvi format. Martin. JANET: Martin.Ward@uk.ac.durham Internet (eg US): Martin.Ward@durham.ac.uk or if that fails: Martin.Ward%uk.ac.durham@nsfnet-relay.ac.uk or even: Martin.Ward%DURHAM.AC.UK@CUNYVM.CUNY.EDU BITNET: Martin.Ward%durham.ac.uk@UKACRL UUCP:...!uknet!durham!Martin.Ward From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 03:38:37 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25417; Fri, 12 Jun 92 03:38:35 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 03:38 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6141; Fri, 12 Jun 92 02:37:43 PDT Date: Fri, 12 Jun 92 09:30:31 GMT From: spqr@MINSTER.YORK.AC.UK Subject: Re: PostScript is not device independant. Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8A00D85E16009B2B@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Martin Ward writes: > > is device independant---hence the name! Dvi files contain no glyph bitmaps: > in fact they know nothing about the shapes of the characters (apart from > what is in the tfm files) or the resolution of the output device. > If you use anything other than the "standard" PostScript fonts (and I am > sure none of us wants to place _that_ restriction on NTS!) then a > PostScript file has to contain the glyph bitmaps for some particular > printing engine at a particular resolution. Try printing dvips output I assumed in my innocence that people would stop downloading bitmaps into their output, and allow the printing device to sort all that sort of thing out. OK, so the PostScript `comment' convention for saying `I need a copy of Bembo Italic' is rather gross, but its there. some printing systems may need to find a copy of the font and download it to the printer, others may know its been downloaded or is on a hard disk. just the same problems for a receiver of the file as when receiving a dvi file. The output from NTS should not contain glyph information, we are all agreed on that (I hope). PostScript and dvi are equal in this respect, IMHO. except that millions more people and software packages know about PostScript than dvi format. Sebastian From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 03:38:50 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25422; Fri, 12 Jun 92 03:38:49 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 03:38 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6149; Fri, 12 Jun 92 02:37:58 PDT Date: Fri, 12 Jun 92 09:30:31 GMT From: spqr@MINSTER.YORK.AC.UK Subject: Re: PostScript is not device independant. Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8A103F3D16009932@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Martin Ward writes: > > is device independant---hence the name! Dvi files contain no glyph bitmaps: > in fact they know nothing about the shapes of the characters (apart from > what is in the tfm files) or the resolution of the output device. > If you use anything other than the "standard" PostScript fonts (and I am > sure none of us wants to place _that_ restriction on NTS!) then a > PostScript file has to contain the glyph bitmaps for some particular > printing engine at a particular resolution. Try printing dvips output I assumed in my innocence that people would stop downloading bitmaps into their output, and allow the printing device to sort all that sort of thing out. OK, so the PostScript `comment' convention for saying `I need a copy of Bembo Italic' is rather gross, but its there. some printing systems may need to find a copy of the font and download it to the printer, others may know its been downloaded or is on a hard disk. just the same problems for a receiver of the file as when receiving a dvi file. The output from NTS should not contain glyph information, we are all agreed on that (I hope). PostScript and dvi are equal in this respect, IMHO. except that millions more people and software packages know about PostScript than dvi format. Sebastian From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 04:32:41 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25664; Fri, 12 Jun 92 04:32:39 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 04:32 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6592; Fri, 12 Jun 92 03:32:01 PDT Date: Fri, 12 Jun 92 11:25:59 BST From: Tim Bradshaw Subject: This whole PostScript/dvi argument Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <919516071600A951@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU I think this argument is terribly premature. Let's say we'll produce PostScript: PostScript is Turing-equivalent so you've just said precisely nothing. Similarly with `DVI' -- what does this mean? Am I allowed to specify a `DVI' format that just happens to be parsable by a PostScript printer given a suitable prologue? I think it just isn't interesting right now to talk about just what bytes we want in our output files; the question should be what we want to be able to *express* in the output files. Once that is sorted out *then* file formats are interesting. A while back people were talking about new operations in DVI -- this is the interesting bit. If you want bezier splines then what does that mean for the rest of the system? How will you make NTS talk about these? Assuming the operations that NTS can do on its output are specified (and `produce PostScript output' is not a specification any more than `write a typesetting system' is) and the thing is cleanly written than it is some small amount of work to glue any arbitrary back end onto it. --tim From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 08:16:24 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27114; Fri, 12 Jun 92 08:16:22 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 08:16 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6884; Fri, 12 Jun 92 07:15:39 PDT Date: Fri, 12 Jun 92 09:05:50 CDT From: William Gropp Subject: This whole PostScript/dvi argument Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L%DHDURZ1.BITNET@anlvm.ctd.anl.gov I'd like to suggest a different resolution to this mess. Rather than decide what output format to use in a turnkey program, why not design a library of routines that perform the text formatting tasks that TeX is particularly good at, with hooks for various extensions. This separates the algorithms from a particular language syntax, and allows good typesetting algorithms to be easily applied in other contexts (such as graphics). It would also allow experimentation with different syntaxes. In terms of the dvi-vs-postscript debate, the interface would have to include a drawing interface; versions for dvi, postscript, and whatever else could be provided. Designing such an interface specification would be very difficult; however, I believe that it would produce a more widely usable result than a "replacement" TeX. The pros of this approach should be obvious; the cons include the danger that having a library of routines would make it too easy to write a formatting program, thus adding to the chaos of existing formats. Bill Gropp From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 13:25:02 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29253; Fri, 12 Jun 92 13:25:00 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 13:24 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1819; Fri, 12 Jun 92 12:24:16 PDT Date: Wed, 3 Jun 92 21:04:33 MESZ From: Joachim Schrod Subject: WEB is not a `better Pascal' In-Reply-To: <199206031850.AA27520@rs3.hrz.th-darmstadt.de>; from"jsmith@king.mcs.drexel.edu" at Jun 3, 92 2:46 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@vm.urz.Uni-Heidelberg.de Comments: Warning -- original Sender: tag was tex@RS3.HRZ.TH-DARMSTADT.DE Justin Smith wrote: > > WEB was originally designed to solve problems that no > longer exist in most programming languages (i.e. lack of external > procedures in the early release of Pascal that Knuth had, etc.). No. WEB was designed as an aid for using the Literate Programming paradigm with Pascal. That DEK did neither use external procedures nor dynamic memory has nothing to do with WEB. (BTW, I did not know that ISO Pascal has a defined way for external procedures now...) And as DEK said it in his Mainz presentation: The `Literate Programming' concept is the main result of his TeX project. (If you contact him at the moment where you present him work about Literate Programming you will get an answer very soon. Try the same with things about TeX...) Check his article in Computer J. (full reference on request) for it. > It has > never (to my knowledge) been widely used for anything but TeX and related > software. Sorry, but isn't this a catch-all phrase? `Widely used' may be judged very subjectively. I know alot' programmers which use the Literate Programming paradigm (but always never with WEB, because they don't use Pascal...) and I know some systems in the 20MB source range created with this paradigm in mind -- so it's also not used only for toy programs. For me, this is `widely used' enough. (Please note that I don't want to join a discussion how to implement a TeX successor. I reacted to your general comments on WEB.) -- Joachim From NTS-L@DHDURZ1.Berkeley.EDU Fri Jun 12 13:25:37 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29258; Fri, 12 Jun 92 13:25:36 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 12 Jun 1992 13:25 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1831; Fri, 12 Jun 92 12:24:53 PDT Date: Fri, 12 Jun 92 20:56:58 MESZ From: Joachim Schrod Subject: Re: Character sets vs. fonts In-Reply-To: <199206101307.AA32374@rs3.hrz.th-darmstadt.de>; from "bbeeton" at Jun 10, 92 3:04 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@vm.urz.Uni-Heidelberg.de Comments: Warning -- original Sender: tag was tex@RS3.HRZ.TH-DARMSTADT.DE barbara wrote: > > robin fairbairns has given a good summary of the dichotomy between > character codes and glyphs as considered by the standards world, and > he's quite right that these two concepts are combined (and thereby > mixed up) in tex's fonts. Hmm, barbara, do I miss something? I cannot follow you and Robin, perhaps because I don't see the program TeX82 alone, but the combination TeX82/driver. TeX82 knows about an 1. input character code set. This character code set is mapped to a 2. normalized character code set Well, at least some kind of. One could say `an extended ASCII'. I think the EC encoding scheme will influence this encoding in the future. The mapping is realized via the xchr/xord mechanism. Although fixed in many implemantations, some _do_ allow to change it at runtime. The normalized character code set is without loss of generality taken as the glyph position within device independent fonts. This is mapped to the 3. glyph position within real, existant, fonts by VF files. Of course, the mapping between the device independent fonts TeX works with (represented by TFM files) and the real fonts (ie, PK fonts or builtin fonts) is not the identical mapping. Drivers may even add the possibility of YetAnotherMapping, eg, within PostScript. Where is the problem? Can you or Robin supply me with examples of encoding problems which are not easily resolved by the existing mechanisms? Where are the three encodings (cf. character coding / glyph position), together with two freely adaptable mappings, not enough? -- Joachim