diff options
author | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
commit | 5f1cfa686748068fedb95d8dafda3dc7f999c948 (patch) | |
tree | 874fa8430be12fe4633924f3b707428170316a46 /info/digests/tex-implementors/message.30 | |
parent | 8982c52e00ffb3fb5a913fc60913ebd9070f091a (diff) |
CTAN sync 202105270301
Diffstat (limited to 'info/digests/tex-implementors/message.30')
-rw-r--r-- | info/digests/tex-implementors/message.30 | 853 |
1 files changed, 853 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/message.30 b/info/digests/tex-implementors/message.30 new file mode 100644 index 0000000000..ae42aa301a --- /dev/null +++ b/info/digests/tex-implementors/message.30 @@ -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 ] +------- + |