========================================================================
Date:         Mon, 1 Jun 92 11:33:41 +0200
Reply-To: "NTS-L Distribution list" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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
<siebenmann@LALCLS.IN2P3.FR>


========================================================================
Date:         Mon, 1 Jun 92 00:56:47 -0400
Reply-To: "NTS-L Distribution list" <NTS-L@vm.urz.Uni-Heidelberg.de>
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
<siebenmann@LALCLS.IN2P3.FR>

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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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
<siebenmann@LALCLS.IN2P3.FR>


========================================================================
Date:         Mon, 1 Jun 92 11:58:35 BST
Reply-To: "NTS-L Distribution list" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Timothy Murphy <tim@MATHS.TCD.IE>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Timothy Murphy <tim@MATHS.TCD.IE>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: malcolm <MALCOLMC@MOLE.PCL.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Timothy Murphy <tim@MATHS.TCD.IE>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Barr <barr@TRIPLES.MATH.MCGILL.CA>
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 <P.Taylor@Vax.Rhbnc.Ac.Uk>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Downes <MJD@MATH.AMS.COM>
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 <MJD@MATH.AMS.COM>
> 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
  <paragraph text>\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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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
           <siebenmann@LALCLS.IN2P3.FR>





========================================================================
Date:         Wed, 3 Jun 92 06:01:40 CET
Reply-To: "NTS-L Distribution list" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: bbeeton <BNB@MATH.AMS.COM>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Downes <MJD@MATH.AMS.COM>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Mike Dowling <I1041301%DBSTU1.bitnet@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: "Jonathan M. Gilligan" <jongill@LILAC.BLDRDOC.GOV>
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 <I1041301%DBSTU1@vm.gmd.de> 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
<jongill@lilac.bldrdoc.gov>	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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: jsmith@MCS.DREXEL.EDU
Subject:      Re: Eradicating artificial limitations in NTS


>Mike Dowling <I1041301%DBSTU1@vm.gmd.de> 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
><jongill@lilac.bldrdoc.gov>	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 <karl@CS.UMB.EDU>
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 <karl@CS.UMB.EDU>
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 <karl@CS.UMB.EDU>
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 <karl@CS.UMB.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Timothy Murphy <tim@MATHS.TCD.IE>
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 <karl@CS.UMB.EDU>
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 <P.Taylor@Vax.Rhbnc.Ac.Uk>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Mike Dowling <I1041301%DBSTU1.bitnet@vm.urz.Uni-Heidelberg.de>


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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Barr <barr@TRIPLES.MATH.MCGILL.CA>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Charles Wells <cfw2@PO.CWRU.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: malcolm <MALCOLMC@MOLE.PCL.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Tim Bradshaw <tim.bradshaw@ED.AC.UK>
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 <MALCOLMC@pcl.mole> 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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Charles Wells <cfw2@PO.CWRU.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Timothy Murphy <tim@MATHS.TCD.IE>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Arthur Ogawa <ogawa@ORION.ARC.NASA.GOV>
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{<hmode>}, 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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Anthony Shipman <als@BOHRA.CPG.OZ.AU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: "Nelson H. F. Beebe" <beebe@MATH.UTAH.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Peter Schmitt <A8131DAL%AWIUNI11.bitnet@vm.urz.Uni-Heidelberg.de>


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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Peter Schmitt <A8131DAL%AWIUNI11.bitnet@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Arthur Ogawa <ogawa@ORION.ARC.NASA.GOV>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: "J.J. Winnink" <winnink@ECN.NL>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: PMW Matheson <amphoras@EPAS.UTORONTO.CA>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Tim Bradshaw <tim.bradshaw@ED.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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 <jeremy@cs.aukuni.ac.nz>  CS Dept, Auckland Univ, NZ |
*---------------------------------------------------------------------*



========================================================================
Date:         Mon, 8 Jun 92 11:16:58 +1200
Reply-To: "NTS-L Distribution list" <NTS-L@vm.urz.Uni-Heidelberg.de>
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 <jeremy@cs.aukuni.ac.nz>  CS Dept, Auckland Univ, NZ |
*---------------------------------------------------------------------*



========================================================================
Date:         Mon, 8 Jun 92 16:44:29 -0700
Reply-To: "NTS-L Distribution list" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Arthur Ogawa <ogawa@ORION.ARC.NASA.GOV>
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 <P.Taylor@Vax.Rhbnc.Ac.Uk>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: yannis <yannis@GAT.CITILILLE.FR>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Barr <barr@TRIPLES.MATH.MCGILL.CA>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Robin Fairbairns <Robin.Fairbairns@LSL.CO.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: bbeeton <BNB@MATH.AMS.COM>
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 <karl@CS.UMB.EDU>
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 <karl@CS.UMB.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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<d><box>" is "equivalent" to
"\moveleft<-d><box>", and that "\moveright<0><box>" is "equivalent" to
"<box>".)

Jeremy

*---------------------------------------------------------------------*
| Jeremy Gibbons <jeremy@cs.aukuni.ac.nz>  CS Dept, Auckland Univ, NZ |
*---------------------------------------------------------------------*



========================================================================
Date:         Thu, 11 Jun 92 09:31:08 EDT
Reply-To: "NTS-L Distribution list" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Henning Schulzrinne <hgschulz@GAIA.CS.UMASS.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Barr <barr@TRIPLES.MATH.MCGILL.CA>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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 <schoepf@SC.ZIB-BERLIN.DE>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Henning Schulzrinne <hgschulz@GAIA.CS.UMASS.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Henning Schulzrinne <hgschulz@GAIA.CS.UMASS.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Tim Bradshaw <tim.bradshaw@ED.AC.UK>
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
 <hgschulz@edu.umass.cs.gaia> 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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: HenningLeidecker <me@LEIDECKER.GSFC.NASA.GOV>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: HenningLeidecker <me@LEIDECKER.GSFC.NASA.GOV>
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 <<imprisoned>> 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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Henning Schulzrinne <hgschulz@GAIA.CS.UMASS.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: "David M. Jones" <dmjones@THEORY.LCS.MIT.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Tim Bradshaw <tim.bradshaw@ED.AC.UK>
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
 <me@gov.nasa.gsfc.leidecker> 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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: "David M. Jones" <dmjones@THEORY.LCS.MIT.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Anthony Shipman <als@BOHRA.CPG.OZ.AU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: malcolm <MALCOLMC@MOLE.PCL.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Martin Ward <Martin.Ward@DURHAM.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Martin Ward <Martin.Ward@DURHAM.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Tim Bradshaw <tim.bradshaw@ED.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: William Gropp <gropp@ANTARES.MCS.ANL.GOV>
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 <schoepf@SC.ZIB-BERLIN.DE>
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 <listserv@vm.urz.uni-heidelberg.de>:

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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Mike Dowling <I1041301%DBSTU1.bitnet@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Tim Bradshaw <tim.bradshaw@ED.AC.UK>
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 <I1041301@earn.dbstu1> 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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Timothy Murphy <tim@maths.tcd.ie>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Werenfried Spit <SPIT@VM.CI.UV.ES>
Subject:      Re: Upwards compatibility necessary?
In-Reply-To:  Message of Tue,
              23 Jun 92 13:02:33 MESZ from
              <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>


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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Werenfried Spit <SPIT@VM.CI.UV.ES>
Subject:      Re: Upwards compatibility necessary?
In-Reply-To:  Message of Tue, 23 Jun 92 12:41:59 BST from <tim@MATHS.TCD.IE>


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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Mark Steinberger <mark@STAT.ALBANY.EDU>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: "B.J. 23-Jun-1992 1211" <herbison@ERLANG.ENET.DEC.COM>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Mike Dowling <I1041301%DBSTU1.bitnet@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Robin Fairbairns <Robin.Fairbairns@LSL.CO.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: bbeeton <BNB@MATH.AMS.COM>
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 <P.Taylor@Vax.Rhbnc.Ac.Uk>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Maschler <MASCHLER%HUJIVMS.bitnet@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: malcolm <MALCOLMC@MOLE.PCL.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: malcolm <MALCOLMC@MOLE.PCL.AC.UK>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Michael Maschler <MASCHLER%HUJIVMS.bitnet@vm.urz.Uni-Heidelberg.de>
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" <NTS-L@vm.urz.Uni-Heidelberg.de>
From: Mike Dowling <I1041301@DBSTU1.RZ.TU-BS.DE>
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

