Pending bugs for original TeX

This page lists bugs in the original (Knuthian) TeX distribution which have been received since the last tune-up (2021). They have been accepted by Knuth's vetters, but are not expected to be seen by Knuth until the next tune-up. If and when he does see them, there is no guarantee that he will consider them to be bugs, or take any particular action.

The original reports and answers have been edited or paraphrased for presentation here.

The page and section numbers are just an initial hint about a relevant location; often more than one place in the code is involved. The initial letter (A, B, …) refers to the Computers & Typesetting volume.

A list of non-bugs is also available. These (plausible) reports have already been deemed not a bug by Knuth or his vetters.

For any discussion about these issues, or further reports, please use the contact information on the main TeX bugs page here.


Volume A: The TeXbook

A044, line 11 (#A044percent) 2021-07-26, Hu Yajie: The temporary definition “\def\%{\char`\%}” lacks a space at the end, so the input “50\% of” (with this definition) will not have a space in the output: “50%of”. The idea of an optional space after a constant being ignored was introduced on the previous page.

A123, line -1 (#A123amount) 2021-03-13, Wolfgang Helbig: The last line reads “First compute the largest amount $v$ such that a height plus depth of $v$”, but an amount does not have a height or depth, not being a box.

A143,A152 (#A143above) 2021-01-20, Barbara Beeton: The descriptions of \above and \abovewithdelims don't mention that the given <dimen> affects the spacing above and below the fraction rule, as well as specifying the height of the rule. Appendix G rule 15d gives the computation, but the visual effect is hard to infer. Indeed, the typeset results are undesirable for any <dimen> larger than 1pt or so; the fraction appears too spacey (but of course the behavior cannot be changed at this late date).

A158, line -12 (#A158rparen) 2021-03-20, Hu Yajie: The math symbol ) is said to be character "28 of family 0, but plain.tex (line 90) assigns \mathcode`\)="5029, so "28 should be "29.

A210, exercise 20.13 (#A210period) 2021-05-25, Hu Yajie: The second-to-last-item, \ifx\ifx\ifx, should presumably be followed by a semicolon, not a period.

A219, line -9 (#A219expands) 2021-03-02, Hu Yajie: The \length macro does not “expand” to 8, since assignments are involved. Similarly on A218, line 21, “expanding the \primes macro” is technically incorrect, though perhaps there the informality is acceptable.

A249, line 5 (#A249crcr) 2023-04-26, Udo Wermuth: The text states: “\crcr … acts exactly like \cr except that it does nothing when it immediately follows a \cr or a \noalign{...}”. \crcr also does nothing when following \crcr.

A254, line 11 (#A254tracingoutput) 2021-05-28, Udo Wermuth:\tracingoutput is nonzero” should be “\tracingoutput is positive” (as on page 273). If \tracingoutput is less than zero, TeX doesn't write this tracing data.

A267, line -16 (#A267eyes) 2021-04-13, Hu Yajie: Use “eyes and mouth” rather than just “mouth”, since this is about reading from input files. Also on C217, line 10.

A272, line -1 (#A272floatingpenalty) 2023-08-19, Udo Wermuth: \floatingpenalty is described as “(penalty for insertions that are split)”, but that is not correct. Insertions that are split don't receive \floatingpenalty. The insertions that follow a split insertion get this value. See page 123, Step 2. Step 4, the step that describes the split, doesn't mention \floatingpenalty. (Perhaps something like: “(penalty for insertions following a split insertion)”, as the description has to fit on one line.)

A274, line 4 (#A274hboxes) 2021-04-05, Hu Yajie: in the description of \overfullrule, “width of rules appended to overfull boxes”, change “boxes” to “hboxes”.

A280, second and fourth bullets (#A280closeout) 2021-05-27, Udo Wermuth: \closeout is specified to take a <4-bit number>, but in fact it takes a general <number>. A \closeout<number> argument outside the 4-bit range 0–15 still produces a whatsit item (but, as described in The TeXbook, has no other effect; for example, \closeout-1 does not close the log file). Aside: In the long past, David Fuchs suggested changing the \closeout implementation to syntactically recognize only a <4-bit number>, as with \openout, \openin, and \closein, but Knuth decided not to do this.

A297, line -10 (#A297nextpara) 2021-07-11, Wolfgang Helbig: TeX will usually notice a missing ‘}’ at the end of the current paragraph, not “the end of the next paragraph”. Perhaps “the next end of paragraph”.

A312, answer to exercise 12.10 (#A312nolineskip) 2021-12-16, Donald Arseneau: mention that \offinterlineskip still allows page breaks between the boxes. And/or, on A331, answer to exercise 21.1: mention that \nointerlineskip prevents a page break, as the interline glue is suppressed.

A315, line 10 (answer to exercise 14.16) (#A315glueparse) 2021-04-07, Ruixi Zhang: There should be a \relax between “\rightskip=1pt” and “<text>” to avoid misparsing of following text starting with plus or minus. \relax is similarly needed in other places:

Two other cases where \relax following a glue assignment might be desirable for clarity and consistency, but since these assignments are followed by tokens that stop parsing of a glue specification, the \relax is not technically needed:

A332, line 14 (#A332exercuted) 2021-02-26, Wolfgang Helbig: Replace “exercuted” by “executed”. [Typo made in 2021, handling a report from 2017. Fixed in the 24th (July 2021) printing of The TeXbook, although the online texbook.tex file has not been updated.]

A333, A363 (#A333m@cro) 2023-09-19, Igor Liferenko: In texbook.tex, code on page 333 uses 0\p@, and on page 363, \dp\z@ and 12\p@. These should be 0pt, \dp0, and 12pt, respectively, per page 348: “we shall stick to the unabbreviated forms below, so that the macros are more readable.”

A354, \s@tcols definition has spurious space (#A354settabsspace) 2023-02-18, Udo Wermuth: the typeset description of \settabs contains the line:

\def\s@tcols#1\columns{\count@=#1 \dimen@=\hsize

That space between #1 and \dimen will be typeset in horizontal modes. The actual definition in plain.tex does not have this space.

A370, line -10 (#A370pattern) 2023-02-07, Ulrich Diez: “\pattern” should be “\patterns”.

A373, line -2 (#A373space) 2021-06-29, Igor Liferenko: In texbook.tex, page 373 has \t* (no space), while page 374 (line -7) has \t *. They are consistent (both have spaces) in the 34th printing; the discrepancy was created at the 2014 tuneup.

A377, line 6 (#A377funnyif) 2023-10-25, Igor Liferenko: In texbook.tex, page 377 says the test \if\fspace* is false. But in this case * is simply ignored during tokenization. It can be confirmed by adding another \fspace after *:

\if\fspace*\fspace\message{TRUE}\else\message{FALSE}\fi
We get TRUE. If * were not ignored, we would get FALSE.

Response: agreed; the \if is neither true nor false, but incomplete. It would work if, say, \0 were used for the name instead of \fspace. A complete runnable file extracted from The TeXbook code:

\uccode` =`*
\uppercase{\uppercase{\def\fspace{ }\let\ftoken= } }
\catcode`*=10
\loggingall
\if\fspace*\fspace\message{true}\else\message{false}\fi
\end

A463, binary operator in index (#A463binaryoperator) 2023-02-18, Udo Wermuth: searching for “binary operator” returns two hits, both in the index: one in the entry for \dagger, the other for \ddagger. These two places are the only occurrences of “binary operator”; everywhere else Knuth writes “binary operation”. (Aside: in The METAFONTbook only “binary operator” is used.)

A467ff., \halign, \ialign, \ooalign index entries 2022-10-08, Udo Wermuth: page 361 listed in the index entry for \halign does not mention it, and several useful entries could be added; there are also useful additions for \ialign and \ooalign. Specifically:


Volume B: TeX: The Program

Bvi, The TeXbook entry (#BviCT;) Dvi, The Metafontbook entry; E020, line 4 2021-06-05, Hu Yajie: Change “Computers and Typesetting” to “Computers \& Typesetting”. The series seems to be otherwise referred to consistently with the ampersand.

B071, section 173 (#B071twolevels) 2023-09-28, Tyge Tiessen: [The description here] states that the recursion of short_display is “never more than one level deep”. It should probably read “more than two levels deep” since calling it on an hlist containing a discretionary node containing a ligature will cause two recursive calls to short_display.

B076, section 185 (code) (#B076columns) 2023-02-18, Udo Wermuth: The string (word) "columns" is always used although in a \valign rows are spanned. This is done without a hint in the text (or in a comment) that the word “columns” is a simplification, as in §159.
A possible implementation of a fix: To output "columns" or "rows" in the code one could split the field glue_sign in an unset_node that is abused in alignments to store the two-bit information glue_order if glue has to shrink. If this field is split into two parts there is enough space for an indicator if the alignment is horizontal or vertical. For example, add 16 to the field in §796 if the alignment is vertical so that the glue_order is extracted in §185, §807, §810, and §811 by a mod 16. In §185 the test glue_sign(p)>15 can be used to decide if "columns" or "rows" should be output. (Test file, sample implementation.)

B130, section 305 (#B130skipping) 2022-06-12, Tyge: in the description of skipping, “a subfile can safely end here” is incorrect, as TeX complains about \outer control sequences in skipped conditional text.

B134, section 313 (#B134insertspace) 2024-02-10, Tyge Tiessen: When TeX prints the context after an error message there is a superfluous space after “<insert>” as compared to other input stack types such as “<*>”. This extra space is produced in section 313 by the code:
else print_nl("<insert> ").

Response: Accepted and will report, especially since since Metafont (mf.web line 13511) does not produce this space.

B155, section 369 (code) (#B155endwrite) 2022-06-27, user202729: \endwrite can be accessed, causing mem[0] to be dereferenced, causing a seg fault in web2c tex, or an out-of-bounds in original TeX if mem_min != 0. Fixed in web2c tex.ch. (Test file.)

B258, section 697 (#B258indent) 2023-09-27, Tyge: line 13736, if (small_fam(left_delimiter(p))<>0)or@+, should end with @| rather than @+, for consistent indentation with the right_delimiter case directly following.

B297, section 717 (#B297remainder) 2022-08-23, Eran Yarkon: mini-index entry for remainder should link to section 104 (“remainder, scaled”) instead of 543 (different remainder, from font metric file).

B326, section 777 (#B326modnameformat) 2022-06-14, Udo Wermuth: in the section name, “|preamble| list” is inconsistent with other uses of “preamble list”, which don't have the code formatting.

B344, section 817 (#B344explicitkern) 2024-01-26, David Fuchs: the position of the break can also be an explicit kern_node. Similarly, in section 879, the first sentence should say “explicit kern”, since non-explicit kern_nodes are not deleted.

B409, section 972 (#B409modnameformat) 2022-06-14, Udo Wermuth: in the section name, “is null” is inconsistent with other uses of “|null|” in the section name (e.g., section 979, “link to |null|”), which do have the code formatting.

B470, section 1128 (#B470consternation) 2023-11-02, Doug McKenna: [regarding the section title] If the error message is issued while an alignment is in progress, then it's not a “fact” that “no alignment is in progress”. A better title would be: @<Express consternation over the possibility that no alignment is in progress@>.

B524, section 1312; D510, section 1195 (code) (#B524undump) 2023-09-14, Gregory James Duck: corrupt fmt/base files can cause a crash, since the result of the addition q+node_size(q) is not checked.

Response and fix from DRF: Given that in some environments the overflow from the addition would be caught in hardware first, and even failing that, we want to catch cases where node_size was, say, bogusly the equivalent of -1 and thus q+node_size would still look valid, a fix would be:

@x
p:=q+node_size(q);
if (p>lo_mem_max)or((q>=rlink(q))and(rlink(q)<>rover)) then goto bad_fmt;
@y
if (node_size(q)>lo_mem_max-q) or (rlink(q)>lo_mem_max)
   or ((q>=rlink(q))and(rlink(q)<>rover))
then goto bad_fmt;
p:=q+node_size(q);
@z

I also added another term to catch a bad rlink(q) field.

There are all sorts of other fields that aren't checked, since it would be a hassle (such as all the |pointer| fields in all node types that have them). Still, it feels right to do this check, since a mess-up in the basic memory-allocation scheme can lead to mysterious, hard-to-find memory-corruption bugs, while other bad values in some node field will generally lead to a clear, relatively easy-to-find failure.

B548, section 1375 (code) (#B548tracingimmediate) 2021-12-17, Udo Wermuth: The one-line input file “\tracingcommands=1 \immediate\openout1=tempfile \end” writes “{vertical mode: \immediate}” in the log; no mention is made of the \openout. Same for the other commands to which \immediate applies: \write and \closeout. However, The TeXbook pages 212 and 273 indicate that \tracingcommands traces every command (emphasis added). Thus \openout, etc., should presumably be included in the trace output. A possible fix: add “if tracing_commands>0 then show_cur_cmd_chr;” after the begin of the if.

B558, index (#B558extra) 2021-06-22, Hu Yajie: in entry Extra \right., delete the period for consistency.


Volume C: The Metafontbook

C119, line 22 (#C119octants) 2023-06-07, Mike Spivey: the octant code ENE should be glossed as East-Northeast. Similarly in other cases: page 206, line -3: South-Southeast, East-Southeast; page 228, line -2: South-Southwest, West-Southwest; page 234, line 6, answer 3.1: south-southwesterly. Wikipedia listing.

C077, line -8 (exercise 9.1) (#C077lft) 2021-07-02, Igor Liferenko: part (c) asks about “lft z21 = rt z20 + 1” but this gives the error “Not implemented: (pair)+(known numeric)”. Presumably “lft z21 = rt z20 + (1,0)” is intended.

C250, line 1 (#C250hide) 2021-03-01, Hu Yajie: “hide(<statement list>)” does not allow for omitting the final semicolon in the argument to hide, since <statement list> (per C217) requires a semicolon. The semicolon to hide is optional because the replacement text (as given) provides it. The informal <statements> would apparently work, since it's used in the definition of hide on C259. (By the way, other bugs in the statement-related syntax rules were fixed in the 2020 tune-up.)


Volume D: Metafont: The Program

D040, section 101, @d quarter_unit (#D040zero) 2021-04-10, Hu Yajie: “represents 0.250000” should perhaps be “represents 0.25000”, since all the other items in the list have five decimal places.

D042, section 107 (#D042lparen) 2021-06-25, Igor Liferenko: In |@t$(2^{29}$@>*p+q), the left paren should be before the @t, to match the q). [Typo made in the 2021 tune-up.]

D131, section 289, line 2 (#D131comma) 2021-04-03, Hu Yajie: The comma at the end of the displayed fraction should not be in the denominator. That is, the whole display should be in braces except for the comma: “{...\over...},”.

D538, index (#D538indexhash) 2021-06-22, Hu Yajie: in entry Missing # (to section 1113, on page 478), the # is the web macro argument, not the character that's missing. Presumably should be merged with the entries for Missing : and Missing ,.


Volume E: Computer Modern Typefaces

E012, line -4 (#E01274) (before table) 2021-05-28, Udo Wermuth: The text says “All of the Computer Modern parameter files look like cmr10.mf, … the other 73 files …”. But there are 74 files besides cmr10; see, for example, page 10, line 1.

E012ff., parameter values (#E012cmparams) 2021-05-26, Hu Yajie:

Page  ColumnRow TypoFix
12 cmr17letter_fit -0.1-3.6
21 cmssqi8notch_cut 23/26 23/36
21 cmssqi8cap_notch_cut  23/2623/36
21 cmssq8notch_cut 23/2623/36
21 cmssq8cap_notch_cut 23/2623/36
22 cmb10cap_height 246247
22 cmbxsl10 bar_height 8785
22 cmbxsl10tiny 813
23 cmfib8cap_stem 4334
26 cmmi8fig_height 185.8185.6
26 cmmi10thin_join 7.57
28 cmu10cap_height 247246
29 cmfi10notch_cut 22/36
29 cmitt10vair_corr 1.50

E020, line 12 (#E020in) 2021-06-05, Hu Yajie: Change the “in” in “1in#” from roman to text italic, for consistency with other sharped units.

E046, line 17 (#E046sqrt) 2021-06-07, Hu Yajie: 36*sqrt(2) is 50.9…; the stated approximation of 52.3 seems unusually imprecise.

E193, line 7 (#E193ital0) 2021-06-09, Hu Yajie: The stated “copy of the program for `0' in romand” is not quite correct. romand.mf's 0 contains the equation x2r=hround max(.7u,1.45u-.5curve), whereas itald.mf's 0 has x2r=hround(1.5u-.5curve).

Similarly, E543-544 state various greekl programs are copied in tsetsl.mf, but there are differences in the source files.

E571ff. (index) (#E571indexhu) 2021-06-07, Hu Yajie.

  1. cap_notch_cut: en-dash instead of em-dash in 411—417.
  2. cmbsy10: omit page 35, which lists all the font names, but is not included in the index entries for any others, e.g., cmr10.
  3. curve: en-dash instead of em-dash in 363—449.
  4. min_Vround: perhaps sort after min_breadth.
  5. rule: spurious comma before en-dash in 521,–541.

E584, line -1 (#E584ligs) 2021-07-12, Hu Yajie: Change “the csc driver file” to “the csc driver file when ligs=1”. When the font layout depends on the ligs parameter, this has generally been indicated (cf. E581, E582, E585), so E584 should probably do the same.


Other WEB programs and sources

dvitype.web, line 2227, section 99 (#dvitypefontoutput) 2022-01-25 and 2022-01-26, Igor Liferenko: When running dvitype on a file from gftodvi, the font definitions can get mashed together, at any output level > 0. For example, dvitype io.dvi as produced from io.mf and gftodvi results in:

Font 1: cmr8Font 2: cmtt10Font 3: grayFont 5: logo8

One possible fix, also supplied by Igor (and already applied in Web2C):

@x
    begin define_font(first_par(k)); k:=nop;
@y
    begin define_font(first_par(k));
      if out_mode<>errors_only then print_ln(' ');
      k:=nop;
@z

gftodvi.web, line 3523, section 160 (#gftodvirange) 2021-04-27, Hu Yajie: The first Pascal comment should be |"/".."8"| rather than |"/"..."8"|, since Pascal ranges are specified with two dots (as in section 181).

gftype.web, line 943, section 43 (#gftypeindexhu) 2021-06-14, Hu Yajie: The index entry “@.This pixel's upper@>” should be “@.This pixel's upper...@>”, since the message is truncated, just like the index entry “@.This pixel's lower...@>” at line 925 just above.

errata.tex, entry for B21 (#errataB21) 2021-06-28, Hu Yajie: The entry for B21 in errata.tex uses a right arrow (\to), but the source uses “..”.

errata.tex, entry for C251 (#errataC251) 2021-03-01, Hu Yajie: The entry for C251 in errata.tex lacks a period after 22.1 following other errata entries. Thus: “{\bf 22.1.}\enspace”. (Aside: the output from manmac's \ansno macro has the \enspace inside the \bf group, as in “{\bf 22.1.\enspace}”, but errata.tex consistently puts the \enspace outside the group. Fine.)

mfman.mf, figure 14e labels (#mfmanfig14e) 2021-05-30, Hu Yajie: mfman.mf, lines 1272 and 1274:

labels.top(2r,2,2l, ...
labels.bot(2r,2,2l, ...

As a result, the top middle of Figure 14e has these points labeled twice. The figure is printed on page C139; it's correct there. So the error is only that mfman.mf hasn't been updated.

plain.mft, updates (#plainmft) 2021-05-29, Hu Yajie: plain.mft misspells plain Metafont's nodisplays as nodisplay. It is also incomplete. In addition to the table here, the tokens range and thru could be either in bold or roman font, but italic seems wrong.

The token should be formatted like
bye end
rotatedabout rotatedaround
div mod
define_good_x_pixels define_pixels
define_good_y_pixels define_pixels
define_whole_vertical_blacker_pixels  define_pixels
define_horizontal_corrected_pixels define_pixels
cutdraw, cutoff filldraw
pensquare, penrazor, penspeck pencircle
proofrule, makelabel, makegrid screenrule
mode_def mode_setup
penlabels labels
gfcorners screenchars

tangle.web, section 31, line 640 (#tangle31quote) 2021-06-01, Hu Yajie: The first Pascal comment should be |`\..'| rather than |'\..'|.

weave.web, section 137, long comment overflow (#weave137commentoverflow) 2023-07-16, Benjamin Gray: If an input line starts with % and has no valid breakpoints, Weave's input buffer can overflow. For example, the two line input file:

@
%\bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

results in various junk being included in the output file. One possible fix, supplied by Andreas Scherer (and already applied in Web2C):

@x l.2234
preceded by another backslash. In the latter case, a |"%"| is output at
the break.
@y
preceded by another backslash or a \TeX\ comment marker. In the latter case, a
|'%'| is output at the break.
@z

@x l.2248
  if (d="\")and(out_buf[k-1]<>"\") then {in this case |k>1|}
@y
  if (d="\")and(out_buf[k-1]<>"\")and(out_buf[k-1]<>"%") then
    {in this case |k>1|}
@z

weave.web formatting and overflow (#weaveformattingoverflow) 2023-07-19, Andreas Scherer:

Section 172.
@x l.3337
@<Change |pp| to $\max(|scrap_base|,|pp+d|)$@>;
@y
@<Change |pp| to $\max(|scrap_base|,\,|pp+d|)$@>;
@z

Section 173.
@x
@ @<Change |pp| to $\max(|scrap_base|,|pp+d|)$@>=
@y
@ @<Change |pp| to $\max(|scrap_base|,\,|pp+d|)$@>=
@z

Section 249.
@x l.4663
  begin if sort_ptr>max_sorts then overflow('sorting');
@y
  begin if sort_ptr=max_sorts then overflow('sorting');
@z

webman.tex typos (#webmantypos) 2023-07-19, Andreas Scherer:

@x l.358 Extra space in example code.
  \.{which is a \\\&\{packed\}{ }\\\&\{array\}{ }\$
@y
  \.{which is a \\\&\{packed\}{ }\\\&\{array\}{ }\$%
@z

@x l.1050 Incorrect subscript.
ASCII codes is $c_1c_2\ldots c_m$, its hash value will be
@y
ASCII codes is $c_1c_2\ldots c_n$, its hash value will be
@z
@x l.1129
ASCII codes is $c_1c_2\ldots c_m$, its hash value will be
@y
ASCII codes is $c_1c_2\ldots c_n$, its hash value will be
@z

@x l.1139 Outdated use of \U macro.
\U section~58.\fi
@y
\U58.\fi
@z

@x l.1592 Missing verb.
first change files; then you can sure that your compiler will handle
@y
first change files; then you can be sure that your compiler will handle
@z

For any discussion about these issues, or further reports to be listed here, please use the contact information on the main TeX bugs page here.


$Date: 2024/02/27 18:50:47 $;
TUG home page; webmaster; facebook; twitter; mastodon;   (via DuckDuckGo)