summaryrefslogtreecommitdiff
path: root/info/digests/tex-implementors/039
blob: 8dd5efb829a9fbbb5511952ccc63fe4d6daaab7c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
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 ]