From e0c6872cf40896c7be36b11dcc744620f10adf1d Mon Sep 17 00:00:00 2001 From: Norbert Preining Date: Mon, 2 Sep 2019 13:46:59 +0900 Subject: Initial commit --- info/digests/tex-implementors/message.13 | 205 +++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) create mode 100644 info/digests/tex-implementors/message.13 (limited to 'info/digests/tex-implementors/message.13') diff --git a/info/digests/tex-implementors/message.13 b/info/digests/tex-implementors/message.13 new file mode 100644 index 0000000000..fc14f3077a --- /dev/null +++ b/info/digests/tex-implementors/message.13 @@ -0,0 +1,205 @@ +Received: from robin by clan.nott.ac.uk id aa02511; 3 Mar 89 9:53 PST +Received: from nss.cs.ucl.ac.uk by much.Cs.Nott.AC.UK id aa17670; + 3 Mar 89 17:50 GMT +Received: from vax02.ams.com by NSS.Cs.Ucl.AC.UK via Satnet with SMTP + id aa08564; 3 Mar 89 16:30 GMT +Date: Fri 3 Mar 89 10:58:54-EST +From: bbeeton +Subject: Announcement of TeX 2.96-2.98; other details +To: TeX-implementors@vax02.ams.com +Message-ID: <604943934.0.BNB@VAX02.AMS.COM> +Mail-System-Version: + +Date: 3 Mar 89 Message No: 013 + +To: TeX implementors and distributors + +From: Barbara Beeton + +Subject: Announcement of TeX 2.96-2.98; other details + + +Some of you are already aware that there exist versions of TeX beyond +2.95. Although I have had that information for some time, lack of time +and hardware problems have prevented me from obtaining all the details +and sending them out to you. This morning I received from Don Knuth a +report that another bug has been found and fixed, bring the version to +2.98. Since I am leaving tomorrow morning for a week of standards +meetings (where I will not have any computer access), and don't have +time before I leave to retrieve the details from Knuth's computer, I +will instead include Knuth's description of the reasons for the changes, +and promise to send the details as soon as possible after I return. + +In one of the last few messages, there was a reference in the ERRATA.TeX +extracts to an item, dated 12/23/88, that hadn't been sent to you. The +missing errata are listed below, incorporating the item of 1/4/89 that +cited the missing one. Needless to say, the additional bug fixes will +involve more errata; those will be sent along with the bug details. + + +######################################################################## + +Knuth's descriptions of the changes + +2.96: + + [ I can't find the message from Knuth notifying me of the + update, but this is the information line in TEX.WEB. ] + + % Version 2.96 corrects bug in "Infinite shrinkage" recovery (January 1989). + + +2.97: + + In TEX.WEB, there are one too many instances of: + @.End of file on the terminal@> + + ... when I created version 2.95 in December, I made a bunch of changes + to ERRATA.TEX etc but I left out the most important change to TEX.WEB + itself! Namely, consider the following excerpt from TEX82.BUG[tex,dek]: + +349. By popular request, undo #347 and fix the bug a more complex way. +@x module 71 [this undoes change #347] +if not input_ln(term_in,true) then t_open_in; +@y +if not input_ln(term_in,true) then fatal_error("End of file on the terminal!"); +@z +@x [and there's a lot more] + + Well, I forgot to install that. So the index was right, but not the + program... At SAIL, I'm unable to test EOF on the terminal. + + *** Folks, please excuse this dreadful oversight. The maintainers of TeX + must think I'm completely off my rocker. I have now fixed TEX.WEB at + SAIL, but not at SCORE or anywhere else. I've changed the version number + to 2.97 simply because there exist versions 2.95--2.96 in which this typo + is present. Version 2.97 is version 2.96 the way I thought 2.96 was. + (I also changed the version numbers in INITEX.CH and TRIP*.) + + +2.98 + + Frank Mittelbach and Rainer Schoepf of Gutenberg's city (Mainz) have + discovered the following bug: If you say simply + \aftergroup\relax\dump + to INITEX, you get a spurious error message (one that David Siegel + used to tell me was pretty funny). + + It was very easy to fix this bug, although I did have to change + TRIP.TEX as well as the other TRIP* files in order to make TRIP + verify its absence. + + Another $163.84; am I really going to be able to double the amount + of reward next year? + + +other questions: + +Wayne Sullivan sent the following inquiry about possible bugs in 2.95: + + I think I have found two 'bugs' in TeX 2.95, athough it would be more + apt to call them 'mites' rather than bugs, for they have no effect on + practically all existing installations of TeX. The first is that there + is to my knowledge no fixed limit on the actual size of font_area or + font_name for a given font. If either of these exceeded 255 bytes in + length, the an invalid DVI file could result. The second is that + get_strings_started calls make_string before the value of init_str_ptr + is set. In the event of overflow, init_str_ptr is used before it has + been defined. + +Knuth's reply: + + ... I looked at this and decided they were NOT bugs. + + 1) We could make TeX guarantee that font area and font name be at most + 255 bytes long, by putting the following code into module 560 just + after "g\gets null_font": + if (length(nom)>255) or (length(aire)>255) then + begin print_err("Font name too long"); + help1("I've substituted \nullfont for a weird font name."); + error; goto done; + end; + But, the DVI problem could arise only if TeX was able to read a valid + TFM file with an unreasonably long name and area. If we assume that the + operating system doesn't break, nobody would be able to use this font + anyway from a DVI file, so I claim such a TFM file will never exist in + a real system. + + 2) It's true that INITEX uses string_vacancies to abort with an + understandable error message if the implementor has set pool_size too low, + while INITEX can abort strangely if the implementor has set max_strings + too low. (The problem in that case is even worse than Mr Sullivan imagines: + The string "number of strings" may not even be present, nor would its + array index necessarily be valid.) But an implementor who is that stupid + doesn't deserve having his hand held.... + + I conclude that no changes to 2.95 are needed (yet). + + +######################################################################## + +Extracts from ERRATA.TeX (differences effective Dec 88) + +;COMPARISON OF PS:ERRATA.TEX.17 AND PS:ERRATA.NEW.2 +;OPTIONS ARE /3 + +**** FILE PS:ERRATA.TEX.17, 4-34 (21096) +\bugonpage C262, line 15 (11/6/88) + +\ninepoint\noindent +|string base_name, base_version; base_name="plain"; base_version="1.6";| +**** FILE PS:ERRATA.NEW.2, 4-34 (21096) +\bugonpage C262, line 15 (12/23/88) + +\ninepoint\noindent +|string base_name, base_version; base_name="plain"; base_version="1.7";| + +\bugonpage C271, line 12 (1/4/89) + +\ninepoint\noindent +the user and \MF's primitive picture commands. +First, some important program\cutpar + +\bugonpage C271, line 4 from the bottom (12/23/88) + +\ninepoint\noindent +|def |^|cutdraw|| expr p = % caution: you may need autorounding=0| + +\bugonpage C272, lines 5 and 6 (12/23/88) + +\ninepoint\noindent +| (cut_ scaled (1+max(pen_lft,pen_rt,pen_top,pen_bot))|\par\noindent +| rotated theta shifted z)t_;| + +\bugonpage C273, lines 20 and 22 (9/26/88) +*************** + +**** FILE PS:ERRATA.TEX.17, 4-45 (21435) +\bugonpage C331, just below the illustration (7/18/87) +**** FILE PS:ERRATA.NEW.2, 4-56 (21754) +\bugonpage C290, line 6 from the bottom (12/23/88) + +\ninepoint\noindent +(2)~A throwaway variable, +`\\{whatever}', nullifies an unwanted equation at the beginning\cutpar + +\bugonpage C331, just below the illustration (7/18/87) +*************** + +**** FILE PS:ERRATA.TEX.17, 4-57 (21758) +\bugonpage C350, left column (7/6/88) +**** FILE PS:ERRATA.NEW.2, 4-74 (22253) +\bugonpage C346, entry for {\tt autorounding} (12/23/88) + +\eightpoint\indent\hskip20pt +212, {\it262}, {\it264}, 271--272. + +\bugonpage C350, left column (7/6/88) +*************** + + +######################################################################## + + +[ end of message 013 ] +------- -- cgit v1.2.3