summaryrefslogtreecommitdiff
path: root/info/digests/tex-implementors/030
diff options
context:
space:
mode:
Diffstat (limited to 'info/digests/tex-implementors/030')
-rw-r--r--info/digests/tex-implementors/030853
1 files changed, 853 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/030 b/info/digests/tex-implementors/030
new file mode 100644
index 0000000000..ae42aa301a
--- /dev/null
+++ b/info/digests/tex-implementors/030
@@ -0,0 +1,853 @@
+Date: 8 April 91 Message No: 030
+
+To: TeX implementors and distributors
+
+From: Barbara Beeton
+
+Subject: bug reports and replies from DEK
+
+
+This message contains only one thing: a file of bug reports that was
+sent to Knuth, annotated with his replies (typed in by me from his
+handwritten notes). Please note that "sections" of this file are
+separated by form feeds (^L); I hope they don't give anyone's machine
+indigestion.
+
+
+########################################################################
+
+a quick summary of what is included here:
+ TeX.WEB 3.1
+ Brian {Hamilton Kelly}, spurious error history with |show_whatever|
+ Wayne Sullivan, non-printing characters in font identifiers
+ Eberhard Mattes, dvi files with more than 65535 pages
+ Barbara Beeton, file found by \input not found by \openin
+ PLAIN.MF
+ Harald B\"ogeholz/Eberhard Mattes, problem when aspect_ratio <> 1
+ TeXbook
+ Robert Hunt, possible bugs in \ifcat test, page 377
+ Robert Hunt, difficulty in appendix G, rule 14
+ GFtype/GF format
+ Peter Breitenlohner, GFtoPK finds an error where GFtype does not;
+ inconsistencies in GF format and programs reading/writing GF files
+ MF.WEB, PK doc
+ Edgar Fuss, precision incompatibilities
+ PLtoTF/VPtoVF
+ Wayne Sullivan/Chris Thompson, a PLtoTF/VPtoVF bug
+ TANGLE
+ Peter Breitenlohner, token memory statistic error while digesting input
+
+
+ ***** TeX.WEB 3.1 *****
+
+Date: Thu, 13 SEP 90 10:10:00 BST
+Reply-to: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk>
+From: TEX@rmcs.cranfield.ac.uk
+Subject: Feature that's really a bug in TeX v3.0 (and earlier)
+
+The routine |show_whatever| at section 1293 is invoked for any variety
+of \show primitive. Eventually, it calls |error| to complete any
+necessary interaction with the user (if desired). However, the latter
+routine:
+(1) always incrments |error_count|, and will crash with a fatal error if
+ there have been 100 ``errors''
+(2) always sets |history := error_message_issued|
+
+The code of |show_whatever| pre-decrements |error_count|, but {\em
+only\/} if not interacting with the user: therefore it's feasible that a
+file could contain 100+ \show commands, and if the user were patient
+enough, would eventually get the fatal error exit.
+
+But more importantly, more sophisticated versions of TeX which pass back
+the value of |history| to the operating system will be misled into
+thinking than a genuine error has occurred, and perhaps the operating
+system will take some (in)appropriate action.
+
+I can see two solutions:
+(1) ensure that |error_count| is always predecremented in
+|show_whatever|, and also preserve the value of |history| before calling
+|error|, and restore it afterwards: however, this sort of external
+interference with global variables is surely to be deprecated
+(2) make |error| take a parameter, which indicates whether the routine
+is being called because of a genuine error, or merely to provide an
+opportunity for interaction: this would more correctly modularize the
+funtionality, but involve changes to many dozens of other calls to
+|error| within the program.
+
+I discovered this when attempting to understand why my VMS
+implementation appeared to swallow the remainder of a DCL command
+procedure with which I was attempting to automate the TRIP test: I'd
+mistakenly thought that TeX was keeping open the |termin| which was in
+this case taking its input from the body of the command procedure. In
+the case of the TRIP test, of course, the exit status was genuinely
+correct in reporting that |error_message_issued|, and the cure was to
+tell DCL not to take error exit from the command procedure; however, in
+course of investigating this with a smaller TeX source, taken again from
+a command procedure, I realized that any \show command also caused the
+exit to occur with error status: and after all, the help for any \show
+is ``This isn't an error, I'm only showing something...''!
+
+ Brian {Hamilton Kelly}
+-------
+
+[ coment by DEK:
+ Granted, the logic isn't ideal.
+ but I was aware of these deficiencies and I don't consider them serious
+ enough to warrant any change at this late date. [METAFONT is by the way
+ exactly the same w.r.t. _showing_, except that it clears error_count
+ after statements rather than paragraphs.]
+ The patient user might indeed have a problem with more than 100 show
+ commands, but there is a way to work around it i a pinch by forcing TeX
+ to think that a paragraph has ended. Or you can type
+ `i\error\errorstopmode\show ...' then `q'.
+]
+
+Date: Wed, 05 Dec 90 15:40:28 GMT
+From: "Wayne G. Sullivan" <WSULIVAN%IRLEARN@pucc.PRINCETON.EDU>
+Subject: TeX Bug
+
+BUG REPORT TeX WEB 3.1 :
+
+In sections 234, 267, 579 and 1322 of TeX 3.1, there appears
+ print_ecs(font_id_text(...))
+ [esc -- correction by DEK ]
+or the equivalent. Since font identifiers can have non-printable
+characters, one of the slow print procedures should be used instead.
+
+ Wayne Sullivan, December 1990
+-------
+Date: Sat, 08 Dec 90 20:47:06 GMT
+From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
+Subject: Wayne Sullivan's new TeX bug
+
+FYI here are the comments I sent him, and his reply.
+
+ ----------------------------------------------------------------------
+
+You are absolutely right. Simplest test I have found that shows the
+effect (from section 267) is
+
+ \expandafter \font \csname abc^^80def\endcsname = cmr10
+ \setbox0=\hbox{XYZ} \tracingonline=1 \showbox0
+
+One gets a space where one should get ^^80.
+ [ ^^^^^ or system crash depending on system -- DEK ]
+
+I believe that you have identified all the cases that need amending.
+All other calls of |print_esc| are either on constant strings made
+up of printable ASCII, or one can prove that the variable argument
+is a string so made up. (There are three such cases: in |print_cs|
+and |sprint_cs| the calls |print_esc(p-single_base)| must refer to
+the printable ASCII representations at the bottom of the string pool;
+and in |print_write_whatsit| the argument |s| is an explicit constant
+string in each of its calls.) Given that, there would probably be a lot
+to be said for inventing a new |print_font_id| routine: one might use
+this to cover up some of the early convoluted forward references at
+the same time.
+
+Chris Thompson
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
+
+ ----------------------------------------------------------------------
+
+Knuth actually catches the important case: \the\font . However, at some
+ [^^^^^ because it fetches
+ the `permanent' font identifier which is
+ treated like any control sequence -- DEK ]
+stage it would be worth cleaning up the others. I think sprint_cs does
+the trick, but a more ornate resolution of the problem may be the
+ultimate outcome. Would you forward a copy of your note to BNB? I sent
+her the same message I sent you, but it could possibly have been missed.
+ Thanks,
+ Wayne
+-------
+
+[ comment by DEK:
+ Since print_esc is never `inner loop' I decided that it
+ should call slow_print. This saves a bit of code in \S262-3 too.
+ By the way, the reward for TeX bugs has reached its max now! So it
+ is not keeping up with inflation and the falling $/\lb ratio, sorry.
+ $326.78 \S63
+ Now slow_print is used _only_ in print_esc.
+]
+
+Date: Fri, 28 Dec 90 15:44:53 +0100
+From: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
+Subject: How to report TeX bugs
+
+Dear Ms. Beeton,
+
+I've found a very very small but old (maybe there has never been a TeX
+version without this bug!) bug in TeX. What's the correct/official way
+of reporting it?
+
+Yours,
+ Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)
+-------
+(replied that if he sent it to me, i would ask chris thompson to vet it,
+and then forward the results to dek)
+-------
+Date: Fri, 28 Dec 90 16:25:01 +0100
+From: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
+Subject: How to report TeX bugs
+
+Here's the bug (thanks for forwarding it to Chris Thompson and DEK!):
+
+total_pages isn't checked for overflow: A dvi file may contain only up
+to 65535 pages. If one feeds a document with more than 65535 pages
+into TeX, either the dvi file is written incorrectly (total number of pages
+modulo 65536 in the postamble) or TeX bombs at
+
+ dvi_out(total_pages div 256); dvi_out(total_pages mod 256);@/
+
+as dvi_out expects a eight_bits number. Maybe it's a limitation rather
+than a bug. But it should be documented.
+
+Yours,
+ Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)
+-------
+Date: Sat, 05 Jan 91 16:28:17 GMT
+From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
+To: bbeeton <BNB@math.ams.com>
+Cc: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
+Subject: DVI files with more than 65535 pages
+
+It is certainly true that TeX will generate an invalid DVI file (if
+it doesn't get a range check first---that will usually depend on
+compilation options) if more than 65535 \shipout commands are obeyed.
+What I don't know is what Don's attitude is likely to be towards this
+as a bug report. For example, he lets himself off a number of painful
+hooks in the comments in section 104:
+
+ The present implementation of TeX does not check for overflow when
+ dimensions are added or subtracted. This could be done by inserting a
+ few dozen tests of the form `if x>='10000000000 then report_overflow'
+ but the chance of overflow is so remote that such tests do not seem
+ worthwhile.
+ [ I was not thinking of PicTeX when I wrote that, but still
+ I am of the opinion that 2^{15} points aer plenty big -- DEK ]
+
+(Actually, it is quite easy to provoke such overflows deliberately, and
+I have occasionally had reports of it happening accidentally.) On the
+other hand, he did add quite a lot of code (#383) in TeX 3.0 to prevent
+demerits overflowing, which, despite what Frank Mittelbach says, I have
+some difficulty believing is a practical problem. (EM's bug is surely
+ [ ^^^^^^^^^ believe me it is! -- DEK ]
+*not* a practical problem, is it? It is certainly 100 times as many
+pages as I have ever TeX'ed at once!)
+
+Eberhard Mattes sent me a message saying, inter alia
+> here are four suggestions for fixing the bug (in decreasing order of
+> (my) preference):
+> - ignore (and document) the bug
+> - change dvi format: total_pages = 65535 means 65535 or more
+> - change dvi format: total_pages = 0 and final_bop <> -1 means
+ [ ^ This alone should suffice to
+ distinguish it in TeX output, but not other routine -- DEK ]
+> 65535 or more.
+> - error message
+
+I don't think changing the DVI specification even in this very minor
+respect is on at this stage: instead, one has to take the line that a
+valid DVI file cannot contain more than 65535 pages. The `correct' fix
+would, I think, be a fatal error (of the |overflow| type) on attempting
+to produce the 65536th page.
+
+Anyway, I think you should you send it to Don and see what he says about
+it. If he does make a TeX change as a result, I suppose I will feel an
+obligation to add a similar check to my program for merging several DVI
+file into one: it certainly doesn't at the moment!
+
+Chris Thompson
+Cambridge University Computing Service
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
+-------
+
+[ comment by DEK:
+ I decided that this isn't serious enough to warrant a
+ change to DVI format [and we do want to save trees];
+ nor to give an overflow error [which would make the TeXbook incorrect];
+ so I'll adapt Everhard's first preference, to ignore and document
+ the bug (but to put total pages need 65536 in DVI file just to
+ avoid bombing out when TeX is someday put onto a chip).
+ Surely max_push will _not_ exceed 65535 ...
+ $2.56 TeX \S642
+]
+
+Problem found at AMS by Barbara Beeton, December 1990
+
+I have a multi-file LaTeX job where i need to keep the input files
+segregated, so I simply made up a suitable search path for tex$inputs
+and worked in another directory. The main file input to LaTeX contains
+several statements \include{file.name} using the technique recommended
+in the LaTeX manual, rather than equivalent \input file.name statements.
+The indicated files are not found, but if \include is replaced by \input,
+the retrieval is successful. This is the behavior on a VAX/VMS system.
+
+LaTeX uses \openin to first check for the presence of \include'd
+files, to permit absent files to be bypassed rather than hanging the
+job.
+
+I next copied the files involved to our DEC-20, and tried again.
+Under TOPS-20, all files were found by the \include/\openin . This
+led me to believe that the problem is system-dependent. I discussed
+the matter with Dave Kellerman, whose VMS implementation we are using.
+He verified that the handling of files with \input and \openin is
+indeed quite different, and that it seems to be consistent with the
+(slender) documentation in the .WEB file. However, he said that some
+changes had been made to \input and it wasn't clear to him whether
+DEK intended to leave \openin unchanged or it was an oversight. Given
+the way that LaTeX is using \openin (which seems quite reasonable), it
+may be an oversight. This conclusion is given more weight by the fact
+that David Fuchs' TOPS-20 implementation used the search path for both
+\input and \openin even though it wasn't in the original .WEB.
+
+I sent an inquiry to Chris Thompson, and here is his analysis. This
+is an area that seems to be too easily interpreted differently by
+different implementors, and an authoritative ruling would be useful.
+-------
+Date: Sun, 06 Jan 91 00:36:53 GMT
+From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
+Subject: \input vs \include (aka \input vs \openin)
+
+The underlying difference in unmodified TeX is that \input (implemented
+in |start_input|) tries first the file name as given, and then (if the
+specified area field was empty, since fix #312) using |TeX_area| as the
+area. \openin (implemented in |open_or_close_in|), on the other hand,
+just tries the name as originally specified, leaving \ifeof<n> true
+if it can't open it. How implementors map this behaviour in terms of
+current directories, paths, or whatever their operating systems provide,
+is no doubt a rich and varied feast. (For the record, in my MVS
+implementation, the "try the default area" behaviour is mapped onto
+"if a simple name is specified, try it first as a DDname, and then as
+a member name in a standard PDS concatenation", and I do maintain the
+difference between \input and \openin.)
+
+I am fairly sure that the rationale for the difference is that \openin
+is paired with \openout (which you clearly wouldn't want to have the
+area defaulting behaviour: you want it to create the file where you
+said, if it doesn't exist already). It seems very likely that any `real'
+use of \openin, i.e. with the intention of using \read, would be reading
+a file created by \openout and \write in the current or a previous run
+of TeX.
+
+LaTeX, on the other hand, uses \openin in a much more sneaky way, to
+obtain a `softly-failing \input' function. The relevant macro, \@input,
+is used not only to read \include'd files, but also when reading back
+the .aux file(s), .toc file, etc. If the \openin fails to open the file
+(as tested by \ifeof), LateX outputs a warning message; otherwise it
+does a \closein and uses \input in the sure and certain knowledge that
+it will find the file. (This is an expensive way of doing things, in
+operating systems that make opening a file a non-trivial activity.
+It has occurred to me that there is scope for some ingenuity in TeX
+implementations in not actually doing an operating system close on
+a stream that is \closein'ed while in the state |just_open|, but
+keeping it around in the hope that a \input for the same file name
+will follow shortly! I haven't actually tried to code this, though.)
+
+With the difference between \input and \openin as in unmodified TeX,
+then it is certainly true that if \openin succeeds, so will \input
+(unless another process is deleting files in parallel, of course), but
+the converse is not true. File names passed to LaTeX's \@input have
+the semantics associated with \openin, not that associated with \input.
+
+I hadn't realised that as many implementations as you say have modified
+the file name semantics of \openin to be the same as \input. Maybe this
+is becoming a de facto standard. I am rather doubtful whether it is
+really the correct thing to do: one should not forget \openin's original
+purpose, as well as LaTeX's peculiarities. It is certainly possible to
+argue that it is a desirable change even in that context, though. I
+suppose it is too large a modification to consider at this stage the
+addition of a conditional-\input primitive to TeX itself.
+
+Chris Thompson
+-------
+
+[ comment by DEK:
+ My current opinion is:
+ If the operating system allows users to define a ``custom''
+ search path at run time, then both \input and \openin
+ should be able to use it, although I would hope that
+ people don't use \openin for `system' files but only for files
+ they tend to control themselves.
+ If the operating system is like WAITS (on which I developed TeX),
+ where there's no decent way to provide a clue to TeX at runtime
+ about a nonstandard search path, then I would provide access
+ to the main system macro files (like plain.tex and
+ webmac.tex) only for \input not \openin; I would
+ use the same strategy to search user's personal files
+ for both \input and \openin.
+ I have found it _very_ useful with UNIX to put `..' on the
+ standard search path. Then I can create a subdirectory
+ called say _pages_ and cd to pages, on which I can
+ run TeX/MF with some temporary changes to input fies and I won't
+ clobber any of the master files or the parent directory.
+ My applications of this idea would fail if \openin didn't
+ also look at .. directory when unable to find an . directory.
+
+ ***** PLAIN.MF *****
+
+Date: Mon, 7 Jan 91 11:38:54 +0100
+From: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
+To: CET1@phoenix.cambridge.ac.uk
+Cc: BNB@math.ams.com
+Subject: Now a real bug
+
+Dear Ms. Beeton, dear Mr Thompson,
+
+now I am reporting a real bug:
+
+plain.mf:
+
+ ----------------------------------------------------------------------
+def drawdot expr z = if unknown currentpen_path: def_pen_path_ fi
+ addto_currentpicture contour
+ currentpen_path shifted z.t_ withpen penspeck enddef;
+ ----------------------------------------------------------------------
+
+does not work correctly with aspect_ratio <> 1. Here's a fix:
+
+ ----------------------------------------------------------------------
+def drawdot expr z = if unknown currentpen_path: def_pen_path_ fi
+ addto_currentpicture contour
+ currentpen_path shifted (z.t_) withpen penspeck enddef;
+ ----------------------------------------------------------------------
+
+BTW, local.mf of emTeX has been containing this fix for over a year,
+and nobody reported this bug. It was found by Harald B\"ogeholz (HWB),
+ [ ^^^^^^^^^^^^^^^^^^^^^^^
+ $2.56 MFbook p271 -- DEK ]
+a friend of mine.
+
+Yours,
+ Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)
+-------
+Date: Mon, 07 Jan 91 15:29:24 GMT
+From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
+To: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.dbp.de>
+Cc: Barbara Beeton <BNB@math.ams.com>
+Subject: Re: [Now a real bug]
+
+Dear Eberhard, & Barbara,
+
+Yes, I agree with that: the bracketing should be
+
+ currentpen_path shifted (z transformed currenttransform)
+
+not, as effectively at present,
+
+ (currentpen_path shifted z) transformed currenttransform
+
+Will you pass that on the Don Knuth, Barbara?
+
+I have sometimes wondered why mode_setup doesn't make t_ into a dummy
+symbolic token when currenttransform (after yscaling by aspect_ratio)
+is the identity, in the same way as o_ is redefined. This would save
+some time in common cases; currently you have to use 'notransforms'
+yourself to achieve it. I suppose it would be an incompatible change
+by now, though, in that METAFONT users may be relying on being able
+ [ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ yes indeed indeed -- DEK ]
+to alter currenttransform at any time.
+
+Chris Thompson
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
+-------
+
+ ***** TeXbook *****
+
+Date: Mon, 21 Jan 91 17:07:05 GMT
+From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
+Subject: TeXbook p.377 bug(?)
+
+ I have had what apparently looks like an error in the TeXbook
+reported to me by a user here, Robert Hunt <reh10@phx.cam.ac.uk> of
+the Department of Applied Maths and Theoretical Physics. He claims
+that in the macro in the footnote on page 377 of the TeXbook, the
+\ifcat test
+
+ \ifcat\noexpand#1\noexpand~\explicitfalse % active funny space
+
+can never give the result true, so that the line is unnecessary (and
+misleading). I think he is right, but this area of TeX is distinctly
+unsusceptible to intuition! I intend to advertise on UKTeX and TeXhax
+a challenge to find arguments to \stest that will make this \ifcat
+deliver true; meanwhile could you please record that Robert has a
+first claim if this does indeed turn out to be a TeXbook bug?
+
+Chris Thompson
+-------
+
+[ comment by DEK:
+ $2.56 He is correct that the test never succeeds
+ but he is wrong to assume that it is unnecessary ...
+ The present code has a bug (it might say that an active
+ implicit funny char is explicit) as in
+ \uccode`=`*\catcode`*=\active
+ \uppercase{\uppercase{\let*=}}
+ \newtoks\t \t={*123}
+ which leads to the
+ \global\explicittrue branch.
+ TeXbook 20\th printing will have corrected code, namely
+ \long\def\ssss#1#2\stest{\funnytrue
+ {\uccode`#1=`~
+ \uppercase{\ifcat\noexpand#1}%
+ \noexpand~\global\explicitfalse
+ \else\escapechar ... \fi\fi}}
+ which makes the points I had hoped to make in the original
+ footnote and preserves the idex entries to {\it 377}.
+ I suspect this will be the all-time champ for obscure bug in
+ The TeXbook ... But that's the whole point of this footnote.
+]
+
+Date: Sun, 27 Jan 91 22:08:12 GMT
+From: Chris Thompson <CET1@phoenix.cambridge.ac.uk>
+Subject: Another TeXbook error (or obscurity)
+
+Robert Hunt (he of the p.377 example) has come up with another (sigh)
+possible TeXbook error. I think his case is pretty good on this one.
+He asks why [ p 444 ]
+
+ \setbox0=\hbox{$V.$}\showbox0
+
+produces
+
+ > \box0=
+ \hbox(6.83331+0.0)x9.16667
+ .\teni V
+ .\kern2.22223 (this is the italic correction for \teni V)
+ .\kern-1.66667 (this is the kern between the V and the .)
+ [ ^^^^^^^ oops, maybe I should have made this more negative ...
+ too late -- DEK ]
+ .\teni :
+ .\mathoff
+
+when Appendix G, Rule 14 says:
+
+ Otherwise if the font information shows a kern between the current
+ symbol and the next, insert a kern item after the current Ord atom
+ and move to the next item after that. Otherwise (i.e., if no
+ ligature or kern is specified between the present text symbol and
+ the following character), go to Rule 17.
+
+and Rule 17 is the only place where italic corrections are added. The
+ [ ^^^^ also, \fontdimen 2\teni is zero, so we get
+ ital correction in spite of being marked as text -- DEK ]
+phrasing `move to the next item after that' makes it sound as though
+processing for the current item is complete. In fact, one should always
+go to Rule 17 (this applies to ligatures as well, for which the phrasing
+is now, since TeX 3.0 changes, quite ambiguous in Rule 14). The code
+has always actually worked like that, and in fact it wouldn't make sense
+to abandon the Ord before the kern at this stage, as its translation
+into a horizontal list, needed for the second pass, has not yet been
+generated.
+
+Chris Thompson
+-------
+ [ $2.56 right, I'll try to clean this up too -- DEK ]
+
+ ***** GFtype/ GF format *****
+
+Date: 18 September 1990, 16:34:53 GMT
+From: PEB%DM0MPI11.BITNET@CUNYVM.CUNY.EDU
+From: Peter Breitenlohner (089) 32308-412 PEB at DM0MPI11
+
+Barbara, can you please relay the following to Don Knuth. Thanks P.B
+
+Subject: Clarification of GF format and proposed GFtype change.
+
+If I interpret the GF format correctly, it is an error if there
+are raster data for a character c (mod 256) and there is no character
+locator for character c in the postamble. It is also an error if
+there are two or more locators for the same character.
+(At least GFtoPK treats these cases as errors.)
+
+If this is correct then it should be specified explicitely in the
+definition of the GF format (in MF, GFtype, GFtoDVI, and GFtoPK).
+ [ I believe it is explicit enough, and
+ fixing GFtype will clinch it -- DEK ]
+Moreover GFtype should test for such anomalies. I find it extremely
+embarrassing that GFtoPK declares such a file as bad whereas GFtype
+[ ^^^^^^^^^^ Well, I am even more embarrassed, since I wrote GFtype -- DEK ]
+does not detect anything unusual.
+
+Another point: GFtype cannot handle specials (xxx or yyy) in the
+postamble. Clearly MF does not produce them but they are allowed in
+the GF format. This is, however, slightly more tedious to fix.
+ [ mistake in documentation. They are allowed within
+ characters but not before _pre_ or after _post_ -- DEK ]
+
+Therefore I propose the following change in GFtype.web (line numbers refe
+to Version 3.0 as of November 5, 1989).
+
+@x [8] m.64 l.1213 - test for missing character locators
+@.should be postpost@>
+@y
+@.should be postpost@>
+for k:=0 to 255 do if char_ptr[k]>0 then
+ error('missing locator for character ',k:1,'!');
+@.missing locator for character...@>
+@z
+%---------------------------------------
+@x [8] m.64 l.1228 - superfluous semicolon
+ error('not enough signature bytes at end of file!');
+@y
+ error('not enough signature bytes at end of file!')
+@z
+%---------------------------------------
+@x [8] m.65 l.1250 - test for duplicate character locators
+ if p<>char_ptr[c] then
+ error('character location should be ',char_ptr[c]:1,'!');
+@.character location should be...@>
+@y
+ if char_ptr[c]=0 then
+ error('duplicate locator for this character!')
+@.duplicate locator for this...@>
+ else if p<>char_ptr[c] then
+ error('character location should be ',char_ptr[c]:1,'!');
+@.character location should be...@>
+ char_ptr[c]:=0;
+@z
+%---------------------------------------
+@x [8] m.65 l.1255 - superfluous semicolon
+until k<>no_op;
+@y
+until k<>no_op
+@z
+%---------------------------------------
+Regards Peter Breitenlohner
+-------
+
+[ comment by DEK:
+ Peter!
+ I _really_ appreciate your help in getting these
+ programs into tiptop shape.
+ You are able to imitate my programming style
+ better than I can myself -- don
+]
+
+ ***** MF.WEB, PK doc *****
+
+Date: Thu, 23 Aug 90 17:21:05 +0200
+From: ef@tools.uucp (Edgar Fuss)
+Subject: MF/PK Documentation errors
+
+There is a documentation error (I think) in mf.web.
+The section on scaled arithmetic says something like ``most internal
+quantities MF deals with are supposed to be less than 4096 in absolute
+value'' and then introduces the |fraction| type which has 28 binary digits
+right to the binary point. In my opinion, on a 32-bit machine, you can only
+represent values smaller than 4 in absolute value that way.
+(However, the |angle| type introduced later on indeed has 20 digits of
+precision and can hold values up to 2048-\epsilon.)
+ [ * ]
+
+There is another bug in the description of the PK format that appears in
+various WEB sources (PKtoPX, for example).
+The definition of the |pre| command says that the |ds| parameter is the
+ [ ^^^ post -- DEK ]
+font's design size in units of 2^{-16} points. However, what GFtoPK really
+puts there is the design size in units of 2^{-20} points.
+This error really bit me last week (is my DVI the only device driver that
+cares about design sizes and checksums?).
+There are also a few errors in the same file where the meaning of various
+flag bits are explained; the bit numbers and bit weights don't match,
+I think, in genearal, the numbers are right and the weights are wrong.
+ [ ** ]
+
+Edgar
+-------
+
+[ comment by DEK:
+ * You are misinterpreting the comment in \S105.
+ In \S101 it points out that _scaled_ numbers have 16 binary places
+ If such numbers are < 2^{12}, that means we have 28 bits.
+ To work with 28 significant bits its convenient to have a _fraction_
+ type as well as a _scaled_ type. Fractions have 28 binary places.
+ Therefore `fractions' can get as large as $8-\epsilon$.
+ ** I know nothing about PKtoPX (and I want PXL files abolished immediately)
+ but I have been involved with GFtoPK, and it's documentation is
+ currently correct ... sice November 89 at least. ... Yes we had to
+ fix it in many respects! Please get up to date sources.
+ Tom Rokicki's dvips driver is now extremely careful with
+ design sizes and checksums, since I rewrote it in 1989.
+]
+
+ ***** PLtoTF/VPtoVF *****
+
+Date: Fri, 11 Jan 91 14:08:16 GMT
+From: CET1@phoenix.cambridge.ac.uk
+Subject: A PLtoTF/VPtoVF bug for Don from Wayne
+
+Barbara,
+
+Please could you forward the enclosed to Don Knuth?
+
+> Accepted: 14:48:12 10 Jan 91
+> From: "Wayne G. Sullivan" <WSULIVAN@EARN.IRLEARN>
+> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX>
+> Subject: A minor blemish in PLtoTF
+>
+> (DESIGNSIZE R 10.0)
+> (DESIGNUNITS R 15.1)
+> (FONTDIMEN
+> (SLANT R 0.00000000)
+> (SPACE R 10.0)
+> (XHEIGHT R 7.5)
+> (QUAD R 20.0)
+> (EXTRASPACE R 15.0))
+> (CHARACTER C A
+> (CHARWD R 241.6)
+> )
+>
+> (COMMENT
+> If the above file is fed to PLTOTF and the resulting TFM file is
+> processed by TFTOPL the result is
+> (FAMILY UNSPECIFIED)
+> (FACE F MRR)
+> (CODINGSCHEME UNSPECIFIED)
+> (DESIGNSIZE R 10.0)
+> (COMMENT DESIGNSIZE IS IN POINTS)
+> (COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE)
+> (CHECKSUM O 32455153636)
+> (SEVENBITSAFEFLAG TRUE)
+> (FONTDIMEN
+> (SLANT R 0.0)
+> (SPACE R 0.662251)
+> (STRETCH R 0.0)
+> (SHRINK R 0.0)
+> (XHEIGHT R 0.496689)
+> (QUAD R 1.324503)
+> (EXTRASPACE R 0.993378)
+> )
+> (CHARACTER C A
+> (CHARWD R 0.0)
+> )
+> Note that the character width is zero, but no error message is
+> given. This is machine dependent because of floating point
+> arithemtic, but the computed value comes from 253335962 / 15833498
+> which is less than 16.0 but rounds to the scaled equivalent of 16.0.
+> )
+ -----------------------------------------------------------------------
+> Submitted: 15:28:45 10 Jan 91
+> From: Chris Thompson <CET1>
+> To: "Wayne G. Sullivan" <WSULIVAN@EARN.IRLEARN>
+> Subject: Re: [A minor blemish in PLtoTF]
+>
+> Yes, agreed. |out_scaled| is defective in that the failure of test
+> |abs(x/design_units)>=16.0| does not necessarily mean that
+> |round((x/design_units)*1048576.0)| will deliver a value strictly
+> less than 2^24. In your case there is a subsequent call of |out(256)|,
+> which will blow up or quietly produce zero as compilation options or
+> runtime routines determine.
+>
+> Shall I send it to Barbara for inclusion on Don's work list?
+ -----------------------------------------------------------------------
+> Submitted: 09:50:34 11 Jan 91
+> From: "Wayne G. Sullivan" <WSULIVAN@EARN.IRLEARN>
+> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX>
+> Subject: out_scaled
+>
+> I believe the same out_scaled routine apears in VPtoVF. The problem with
+> 16.0 is highly unlikely to cause problems in practice, but since these
+> WEB files are considered as patterns of good software, it would seem to
+> be in order to sort out the problem whenever there is a revised version of
+> PLtoTF or VPtoVF. I would appreciate it if you would pass it on in the
+> proper manner.
+> I noticed the 16.0 problem when I was trying to figure out how 'shorten'
+> works in connection with using PostScript resident fonts with TeX. The
+> limitations of TFM files can have side effects. In the new character
+> mapping for 256 character fonts given in Ferguson's article (TUG-11/4)
+> a zero width character for inhibiting ligatures is included. It is
+> possible, though unlikely, that after 'shorten' has been applied, that
+> this character will no longer have zero width. It might be a good idea
+> to make the 'rounding' message a bit more forceful to encourage further
+> checks when rounding of character dimensions is necessary.
+> Wayne
+
+Chris Thompson
+JANET: cet1@uk.ac.cam.phx
+Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
+-------
+
+[ comment by DEK:
+ I guess you're right, but only if all 256 widths are different
+ _and_ the closest two widths happen to be between 0 and something
+ very near 0!
+ The main side effects I've ever noticed were in connection with
+ math extension font ... it is very important not to diddly with
+ height or depth of characters used to build up large parens etc.
+
+ PLtoTF version 3.4 \ have out_scaled
+ VPtoVF version 1.3 / more robust!
+ Thanks again don
+ ?
+ Interestingly if you had had R-241.6
+ the output would have contained R-16.0
+]
+
+ ***** TANGLE *****
+
+Date: Fri, 01 Mar 91 13:08:38 GMT
+From: Peter Breitenlohner <PEB%DM0MPI11.BITNET@CUNYVM.CUNY.EDU>
+Organization: Max-Planck-Institut fuer Physik, Muenchen
+Subject: patgen and tangle
+
+[ while i was in vienna at the dante meeting, i talked with peter about
+ the maintenance of various ur-tex-utilities, in particular patgen.
+ i couldn't say who, if anyone, is currently responsible for patgen
+ maintenance. can you shed any light on this? ]
+ [ This has been up for grabs ever since Frank finished his
+ thesis. All volunteers welcome to step up and advertise
+ their presence. -- DEK ]
+
+I found a bug in tangle. If there is a fatal error in phase on (i.e.,
+while digesting the input), the token memory usage statistic is garbage.
+This is particularly annoying if the fatal error is token memory overflow
+(as it happened to me).
+
+Below is my proposed bug fix, line numbers refer to
+ TANGLE.WEB 4.1 as of September 5, 1990.
+
+@x [18] m.186 l.3272 - bug fix: initialize max_tok_ptr
+print(' bytes, ', max_tok_ptr[0]:1);
+@y
+if phase_one then
+ for ii:=0 to zz-1 do max_tok_ptr[ii]:=tok_ptr[ii];
+print(' bytes, ', max_tok_ptr[0]:1);
+@z
+%---------------------------------------
+
+Regards Peter
+-------
+
+[ comment by DEK:
+ Thanks Peter for excellent diagnosis & correction.
+ Will be fixed in v4.2. -- don
+]
+
+
+########################################################################
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% 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 030 ]
+-------
+