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
************************************************************************