summaryrefslogtreecommitdiff
path: root/info/digests/tex-implementors/message.45
blob: 42c30a48a76cd0858bb502fa7b2fe51d991cdd24 (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
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
TeX 3.14159 and other updates -- file 2 of 2

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

>>> plain.tex

    +++ \oalign and \d{}

[ the following two reports, from j"org knappen and petr sojka,
  cover the same territory, but with different proposals for fixing
[ dek --    ^^^^^^^^^^^^^^ _different_ bugs in the same territory
]
  the problem.  i've included both since both looked reasonable to me.
]
-------
Newsgroups: comp.text.tex
Date: 17 May 1992 20:28:21 +0000 (GMT)
[ dek -- 1992 again -- I changed \d in 1993 but never had heard of this
]
Organization: Computer Science Dept, University of Tennesee, Knoxville
From: eijkhout@cupid.cs.utk.edu (Victor Eijkhout)
Subject: Re: \d{}

In article <01GK1PHMODB48WWBZV@VzdmzA.ZDV.Uni-Mainz.DE>,
 KNAPPEN@VKPMZD.KPH.Uni-Mainz.de (J%org Knappen) writes:
|> The following line
|> 
|> Das ist ein Test von (\d{}) \verb:(\d{}):
|> 
|> runs through TeX without any error messages, but produces an underdot which
|> is more than 300pt left off the paper.

About 1000pt left of the opening bracket to be a bit more precise.

|> \d{ } also fails, \d{\ } works and
|> produces a dot under ``nothing''.
|> 
|> The test above turns out to be a driver's test, too. Two of four
|> dvi-drivers (on our VAX/VMS-system) did not complain nor show the mistake
|> in output.

What mistake? How can a device driver know that your printer doesn'
have paper 1 meter wide? (With the margin only 20 cm from the right
paper edge :-)

|> I consider the facts above as a misfeature (not to say bug).

I consider the posting above as uninformed.

But seriously, one might wonder what happens here.

Watch this:

This is TeX, C Version 3.0
(/usr/local/lib/TeX/inputs/nul.tex
LaTeX Version 2.09 <7 Dec 1989>
)
*\show\d
> \d=macro:
->\protect \pd .
<*> \show\d

? i\show\pd
> \pd=macro:
#1->\oalign {#1\crcr \hidewidth .\hidewidth }.
<insert>   \show\pd

(Yes, that's true, I run TeX interactively. I must be just about
the only one on earth to do this.)

This tells you that \d is essentially a macro with one argument.
You give it the empty argument, so it expands to
 \oalign { \crcr \hidewidth .\hidewidth }

Now, \oalign is essentially \halign, and we know (otherwise look it up)
that \crcr only gives a new line if there was a line to terminate.
Which there isn't in this case, so we get
 \halign { \hidewidth .\hidewidth }
[ dek --  ^ \preamble\cr
]

and since \hidewidth is \hskip -1000pt plus 1fil, you have managed to
move the . 1000pt left of where you intended it to be.

All of this does make me wonder a bit, though. Why did Knuth use \hidewidth?
Well obviously so that you could put objects under 'nothing'.
[ dek --                                     under very _narrow_ things
]
But why then \crcr and not just \cr? Well, probably he foresaw
that people might want to put stuff under more than one line, so both
\d{a\cr b} and \d{a\cr b\cr} had to give the same result.

Hey, waddaya know! Everything is logical after all!

|> Yours, J"org Knappen.

Victor.
-------
X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu>
Date: 21 May 1992 12:46 +0000 (GMT)
From: J%org Knappen <KNAPPEN@VKPMZD.KPH.Uni-Mainz.de>
Subject: Again \d{}, with a bug fix

  Dear samretanoj,

  After reading Victor's posting carefully, the following bug fix comes to my
  mind:
\def\d#1{\oalign{\null#1\crcr\hidewidth.\hidewidth}}
[ dek --         ^^^^^ \relax is better
]
  (Barbara, are you listening? Please forward it to DEK)

  It passes the following tests:
Teste \d{}, \d{ }, \d{\ }!

Mehr Tests: \d{a\cr b} und \d{a\cr b\cr}!
\bye
  An analogous fix should be done to \b, both in plain.tex and lplain.tex.

  On drivers:
  here is how a good driver (Brian {Hamilton Kelly}'s DVItoLN03) behaves:
This is DVItoLN03, Vax/VMS Version 4.0-3
[Some more message stuff deleted (JK)]
Warning: Characters '' set off paper
( x = -3768..-3768, y = 342 ) - ignored
Warning: Characters '.' set off paper
( x = -3768..-3756, y = 342 ) - ignored
[153] Warning: Page wider than TeX reported by 510.2450pt

  Yours, J"org Knappen.

  P.S. Originally, I asked my question on the info-tex mailing list. The most
  valuable contributions were only sent to the news group comp.text.tex.
  Fortunately since one month I have also access to news...I must have missed
  much before, even follow-ups to my own postings!
-------
Date: 12 Jan 1995 22:55:33 +0100 (MET)
From: Petr Sojka <sojka@daeron.ics.muni.cz>
Organization: Masaryk University, Brno, The Czech Republic
Subject: Bug in plain.tex -- please pass to DEK

Barbara,

here is what I consider as a bug of plain.tex:
You read there:

% This is the plain TeX format that's described in The TeXbook.
% N.B.: A version number is defined at the very end of this file;
%       please change that number whenever the file is modified!
% And don't modify the file under any circumstances.

...

\def\oalign#1{\leavevmode\vtop{\baselineskip\z@skip \lineskip.25ex%
  \ialign{##\crcr#1\crcr}}} % put characters over each other
\def\ooalign{\lineskiplimit-\maxdimen \oalign}
\def\sh@ft#1{\dimen\z@.00#1ex\multiply\dimen\z@\fontdimen1\font
  \kern-.0156\dimen\z@} % compensate for slant in lowered accents
\def\d#1{\oalign{#1\crcr\hidewidth\sh@ft{08}.\hidewidth}}
\def\b#1{\oalign{#1\crcr\hidewidth\sh@ft{29}%
    \vbox to.2ex{\hbox{\char22}\vss}\hidewidth}}
\def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1%
  \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi}
\def\copyright{{\ooalign{\hfil\raise.07ex\hbox{c}\hfil\crcr\mathhexbox20D}}}

Simply saying, Don forgot setting of \lineskiplimit to zero
in \oalign as one of the line vertical spacing parameters
besides \baselineskip and \lineskip
   I found this bug when having set globally \lineskiplimit to
-2dd and setting e.g. \d{a}. What a surprise -- the dot
wasn't there! Or what do you expect to see with simple
file saying
\lineskiplimit-2dd\d a\bye
? Dot below a or `in a'?

Will I be sent a check?

Petr Sojka <sojka@muni.cz>
-------
(reply, 12 Jan 1995)
yep, you're right.  it's a bug.
the dot doesn't disappear, exactly, it just hides "in" the a.
\b b does kind of the same thing, but \c c is protected because
it uses \ooalign.

yes, i think you'll get a check for this one, though i predict
it'll be just a small one, 'cuz the big ones only get awarded
for bugs in tex(.web) itself.
[ i didn't discover the earlier report until after i'd replied;
  too bad. ]
-------

 ----------------------------------------------------------------------

    +++ hyphenation inhibited by struts

Date: 06 Jan 1994 12:04:38 +0100
From: Piet van Oostrum <piet@cs.ruu.nl>
Subject: Bug in TeX

Barbara,

Could you forward the following to Knuth (I suppose you still act as a
forwarding agent).

I consider the following a bug in TeX (in fact in the Plain macros):

The first and last words in a footnote are never hyphenated.

This is because plain TeX inserts struts, which are rules, and as these are
adjacent to the first and last words, they inhibit hyphenation.

The solution is to insert \hskip0pt\relax between the struts and the text.
In fact I think it would be better to include this in the definition of
\strut.

The solution to Exercise 22.8 has the same deficiency.

Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
-------
[ dek -- I believe it is also true that the first word of _any_
	 paragraph is not hyphenated.  (I prefer actually to
	 disable hyphens on the final word; but anyway this change
	 is far too drastic to be contemplated at this time.)
]
(reply, 06 Jan 1994)
piet,
thanks for your report.
i'll forward it to knuth, but i know his response:
this isn't a real bug; it's an unfortunate feature, and if he
had thought about it in 1984, he probably would have done what
you suggest.  but tex/plain/etc. are now frozen, and he's not
going to make any changes except for indisputable bugs.

he will probably also suggest that you write this up for tugboat.
so i will beat him to it -- would you write this up in a form
suitable for the "warnings" column?  this would best take the
form of a brief, clear description (the description in your
message is certainly clear enough) with an example or two
showing "before" and "after".  let me know what you think.
-------
Date: 07 Jan 1994 09:44:09 +0100
From: Piet van Oostrum <piet@cs.ruu.nl>
Subject: Re:  Bug in TeX

>>>>> bbeeton <BNB@MATH.AMS.ORG> (BB) writes:

BB> piet,
BB> thanks for your report.
BB> i'll forward it to knuth, but i know his response: [...]

I'll just wait for DEK's response and then write a warning article about
it. Thanks for your effort.
-------
[ dek -- I certainly agree that he should make such a contribution to
	 _Warnings_.
	 NB. There is an \allowhyphens macro [in Appendix D, not in plain]
]

 ----------------------------------------------------------------------

    +++ TeXbook, page 363, in \endinsert

Date: 09 Feb 1994 12:29:08 +0100 (MET)
From: vieth@convex.rz.uni-duesseldorf.de (Ulrik Vieth)
Organization: Heinrich-Heine-Universitaet Duesseldorf
Subject: Re: for Knuth: minor typo in MFbook

Hi Barbara,

after I printed out all the errata files yesterday, I've checked it
again. Here is what I found out:

[ this turned out to have been resolved, but i've left the comment
  in the report for background. ]
The METAFONTbook, 5th printing, March 1990 is quite a strange mixture.
[ dek -- royal foulup in _many_ printings.  Ask Phyllis for copies
	 of letters I wrote to A-W when i first noticed it ...
]
It does include the changes from errata.five (1989) and errata.six
until 3/13/90, excluding those dated 3/24/90 or later. It does *not*
include the changes from errata.three nor those from errata.four,
unless they happen to fall on pages affected by the later changes.
My conclusion that some of the changes from 3/87 were done, was just
a conincidence since most of them were index corrections on pages
that were changed again in 1989--1990. I'll try to locate a newer
printing of the METAFONTbook next week at the DANTE meeting to check
if they have been done in subsequent printings. However, I couldn't
find any note about the 6th printing in my copy of errata.three.
There seem to be different of that file around.

[ this is the problem that still remains ... ]
OK, so far about the METAFONTbook. When I was at it, I also checked
my copy of the TeXbook, 18th printing, May 1990. Here, there were
no serious problems. It includes the changes from errata.six until
3/24/90, so it was completed sliightly later than the METAFONTbook,
5th printing. The only small problem I found was the change on page
A363, dated 8/12/89, that should have been in, but isn't.  I'll try
[ dek -- he's correct ... this never made it into print.
]
to investigate this in a newer printing as well, but there might be
the odd chance that it came too late when the bunch of changes
dated 3/12/89 were send off and was forgotten with the next bunch
a few months later. In any case, I'll try to find out.

Greetings, Ulrik Vieth.
-------

i found this bug for page a363 in errata.six:

    \bugonpage A363, lines 8--9 from the bottom (12/8/89)

    {\ninepoint\parindent=0pt
    |  \if@mid \dimen@=\ht0 \advance\dimen@ by\dp\z@ |%
     |\advance\dimen@ by12\p@|\parbreak%
    |    \advance\dimen@ by\pagetotal \advance\dimen@ by-\pageshrink|
    \par}
[ dek * ]
-------
Date: 18 Feb 1994 18:23:06 +0100 (MET)
From: vieth@convex.rz.uni-duesseldorf.de (Ulrik Vieth)
Subject: Re: for Knuth: minor typo in MFbook

Hi Barbara,

I have just returned from the DANTE meeting, where I found a copy of
the 7th printing of the METAFONTbook to check. It appears to me that
the changes from errata.three and errata.four that were missing in
the 5th printing are finally in there. So the problem I reported is
mostly solved.

About the TeXbook: I've noticed that the famous duplicated exercise bug
that was still present in the 22nd printing (final version) has been
corrected in the 23rd printing. However the change on page A363 (8/12/89)
is missing there as well. Of course it is in plain.tex 3.0 or later, but
apparently page A363 has not been updated in the 18th printing or any
other printing since then. So I guess this is indeed a problem for Knuth
and Addison-Wesley. Although my first problem has disappeared in the end,
this has led to the discovery of another problem still pending, so it
was worthwhile after all.
[ dek -- \check
]

Ulrik Vieth.
-------

<<< end plain.tex

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

>>> Metafont

    +++ arithmetic overflow with z=whatever[z',z'']

Date: Mon, 9 May 94 14:44:46 WETDST
From: Tomek Przechlewski <tomasz@panda.bg.univ.gda.pl>
Subject: Bug in Metafont?

Dear Barbara,

I am passing the request of my friend Bogus{\l}aw
Jackowski (you have met him in Aston last year). He cannot find the
explanation of MF performance in the  example appended below.

Could you answer why in quite similar situations there are
so different outcomes. Is this a bug in Metafont or a feature?

I look forward to hearing from you

--Tomek Przechlewski

% ===================================================================

%
% \rm{}The following simple \MF\ program yielded unexpected (to me) results:
%
z1=whatever[(0,328),(100,329-eps)];
z2=whatever[(0,328),(100,329)];
z3=whatever[(0,328),(100,329+eps)];
z4=whatever[(0,328),(100,329+2eps)];
showdependencies;
end.
%%\def\~{\kern.15em}
%
% \rm{}The log file produced by, e.\~g., sbMF reads as follows:
%
%    This is METAFONT, Version 2.71(c)sb13 (preloaded base=plain 93.5.6)
%    23 JUL 1993 17:22
%%%% originally the ampersand was not preceded by the slash, of course
%    ** \&plain aritover.mf
%    (aritover.mf
%    ! Arithmetic overflow.
%    l.5 ...atever[(0,328),(100,329)]
%                                    ;
%    ? 
%    ! Arithmetic overflow.
%    l.6 ...er[(0,328),(100,329+eps)]
%                                    ;
%    ? 
%    ! Arithmetic overflow.
%    l.6 ...r[(0,328),(100,329+eps)];
%                                    
%    ? 
%    y4=0.01001x4+328
%    y3=0.01001x3+327.83998
%    y2=0.01x2+327.68
%    y1=0.01x1+328 )
%
% \rm{}Although Phil Taylor's opinion is that ``.\~.\~. the `bug' appears
% \rm{}to be a feature; the error message is well-defined, and `help' gives
% \rm{}a sensible diagnostic .\~.\~.'' I can hardly agree that this is OK.
% \rm{}Good luck to everybody using equations of the form |z=whatever[z',z'']|.
%
%                                                 \rm{}Bogus\l{}aw Jackowski
%                                                 \rm{}ul. Tatrza\'nska 6/1
%                                                 \rm{}80-331 Gda\'nsk, Poland.
%
%
% \rm{}P.\~S. For the first time I came up against this situation on 4 III 1993
% \rm{}(the equation was |z=whatever[(37.0092,419.22664),(280.3105,417.96634)]|).
% \rm{}Since that time I had ``a pleasure'' of encountering it several times. BJ.
%%\let\makefootline\empty\end
-------
Date: Tue, 17 May 94 12:46:02 WETDST
From: Tomek Przechlewski <tomasz@panda.bg.univ.gda.pl>
Subject: B. Jackowki's replay

Dear Barbara,

thank you for your responding to Tomek's mail.

> ...there was another report about METAFONT arithmetic overflow just
> last week...

Both error messages which are the subject of Pierre MacKay's response
have nothing to do with the METAFONT's behavior I had to struggle with:

1.
> alpha=diag_ratio(4,stem2-stem3+stem4,y1-y2,x8r-x1l+mid_corr-2apex_corr);

The `diag_ratio' macro does not make any use of `whatever[...]' construction,
while my troubles are strictly connected with this construction.

2.
>z4=z5+whatever*(150u,h);

Here the `! Arithmetic overflow' error occurs because the value of expression
`150u' is too large: for cminch font u=223.51988 at 2540 dpi, hence the
product would be about 33528, which is the number too large for METAFONT
(her actual infinity is 32767.99998). So, once again, `whatever[...]'
construction is not to blame.

In my example I am using fairly ``regular'' numbers (ranging from zero to
about 300) and, moreover, the behavior of METAFONT seems to be numerically
instable, as changing the numbers by `eps' (in plain METAFONT eps=0.00049)
has apparent impact on `! Arithmetic overflow' error.

Of course, I am not in a position to insist on prof. Knuth to change
METAFONT, neither I wish to overload him with unnecessary work. Nevertheless,
I would be happy to learn at least when such a situation may occur; then it
will perhaps become clear how to avoid it.

Cheers. Jacko

PS: and Tomek.
-------
[ message forwarded to chris thompson, but no response ]

 ----------------------------------------------------------------------

    +++ several reports from Bogus{\l}aw Jackowski

Date: 18 Oct 1994 16:06:45 +0100 (MET)
From: Wlodek Bzyl <matwb@halina.univ.gda.pl>
Subject: errors of TeX, MF (from B. Jackowski)

Hi, Barbara,

This file contains actually five different files put together to facilitate
electronic transmission and maintenance. Files are separated by `-=-=-= ...'
lines. All of them contain remarks concerning may-be-bugs in various
D. E. Kunth's products. If the authorship of a remark is not stated
explicitly, this means that it is mine (BJ's).

                                         Bogus\l{}aw Jackowski
                                         ul. Tatrza\'nska 6/1
                                         80-331 Gda\'nsk, Poland


                                SYNOPSIS

1) File ARITOVER.MF: describes troubles with METAFONT's arithmetical overflow
   in context of linear equations; I've already sent this file to you,
   but for the completeness reason I put it along with other messages.
   To see the problem you can compile the file with METAFONT and/or
   to print it using MFT utility with PL.MFT data (enclosed separately).
   
   Perhaps Phil Taylor is right that what I regard as a bug is merely
   a feature. If so, I would gladly learn how to avoid the problems
   which this `feature' may cause.

2) File SHUFFLED.TEX: discusses the problem of validity of the
   ``shuffled binary property'' of METAFONT operation `intersectiontimes.'
   This file can be compiled using TeX + MANMAC macros.

3) File CSCSPU.CH: contains a minor change to the METAFONT sources
   of the CM fonts.

4) File ITALD.CH: contains a minor change to the METAFONT sources
   of the CM fonts.

5) File 2R1Q2TXB.TEX: contains two minor remarks (possibly out of date)
   and one question concerning misprintings in The TeXbook. This file
   can be compiled using TeX + MANMAC macros.

%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                              FILE ARITOVER.MF
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%
% \rm{}The following simple \MF\ program yielded unexpected (to me) results:
%
z1=whatever[(0,328),(100,329-eps)];

% [ text removed; complete message appears above ]
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                          END OF FILE ARITOVER.MF
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                              FILE SHUFFLED.TEX
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

\let\MFmanual=\!
\input manmac \vsize24cm \pageheight\vsize
\def\rhead{Chapter 14. Paths}
\def\MFbook#1{%
 {\def\MF{{\manual 89:;}\-{\manual <=>:\/}}% slant the logo
 \sl The~\MF book#1}}
\pageno137 \proofmodefalse

\vdots

\bigskip

[ dek -- p137
]
\ddanger If the paths intersect more than once, \MF\ has a somewhat
peculiar way of deciding what times $(t,u)$ should be reported by
`$p$~intersectiontimes~$q$'. Suppose $p$ has length~$m$ and $q$ has
length~$n$. \ (Paths of length~0 are first changed into motionless paths
of length~1.) \ \MF\ proceeds to examine subpath~$(k,k+1)$ of~$p$
versus subpath~$(l,l+1)$ of~$q$, for $k=0$, \dots,~$m-1$ and $l=0$,
\dots,~$n-1$, with $l$ varying most rapidly. This reduces the general
problem to the special case of paths of length~1, and the times $(t,u)$
for the first such intersection found are added to $(k,l)$. But within
paths of length~1 the search for intersection times is somewhat
different: Instead of reporting the ``lexicographically smallest'' pair
$(t,u)$ that corresponds to an intersection, \MF\ finds the $(t,u)$
whose ``^{shuffled binary}'' representation $(.t_1u_1t_2u_2\ldots\,)_2$
is minimum, where $(.t_1t_2\ldots\,)_2$ and $(.u_1u_2\ldots\,)_2$ are
the radix-2 representations of $t$ and~$u$.

\bigskip

\vdots

\bigskip

\tenpoint

This is what \MFbook\/ says on page 137. Then follows Exercise 14.17 which
makes use of the ``shuffled binary property.'' Alas, the ``shuffled binary
property'' does not hold. Consider a path $p=(a,b)\dashto(c,d)$. One would
expect that the result of `$p$~\null intersectiontimes~\null reverse~$p$'
should be $(0,1)$, as the shuffled binary representation is for this case
$(.01010\ldots\,)_2$ which is the {\it minimum\/} of the shuffled binary
representations for pairs $(x,1-x)$, ${0\le x\le1}$.

Indeed, most likely the result will be like that (sometimes within some
accuracy).  But if there exist \MF\ numbers $c'$~and~$d'$ such that
$c$~and~$d$ are of the form ${c=a+3c'}$ and ${d=a+3d'}$, the result is
[ dek --                                        ^ b
]
astonishingly~$(0.5,0.5)$. This apparently contradicts the quoted statement
as the shuffled binary representation of $(0.5,0.5)$ is $(.11)_2$ which is
the {\it maximum\/} of the shuffled binary representations for pairs
$(x,1-x)$, ${0\le x\le1}$.

Here you have a little \MF\ program which can produce arbitrarily many
`|>>|~|(0.5,0.5)|' messages on your terminal:

 \begintt
 path p; numeric a,b,c,d,n; n:=10;
 for i:=1 upto n:
  a:=uniformdeviate 1000; b:=uniformdeviate 1000;
  c:=a+3uniformdeviate 1000; d:=b+3uniformdeviate 1000;
  p:=(a,b)--(c,d);
  show p intersectiontimes reverse p;
 endfor
 \endtt

\medskip

My basic question is: does the above specification cover all exceptions
from the shuffled binary property?

Also, I wonder whether it is a ``white lie,'' or a mistake in \MFbook,
or---God forbid!---a bug in \MF\kern.1em?

[ dek -- ANSWER:
	 This is an interesting question (but you could have figured it
	 out from the program.  I admit that the documentation is ``terse'',
	 but the algorithm is pretty enough to reward a close look.)
	 In fact we _do_ get the minimum shuffled binary, which happens
	 to be not .0101010101... but .001111111111... [even smaller!];
	 which gives (0.5,0.5).
	 The point .001111111111 seems to lie on both curves only when
	 there is absolutely no truncation error, and I believe this
	 happens if and only if the control points z_0 .. controls z,
	 and z_2 .. z_3 satisfy z_1 - z_0 = z_2 - z_1 = z_3 - z_2 .
	 Otherwise it's necessary to go to the next higher case.
	 Of course the intersection point routine is not intended for
	 such curves -- it is supposed to -|- find genuine crossing points.
]

\bigskip

\rightline{\vbox{\halign{#\hss\cr
\it June 10, 1994\cr
\noalign{\medskip}
Bogus\l{}aw Jackowski\cr
ul. Tatrza\'nska 6/1\cr
80-331 Gda¤sk\cr
Poland\cr
}}}

\end

%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                           END OF FILE SHUFFLED.TEX
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                              FILE CSCSPU.CH
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

% Following a change in ROMANU.MF I would suggest a similar change
% in CSCSPU.MF:
%
@x
bulb(3,4,5);  % bulb
@y
[ dek -- $2.56
]
pickup tiny.nib; bulb(3,4,5);  % bulb
@z
%
% The original version of CSCSPU generates bad ``dotless'' small cap `j'
% in Computer Concrete CCCSC10 font.

%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                           END OF FILE CSCSPU.CH
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                              FILE ITALD.CH
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

% The non-zero depth of the italic digit seven was noticed by 12 years old
% Joanna Ry\'cko. I cannot see any reason for keeping this state of the art.
% It seems that the following change in ITALD.MF would be appropriate:
@x
beginchar("7",9u#,fig_height#,desc_depth#);
@y
beginchar("7",9u#,fig_height#,0);
@z

[ dek -- I have sworn not to change the TFM files ever again.  So this
	 curious glitch is permanent.  (Long ago _all_ italic digits had
	 the same descender.  Later I corrected everything but the 7;
	 we can live with it.
]

%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                          END OF FILE ITALD.CH
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                            FILE 2R1Q2TXB.TEX
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

\input manmac \vsize24cm \pageheight\vsize
\proofmodefalse
\def\rhead{}
\def\rightheadline{}
\font\bsl cmbxsl10

\centerline{\bf Two Remarks and One Question}
\centerline{\bf Concerning \bsl The \TeX book}

\bigskip

% [ this one has been fixed ]
1)\enspace Noticed by Marek Ry\'cko: In the eighteenth printing of {\sl The
\TeX book\/} Exercise~8.7 appears twice (one after the other).

\bigskip

2)\enspace Noticed by Marek Ry\'cko: In the source of {\sl The \TeX book\/}
(incorporating the final corrections made in 1993) on the page~31 a space
precedes improperly the word `\TeX' just after the verbatim quotation:
[ dek -- $2.56
]

\medskip

\noindent `[\dots] after typing something like this:
\begintt
! Undefined control sequence.
l.2 \vship
           1in
?
\endtt
\def\storypage{24} % listing of story.tex
\TeX\ begins its error messages with `|!|', and it shows what it was
reading at the time of the error by displaying two lines of context~[\dots]'

\medskip

\tolerance1000
The reason for this is that after the verbatim quotation there is a command
|\def\storypage{24}|, and there is a space after it.
[ dek -- ^^^^^^ This command is in fact redundant -- I moved it to
	 manmac.tex but forgot to delete it from texbook.tex
]

\bigskip

3)\enspace The ``problem'' raised during the Euro\TeX'94 meeting in Gda\'nsk,
Poland:  What is the proper spelling of Addison$\,*\,$Wesley:  Addison-Wesley
(back of the cover of {\sl The \TeX book}, prepared probably by the
publisher) or Addison Wesley (the~source of {\sl The \TeX book\/}), or both? 

[ dek -- They flip-flopped several times during the 80s, as they had
	 different chief graphic designers for their ``corporate image''.
	 I couldn't keep up.
]

%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%                        END OF FILE 2R1Q2TXB.TEX
%-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-------

<<< end Metafont

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

>>> CM fonts

    +++ missing "cmchar"s in bigdel.mf

Date: Sat, 07 Mar 92 15:23:59 GMT
From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
Cc: REH10@phoenix.cambridge.ac.uk
Subject: Missing "cmchar"s in bigdel.mf

Barbara,

[ dek -- E95,E97  $2.56
]
Robert Hunt (reh10@phx.cam.ac.uk) has pointed out that in bigdel.mf
the expected "cmchar"s on line 596 (character `077) and line 645
(character `167) are missing. (As "cmchar" is usually a no-op, this
only matters if you are trying to play the sort of games described
on pp.312-313 of the METAFONTbook.) It seems to be just an oversight:
perhaps you can add it to DEK's list?

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
-------

 ----------------------------------------------------------------------

    +++ shaved_stem vs. cap_stem in greeku.mf

Date: 14 May 1993 17:38:30 -0300 (BST)
From: Chris Thompson <CET1@phx.cam.ac.uk>
To: Barbara Beeton <BNB@MATH.AMS.ORG>
Cc: Robert Hunt <REH10@phx.cam.ac.uk>
Subject: Re: [Minor CM fonts bug]

Barbara,

Robert Hunt reports the following:
> Line 196 of greeku.mf, which currently reads
[ dek -- E187,E189  $2.56
]
>
> lft x1l=lft x2l=hround(.5w-.5cap_stem); top y1=h; bot y2=0;
>
> should read
>
> lft x1l=lft x2l=hround(.5w-.5shaved_stem); top y1=h; bot y2=0;
>
> Exactly the same bug also occurs on line 215. (These are in the
[ dek --                                   ^^^ 216
]
> character programs for capital Phi and Psi respectively.)

This looks right to me: at some stage 'shaved_stem' was introduced
to these programs instead of 'cap_stem', but these two occurrences
were missed.

Chris Thompson
Cambridge University Computing Service
-------

 ----------------------------------------------------------------------

    +++ miscellanea from Robert Hunt, mostly in CM sources

Date: 29 Mar 1994 21:01:42 -0300 (BST)
From: Robert Hunt <REH10@phx.cam.ac.uk>
Cc: Chris Thompson <CET1@phx.cam.ac.uk>
Subject: TeX bugs

Dear Barbara,

I've been saving up several bugs I've found in the Computer Modern sources, the
METAFONTbook and Plain TeX for quite a while, and am now sending them on to you
for DEK. Perhaps you could add them to his list of things to look at next time
he reviews TeX etc. - I fully realise that this probably won't be for some
quite considerable time!
[ dek - ^^^^^^^^^^^^^^^                                               ^^^^
]

This message is, I'm afraid, rather long, but I thought it'd be better to send
you everything in one go rather than split it up into lots of separate
messages. Each of the bugs is separated by a line of ------'s below.
[ dek -- well done
]

Thanks & best wishes,
Robert Hunt.

 ------------------------------------------------------------------------------

There seems to be a recurrent error in the code for the various Computer Modern
[ dek -- OK on pE481
]
integral signs. For example, in the code for the \displaystyle integral sign in
bigop.mf, the line
   lft x5r=hround(.5w-.5stem);
[ dek -- E113, E115  $2.56
         four places in bigop.mf
	   "     "   "  ebigop.mf
]
should actually read
   lft x5r=hround(.5w-.5max_size);
as the character is max_size pixels wide at z5. (In fact, the stem parameter
does not feature in the program for this character in any other way!) Similar
comments apply to all the other sizes and styles of integral signs.

 ------------------------------------------------------------------------------

In the code for the Computer Modern partial differential sign in italms.mf, the
line
   path p; p=pulled_super_arc.l(3,4)(pull);
[ dek -- E233  $2.56
]
should be replaced by
   path p; {{interim superness:=more_super; p=pulled_super_arc.l(3,4)(pull)}};

 ------------------------------------------------------------------------------

In symbol.mf, the code for the Computer Modern elementary division operator has
a bug causing the dots to be drawn with diameter dot_size+rule_thickness rather
than dot_size. (It's clear that they're meant to be of diameter dot_size
[ dek --             ^^^^^ No, the dots are the correct size but the
	                   defs of x_3,y_3 are inappropriate
	 E438  $2.56
]
because of the definition of x3.) The reason that the code doesn't work is that
pos doesn't know the breadth of rule.nib, so doesn't subtract anything off from
[ dek -- currentbreadth is in fact set from the pickup fine.nib of the
         integral sigh (by chance) -- I should make my intentions clear,
	 without changing the character image that I got by luck.
]
dot_size. Various fixes are possible (such as changing the font_setup routine
in cmbase.mf to define breadth_[rule.nib]=rule_thickness), but the simplest
seems to be to insert a line saying "pickup fine.nib;" just after the draw
command.

 ------------------------------------------------------------------------------

There seems to be an error in the syntax definition for <path expression> on
page 213 of the METAFONTbook (and also in the simplified definition on page
129). I hope that I haven't embarrassed myself by misunderstanding it!

The syntax as given doesn't seem to allow "(0,0)..(1,0)" as a
<path expression>. A <path join> (".." here, with empty direction specifiers)
must be followed by either "cycle" or <path tertiary>. A <path tertiary> must
start with a <path primary>. But "(1,0)" cannot be a <path primary>, as it is
[ dek -- C129  $2.56
]
not a <path argument> or <path variable>, nor is it "(<path expression>)"
(since "1,0" without the brackets is not a valid <path expression>).
[ dek -- <pair tertiary< movves from subexpr level to tertiary level
]

 ------------------------------------------------------------------------------

There is a low-resolution anomaly that arises in the Computer Modern equals
sign and several other such characters. Each of the bars of "=" is meant to be
drawn by an identical _circular_ pen. However, at low resolutions (e.g.,
300dpi, with mode CanonCX) the character can often turn out looking like the
following:

                                 xxxxxxxxxxxx
                                xxxxxxxxxxxxxx

                                xxxxxxxxxxxxxx
                                 xxxxxxxxxxxx

which doesn't have the symmetry one would expect at the end-points of the
lines. This is due to the way in which the heights of the two bars are chosen;
the centre-points of the bars are at heights math_axis+.5spread and
math_axis-.5spread. Now math_axis has been chosen to be a good.y position for
rule.nib, and spread has been chosen to be an integer+eps; but this means that
if spread is an _odd_ integer (+eps) then the edges of the nib when it draws
the two bars are at almost exactly the _least_ optimal heights for drawing!
(I.e., an integer+.5+1/2eps.) This results in a loss of vertical symmetry at
the end-points of each bar.

My suggested solution for this is to ensure that spread is always an even
integer (apart from the correction of size eps), as follows:
   def compute_spread(expr normal_spread,big_spread)=
    spread#:=math_spread[normal_spread,big_spread];
    spread:=2ceiling(spread#*hppp/2)+2eps; enddef;
[ dek -- E491  $2.56                 ^ I left this out.  _I_ _don't_ _know_
		_why_, but it caused the equal isgn to look like
				xxx---x
				 xx---x

				 xx---x
				xxx---x
		quite asymmetric!
		I don't have time to fool around, but I guess this definition
		is an improvement even though the 2eps should've been
		good too ...
				+0	OK
				+eps	OK
				+2eps	NG
				+3eps	NG
				+1/3	NG
]
This does have the disadvantage that at very low resolutions characters can end
up being rather widely spread.

 ------------------------------------------------------------------------------

The character "H" in font cmssdc10, at pixels_per_inch=300 and mag=magstep1
(the other parameters are unimportant), demonstrates a rounding problem which
is in fact present in a very great number of the Computer Modern character
definitions. At the top and bottom left of the left-hand stem, a pixel has been
cut out; but on the right of the left-hand stem, and on both sides of the
right-hand stem, these pixels are filled in. This makes the character very
asymmetric.

The problem is caused because the stem is drawn with a pen of non-zero
thickness which is turning a corner, and because of a nicety which is discussed
in the METAFONTbook on the top of page 200. Basically, the line
  lft x1l=lft x2l=hround max(2u,3u-.5cap_stem); x3=x4=w-x1;
in the definition of "H" in romanu.mf should be replaced by the two lines
  lft x1l=lft x2l=hround max(2u,3u-.5cap_stem)-eps;
  rt x3r=rt x4r=w-hround max(2u,3u-.5cap_stem);
(or something equivalent to these two). We want to avoid the vertices of the
"tiny" pen polygon (which is being used to draw the character) passing through
any ambiguous points whenever it turns a corner, and to do that we want its
centre to lie at a half-integer minus eps whenever it's at the left-hand side
of a stroke region, and at a half-integer (exactly) when it's at the right-hand
side of a stroke. (By "half-integer" here I mean either an integer or an
integer plus 1/2, dependent on the breadth of the "tiny" nib.) Since the "pos"
command of cmbase sets the distance between x$l and x$r to be an integer plus
eps (because the breadth of the tiny pen is set to an integer minus eps by the
font_setup routine), the command "lft x1l=hround(...)-eps" sets lft x1l to an
integer minus eps and rt x1r to exactly an integer; whereas "rt
x3r=hround(...)" sets rt x3r to an integer and lft x3l to an integer minus eps.
These commands therefore ensure that the stroke will have left-right symmetry.

So the general rule which seems to be required is that in many of the CM
programs,
  lft x$l=hround(...);
should be replaced by
  lft x$l=hround(...)-eps;
whereas
  rt x$r=hround(...);
should be left alone. Unfortunately this isn't a hard-and-fast rule, so would
be difficult to do automatically; in particular, commands such as
  lft x$l=w-rt x$$r=hround(...);
need to be split into two statements.

In fact, even the METAFONT logo font itself is subject to this problem! The "F"
character in logo.mf can suffer from asymmetry of the top bar, with pixels
being lost at the left-hand side (the right-hand side being alright). A quick
solution would seem to be to set leftstemloc to an integer minus eps instead of
exactly an integer, but I haven't checked this carefully to make sure it would
work correctly.

Is it worth doing anything about this? It's a very minor problem, and to put it
[ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	 To raise this question is to answer it!
]
right would require an awful lot of changes to the Computer Modern source
files. Unless some super-whazzo solution involving changing the "lft" macro
(etc.) can be thought up, it would be a very large amount of work.

 ------------------------------------------------------------------------------

There are a number of infelicities and/or bugs in the Plain TeX format. I've
listed some I know about below in approximately decreasing order of importance;
some (especially near the end of the list) are a little esoteric.

% The Plain TeX \skew macro does not work properly with variable-size accents
% such as \widetilde. The following rewrite corrects that.
[ dek -- And makes people wonder why divide by 2 instead of using half
	 the skew originally!
]
%
\def\skew#1#2#3{{\muskip\z@#1mu\divide\muskip\z@\tw@ \mkern\muskip\z@
  #2{\mkern-\muskip\z@{#3}\mkern\muskip\z@}\mkern-\muskip\z@}{}}
[ dek -- p359  $2.56
]
%
% The maths spacing inserted by \bmod is incorrect in script or scriptscript
% styles, because \nonscript was not used.
%
\def\bmod{\nonscript\mskip-\medmuskip\mkern5mu
  \mathbin{\rm mod}\penalty900\mkern5mu\nonscript\mskip-\medmuskip}
[ dek -- p361  $2.56
	 I hope this won't mess up too many people who have already
	 compensated for this bug.
]
%
% \displaylines does not work correctly if \tabskip happens to be non-zero when
% it is called (for instance, if the user does an \halign of his own with a
% non-zero \tabskip, just before using $$\displaylines{...}$$).
%
\def\displaylines#1{\displ@y \tabskip\z@skip
  \halign{\hbox to\displaywidth{$\@lign\hfil\displaystyle##\hfil$}\crcr
    #1\crcr}}
[ dek -- p362  $2.56
]
%
% If a maths display is started when \prevdepth=-1000pt, the \openup adjustment
% which \displ@y automatically inserts before the first line of the display to
% compensate for the change in the value of \baselineskip should be omitted.
%
\def\displ@y{\global\dt@ptrue\openup\jot\m@th
  \everycr{\noalign{\ifdt@p \global\dt@pfalse \ifdim\prevdepth>-1000\p@
      \vskip-\lineskiplimit \vskip\normallineskiplimit \fi
      \else \penalty\interdisplaylinepenalty \fi}}}
[ dek -- p362  $2.56
	 It is _very_ hard to reach this situation!
	 \noindent $$ \displaylines ... seems to be the simplese.
]
%
% [ \d{} and \b{} were reported earlier; see above under >>> plain.tex;
%   this is the first report of \@vereq, i believe ]
% The \d and \b accent macros don't work if the user has set \lineskiplimit to
% a negative value, say around -2pt or less. The \@vereq macro (used only by
[ dek --                                                 esplicitly ^
]
% \cong) suffers from a similar problem.
%
\def\d#1{{\lineskiplimit\maxdimen\oalign{#1\crcr\hidewidth.\hidewidth}}}
\def\b#1{{\lineskiplimit\maxdimen\oalign{#1\crcr
    \hidewidth\vbox to.2ex{\hbox{\char22}\vss}\hidewidth}}}
\def\@vereq#1#2{\lower.5\p@\vbox{\lineskiplimit\maxdimen\lineskip-.5\p@
    \ialign{$\m@th#1\hfil##\hfil$\crcr#2\crcr=\crcr}}}
[ dek -- p360  $2.56
]
%
% Several definitions in Plain TeX contain excess tokens (typically redundant
% "=" signs, "by" keywords, etc.). Some (e.g. \m@th) are executed so frequently
% that it's worth removing them, which the following definitions do.
%
% [ removed ]
%
% [ removed some suggested hyphenations
%
% [ removed some suggested enhancements to operators like \sin ]
%
% \settabs breaks spectacularly in the (somewhat unlikely) eventuality of it
[ dek --          ^^^^^^^^^^^^^ agreed
]
% being followed by an \if; for example,
% \settabs \ifdim\hsize<8in 3 \else 4 \fi\columns
[ dek -- p354  $2.56
]
%
\let\temp=\+ \let\+=\relax

\def\sett@b{\ifx\next\+\def\nxt{\afterassignment\s@tt@b\let\nxt}%
  \else\let\nxt\s@tcols\fi \let\next\relax \nxt}
\def\s@tt@b{\let\nxt\relax\us@false\m@ketabbox}

\let\+=\temp
%
% English authors would greatly prefer to use English spellings in their
% command names!
%
% [ removed ]

 ------------------------------------------------------------------------------

[ additional bugs summarized; separate reports included above ]
-------
(reply, 29 Mar 1994)
robert,
thanks very much for your collection.

a comment on plain.tex.  knuth has communicated to me that he
will never again change plain.tex ; here is his response to a
suggestion sent to him in february 1993:

  [ dek:  These macros look very good but I cannot change plain TeX
	  any more at this late date.  _Ever_._
	  (Wish I had thought of them in 1985!)
	  He should publish them in TUGboat.
  ]

presumably if there is a very bad and obscure bug *that doesn't
take effect very often* he might consider making an exception,
but his ideal now is that the entire tex system remain stable,
permanently.  his recommendation that remaining problems, and
suggested improvements, be published in tugboat must be taken
at face value.  if i don't pay attention to such comments, and
send in everything that's sent to me, i put myself in danger
of incurring his severe displeasure, which would jeopardize my
welcome to forward real bugs.  if you really do want to submit
these suggestions for plain.tex to him, you should do it yourself
by regular post.  his address is

    Prof. Donald E. Knuth
    Department of Computer Science
    Stanford University
    Stanford, CA 94305 U.S.A.

you could mention that i wouldn't forward them, or not, as you
wish.  (i'll let you know what i do forward when i next put a
package together; that should be within the coming month.)

regarding the computer modern sources, he may feel the same way
as about plain.tex, but it's never been tested.
-------
Date: 11 Apr 1994 21:42:27 -0300 (BST)
From: Robert Hunt <REH10@phx.cam.ac.uk>
To: bbeeton <BNB@MATH.AMS.ORG>, Chris Thompson <CET1@phx.cam.ac.uk>
Subject: Re: TeX bugs

Dear Barbara,

Thanks for your message about my bug collection. I understand DEK's position on
Plain TeX, that he doesn't want to change it any more, and will certainly
respect that. (Though I suppose I would be grateful if when you forward the
rest of my list to him, you would just add a one-liner saying that there used
to be several Plain TeX bug-fixes there but that you've removed them with my
co-operation for this very reason!)

How would I go about publishing them in TUGboat? [...]
-------

[ dek -- Barbara, I relented this time only because his macros were elegant
	 and instructive and (with the exception of \bmod) unlikely to
	 make existing .tex files obsolete.
	 The \bmod bug is something I'm sure people have compensated for,
	 e.g., by inserting a thin space where it now will look better
	 without any such manual tuning up ...
	 but I decided the correction desirable anyway.

	 For example, I had to change the MS to Concrete Math in seven places.
	 We could tell people to put the old def of \bmod in their files
	 if they don't wish to change.  (That's what I decided to do with
	 Concrete Math.)

	 I do expect to be EXTREMELY hardnosed about ANY future changes
	 to plain.tex, however.  My thought is that this might as well be
	 the one last chance for changes -- since \d was so badly in need
	 of correction (four separate changes to it!)
	 Therefore, _please_ _keep_ telling people so exactly what you have
	 been telling them so kindly about the frozen-ness of plain.tex.
]

 ----------------------------------------------------------------------

    +++ cap_ess in cmmi12 and larger

Date: 01 Feb 1994 18:17:07 +0100
Reply-to: METAFONT Distribution List <metafont@ens.fr>
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Subject: c-cmmi.mf (Sauter tools) revisited: Bug in cap_ess
[ dek --            ^^^^^^^^^^^^ This is something I have nothing to do with...
]

Bug report in c-cmmi.mf

At 17.28pt the middle part of the letter S in cmmi looks too thin. I have 
gone into the parameters and found the following formula for 
cap_ess (design_size>10, rest omitted):

cap_ess#:=(-design_size*5 + 380)/360 pt#;

this means that the parameter cap_ess# decreases with design_size and will 
reach zero at 76 pt! So why that decrease? Let's look at the Knuthian 
parameters for cmr, cmmi and cmti:

font    5      6      7       8        9       10       12 (pt#)
cmr    14     19     23      27       31       35       43 (1/36 pt#)
cmmi   13.5   18.5   22.5    26       30       33       32
cmti   --     --     21      24       27       31       34

For all font but cmmi12, cap_ess of cmmi is between the values of cmr and 
cmti, but closer to the cmr value. It look as if for cmmi12 a value of 42
was aimed at, but for some reasons 32 has become a feature of this font. If 
you look sharply at the S in cmmi12 (at 600dpi), you might find it a little 
too light besides the letter R, but this is at the edge of visibility (at 
least for my eye), therefore I'd never noticed it without looking at the 
parameters.
[ dek -- As far as I know, there was no good formula for the ess widths;
	 I just played until they seemed right -- I defer to committee for
	 these things.
]

However, further decrease of cap_ess is a bad idea, it should increase 
again from design_size=12 on.

Here a proposed formula for design_size>12, it yields 320/360 pt# at 
12 and increases then, never getting bigger then the cmr-value:

(design_size*9 + 216) / 360pt#

It will be, however, lower then the value of cap_ess in cmti.
Since roman letters may appear in matematical formulae, the alignment 
to the cmr parameters is imho the more important case.

Fortunately, a change in the parameter cap_ess does not affect the font 
metrics (or have I missed something?), therefore we can make a change here 
[ dek --                  ^^^^^^^^^ true -- anybody can change to
			            heart's content
]
without disturbing documents using the Sauter fonts.

Comments?

Yours, J"org Knappen.	
-------

 ----------------------------------------------------------------------

    +++ possible glitch in cmbx5 and cmbx6

Date: 15 Dec 1994 12:01:51 -0800 (PST)
From: kinch@netcom.com (Richard J. Kinch)
To: tex-implementors@MATH.AMS.ORG
Subject: Bug in cmbx5 and cmbx6

I believe there is a latent bug in Computer Modern cmbx5 and cmbx6.
 
The meta-ness seems to degenerate at the 5-point optical size used in cmbx5.
For example, digit "7" grows a wart on top, and serifs on glyphs like A, K, M,
N, U, V, W, X, Y, and others are notched in the inside corners.  The "7"
problem is clearly visible at 300 dpi when magnified to cmbx5 at 37.15pt.  The
serif notching is not evident except at even larger magnifications.  At normal
size at 300 or 600 this is not necessarily visible.
 
In C&T Volume E (Computer Modern Typefaces) on page 560 there is a sample of
cmbx5.  Under a 10x lens or so you can see extra ink on the top of the
digit "7".  I believe there is a one- or two-pixel wart on top of "7" in the
cmbx6 sample, too.
 
The problems are evident in proof-size printouts.
 
I discovered this in converting the METAFONT shapes to Bezier outlines with my
automatic converter, METAFOG.  I saw the misshapen glyphs and puzzled for days
thinking I had a bug in my converter.
 
Richard Kinch
-------

[ dek -- It's okay to change the shapes of CM fonts as long as you don't
	 change the TFM files.  I haven't time to fix this problem
	 since I don't consider enlarged cmbx an important font ...
	 I was unable to see the notches on the A, but I agree that the 7
	 [drawn outline of 7, with a lump on the top] looks cancerous.
	 Not a problem at the sizes intended.  Ultrabold is where
	 meta-ness can be expected to break first.

	 (Congrats on METAFOG)
]

 ----------------------------------------------------------------------

    +++ arithmetic overflow in CMinch

Date: 05 May 1994 14:08:55 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
To: BNB@MATH.AMS.ORG
Cc: Bob@microprograms.com, mackay@cs.washington.edu, unixtex@u.washington.edu
Subject: Arithmetic overflow in CMinch

Bob Harris (bob@microprograms.com) got in touch with me a couple
of days ago to report that it was not popssible to run
cminch with a 2540dpi LinotypeThreeZeroZero mode_def.

The letter W and the numeral 3 generate the
! Arithmetic overflow
message, and the problem is far too serious to
be turned off with warningcheck:=0;
even if you wanted to do that.

The offending lines were easy enough to spot:
     in romanu.mf one third of the way through "The letter W"
[ dek -- E291  32\cents
]

alpha=diag_ratio(4,stem2-stem3+stem4,y1-y2,x8r-x1l+mid_corr-2apex_corr);

     in romand.mf. halfway through "The numeral 3"

z4=z5+whatever*(150u,h);

Fortunately both of these statements generate ratios, so that the
raw arguments can be reduced consistently with no change in the results.
I extract from my email messages, slightly edited.

 >  Think of "whatever" (in this manifestation)
 >  as a path of infinite length along the angle
 >  specified by (150u,h)
 >  Since the angle (15u,0.1h) is exactly the same
 >  ---I checked it with expr.mf, and there is no
 >  loss of precision---there is the answer.  
 >  Write the offending line as

z4=z5+whatever*(15u,0.1h);

 >  The same trick that works for 3 works for W, though it requires a
 >  little more editing.

alpha=diag_ratio(4,.1(stem2-stem3+stem4),
	         .1(y1-y2),.1(x8r-x1l+mid_corr-2apex_corr);
[ dek -- This doesn't fit on page E113 and besides it is too kludgy --
	 bad style ...
	 What I shall really do is redefine diag_ratio -- it's pointless
	 to multiply by y and divide by y again!

 >  This has the effect of calculating on a dpi measure of 254, but since what
 >  we are looking for is a ratio, it makes no difference.  I ran with
 >  both calculations using the ljfour mode (effectively that means one 
 >  calculation at 600dpi and one at 60dpi) and got exactly the same ratio

 >  There is a small rounding difference in the 2540dpi file

 >  600dpi gives a diag_ratio of 1.03595
 >  2540 dpi gives a diag_ratio of 1.03609

 >  That may well be an artifact of some decisions in the parameter file.
 >  I doubt that .00014 is enough to worry about in this context.
 >  (The ratio that results after the ! arithmetic overflow is, of course,
 >  grossly out of line.

I was a bit puzzled at first to explain why this hadn't showed up before,
since I have made up fonts at 9600dpi and even 14454dpi, but the answer
lies in the peculiarity of a 72.27pt font.  Even a 17pt parameter file
has to be run at magstep 3 before its em-square reaches 1000 pixels in
width at 2540dpi.  But there could be real problems with cmr17 at the
9600dpi that Lance Carnes uses to derive his Chelgraph outlines from.

I wonder if DEK would be interested in preempting this problem, since
the solution is so painless, and will not affect TFM checksums.
-------

 ----------------------------------------------------------------------

    +++ sterling sign

Date: 04 Jan 1995 00:29:37 +0100
Reply-to: METAFONT Distribution List <metafont@ens.fr>
From: Yannis Haralambous <Yannis.Haralambous@univ-lille1.fr>
Subject: error in CM fonts

IMHO the following error has to be corrected:

In file italp.mf, character "Sterling sign", line -7, replace
rt x9r=hround(w-u);
[ dek -- E239  $2.56
]
by 
rt x9l=hround(w-u);
Otherwise the results are bad in typewriter style and catastrophic in
sans-serif. The funny thing is that I could _swear_ that on the image
of the character the code is correct [probably a typo by Addison-Wesley].

Yannis
-------
Date: 04 Jan 1995 10:35:54 +0100
Reply-to: METAFONT Distribution List <metafont@ens.fr>
From: Piet van Oostrum <piet@cs.ruu.nl>
Subject: Re: error in CM fonts

>>>>> Yannis Haralambous <Yannis.Haralambous@univ-lille1.fr> (YH) writes:

YH> IMHO the following error has to be corrected:

YH> In file italp.mf, character "Sterling sign", line -7, replace
YH> rt x9r=hround(w-u);
YH> by 
YH> rt x9l=hround(w-u);
YH> Otherwise the results are bad in typewriter style and catastrophic in
YH> sans-serif. The funny thing is that I could _swear_ that on the image
YH> of the character the code is correct [probably a typo by Addison-Wesley].

It can't be a typo by Addison Wesley, because it is in Knuth's original
sources (AW didn't type, they got -- of course -- the source from Knuth).

If you look at the image you can really see that it is generated by the x9r
code, because the character sticks out a little bit to the right of the
x=11 line. Notice that the x9r point is to the LEFT of the x9l point!!

And yes, with your correction it looks much better in sans serif. In the
[ dek --                                              ^^^^^^^^^^
	 what sans serif??  This char does not have a sans serif style
	 in the present design ... sans serif has no ``bulbs''
]
italic font, which is the only cm font where it is used, the difference
[ dek --     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
]
isn't very great because the x9r and x9l point are quite close top each
other, whereas in the sans-serif case they are 1 u apart.
 -- 
Piet van Oostrum <piet@cs.ruu.nl>
-------

<<< end CM fonts

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

>>> Fontware

    +++ testfont.tex

X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu>
Date: 05 Feb 1993 20:44 +0000 (GMT)
From: J%org Knappen <KNAPPEN@VKPMZD.KPH.Uni-Mainz.de>
Subject: Bug in testfont.tex

By chance I came across to notice a feature of testfont.tex, which I regard
as a bug:

In the \lowers and \uppers test, the kerning and ligature information is
not used. Therefore it is not possible to adjust the spacing of a font
using this tool. Since I know that some experts in macro expansion are
aroung here, i think one of them will take the challenge to rewrite
the routines of testfont.tex in order to be completely expandable and use
the kerning.

Yours, J"org Knappen.
-------

[ dek -- Font designers traditionally test without kerning (at least
	 they did when I worked with them in 80-85), but I suppose
	 such macros would be easy to write.
]

 ----------------------------------------------------------------------

    +++ VPtoVF

Date: 23 Aug 1993 10:08:20 +0200
From: Armin.Koellner@RUBA.RZ.ruhr-uni-bochum.de
Subject: VPtoVF bug report and some comments on the AMS fonts

Dear Barbara Beeton,

since you stated in one of your letters that you are the right person
to get in contact with D.E.Knuth, I am sending to you a report of a
bug in the web file VPtoVF (Version 1.2, 90/9/5) which I found when
experimenting with ligature tables generated by a program written by
myself:

If a ligature table erroneously starts with a STOP command, VPtoVF
will often destroy other data. This abnormal behaviour appears
because the variable lk_step_ended is not initialized by program code
to be FALSE, so that the conduct of the program depends on the random
contents of the memory cell the variable inherits. I suggest to
change the web file in order to correct this bug.

Additionally, I would like to suggest some improvements on the AMS
symbol fonts, and, as you are working for the AMS (I suppose), could
you please give it to the font developer of your organisation? Thank
you very much.

When I experimented with a program which handles fonts by detecting
their font coding scheme, I got stuck with the AMS symbol font series
msam and msbm. At first I detected that in my version of these fonts
(version="2.1a", date="15-OCT-1991") the series msbm* had no font
coding scheme string at all! This happened because the file xbbold.mf
ends with the token "end" instead of giving the control back to the
file amsyb.mf which ends correctly with "bye". I think, this bug
should be corrected.
[ this bug was fixed shortly after receiving this report ]

Secondly, the AMS symbol fonts have the same font coding scheme
string as the cmsy* series, namely "TeX math symbols". This makes
them indistinguishable when considering only this string. As far as
[ dek -- not really needed for msam -- only for fonts used in
	 family 2, 3 ...
]
I understand, this special name is necessary for programs like TFtoPL
and VFtoVP to handle the character coding and math symbol font
parameters correctly. However, by reading the corresponding web files
for these programs, I learned that they only consider the first 11
characters of the font coding scheme string. Therefore, I suggest for
the next version of your font series to name the font coding scheme
"TeX math symbols by AMS, Part A" and "TeX math symbols by AMS,
Part B", resp.
[ dek -- good suggestion
]

Yours sincerely,
Armin K\"ollner
-------
Date: 26 Aug 1993 12:54:58 -0300 (BST)
From: Chris Thompson <CET1@phx.cam.ac.uk>
Subject: Re: [[Armin.Keollner: VPtoVF bug report and some comments]]

Barbara,

Armin Kollner writes:
> If a ligature table erroneously starts with a STOP command, VPtoVF
                                          (or a SKIP command)
> will often destroy other data. This abnormal behaviour appears
> because the variable lk_step_ended is not initialized by program code
> to be FALSE, so that the conduct of the program depends on the random
> contents of the memory cell the variable inherits. I suggest to
> change the web file in order to correct this bug.

This is indeed a bug in the current versions of VPtoVF and PLtoTF.
I found it rather difficult to demonstrate, as the uninitialised
variable ends up as binary zero (typically = Pascal "false") on
most systems. I did manage it eventually, though.

[...]

> Secondly, the AMS symbol fonts have the same font coding scheme
> string as the cmsy* series, namely "TeX math symbols". This makes
> them indistinguishable when considering only this string. As far as
> I understand, this special name is necessary for programs like TFtoPL
> and VFtoVP to handle the character coding and math symbol font
> parameters correctly. However, by reading the corresponding web files
> for these programs, I learned that they only consider the first 11
> characters of the font coding scheme string. Therefore, I suggest for
> the next version of your font series to name the font coding scheme
> "TeX math symbols by AMS, Part A" and "TeX math symbols by AMS,
> Part B", resp.

It is true that PLtoTF and VPtoTF (currently!) test only the initial
section of the coding scheme ("TEX MATH SY" or "TEX MATH EX", after
upper casing) when setting |font_type|. The result is used to control
the  format used in the (V)PL output for various things (whether to
use names or numbers for the higher-numbered FONTDIMENs, and whether
to use D or C format for certain character numbers). This only affects
human-readability, though: the semantic content is not affected.

Quite how the "font coding scheme" should be used is far from obvious,
but it is certainly arguable that the msam*/msbm* fonts do not have
the same "coding scheme" as the cmsy* fonts, in the sense that
characters at corresponding code positions are not, in any plausible
sense the "same" meta-character. I don't know whether a change could
really be said to make "use of these files ... more reliable" (to
quote you), though.

[...]

Chris Thompson
Cambridge University Computing Service
-------

<<< end Fontware

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