======================================================================== Date: Mon, 1 Jun 92 11:33:41 +0200 Reply-To: "NTS-L Distribution list" From: N.POPPELIER@ELSEVIER.NL Subject: RE: TeX is perfect In-Reply-To: <48771FB76009B459@HEARNVAX.nic.SURFnet.nl> >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 ======================================================================== Date: Mon, 1 Jun 92 11:36:19 +0200 Reply-To: "NTS-L Distribution list" From: N.POPPELIER@ELSEVIER.NL Subject: RE: What should we discuss? In-Reply-To: <543DE5A34007FA80@HEARNVAX.nic.SURFnet.nl> I agree with Karl: we should TeX 3.14/METAFONT 2.7 as starting point, and consider extensions to them. Nico ======================================================================== Date: Mon, 1 Jun 92 01:45:44 -0400 Reply-To: "NTS-L Distribution list" From: laurent@MATH.TORONTO.EDU Subject: OOPS CORRECTION: 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 ======================================================================== Date: Mon, 1 Jun 92 00:56:47 -0400 Reply-To: "NTS-L Distribution list" From: laurent@MATH.TORONTO.EDU Subject: LINESPACING EXAMPLE. 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. ======================================================================== Date: Mon, 1 Jun 92 00:55:25 -0400 Reply-To: "NTS-L Distribution list" From: laurent@MATH.TORONTO.EDU Subject: VICTOR ON THE SKYLINE 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 ======================================================================== Date: Mon, 1 Jun 92 11:58:35 BST Reply-To: "NTS-L Distribution list" 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 > 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 ======================================================================== Date: Mon, 1 Jun 92 17:40:14 BST Reply-To: "NTS-L Distribution list" 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 > 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 ======================================================================== Date: Tue, 2 Jun 92 08:10:00 GMT Reply-To: "NTS-L Distribution list" From: malcolm Subject: RE: TeX is not perfect! 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? ======================================================================== Date: Tue, 2 Jun 92 16:50:13 BST Reply-To: "NTS-L Distribution list" From: Timothy Murphy Subject: RE: TeX is not perfect! In-Reply-To: malcolm's message of Tue, 2 Jun 92 08:10:00 GMT > 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 ======================================================================== Date: Tue, 2 Jun 92 14:02:36 EDT Reply-To: "NTS-L Distribution list" From: Michael Barr Subject: RE: TeX is not perfect! 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 ======================================================================== Date: Tue, 2 Jun 92 19:46:53 BST Reply-To: RHBNC Philip Taylor From: CHAA006@VAX.RHBNC.AC.UK Subject: RE: TeX is not perfect! 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 ======================================================================== Date: Tue, 2 Jun 92 21:21:08 CET Reply-To: "NTS-L Distribution list" From: Michael Downes Subject: Imperfections of TeX 3 In-Reply-To: <01GKQQXX7746ELNYPI@MATH.AMS.COM> 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. ======================================================================== Date: Tue, 2 Jun 92 22:27:40 -0400 Reply-To: "NTS-L Distribution list" From: laurent@MATH.TORONTO.EDU Subject: Downes on line spacing. 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 ======================================================================== Date: Wed, 3 Jun 92 06:01:40 CET Reply-To: "NTS-L Distribution list" From: bbeeton Subject: Re: Downes on line spacing. In-Reply-To: <01GKR738CXO2ELNXY2@MATH.AMS.COM> 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 ======================================================================== Date: Wed, 3 Jun 92 09:11:51 LCL Reply-To: "NTS-L Distribution list" From: spqr@MINSTER.YORK.AC.UK Subject: how do you spot TeX? "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 ------- ======================================================================== Date: Wed, 3 Jun 92 15:39:37 +0200 Reply-To: "NTS-L Distribution list" From: N.POPPELIER@ELSEVIER.NL Subject: RE: Imperfections of TeX 3 In-Reply-To: <442F7262000A107F@HEARNVAX.nic.SURFnet.nl> 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 ======================================================================== Date: Wed, 3 Jun 92 14:11:56 CET Reply-To: "NTS-L Distribution list" From: Michael Downes Subject: Re: Downes on line spacing. In-Reply-To: <01GKR73COBT2ELNXY2@MATH.AMS.COM> > 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. ======================================================================== Date: Wed, 3 Jun 92 17:37:51 MEZ Reply-To: "NTS-L Distribution list" From: Mike Dowling Subject: Eradicating artificial limitations in NTS 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 ======================================================================== Date: Wed, 3 Jun 92 12:19:34 -0600 Reply-To: "NTS-L Distribution list" 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> 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. ======================================================================== Date: Wed, 3 Jun 92 14:46:05 -0500 Reply-To: "NTS-L Distribution list" From: jsmith@MCS.DREXEL.EDU Subject: Re: Eradicating artificial limitations in NTS >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 ======================================================================== Date: Wed, 3 Jun 92 17:59:06 EDT Reply-To: karl@cs.umb.edu 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> 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.) ======================================================================== Date: Wed, 3 Jun 92 18:15:45 EDT Reply-To: karl@cs.umb.edu 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> 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." } ======================================================================== Date: Wed, 3 Jun 92 18:16:31 EDT Reply-To: karl@cs.umb.edu 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> 8. Recategorizing a token list. Yes! Do you have a possible syntax/primitives to suggest? K ======================================================================== Date: Wed, 3 Jun 92 18:28:38 EDT Reply-To: karl@cs.umb.edu 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> 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 ======================================================================== Date: Thu, 4 Jun 92 02:21:29 BST Reply-To: "NTS-L Distribution list" 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 > 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 ======================================================================== Date: Wed, 3 Jun 92 22:00:10 EDT Reply-To: karl@cs.umb.edu 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> > 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 ======================================================================== Date: Thu, 4 Jun 92 10:44:56 BST Reply-To: RHBNC Philip Taylor From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: Eradicating artificial limitations in NTS 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 ======================================================================== Date: Thu, 4 Jun 92 12:56:56 MEZ Reply-To: "NTS-L Distribution list" From: Mike Dowling 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 ======================================================================== Date: Thu, 4 Jun 92 08:47:21 EDT Reply-To: "NTS-L Distribution list" From: Michael Barr Subject: Re: Eradicating limits 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 ======================================================================== Date: Thu, 4 Jun 92 12:01:27 EDT Reply-To: "NTS-L Distribution list" From: Charles Wells Subject: TeX as a programming language 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 ======================================================================== Date: Thu, 4 Jun 92 13:22:33 -0500 Reply-To: "NTS-L Distribution list" From: jsmith@MCS.DREXEL.EDU Subject: Re: TeX as a programming language >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 ======================================================================== Date: Thu, 4 Jun 92 19:53:00 GMT Reply-To: "NTS-L Distribution list" From: malcolm Subject: Re: TeX as a programming language 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?}) ======================================================================== Date: Thu, 4 Jun 92 20:05:46 BST Reply-To: "NTS-L Distribution list" 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> >>>>> 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 ======================================================================== Date: Thu, 4 Jun 92 14:24:42 EDT Reply-To: "NTS-L Distribution list" From: Charles Wells Subject: Re: TeX as a programming language In-Reply-To: MALCOLMC@MOLE.PCL.AC.UK > 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 ======================================================================== Date: Fri, 5 Jun 92 00:59:03 BST Reply-To: "NTS-L Distribution list" 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 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 ======================================================================== Date: Thu, 4 Jun 92 19:18:41 -0700 Reply-To: "NTS-L Distribution list" 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> 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 ======================================================================== Date: Fri, 5 Jun 92 12:35:58 EST Reply-To: "NTS-L Distribution list" 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 > > 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 ======================================================================== Date: Thu, 4 Jun 92 17:36:29 MDT Reply-To: "NTS-L Distribution list" From: "Nelson H. F. Beebe" Subject: Re: TeX as a programming language In-Reply-To: Your message of Thu, 4 Jun 92 19:53:00 GMT 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. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== ======================================================================== Date: Fri, 5 Jun 92 13:03:06 MEZ Reply-To: "NTS-L Distribution list" From: Peter Schmitt set nts-l ack Peter Schmitt a8131dal@awiuni11.bitnet schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria ======================================================================== Date: Fri, 5 Jun 92 13:09:26 MEZ Reply-To: "NTS-L Distribution list" From: Peter Schmitt Subject: Sorry - I used the wrong nickname 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 ======================================================================== Date: Fri, 5 Jun 92 05:08:58 -0700 Reply-To: "NTS-L Distribution list" 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> >>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 ======================================================================== Date: Fri, 5 Jun 92 14:10:35 +0200 Reply-To: "NTS-L Distribution list" From: "J.J. Winnink" Subject: Re: TeX as a programming language 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 ======================================================================== Date: Fri, 5 Jun 92 12:28:09 -0500 Reply-To: "NTS-L Distribution list" From: jsmith@MCS.DREXEL.EDU Subject: Re: TeX as a programming language >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 ======================================================================== Date: Fri, 5 Jun 92 13:01:46 -0400 Reply-To: "NTS-L Distribution list" From: PMW Matheson Subject: \onpage and .tfm modifications? 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 ======================================================================== Date: Fri, 5 Jun 92 21:42:18 BST Reply-To: "NTS-L Distribution list" 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> >>>>> 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 ======================================================================== Date: Mon, 8 Jun 92 10:46:42 +1200 Reply-To: "NTS-L Distribution list" From: jeremy@CS.AUKUNI.AC.NZ Subject: Re: [\onpage and] .tfm modifications? 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 | *---------------------------------------------------------------------* ======================================================================== Date: Mon, 8 Jun 92 11:16:58 +1200 Reply-To: "NTS-L Distribution list" From: jeremy@CS.AUKUNI.AC.NZ Subject: Re: TeX as a programming language 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 | *---------------------------------------------------------------------* ======================================================================== Date: Mon, 8 Jun 92 16:44:29 -0700 Reply-To: "NTS-L Distribution list" 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> >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 ======================================================================== Date: Tue, 9 Jun 92 10:44:14 BST Reply-To: RHBNC Philip Taylor From: CHAA006@VAX.RHBNC.AC.UK Subject: RE: TeX exported (was: TeX as a programming language) 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 ======================================================================== Date: Tue, 9 Jun 92 13:30:45 +0200 Reply-To: "NTS-L Distribution list" From: yannis Subject: my own small list of wishes 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 ======================================================================== Date: Tue, 9 Jun 92 14:54:27 LCL Reply-To: "NTS-L Distribution list" From: spqr@MINSTER.YORK.AC.UK Subject: Re: my own small list of wishes 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 ======================================================================== Date: Tue, 9 Jun 92 21:34:59 EDT Reply-To: "NTS-L Distribution list" From: Michael Barr Subject: Yannis' post 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 ======================================================================== Date: Wed, 10 Jun 92 12:06:30 +0100 Reply-To: "NTS-L Distribution list" From: Robin Fairbairns Subject: Character sets vs. fonts 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 ======================================================================== Date: Wed, 10 Jun 92 15:04:02 CET Reply-To: "NTS-L Distribution list" From: bbeeton Subject: Re: Character sets vs. fonts In-Reply-To: <01GL1HV3QS6QEO5OE5@MATH.AMS.COM> 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 ======================================================================== Date: Wed, 10 Jun 92 12:43:38 EDT Reply-To: karl@cs.umb.edu From: Karl Berry Subject: more possibilities for succ(TeX) 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. ======================================================================== Date: Wed, 10 Jun 92 14:50:36 EDT Reply-To: karl@cs.umb.edu 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> 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.) ======================================================================== Date: Thu, 11 Jun 92 11:40:26 +1200 Reply-To: "NTS-L Distribution list" From: jeremy@CS.AUKUNI.AC.NZ Subject: Re: my own small list of wishes 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 | *---------------------------------------------------------------------* ======================================================================== Date: Thu, 11 Jun 92 09:31:08 EDT Reply-To: "NTS-L Distribution list" 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 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 ======================================================================== Date: Thu, 11 Jun 92 10:17:06 EDT Reply-To: "NTS-L Distribution list" From: Michael Barr Subject: PS output 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 ======================================================================== Date: Thu, 11 Jun 92 10:57:22 EST Reply-To: "NTS-L Distribution list" From: Jacques_Gelinas%CMR001.bitnet@vm.urz.Uni-Heidelberg.de Subject: PostScript output format for NTS 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). ======================================================================== Date: Thu, 11 Jun 92 17:05:30 +0200 Reply-To: Schoepf@sc.ZIB-Berlin.DE From: Rainer Schoepf Subject: The prupose of this discussion list 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 ======================================================================== Date: Thu, 11 Jun 92 11:45:47 EDT Reply-To: "NTS-L Distribution list" 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 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 ======================================================================== Date: Thu, 11 Jun 92 12:03:20 EDT Reply-To: "NTS-L Distribution list" 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 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 ======================================================================== Date: Thu, 11 Jun 92 17:29:51 BST Reply-To: "NTS-L Distribution list" 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> >>>>> 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 ======================================================================== Date: Thu, 11 Jun 92 12:58:19 EDT Reply-To: "NTS-L Distribution list" From: HenningLeidecker Subject: Re: Output sizes for *.tex, *.dvi, and *.dvi 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 ======================================================================== Date: Thu, 11 Jun 92 13:13:46 EDT Reply-To: "NTS-L Distribution list" From: HenningLeidecker Subject: Re: NTS and computer-text management? ========================================= 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 ======================================================================== Date: Thu, 11 Jun 92 13:48:46 EDT Reply-To: "NTS-L Distribution list" 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 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 ======================================================================== Date: Thu, 11 Jun 92 13:46:48 EDT Reply-To: "NTS-L Distribution list" 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> >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 ======================================================================== Date: Thu, 11 Jun 92 18:46:48 BST Reply-To: "NTS-L Distribution list" 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> >>>>> 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 ======================================================================== Date: Thu, 11 Jun 92 14:03:19 EDT Reply-To: "NTS-L Distribution list" 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> 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 ======================================================================== Date: Fri, 12 Jun 92 13:34:13 EST Reply-To: "NTS-L Distribution list" 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 > > 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 ======================================================================== Date: Fri, 12 Jun 92 08:03:00 GMT Reply-To: "NTS-L Distribution list" From: malcolm Subject: RE: Output format for NTS 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 ======================================================================== Date: Fri, 12 Jun 92 09:30:31 GMT Reply-To: "NTS-L Distribution list" From: spqr@MINSTER.YORK.AC.UK Subject: Re: PostScript is not device independant. 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 ======================================================================== Date: Fri, 12 Jun 92 09:34:34 BST Reply-To: "NTS-L Distribution list" From: Martin Ward Subject: PostScript is not device independant. 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 ======================================================================== Date: Fri, 12 Jun 92 10:45:04 BST Reply-To: "NTS-L Distribution list" From: Martin Ward Subject: Re: PostScript is not device independant. > 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. I had thought that the idea of NTS producing PostScript was that you could send the output straight to a PostScript device without translating it. If the PostScript is truly device independant then it needs to be translated before you can print or display it. As you say "PostScript and dvi are equal in this respect". But dvi is _more_ portable than "dvi-PostScript" since there are dvi to ps programs for virtually all the systems TeX runs on, and there are dvi interpreters for dot matrix printers, laserjets (for which there is also ghostscript on _some_ systems) and weird typesetting devices which haven't a hope of coping with PostScript. So dvi wins. :-) 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 ======================================================================== Date: Fri, 12 Jun 92 11:25:59 BST Reply-To: "NTS-L Distribution list" From: Tim Bradshaw Subject: This whole PostScript/dvi argument 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 ======================================================================== Date: Fri, 12 Jun 92 09:05:50 CDT Reply-To: "NTS-L Distribution list" From: William Gropp Subject: This whole PostScript/dvi argument 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 ======================================================================== Date: Mon, 22 Jun 92 20:29:35 +0200 Reply-To: Schoepf@sc.ZIB-Berlin.DE From: Rainer Schoepf Subject: Information message There have been some reports about problems with this mailing list. As a consequence sending to this list is now allowed for everyone, although reviewing the list (i.e. determining the subscribers' adresses) is possible only for people on the list. Unfortunately, when we first tried to change this, a mistake was made that disallowed the sending of messages. This has now been corrected. Furthermore, anyone can set his or her personal list options so that copies of his/her mail messages are sent back, by sending the following command to : set nts-l repro I have now made this setting the default for all NEW subscriptions. Rainer Sch"opf ======================================================================== Date: Tue, 23 Jun 92 09:48:58 MEZ Reply-To: "NTS-L Distribution list" From: Mike Dowling Subject: Upwards compatibility necessary? In answer to Rainer Schoepf's request for pertinent info about the successor to TeX, perhaps a word or two from a user. Certainly within a university, TeX is used mainly for theses, publications, and incidental stuff such as tutorial example sheets and examination sheets. In any case, this appears to be the principle uses at my institution. This simple observation leads me to a few answers to the questions posed by Schoepf. (1) Upwards compatibility is a very minor issue for the user. Theses are written only once; there is little or no need to recompile under the successor to TeX after the thesis has been submitted. The same comment goes for publications. It is easy to dream up exceptions to this, but I contend that they are just that, exceptions. (A good counter example is the is a script accompanying a course. This script will be modified and recompiled every time the course is offered.) Another reason why I do not think that upwards compatibility is an issue for most of us is that good TeX style dictates that our input should consist of a description of the contents rather than how the contents should be formatted. This latter problem is the addressed by the macros used. Unless the successor to TeX is unrecognisably different from TeX, then converting is merely a question of changing the descriptors. I can and have changed to and from PLAIN, AMSTeX, and AMSLaTeX, and find that I can convert from one to the other at a rate of about 3000 lines in 30 Min. I am therefore confident that the few TeX files that I need to convert to NTSL will not involve significantly more time. (2) Looking at the TeX output here one must conclude that a very significant portion of the use of TeX is by students for theses. The bulk of these students have probably never used TeX before and will probably never use it again. The first conclusion is that for these users upwards compatibility cannot be issue at all. Another conclusion is that the common complaint that TeX is hard to learn is a valid one. Recall that TeX entails first reading the LaTeX book, and the TeX Book or whatever, and then editing, only to find that you have made mistakes and the file must be debugged. All this effort just for a single document? TeX in this respect is not cometetive with a wysiwyg. Of course, the experienced user does not experience these difficulties, and usually shrugs his or her shoulders dismissively when this criticism is made. Despite persuasive argument of this nature, I nevertheless remain opposed to changes in the TeX user interface. In fact, I contend that this is not so much a criticism of TeX but of the lack of support from editors which aught to supply help and syntax checking while the text is being entered. I find the idea of entering ascii text and compiling with TeX as an external program a good one, and would very much regret any divergence by the successor to TeX. (In fact, I would not update to anything that uses a graphics interface, mice and so on. I would stick to the old TeX. The reason quite simply is that mice and graphical interfaces, while reducing the knowlegde demands of the user, do so at the price of considerably slowing his or her effective working speed.) In summary, I am very much a proponent of any changes that will improve the quality and versatility of the current TeX, but am very much against any attempt at changing the nature of the user interface. Mike Dowling ======================================================================== Date: Tue, 23 Jun 92 11:52:39 BST Reply-To: "NTS-L Distribution list" From: Tim Bradshaw Subject: Re: Upwards compatibility necessary? In-Reply-To: Mike Dowling's message of Tue, 23 Jun 92 09:48:58 MEZ <9206230844.aa16214@uk.ac.ed.festival> >>>>> On Tue, 23 Jun 92 09:48:58 MEZ, Mike Dowling said: > (1) Upwards compatibility is a very minor issue for the user. Theses > are written only once; there is little or no need to recompile under the > successor to TeX after the thesis has been submitted. The same comment > goes for publications. It is easy to dream up exceptions to this, but > I contend that they are just that, exceptions. (A good counter example > is the is a script accompanying a course. This script will be modified > and recompiled every time the course is offered.) This is true in a rather limited way. A random user doesn't care of course, but they will care if all their weirdo undocumented macro packages, using undocumented features, that got installed 5 years ago from no-one knows where stop working. At my current workplace an antique TeX is used, largely by naive users. One of the reasons I haven't installed anything more recent (yet...) is unwillingness to solve all the problems likely to arise when moving from 2.x with an old LaTeX to 3.x with a new LaTeX + NFSS &c &c. Major changes to TeX itself will make this problem orders of magnitude harder. I vote for absolutely freezing TeX -- it works, why not leave it? -- and really starting afresh with no ideas of backwards compatibility at *all*. --tim ======================================================================== Date: Tue, 23 Jun 92 13:02:33 MESZ Reply-To: "NTS-L Distribution list" From: Joachim Schrod Subject: Re: Upwards compatibility necessary? In-Reply-To: <199206230843.AA26561@rs3.hrz.th-darmstadt.de>; from "Mike Dowling"at Jun 23, 92 9:48 am Mike Dowling wrote that IHO upward compatibility is not so important. I agree with him. Moreover he pointed out that he still wants the ability to work on ASCII (I equate this with `non-binary') text. I could not agree more. But I cannot resist to add a minor nitpicking. On the topic of contant-aware input systems he writes: > (In fact, I would not update to anything that uses a > graphics interface, mice and so on. I would stick to the old TeX. The > reason quite simply is that mice and graphical interfaces, while reducing > the knowlegde demands of the user, do so at the price of considerably > slowing his or her effective working speed.) I can never understand why people present graphics interface as an `all-or-nothing' choice. The good GUIs I work with have always both possibilities: To address a functionality via keyboard and via mouse, menu, or whatsever. The first possibility is very valuable for the things I know very well, the second for things I'm stumbling across. Combine the best of both worlds. Btw, there is no empirical study which supports your claim that GUIs ``[slow down] his or her effective working speed.'' But there are a lot of empirical studies which show quite the opposite. ``We've done $50 million of R&D on the Apple Human Interface. We've discovered, among other things, two pertinent facts: 1) Test subjects consistently report that keyboarding is faster than mousing. 2) the stopwatch consistently reports that mousing is faster than keyboarding.'' -- Bruce Tognazzini, Tog on Interface, Addison Wesley, 1992 -- Joachim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ``How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence? -- Peter Flynn ======================================================================== Date: Tue, 23 Jun 92 12:41:59 BST Reply-To: "NTS-L Distribution list" From: Timothy Murphy Subject: Re: Upwards compatibility necessary? In-Reply-To: Mike Dowling's message of Tue, 23 Jun 92 09:48:58 MEZ Mike Dowling writes: > Certainly within a university, TeX is used mainly for theses, > publications, and incidental stuff such as tutorial example sheets and > examination sheets. Aren't you being a little arrogant in assuming that every university is like your (unnamed) institution? In this Maths Dept, everything down to internal memos is done in TeX/LaTeX. Every student is supposed to become familiar with TeX in their first year. We regard TeX as the standard language for the communication of mathematics. > (1) Upwards compatibility is a very minor issue for the user. I couldn't disagree more. Shoepf and Mittelbach have gone to a great deal of trouble to maintain compatibility as far as possible. Even so, their changes have caused considerable misgivings here. A colleague said to me last week that he felt LaTeX was being taken over by non-mathematicians. (This was apropos of printing a single bold character in mathmode. He argued that this was something every mathematician would want to do, and that S&M did not seem to appreciate that.) If Mike's advice were followed, LaTeX/NTS would die out in a year. The number of people who are going to use an undocumented system, with innumerable added 'features', is negligible. Let's put our cards on the table. TeX/LaTeX is basically a system for printing mathematics. It is not a toy for computer scientists. If it is found useful for printing Devanagari or music (or Devanagari music), so much the better. But if it ever loses that central user-base of mathematicians, it is doomed. In my view, every "improvement" to TeX/LaTeX should first be tried out on a battery of tame mathematicians. 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 ======================================================================== Date: Tue, 23 Jun 92 15:33:58 EST Reply-To: "NTS-L Distribution list" From: Werenfried Spit Subject: Re: Upwards compatibility necessary? In-Reply-To: Message of Tue, 23 Jun 92 13:02:33 MESZ from Mike Dowling wrote that upward compatibility is not important. I do not really know if it is, but I do not agree at all on one of the reasons he gives for his opinion. He says that processing older documents is not a mayor issue. I'm just a simple user of LaTeX, but I think it is. I quite often use parts of older notes when writing a paper, especially when the older notes contain interesting tables or formulas. The reason being that retyping these *without errors* can be more work than I like. A related (and probably more important) issue in my experience is preparing a document with more authors. I have done a lot of retyping when other authors used WP/ChiWrite/whatever; I wouldn't like to retype or do a lot of conversion work also when other authors use (La)TeX and I use NTS. Clearly both situatiuons will only be around for the time that both TeX and NTS will be used. But that could be for a reasonable while I'd guess. I do not know if preventing problems in this kind of situations really demands upward compatibility (I could think of a *very good* TeX2NTS tool to accompany NTS), but I think they merit some thought. ------------------------------------------------------------------------ Werenfried Spit tel: +34-6-386 4551 Departamento de F%sica Tehrica spit@vm.ci.uv.es Universidad de Valencia spit@evalun11.bitnet ======================================================================== Date: Tue, 23 Jun 92 15:46:23 EST Reply-To: "NTS-L Distribution list" From: Werenfried Spit Subject: Re: Upwards compatibility necessary? In-Reply-To: Message of Tue, 23 Jun 92 12:41:59 BST from On Tue, 23 Jun 92 12:41:59 BST Timothy Murphy said: > >[argument about upward compatibility deleted] > >Let's put our cards on the table. >TeX/LaTeX is basically a system for printing mathematics. > I think here Timothy is making the same mistake as Mike: assuming his own situation to be the predominant one. (La)TeX is also an important system in the physics world, and as far as I know it is also used in linguistic departments a.o. because of its abilities to handle all kinds of alphabets. Certainly NTS should be a valuable tool for mathematicians, just like TeX is. But it should *not* be a toy for mathematicians only. >It is not a toy for computer scientists. > That's certainly ture. ------------------------------------------------------------------------ Werenfried Spit tel: +34-6-386 4551 Departamento de F%sica Tehrica spit@vm.ci.uv.es Universidad de Valencia spit@evalun11.bitnet ======================================================================== Date: Tue, 23 Jun 92 13:43:30 LCL Reply-To: "NTS-L Distribution list" From: spqr@MINSTER.YORK.AC.UK Subject: Re: Upwards compatibility necessary? Timothy Murphy writes: > A colleague said to me last week > that he felt LaTeX was being taken over by non-mathematicians. thank god for that! > Let's put our cards on the table. > TeX/LaTeX is basically a system for printing mathematics. > It is not a toy for computer scientists. > If it is found useful for printing Devanagari or music (or > Devanagari music) if TeX is for mathematics, then why not just leave it alone? I thought the reason for its survival was that it is a system for describing printed pages which has many interesting applications. If it evolves into a system whose overwhelming raison d'etre is printing maths, then it will die even sooner, since it will never be adopted by the `ordinary' publishers and printers whose needs dominate the industry. Or maybe we *want* TeX to remain an academic curiosity. sebastian ======================================================================== Date: Tue, 23 Jun 92 11:14:41 EDT Reply-To: "NTS-L Distribution list" From: Mark Steinberger Subject: Interface? I concur that a graphics interface is a very bad idea. I do most of my work by dialup, and get no graphics capability at all while I work. I suspect that a number of people who use mainframe based systems are in exactly the same situation. At the same time, I think the plusses involved in having a centralized, mainframe based facility at a given site are significant. For instance, who is going to take the time to maintain a tex collection on each and every PC in the department? You can't assume that all users will have work stations with a GUI or that those who have them will not spend significant time dialing in from home. Besides, with a little experience, previewing becomes relatively unimportant, as the resolution of a previewer is rarely sufficient to cover all the things you want to check out. You are going to have the same problem if you try to compose using a graphical interface. It's much better to design your document conceptually, and then check hard copy where necessary, to see if the concepts work. --Mark ======================================================================== Date: Tue, 23 Jun 92 12:13:01 EDT Reply-To: "NTS-L Distribution list" From: "B.J. 23-Jun-1992 1211" Subject: RE: Interface? > I concur that a graphics interface is a very bad idea. > > I do most of my work by dialup, and get no graphics capability at all > while I work. I suspect that a number of people who use mainframe > based systems are in exactly the same situation. This is a good reason that a graphical interface shouldn't be the only interface, but it is a terrible reason for not having a graphical interface. It's an argument along the same lines as `Sometimes I don't have a pen, so everyone should do all their work using stone tablets'. I agree that it is important to have a good character cell interface, but that shouldn't preclude a graphical interface. > At the same time, I think the plusses involved in having a > centralized, mainframe based facility at a given site are significant. > For instance, who is going to take the time to maintain a tex > collection on each and every PC in the department? I don't use PCs regularly, but don't `PC networks' solve this problem? If they don't, then the will soon because this problem isn't specifically a TeX problem--any large program set will have the same problem. > Besides, with a little experience, previewing becomes relatively > unimportant, as the resolution of a previewer is rarely sufficient to > cover all the things you want to check out. After eight years of using TeX, I still find that I regularly use previewers and find that the standard resolution (one page inch equal to one screen inch) is almost always sufficient for my needs. On the rare occasion when the resolution isn't sufficient, I change the resolution to one (or four) screen pixels for each page pixel. This allows me to see the details of the problem when the printed version only shows that a problem exists. Hardcopy is necessary for final distribution of the document, but is rarely sufficient for preparation. > You are going to have the same problem if you try to compose using a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > graphical interface. It's much better to design your document > conceptually, and then check hard copy where necessary, to see if the > concepts work. You are painting with quite a broad brush. The graphical interface hasn't been defined and you already know the problems it will have. If the graphical interface is a WYSIWYG interface then the problem you describe is likely, but I wouldn't consider a system with only a WYSIWYG interface to be a likely successor to TeX. B.J. ======================================================================== Date: Tue, 23 Jun 92 19:17:18 MEZ Reply-To: "NTS-L Distribution list" From: Mike Dowling Subject: Re upwards compatibility I would like to get one point straight, and that is that I did not intend to make the "arogant" claim that my situation as far as upwards compatibility is concerned is necessarily the same for everyone. I merely wanted to make a point that I think is a valid one, namely that, as long as you don't go in for personal hacks, your text is generally easily converted from one macro system to another, and that will probably go for porting TeX to NTS. Moreover, most texts will not need porting anyway. I am quite well aware that there are many other users with differering problems, and thought that I had been careful to point out that I was speaking about my experiences and those with whom I have a close contact. A second point was that the bulk of TeX users here appear to be students, and, since most complete their degree within about 5 years or so, for them upwards compatibility is an issue that will die within that period. Upwards compatibility for FORTRAN has not been good for FORTRAN, while the economic arguments there are much more convincing. I feel that it would be a pity to create this sort of straight-jacket for NTS, where, and I say it again, the need for it is probably the exception and not the rule. I repeat, I am speaking as a user and not a macro writer. Those who will have the most to loose if upwards compatibility is not enforced are those who have written extensive macro packages. Particularly publishing houses, those who write style files for thesis formats or technical reports, and so on, they will have a lot of work on their hands. Nevertheless, those expecting problems can speak for themselves; it is not for me to plead their cases. ======================================================================== Date: Wed, 24 Jun 92 14:34:19 +0100 Reply-To: "NTS-L Distribution list" From: Robin Fairbairns Subject: Re: Character sets vs. fonts [I tried to post this reply to the list some time ago, but was caught up in the problems I've mentioned elsewhere (comp.text.tex). This is a followup to a posting by (as I recall) Joachim Schrod, addressed to Barbara and me: Barbara has said that she doesn't have time to take an active part...] >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. [...] >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? My original posting came up in response to Yannis' post saying that he wanted to have font-dependent uc/lccodes. Fair enough, considering the sorts of things he does. But he also mentioned that there were fonts that he deals with that won't fit into a single TeX (256-position) font. Suppose, then, that he has a uccode mapping that might take him into a different (TeX) font. What is he to do? (Note: I have no idea whether this happens in `real life'.) But Yannis had merely rattled my cage about an issue that I had always considered an untidiness of TeX82, viz., its combination of the two orthogonal concepts of font and character set into a single entity, the TeX font. So we have a hard-wired xchr/xord mechanism in TeX, that takes _all_ 8-bit character sets to the _same_ internal representation. For TeX's original audience (i.e., DEK writing The Art), a single 7-bit character set (mangled ASCII) was adequate. With TeX 3.0, we have the recognition that things aren't as simple, and we have the VF mechanism in support of character translation. But that's seriously `after the event'. What constitutes a `letter' can reasonably be very different in different character sets. Similarly for the relationship between upper- and lower-case codes. Aside from all this is the practical point of what commercially- available fonts, and their supporting technology, are going to look like by the time NTS hits the streets. My guess is that they'll all have ISO 9541 font metrics, and that they'll all be published with ISO 10646 (i.e., Unicode) based cell mappings. So my argument (reconstructed from the posting that Listserv has dropped on the floor) is 1. There seems to be a problem beyond what Yannis outlined 2. Design purity (distinction of orthogonal concepts) suggest a different approach 3. Commercial fonts will probably start appearing that require a change on NTS's part if they are to be used. -- Robin Fairbairns, sometime Senior Consultant, postmaster, etc. Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ======================================================================== Date: Mon, 29 Jun 92 15:56:00 EET Reply-To: "NTS-L Distribution list" From: NMARTOLA@FINABO.ABO.FI Subject: Re: Upwards compatibility necessary? From: IN%"NTS-L%DHDURZ1.BITNET@FINHUTC.hut.fi" "NTS-L Distribution list" 23-JUN-1992 17:10:52.10 To: IN%"NMARTOLA@finabo.abo.fi" "Nils Martola" CC: Subj: RE: Upwards compatibility necessary? On Tue, 23 Jun 92 12:41:59 BST Timothy Murphy said: > >[argument about upward compatibility deleted] > >Let's put our cards on the table. >TeX/LaTeX is basically a system for printing mathematics. > I think here Timothy is making the same mistake as Mike: assuming his own situation to be the predominant one. (La)TeX is also an important system in the physics world, and as far as I know it is also used in linguistic departments a.o. because of its abilities to handle all kinds of alphabets. Certainly NTS should be a valuable tool for mathematicians, just like TeX is. But it should *not* be a toy for mathematicians only. --------------------------------------------------- I second that! ------------------------------------------------------------------------ >Werenfried Spit tel: +34-6-386 4551 > Departamento de F%sica Tehrica spit@vm.ci.uv.es > Universidad de Valencia spit@evalun11.bitnet Nils Martola nmartola@finabo (Earn/Bitnet) nmartola@abo.fi (Internet) ======================================================================== Date: Mon, 29 Jun 92 15:54:54 CET Reply-To: "NTS-L Distribution list" From: bbeeton Subject: Re: Upwards compatibility necessary? In-Reply-To: <01GLS5HXJ1N68WW4DZ@MATH.AMS.COM> i realize that responding to the comments about upward compatibility and what tex is designed for comes dangerously close to flaming, but ... please let's not lose sight of the fact that the original use for tex -- technical text -- is not satisfied for certain math publishers by *any* *other* *tool*. and if nts, regardless of how many improvements for internal graphics processing, etc., is not as suitable for that purpose, then those publishers would be left with the original tex or *nothing*; that would be a most unsatisfactory situation. -- bb ======================================================================== Date: Mon, 29 Jun 92 15:53:23 BST Reply-To: RHBNC Philip Taylor From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: Upwards compatibility necessary? >>> i realize that responding to the comments about upward compatibility >>> and what tex is designed for comes dangerously close to flaming, but ... And disagreeing with Barbara is dangerously close to heresy, but that won't stop me ... >>> if nts, [...] is not [...] suitable [...] >>> then those publishers would be left with >>> the original tex or *nothing*; that would be a most unsatisfactory >>> situation. Most unsatisfactory? Methinks you go too far! Has the position been either an unsatisfactory NTS or nothing, I could/would agree with you, but to be left with TeX V3 or nothing is very decidely _not_ unsatisfactory. TeX V3 is a _very_ satisfactory system (IMHO), and one which a leading mathematician with initials in the set {D, E, K} has deemed to be quite satisfactory enough to leave for posterity. Of course we may be able to improve on TeX, but to argue that `TeX or nothing' is an unsatisfactory position is surely indefensible ? ** Phil. ======================================================================== Date: Mon, 29 Jun 92 20:18:00 +0300 Reply-To: "NTS-L Distribution list" From: Michael Maschler Subject: Re: Upwards compatibility necessary? The debate whether a new version of TeX should be upward compatible has nothing to do with the fact that TeX is mainly/only used to type mathematical texts. Neither has it anything to do with the fact that some/many users use it only to type one thesis. Such students will be much better off if they hire a typist to type their thesis. They will save themselves a lot of time and agony. The real issue is: how many users need TeX to read/modify old texts, as compared to what sacrifices are needed, to achieve compatibility. To cite a sample of one person, I desire upward compatibility for the following reasons: 1. I keep a rather large list of articles, written in TeX, which is updated regularly. I hate to think that it will have to be retyped when a new version arrives. 2. I maintain many reprints in TeX form to be delivered to whoever requests them. [Of course, I could keep them in .ps form, so this is not so important.] 3. I am engaged in writing a book --- a project that takes several good years, because I also do other things. For me, therefore, it is unthinkable to switch to a noncompatible version. Michael ======================================================================== Date: Tue, 30 Jun 92 07:56:00 GMT Reply-To: "NTS-L Distribution list" From: malcolm Subject: Re: Upwards compatibility necessary? i don't want to get into this compatibility debate. but michael's reasons don't seem to me to hold water. is it impossible for the old and the new to coexist? let's try to be realistic: if the new system is incompatible, many people will not change. they don't want to relearn, they have some investment in the old system. there will probably be a big enough reservoir that people will still go on porting TeX to whatever new systems come along (or keep an ageing sparc10 just for (La)TeX work). the new system, however magnificent and typographically sound, will not oust TeX entirely. apart from anything else, it is not TeX. people have heard of TeX, even if only the curses of TeXies and nonTeXies alike. you cannot spend money on promoting nts (because you don't have any), and it will spread only slowly through academia, and perhaps a few publishers (probably driven by their authors). if it is compatible with TeX, many people, like me, will have no real reason to change. after all, it is 99% sufficient for us already. whether that extra 1% is worth the pain wil be an indivual decision. incidentally, if people wrote their documents in sgml, then it wouldn't matter what the formatter was. must go and wash my mouth out. this orthogonality of form and structure is crucifying me. best malcolm ======================================================================== Date: Tue, 30 Jun 92 09:44:09 +0200 Reply-To: "NTS-L Distribution list" From: rolf.lindgren@USIT.UIO.NO Subject: Re: Upwards compatibility necessary? malcolm writes: > i don't want to get into this compatibility debate. > but michael's reasons don't seem to me to hold water. > is it impossible for the old and the new to coexist? > I think a major point stated earlier in this discussion concerend the matter of resources. TeX is huge, and so will NTS most likely be, and lots of (PC, Mac, Amiga, Atari) users won't have room for both. I don't see a real reason why users of NTS should _have_ to convert all their old documents, I for one would keep the dvis or PSs and print them out at leisure. But at what level would compatilbility be needed? The main reason TeX is so huge is the fonts. If NTS and TeX could share the same fonts, then would the combination still be too large? What I would do as the maintainer of a fairly small PC site might be to keep TeX on one PC, and have the users switch from TeX to NTS. Rolf Lindgren | "The opinions expressed above are 616 Bjerke Studentheim | not necessarily those of anyone" N-0589 OSLO 5 | rolfl.lindgren@usit.uio.no ======================================================================== Date: Tue, 30 Jun 92 15:41:00 GMT Reply-To: "NTS-L Distribution list" From: malcolm Subject: Re: Upwards compatibility necessary? fonts: i had rather taken it for granted that nts would make use of more modern font technologies, which i take to be more compact. i realise that this was a rather implicit assumption that has not been examined. (i now expect to be chastised by nelson for refering to an implementation issue...) but given the extremely low price of disk space, is size really an issue (hmm)? i'm afraid that if it is not worth spending \quid200 or so for the extra disk (which will only be 10% used by nts, even with bitmapped fonts), then your interest in upwards compatibility and or quality may be compromised. and by the time nts is ready, that \quid200 will be even lower. malcolm ======================================================================== Date: Tue, 30 Jun 92 19:50:00 +0300 Reply-To: "NTS-L Distribution list" From: Michael Maschler Subject: Re: Upwards compatibility necessary? > i don't want to get into this compatibility debate. > but michael's reasons don't seem to me to hold water. > is it impossible for the old and the new to coexist? > > > best > > malcolm That depends on your storage capacity. Note that a new version is not just another set of macros. It may need a different set of fonts, a different set of environment variables, etc. To work with different sets means also using a different syntax as well as different commands. Show me a secretary who will want to undergo such a ``split personality''. Regards, Michael ======================================================================== Date: Tue, 30 Jun 92 21:09:16 MEZ Reply-To: "NTS-L Distribution list" From: Mike Dowling Subject: upwards compatibility again (1) It was recently pointed out that ntls might get too big for say DOS. I don't know what the time schedule is for nts but would be surprised if it became available within fewer than 5 years. If DOS survives until then (and I have my doubts) it will certainly have been transformed so that large programs will run without dos extenders and so on. If I am right, creating nts to fit into the straight-jacket of the current versions of dos will prove superfluous. (2) My suspicion is that any nts will be differ mainly in the guts of the TeX lion and probably will not necessitate much change with the user interface. I would be interested in the comments of a few experts here; does anyone really envisage changes that are so drastic as to necessitate retyping older texts? I am also in the process of writing a book and have been keeping up to scratch with the new LaTeX and have hitherto experienced no problems when updating my texts. (I once had a compatibility problem because I was fool enough to to mix old styles with the new, but mistakes like this are made only once.) Mike Dowling