path: root/info/digests/tex-implementors/message.39

Date:     14 March 91                           Message No:     039

To:       TeX implementors and distributors

From:     Barbara Beeton

Subject:  Messages from DEK, part 4


************************************************************************

>>> \TeX logo; some problems with \loop

i accidentally misfiled this with another problem that had already
been solved; it should have been sent to you months ago.
 -------
Date: Mon 24 Jun 91 14:39:46-EST
From: Michael Downes <MJD@MATH.AMS.COM>
Subject: \TeX

%      These %'s are so that you can move this file out of mail
%      and \TeX{} it as is to run the tests given below.
%
%      What version of plain.tex were you using when you checked the
%      spacefactor after \TeX? The one running on the TeXserver is
%      presumably quite recent since the version of TeX is 3.1, from
%      the standard Unix distribution. The following test demonstrates
%      that the spacefactor after \TeX{} has to be manually adjusted
%      to get proper spacing when punctuation follows (if \nonfrenchspacing
%      is in effect). This can be corrected so easily by adding
%      \spacefactor\@m at the end of \TeX's definition that I
%      don't know why it hasn't been done already. Perhaps there's
%      some reason not to do so that Knuth can explain.
 [ dek:
        That would have been better but I think it's too late now to
        make such a change
 ]

%      The space after the first period differs from the space after
%      the second period, as demonstrated by the \showlists command.
\tracingonline=1 \showboxbreadth=\maxdimen 
\TeX{}. Next. Third.\showlists
      
%      If Knuth changes plain.tex to fix \multispan perhaps he'll be
%      willing to consider another obvious improvement:
%      
%      Redefine \loop, as described in TUGboat vol 8 no 2 July 1987
%      by Alois Kabelschacht.
%      
%      This allows an \else branch on the repeat condition to be used,
%      which seems rather important in light of the fact that TeX \ifnum
%      and \ifdim tests only allow <, =, and > comparisons, with no
%      "not" operator or <= or >= combinations. Knuth might be unwilling
%      to do this, however, since it would require corresponding changes
%      in the TeXbook in the description of plain.tex; and it might be
 [ dek:
        All the macros in Plain TeX are merely simple examples that can
        be improved ad infinitum ... I cannot keep doing it
 ]
%      only 99.8% backward compatible. [However, no existing TeX file
%      will fail to run under the following redefinition unless it
%      refers to the internal pieces of \loop (\body and \next), and
%      perhaps the most likely reason someone might have done so would
%      be to compensate for the lack of an \else possibility!!]

\def\loop#1\repeat{\def\iterate{#1\expandafter\iterate\fi}%
 \iterate \let\iterate\relax}

%      The following example illustrates an \else condition in
%      the internal loop. It takes an even number and keeps
%      dividing it until the result is odd. Try a large
%      power of 2, e.g., 65536.
\newcount\n 
\newlinechar=`\&
\loop
\message{&Enter a large even number (RETURN to stop): }%
\read-1 to\answer  \n=0\answer\relax
 [ dek:                 ^^^^^^
        wow, a trick I didn't know
 ]
\ifnum\n>0
%      Braces to localize \iterate
{\loop
\divide \n by 2
\message{&N divided by 2 = \number\n}%
\ifodd\n
\else\repeat}%
\repeat

\bye
 -------
comment by bb:
i thought the definition of \TeX had been changed, because the
following definition accompanied DEK's article of October '90
on "The future of TeX and METAFONT":
  \def\TeX{T\hbox{\hskip-.1667em\lower.424ex\hbox{E}\hskip-.125em X}}
i'm pretty sure if that had been my addition, i would have marked it as
such, or would have made the change at a more general level.  but i
could very well be misremembering.
 -------

Date: Fri, 3 JAN 92 22:14:36 GMT
Originally-from: TEX "Brian {Hamilton Kelly} <TeX@Uk.Ac.Cranfield.RMCS>"
From: TEX@rmcs.cranfield.ac.uk
Subject: RE: flash!!! notice that tex update is about to happen

[ ... ]
Brian
PS I'd love to see some way of using \loop... within an \halign; at
present it falls over because each & cancels a level of grouping, and so
the definition of \body (or is it \repeat) keels over.  But I guess this
is too big a change.
 [ dek:
        Well \dosplits on page 397 does iterate within \valign
        (which is similar)
 ]
-------

<<< end \TeX logo; some problems with \loop

************************************************************************

>>> cedilla accent macro in plain.tex

Date: Mon, 23 Sep 91 11:56:15 +0200
From: Bernd Raichle <raichle@azu.informatik.uni-stuttgart.de>
Subject: TeX Bug Report -- plain.tex, cedilla accent macro

Dear Ms. Beeton,

I've found a small bug in `plain.tex' (and a missing index entry in
the TeXbook).  Perhaps someone has reported it before, but I have seen
no fix for it...

1.  There's a missing index entry for "ligatures" in the TeXbook.
    Page 306 contains the answer of exercise 5.1.  This answer explains
    how to supress unwanted ligatures.
 [ dek:
        No ... p 19 (ex 5.1, about suppressing unwanted ligs) is indexed.
        see p 457 "an answer page is not indexed unless ..."
 ]

2a. The \c macro in `plain.tex' produces a box with the wrong dimensions
    (height = depth = 0pt) for arguments with height != 1ex.

    Fix 1: exchange the \unhbox\z@ and \hidewidth\char24\hidewidth in
           the macro definition
 [ dek:
        good
        $2.56
        \ooops
 ]

\def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1%
  \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi}

2b. For characters with depth != 0pt, the "cedilla" character is not
    lowered. I don't know of any use for this, because there's only the
    c-cedille accent.  But the idea used in the proposed fix can be
    used for the under-dot and under-bar accent (and \AA) too.  The
    accent characters of these macros are misplaced if used within a
    slanted font.

    Fix 2: use the \accent primitive and a changed ex-value to shift
           the accent character to the correct place

\def\c#1{{\dimen@ 1ex%
    % Compute new ex value:
    % The cedilla accent should not be shifted for uppercase characters,
    % => new-ex := height(#1).
  {\setbox\z@\hbox{#1}\dimen@\ht\z@
    % but we have to shift it down, if the character has depth.
    % => new-ex := new-ex + depth(#1)
  \advance\dimen@\dp\z@
    % Set the `ex' value (fontdimen change is always global),
  \fontdimen5\font\dimen@}%
    % ... set the accent char, reset `ex' to the old value
    % and do the rest.
  \accent24\fontdimen5\font\dimen@ #1}}


Yours,
       Bernd Raichle  (raichle@azu.informatik.uni-stuttgart.de)

PS: Please can you add me to the `tex-implementors' list?
    Thanks in advance.
 -------
Date: Sun, 29 Sep 91 15:37:10 BST
From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
Subject: Re: [[Bernd Raichle <raichle@azu.informatik.uni-stuttgart.de>:
         TeX BugReport -- plain.tex, cedi]]

Dear Barbara,

> 1.  There's a missing index entry for "ligatures" in the TeXbook.
>     Page 306 contains the answer of exercise 5.1.  This answer explains
>     how to supress unwanted ligatures.

Yes, I think it plausible that 306 should appear in the list. It doesn't
in the most recent 'texbook.tex' I have access to.

> 2a. The \c macro in `plain.tex' produces a box with the wrong dimensions
>     (height = depth = 0pt) for arguments with height != 1ex.
>
>     Fix 1: exchange the \unhbox\z@ and \hidewidth\char24\hidewidth in
>            the macro definition
>
> \def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1%
>   \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi}

Amazing that this hasn't come to light earlier: \hbox{\c C} has zero
height and depth as stated! Bernd's fix would appear to be the right
one: but maybe there is some subtle reason why the alignment is written
that way round at the moment---it's such a counterintuitive thing to do!

> 2b. For characters with depth != 0pt, the "cedilla" character is not
>     lowered. I don't know of any use for this, because there's only the
>     c-cedille accent.  But the idea used in the proposed fix can be
>     used for the under-dot and under-bar accent (and \AA) too.  The
>     accent characters of these macros are misplaced if used within a
>     slanted font.
>
>     Fix 2: use the \accent primitive and a changed ex-value to shift
>            the accent character to the correct place
>
> \def\c#1{{\dimen@ 1ex%
>     % Compute new ex value:
>     % The cedilla accent should not be shifted for uppercase characters,
>     % => new-ex := height(#1).
>   {\setbox\z@\hbox{#1}\dimen@\ht\z@
>     % but we have to shift it down, if the character has depth.
>     % => new-ex := new-ex + depth(#1)
>   \advance\dimen@\dp\z@
>     % Set the `ex' value (fontdimen change is always global),
>   \fontdimen5\font\dimen@}%
>     % ... set the accent char, reset `ex' to the old value
>     % and do the rest.
>   \accent24\fontdimen5\font\dimen@ #1}}

This is a much more ambitious change, and I have doubts about its
having sufficient backwards compatibility, and its robustness. An
interesting technique, though, which relies on the x-height of the
current font being recorded before the |do_assignments| call in
|make_accent|. I think you should show it to Don together with
the rest.

Chris Thompson

<<< end cedilla accent macro in plain.tex

************************************************************************

>>> missing \mathsurround in plain.tex

Date: Mon, 4 Nov 91 13:35:11 +0100
From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)
Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin
Subject: Glitches in plain.tex

Barbara,

while revamping the LaTeX files I found that some macros from
plain.tex lack the \m@th (i.e. \mathsurround=0pt) assignment. The
macros in question are:

\overrightarrow
\underrightarrow
 [ dek: (scratched out \underrightarrow)
        \overleftarrow
 ]
\overbrace
\underbrace
\notin/\c@ncel
\rightleftharpoons/\rlh@
 [ dek:
        $2.56 x 3
        A359, A360, A361
 ]

What do you think? I append a demo file.

Rainer

 ------------------demo for plain tex--------------------

text$\overrightarrow{abcdef}$text

text$a \notin b$text

\mathsurround =10pt

text$\overrightarrow{abcdef}$text

text$a \notin b$text

text$a \rightleftharpoons b$text

\bye

<<< end missing \mathsurround in plain.tex

************************************************************************

>>> \arrowvert code, plain.tex

comment by bb:
there are several symbols in cmex* that are meant as midsections of
arrows, brackets, etc., but which are also given \cs names.  these
include
    \arrowvert
    \Arrowvert
    \bracevert
it seems that as long as these are referenced indirectly, through
\uparrow, \downarrow, etc., they are well behaved, but when they are
referenced by the \cs name, the wrong symbol is produced.  i'm not the
only one who finds the \delimiter values assigned in plain somewhat
mysterious.  if these really are errors, there's a different claimant
for each one: \arrowvert -- Phil Taylor, \Arrowvert -- me, \bracevert --
Chris Thompson.  if the values are correct though, we'd really
appreciate a good explanation of how this works.

re the comments by michael barr regarding how much memory is required for
rules vs. characters, i know that's been explained before, but perhaps
it's time to do it again.  i shall ask chris thompson or brian {hk}.
 -------
Date: Mon, 11 NOV 91 17:43:28 BST
Reply-to: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC)
From: CHAA006@vax.rhbnc.ac.uk
Subject: [Surely not another] bug in Plain.TeX ?

For a book on French linguistics, I need up/down arrows which span rows
in an \halign; I use \uparrow, \downarrow and \arrowvert.  In both the
MS/DOS (emTeX) and VAX/VMS versions of Plain.TeX, \arrowvert translates
to \delimiter"33C000.  Character "3C in family 3 (cmex10) is the centre
part of a brace, not a vertical arrow ...
 [ dek:
        right, as stated on page 150.  I admit these names are not the
        best, but you are supposed to regard them as _verts_ (with
        differing weights) derived from arrows/braces _not_ as
        arrows/braces
 ]

                                        ** Phil.

P.S. Plain version 3.0 (can't find a date).
 -------
Date: Mon, 18 NOV 91 10:57:30 BST
Reply-to: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC)
From: CHAA006@vax.rhbnc.ac.uk
Subject: Re: [Surely not another] bug in Plain.TeX ?

>>> however, now that i look at this, i'm wondering why you haven't just
>>> used \uparrow, \downarrow, and \updownarrow, forcing them to whatever
>>> size you want with phantoms.  or have you?  if so, and you're really
>>> getting the wrong pieces, then there's a problem in the .tfm file too.

I did, in the end; here's the current version:

%
\newbox \arrowbox
\setbox \arrowbox = \hbox 
       {\let|=\strut\smash{$\left\updownarrow\matrix{|\cr|\cr|\cr|\cr}\right.$}}
\def \arrow {\copy \arrowbox}
%
\Begin {columns} \options = {\listindent = 0.25 \listindent}
%
        \+&&Il&&&&effondr{\'e}&&&&&&&&une chaise.&\cr 
        \+&&Pierre&&s'est&&assis&&sur&&&&&&un si{\`e}ge.&\cr
        \omit&\arrow&&&&\arrow&&&&&&&&\arrow&&\cr
        \+&&L'{\'e}tudiant&&&&install{\'e}&&&&&&&&un tabouret.&\cr 
        \+&&&&&&&&&&&&&&un canap{\'e}.&\cr 
        \+&&\multispan 4{\qquad \leftarrowfill\rlap {$\joinrel \rightarrow$}}&&
            \multispan 2{\llap {$\leftarrow$}$\joinrel$\rightarrowfill}&&&&&
            \multispan 2{\llap {$\leftarrow$}$\joinrel$\rightarrowfill}&\cr
%
\End {columns}

[ ... ]
 -------
Date: Wed 20 Nov 91 07:02:41-EST
From: bbeeton <BNB@MATH.AMS.COM>
To: CET1@phx.cam.ac.uk

by the way, phil taylor has found another plain bug -- the character
referenced by \arrowvert is wrong; following his lead, i discovered
that \Arrowvert also looks bad.  (these are rarely used, but even so,
it's surprising they haven't been found before; i think they've
been this way since versions >1.)  phil is concocting a routine to
print out all the plain math characters for checking.
                                                -- bb
 -------
Date: Thu, 21 Nov 91 16:39:06 GMT
From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>

[ ... ]

   I met Phil Taylor at the UKTeX meeting in Oxford yesterday, and he
told me about the \arrowvert..\Arrowvert problem. I was surprised that
such a bug had gone unnoticed so long. Are you both sure about this?
I get the appearance described on page 150 of the TeXbook in test
programs. (All this complicated by the variable-character codes in
cmex10, by which a character rarely means itself! "3C as varchar is
actually repeating bits of "3F, and "3D as a varchar is repeating bits
of "77.) There was a change in plain \fmtversion 2.92 (I think) in which
the definitions of \arrowvert, \Arrowvert and \bracevert were changed
from "33C, "33D & "33E to "33C000, "33D000 & "33E000: I never understood
in what circumstances this could make a difference!
 [ dek:
        Yes, see the bottom of page 156
 ]

Chris Thompson
 -------
Date: Fri, 22 NOV 91 11:02:27 BST
Reply-to: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC)
From: CHAA006@vax.rhbnc.ac.uk
Subject: Arrowvert (forgot to cc you)

Dear Chris ---

>>> I was using tests like

>>> $$\left\arrowvert X\sp h \over J_y \right\Arrowvert$$

>>> and they seem to work. Have you got an example which fails?

Yes !  $ \arrowvert $ !  [I suppose this means I must be abusing \arrowvert,
 [ dek: ^^
        \bigg would produce a particular size
        I will pay Phil $2.56
 ]
but I can't for the life of me see why ...]

                                        ** Phil.
 -------
Date: Fri, 22 Nov 91 15:37:37 GMT
From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
To: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC)
Subject: RE: \arrowvert..\Arrowvert

Phil,

Ah, I see! Although $\left\arrowvert...$ works, $\arrowvert$ doesn't.
The trouble is, I don't see how it can be made to...

When \arrowvert is used in the context of a <math character>, only
the top 15 bits of the 27-bit number following \delimiter are used.
Before the change in plain 2.92 (if that is in fact when it was) this
would have produced \mathchar"0000 (clearly wrong); now it produces
\mathchar"033C (unfortunately, still wrong). cmex10 character "3C as
a math character is the middle piece of a large \lbrace as shown on
p.432, but when used as a <delim> (after \left, or the macros \bigl,
\Biggl, etc.) its varchar definition is used, and that says that it
should be made up of a lot of copies of character "3F (no top, middle
or bottom piece used). If the definition of \arrowvert was changed to
"033F000, then the <math character> context would work, but the <delim>
one wouldn't: instead it would be like \updownarrow.

 [ dek:
        Next version of plain has a good compromise:
        \lmoustache "437A340    \arrowvert "026A33C
        \rmoustache "437B341    \Arrowvert "026B33D
        \lgroup     "462833A    \bracevert "077C33E
        \rgroup     "462933B
 ]

Chris Thompson
 -------
Date: Thu, 21 Nov 91 11:31:24 EST
X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu>
From: barr@triples.Math.McGill.CA
Subject: Optimizing TeX?

Let me begin by mentioning a misprint in the Book.  On page 358, line
-8 (17th printing, Jan. 1990), it says
\mathchardef\mapstochar="322F \def\mapsto{\mapstochar\rightarrow}
and the "322F should be (and is, in plain.tex) "3237.
 [ dek:
        $2.56 was paid to Karl Berry for this on 19 Sep 91.  Labrea
        sources haven't changed yet but my texbook.tex had this
        correct as of 18 Sep 91 acc. to errata.tex
 ]

The reason I noticed this was that a colleague had tried to make a
\mapsfrom macro and discovered a curious fact.  The \mapstochar is not
just a vertical line, but has a blip in the middle on the right hand
side that effectively ruins it for any other purpose.  I told my
colleague to use a rule and he did.

I know from something that appeared in UKTeX a ffew weeks ago that rules
are expensive in space.  There is a reason for this.  It requires 4 real
numbers to specify a rule (the space of rules is a 4-manifold and fewer
numbers will not do, no matter how you describe them).
 [ dek:
        not true; 3 numbers (height, width, depth) suffice in context
 ]
                                                        Possibly 4 16
bit numbers would have given sufficient precision, but Knuth coded all
dimensions as 32 bit numbers.  So, it presumably takes 16 bytes to
specify a rule and it is going to be much more wasteful of space to use
a rule than it would have been to use the \mapstochar.  Is this correct?
More to the point, how can one find out about coding TeX to optimize for
space?  For time?  Knuth drops a few clues in the discussion on pp.
373-374, but that is almost the only place this is done.  For instance,
can anyone tell me the relative cost of factoring macros into smaller
ones, assuming you never reuse the pieces?

Michael Barr
 -------
Date: Fri, 22 Nov 91 17:07:28 GMT
From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
Subject: This and that

Barbara,

You write
>                  there was another in that category reported just
> today by michael barr -- the \mapstochar.  if you read comp.text.tex,
> look for his report, because it's asking a couple more basic questions,
> namely how much memory space do certain techniques require, and what's
> the most efficient way to do certain things.

I follow comp.text.tex only intermittently, as its volume is really
rather high. I took a look at Michael Barr's posting, and have posted
a reply. He is certainly right about \mapstochar: the TeXbook said
"322F in 1984, and the latest texbook.tex from labrea still says it;
on the other hand plain.tex has always (correctly) had "3237 since 1.0
(I am fairly sure of this: despite the absence of a plain.tex.history
file, I do do compares of old with new each time I upgrade and note
down the salient changes).

Chris Thompson

<<< end \arrowvert code, plain.tex

************************************************************************

>>> MF -- bugs or features?  (also, some ACP errata)

Date: Tue, 22 Oct 91 12:04:23 +0100
From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)
Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin
Subject: Questionable features of Metafont

Barbara,

here is the report about two features of Metafont that I find
questionable. I hesitate to call them bugs as it is said nowhere in
the book that Metafont should not behave that way.

Number 1:
---------

The book says that

addto V also P;

is "essentially the same as"

V := V + P;

But this is only true if the evaluation of the picture expression P
does *not* change the value of the picture variable V as a side
effect. The second expression is correctly evaluated left to right.
The first one, however, uses the value of V *after* P has been
evaluated. Looking into the program one sees that "addto" reads the
token list for V, evaluates the expression P, and converts the token
list for P into an edge structure afterwards.

I assume that the same behaviour happens with "cull".
 [ dek:
        I suppose so -- just as you would expect in C when comparing
        x=x+f(x) to x+=f(x) when f has side effects
 ]


Number 2:
---------

Define the following macro:

def xxx =
  begingroup 
    save x;
    newinternal x;
     ....
  endgroup
enddef;

After a hundred expansions  Metafont gives you an "capacity exceeded"
error since every call to newinternal statically allocates a slot in
an internal array, which is not freed again at the end of the group.
However, in this case, it is very easy to free the slot again.
 [ dek:                      ^^^^^^^^^
        STRONGLY DISAGREE that _any_ change can be described as
        ``very easy''!


Bugs or features?

At least, this behaviour should be documented!
 [ dek:
        Maybe in TUGboat.  Certainly the ``capacity exceeded'' error
        tells you that you've exceeded the number of internals.
 ]


[ ... ]


Rainer

<<< end MF -- bugs or features?  (also, some ACP errata)

************************************************************************

>>> MFbook errata

Date: Tue, 5 Nov 1991 05:48:03 +0100
From: Lutz Birkhahn <lutz@bisun.nbg.sub.org>
Subject: Errors in METAFONTbook (C&T Vol. C)

Barbara,
just for the record, here are some minor bugs in the METAFONTbook (C & T
vol. C) index:

   "openwindow", "or", and "string"

each are METAFONT primitives, so they deserve to get a starred entry (preceded
with an asterisk `*') in the index on pages 353, 354, and 356, respectively.

This error shows up in my edition from 1986 (first printing, I think) as well
as in the source code I have, stating "Fifth printing, revised, March 1990"
(although the C & T Publication info table you posted recently said that
the 4th printing of Volume C, Sept 1991, is the latest...).

 [ dek:
        3 x $2.56  many thanks  C354^2 C356
 ]

Bye,
Lutz

Lutz Birkhahn (Germany)   email: lutz@bisun.nbg.sub.org (don't use another!)
F"urther Str. 6          +--------------------------------------------------
D-W-8501 Cadolzburg 2    | "It is an error to not have enough arguments"
Voice: 09103 / 2886      |                         (Hype Programmer's Guide)

<<< end MFbook errata

 [ dek:
        notes to myself
        only boolean was done as I had intended
        353 numeric     356 string      357 transform
        354 openwindow
            or
            pair
            path
            pen
            picture
 ]


########################################################################

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Character code reference
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%                       Upper case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ
%                       Lower case letters: abcdefghijklmnopqrstuvwxyz
%                                   Digits: 0123456789
% Square, curly, angle braces, parentheses: [] {} <> ()
%           Backslash, slash, vertical bar: \ / |
%                              Punctuation: . ? ! , : ;
%          Underscore, hyphen, equals sign: _ - =
%                Quotes--right left double: ' ` "
%"at", "number" "dollar", "percent", "and": @ # $ % &
%           "hat", "star", "plus", "tilde": ^ * + ~
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

[ end of message 039 ]