summaryrefslogtreecommitdiff
path: root/info/digests/tex-implementors/message.39
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2021-05-27 03:01:40 +0000
committerNorbert Preining <norbert@preining.info>2021-05-27 03:01:40 +0000
commit5f1cfa686748068fedb95d8dafda3dc7f999c948 (patch)
tree874fa8430be12fe4633924f3b707428170316a46 /info/digests/tex-implementors/message.39
parent8982c52e00ffb3fb5a913fc60913ebd9070f091a (diff)
CTAN sync 202105270301
Diffstat (limited to 'info/digests/tex-implementors/message.39')
-rw-r--r--info/digests/tex-implementors/message.39684
1 files changed, 684 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/message.39 b/info/digests/tex-implementors/message.39
new file mode 100644
index 0000000000..8dd5efb829
--- /dev/null
+++ b/info/digests/tex-implementors/message.39
@@ -0,0 +1,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 ]
+