10-Jul-90 08:26:45-MDT,1477;000000000001 Return-Path: <@MATH.AMS.COM,@NSFnet-Relay.AC.UK:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by science.utah.edu with TCP; Tue 10 Jul 90 08:26:33-MDT Received: from NSFnet-Relay.AC.UK by MATH.AMS.COM via SMTP with TCP; Tue, 10 Jul 90 10:11:02-EDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa10816; 10 Jul 90 14:33 BST Date: Tue, 10 Jul 90 15:01:03 BST From: Chris Thompson To: tex-implementors@math.ams.com Subject: A bug in TeX 3.0 Message-ID: I gave the details of the following bug to Barbara Beeton a few weeks ago, and I believe she has passed it on to Don Knuth, but we don't seem to have an official fix number for it yet. As it seems completely uncontentious (to me, anyway!) I think that tex-implementors should know about it. The following initialisations, which should have been added since TeX 2.992, are missing from section 552: bchar_label[null_font]:=non_address; font_bchar[null_font]:=non_char; font_false_bchar[null_font]:=non_char; The last two may not actually be necessary, although they can certainly do no harm. However the absence of the first can cause various nasty effects if an attempt is made to typeset a character from \nullfont: random locations in |font_info| get interpreted as a kern/ligature program. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk 27-Jul-90 20:17:42-MDT,1903;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Fri 27 Jul 90 20:17:40-MDT Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 27 Jul 90 22:20:14-EDT Date: Fri, 27 Jul 1990 15:21 PDT From: Don Hosek Subject: VMS TeX tape from Maria Code To: tex-implementors@math.ams.com Message-id: X-Envelope-to: tex-implementors@math.ams.com X-VMS-To: in%"tex-implementors@math.ams.com" A twofold message: First, I'd like to let you know that I've made the necessary arrangements and come September, people ordering VMS TeX will be getting TeX 3.0 and other up-to-date files. Second, the distribution is limited to a 1200' reel (they can do 2400', but prefer the smaller size) at 1600bpi. I'll need to do some experiments to see exactly what that translates to in VMS blocks, to see exactly what I can fit on the tape, but at present this is what I anticipate putting on it: (in order of decreasing priority). WEB sources for TeX, WEB, MF, TeXware, MFware Basic TeX input files Basic MF input files Standard LaTeX files Mainz LaTeX files (eventually these will be part of the above section) CM font sources BibTeX and standard BibTeX styles Makeindex DVIOUT (PostScript driver) (unless anybody has a better PS driver) DVItoVDU (Previewer for graphics terminals) DVILN03 (Brian Hamilton Kelly's version) XDVI (X previewer) (unless DVIDecwindows--on its way--is better) AmSTeX and AmSfonts sources Contributed LaTeX files Contributed BibTeX files Contributed Plain TeX files I'll be very surprised if I make it this far... Various foreign language support files (from the Babel tree at ymir) Other TeX macro packages and random MF fonts. Nelson Beebe's driver family etc. Any comments on the priorities, etc.? -sh 14-Aug-90 14:19:44-MDT,9297;000000000011 Return-Path: Received: from MATH.AMS.COM by science.utah.edu with TCP; Tue 14 Aug 90 14:19:32-MDT Date: Tue 14 Aug 90 16:06:22-EST From: bbeeton Subject: Some corrections; TFtoPL 3.1; catching up To: TeX-implementors Message-ID: <650664382.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 14 Aug 90 Message No: 026 To: TeX implementors and distributors From: Barbara Beeton Subject: Some corrections; TFtoPL 3.1; catching up I started putting this message together in April, but was interrupted and never sent it. Fortunately, there has not been too much activity in the intervening months that has required new versions of TeX/ware and MF/ware to be retrieved and installed; however, I recently received a message from Knuth saying that he expected to spend some of August tending to his TeX correspondence, so it's time to clear the decks. It was called to my attention that some lines in difference listings in these messages have been corrupted. Below are corrections as necessary. The corrected passages include the complete difference segments, not just individual lines. Please replace the offending segments as appropriate. (Note that if you received andy of the affected messages after the initial mailing, the original files have been corrected.) A short explanation may be useful. I use the TOPS-20 SRCCOM program to generate the difference lists. This program has a couple of flaws (it omits blank lines, for example), but it has the virtue that it does not extend lines beyond their original length, unlike the VMS DIF program, which is the only other option available to me. This makes for more reliable transmission across network gateways. After creating and validating a difference file, I transfer it to a VAX for construction of the message and mailing. This sometimes runs afoul of a TOPS-20/VMS imcompatibility, namely that the DEC-20 is a 36-bit-word machine, and ascii is packed at 5 characters to a word with one slack bit. If the slack bit happens to be turned on, that word will be lost in the 20-to-VAX transfer. In the examples corrected here, I forgot to take one more step, namely running the difference files through a program that turns off all slack bits. I realize there are undoubtedly better tools available to do this job automatically, but the local systems programming staff hasn't come up with any. Apologies for any problems caused by these errors. Although it's probably general knowledge by now, having been posted to TeXhax, Karl Berry is now "more or less maintaining" web2c. To quote his most recent message to me, "the port for TeX 3.0 and Metafont 2.0 is released, and now on ics.uci.edu and labrea.stanford.edu, as well as in Europe." Any questions can be sent to Karl at karl@cs.umb.edu on CSnet. The afore-mentioned TOPS-20 machine is scheduled to be unplugged at the end of the year. One of my biggest jobs is to migrate all the Math Society's TeX archives and records from the 20 to the VAX, and I'm spending every spare moment on that. In the process, I keep finding things that should have been announced here, so I will announce them, regardless of how late. For a start, TFtoPL was upgraded to version 3.1 last November. Differences between versions 3.0 and 3.1 below. Oren Patashnik has announced the availability of a set of TeX macros that make BibTeX work with plain TeX; the message to TeXhax will be distributed in due course, but here's a copy of the advance notice he sent me: Date: Tue, 14 Aug 1990 10:19:50 PDT From: Oren Patashnik To: texhax@cs.washington.edu Subject: BibTeX-for-plain-TeX macros There is now distributed with BibTeX a set of TeX macros that makes BibTeX work with plain TeX (and presumably with other macro packages that don't deviate too far from plain TeX). The file is btxmac.tex, stored on Labrea.Stanford.EDU's BibTeX area (pub/tex/bibtex). --Oren Patashnik Finally, it's now been about four months since I last sent a message to this list, and quite a few address changes have been made. Please help out by acknowledging receipt. (I should hear about the bounces sooner than I'd like to.) ######################################################################## Corrections to differences between WEBMAC.TEX versions 1.4 and 4.0 (message #25) **** FILE TX:WEBMAC.CM.1, 1-62 (2808) \def\A{\note{See also}} % cross-reference for multiply defined section names \def\B{\mathopen{\.{@\{}}} % begin controlled comment **** FILE TX:WEBMAC.TEX.1, 1-62 (2843) \def\A{\note{See also section}} % crossref for doubly defined section name \def\As{\note{See also sections}} % crossref for multiply defined section name \def\B{\mathopen{\.{@\{}}} % begin controlled comment *************** **** FILE TX:WEBMAC.CM.1, 1-186 (9074) \def\U{\note{Used in}} % cross-reference for uses of sections \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} **** FILE TX:WEBMAC.TEX.1, 1-190 (9406) \def\U{\note{Used in section}} % crossref for use of a section \def\Us{\note{Used in sections}} % crossref for uses of a section \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} *************** ######################################################################## Differences between TFtoPL.WEB versions 3.0 and 3.1 ;COMPARISON OF TX:TFTOPL-30.WEB.1 AND TX:TFTOPL-31.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TFTOPL-30.WEB.1, 1-15 (852) % Here is TeX material that gets inserted after \input webmac **** FILE TX:TFTOPL-31.WEB.1, 1-14 (850) % Version 3.1 (November 1989) renamed z[] to lig_z[] for better portability. % Here is TeX material that gets inserted after \input webmac *************** **** FILE TX:TFTOPL-30.WEB.1, 1-32 (1473) \centerline{(Version 3, October 1989)} \vfill} **** FILE TX:TFTOPL-31.WEB.1, 1-33 (1551) \centerline{(Version 3.1, November 1989)} \vfill} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-63 (2869) @d banner=='This is TFtoPL, Version 3' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that **** FILE TX:TFTOPL-31.WEB.1, 1-64 (2950) @d banner=='This is TFtoPL, Version 3.1' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1256 (48904) end; right; **** FILE TX:TFTOPL-31.WEB.1, 1-1257 (48987) end; {there are no other cases} right; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1409 (54539) @!z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} **** FILE TX:TFTOPL-31.WEB.1, 1-1410 (54649) @!lig_z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1471 (57148) t:=z[h]; z[h]:=zz; zz:=t; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1472 (57262) t:=lig_z[h]; lig_z[h]:=zz; zz:=t; end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1475 (57240) hash[h]:=key; class[h]:=cc; z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; **** FILE TX:TFTOPL-31.WEB.1, 1-1476 (57362) hash[h]:=key; class[h]:=cc; lig_z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1513 (58592) left_z: begin class[h]:=pending; z[h]:=eval(z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; z[h]:=eval(x,z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; z[h]:=eval(eval(x,z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=z[h]; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1514 (58718) left_z: begin class[h]:=pending; lig_z[h]:=eval(lig_z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; lig_z[h]:=eval(x,lig_z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; lig_z[h]:=eval(eval(x,lig_z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; lig_z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=lig_z[h]; end; *************** ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 026 ] ------- 15-Aug-90 16:06:10-MDT,527;000000000001 Mail-From: BEEBE created at 15-Aug-90 16:06:09 Date: Wed 15 Aug 90 16:06:09-MDT From: "Nelson H. F. Beebe" Subject: Re: Some corrections; TFtoPL 3.1; catching up To: BNB@MATH.AMS.COM cc: Beebe@SCIENCE.utah.edu In-Reply-To: <650664382.0.BNB@MATH.AMS.COM> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12614086410.21.BEEBE@SCIENCE.utah.edu> Received your tex-implementors message about tftopl. ------- 18-Aug-90 15:07:15-MDT,9445;000000000001 Return-Path: Received: from MATH.AMS.COM by science.utah.edu with TCP; Sat 18 Aug 90 15:07:07-MDT Date: Sat 18 Aug 90 16:55:55-EST From: "Richard DeJordy, x4029" Subject: FORWARDED MESSAGE FOLLOWS To: TeX-implementors Cc: rad Date: Tue 14 Aug 90 16:06:22-EST From: bbeeton Subject: Some corrections; TFtoPL 3.1; catching up To: TeX-implementors Message-ID: <650664382.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 14 Aug 90 Message No: 026 To: TeX implementors and distributors From: Barbara Beeton Subject: Some corrections; TFtoPL 3.1; catching up I started putting this message together in April, but was interrupted and never sent it. Fortunately, there has not been too much activity in the intervening months that has required new versions of TeX/ware and MF/ware to be retrieved and installed; however, I recently received a message from Knuth saying that he expected to spend some of August tending to his TeX correspondence, so it's time to clear the decks. It was called to my attention that some lines in difference listings in these messages have been corrupted. Below are corrections as necessary. The corrected passages include the complete difference segments, not just individual lines. Please replace the offending segments as appropriate. (Note that if you received andy of the affected messages after the initial mailing, the original files have been corrected.) A short explanation may be useful. I use the TOPS-20 SRCCOM program to generate the difference lists. This program has a couple of flaws (it omits blank lines, for example), but it has the virtue that it does not extend lines beyond their original length, unlike the VMS DIF program, which is the only other option available to me. This makes for more reliable transmission across network gateways. After creating and validating a difference file, I transfer it to a VAX for construction of the message and mailing. This sometimes runs afoul of a TOPS-20/VMS imcompatibility, namely that the DEC-20 is a 36-bit-word machine, and ascii is packed at 5 characters to a word with one slack bit. If the slack bit happens to be turned on, that word will be lost in the 20-to-VAX transfer. In the examples corrected here, I forgot to take one more step, namely running the difference files through a program that turns off all slack bits. I realize there are undoubtedly better tools available to do this job automatically, but the local systems programming staff hasn't come up with any. Apologies for any problems caused by these errors. Although it's probably general knowledge by now, having been posted to TeXhax, Karl Berry is now "more or less maintaining" web2c. To quote his most recent message to me, "the port for TeX 3.0 and Metafont 2.0 is released, and now on ics.uci.edu and labrea.stanford.edu, as well as in Europe." Any questions can be sent to Karl at karl@cs.umb.edu on CSnet. The afore-mentioned TOPS-20 machine is scheduled to be unplugged at the end of the year. One of my biggest jobs is to migrate all the Math Society's TeX archives and records from the 20 to the VAX, and I'm spending every spare moment on that. In the process, I keep finding things that should have been announced here, so I will announce them, regardless of how late. For a start, TFtoPL was upgraded to version 3.1 last November. Differences between versions 3.0 and 3.1 below. Oren Patashnik has announced the availability of a set of TeX macros that make BibTeX work with plain TeX; the message to TeXhax will be distributed in due course, but here's a copy of the advance notice he sent me: Date: Tue, 14 Aug 1990 10:19:50 PDT From: Oren Patashnik To: texhax@cs.washington.edu Subject: BibTeX-for-plain-TeX macros There is now distributed with BibTeX a set of TeX macros that makes BibTeX work with plain TeX (and presumably with other macro packages that don't deviate too far from plain TeX). The file is btxmac.tex, stored on Labrea.Stanford.EDU's BibTeX area (pub/tex/bibtex). --Oren Patashnik Finally, it's now been about four months since I last sent a message to this list, and quite a few address changes have been made. Please help out by acknowledging receipt. (I should hear about the bounces sooner than I'd like to.) ######################################################################## Corrections to differences between WEBMAC.TEX versions 1.4 and 4.0 (message #25) **** FILE TX:WEBMAC.CM.1, 1-62 (2808) \def\A{\note{See also}} % cross-reference for multiply defined section names \def\B{\mathopen{\.{@\{}}} % begin controlled comment **** FILE TX:WEBMAC.TEX.1, 1-62 (2843) \def\A{\note{See also section}} % crossref for doubly defined section name \def\As{\note{See also sections}} % crossref for multiply defined section name \def\B{\mathopen{\.{@\{}}} % begin controlled comment *************** **** FILE TX:WEBMAC.CM.1, 1-186 (9074) \def\U{\note{Used in}} % cross-reference for uses of sections \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} **** FILE TX:WEBMAC.TEX.1, 1-190 (9406) \def\U{\note{Used in section}} % crossref for use of a section \def\Us{\note{Used in sections}} % crossref for uses of a section \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} *************** ######################################################################## Differences between TFtoPL.WEB versions 3.0 and 3.1 ;COMPARISON OF TX:TFTOPL-30.WEB.1 AND TX:TFTOPL-31.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TFTOPL-30.WEB.1, 1-15 (852) % Here is TeX material that gets inserted after \input webmac **** FILE TX:TFTOPL-31.WEB.1, 1-14 (850) % Version 3.1 (November 1989) renamed z[] to lig_z[] for better portability. % Here is TeX material that gets inserted after \input webmac *************** **** FILE TX:TFTOPL-30.WEB.1, 1-32 (1473) \centerline{(Version 3, October 1989)} \vfill} **** FILE TX:TFTOPL-31.WEB.1, 1-33 (1551) \centerline{(Version 3.1, November 1989)} \vfill} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-63 (2869) @d banner=='This is TFtoPL, Version 3' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that **** FILE TX:TFTOPL-31.WEB.1, 1-64 (2950) @d banner=='This is TFtoPL, Version 3.1' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1256 (48904) end; right; **** FILE TX:TFTOPL-31.WEB.1, 1-1257 (48987) end; {there are no other cases} right; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1409 (54539) @!z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} **** FILE TX:TFTOPL-31.WEB.1, 1-1410 (54649) @!lig_z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1471 (57148) t:=z[h]; z[h]:=zz; zz:=t; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1472 (57262) t:=lig_z[h]; lig_z[h]:=zz; zz:=t; end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1475 (57240) hash[h]:=key; class[h]:=cc; z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; **** FILE TX:TFTOPL-31.WEB.1, 1-1476 (57362) hash[h]:=key; class[h]:=cc; lig_z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1513 (58592) left_z: begin class[h]:=pending; z[h]:=eval(z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; z[h]:=eval(x,z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; z[h]:=eval(eval(x,z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=z[h]; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1514 (58718) left_z: begin class[h]:=pending; lig_z[h]:=eval(lig_z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; lig_z[h]:=eval(x,lig_z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; lig_z[h]:=eval(eval(x,lig_z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; lig_z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=lig_z[h]; end; *************** ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 026 ] ------- 23-Aug-90 03:55:28-MDT,1572;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 23 Aug 90 03:55:22-MDT Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 23 Aug 90 05:50:01-EDT Date: Thu, 23 Aug 1990 02:38 PDT From: Don Hosek Subject: That nasty dropped E problem--finally solved!!! To: tex-implementors@math.ams.com Message-id: X-Envelope-to: tex-implementors@math.ams.com X-VMS-To: in%"tex-implementors@math.ams.com" OK, I *finally* have a solution to that old nasty dropped E problem... (after wasting much time on \afterassignment, and looking for missing spaces I hit on a much simpler solution: @x [0] DAH: Fix problems WEAVEing TeX and BibTeX. \def\drop{\kern-.1667em\lower.5ex\hbox{E}\kern-.125em} % middle of TeX \catcode`E=13 \uppercase{\def E{e}} \def\\#1{\hbox{\let E=\drop\it#1\/\kern.05em}} % italic type for identifiers @y \def\\{\catcode`\E=13 \finishid} \catcode`\E=13 \uppercase{\def E{e}} \def\finishid#1{\hbox{\let E=\cape \it#1\/\kern.05em}% \catcode`\E=11\relax} % Guess what terrible thing happens if the % \relax is left out with the text below. \catcode`\E=11 \def\drop{\kern-.1667em\lower.5ex\hbox{E}\kern-.125em} % Middle of TeX \def\cape#1{\if X#1\drop\else E\fi#1} % E's in identifiers @z And yes, THIS time it works. (By the way, this *is* a genuine TeX bug so it should ultimately find its way into the WEB source. Do I get a check? :-) -dh 23-Aug-90 06:31:58-MDT,1462;000000000001 Return-Path: Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 23 Aug 90 06:31:55-MDT Date: Thu 23 Aug 90 08:25:23-EST From: bbeeton Subject: Re: That nasty dropped E problem--finally solved!!! To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-implementors@MATH.AMS.COM Message-ID: <651414323.0.BNB@MATH.AMS.COM> In-Reply-To: Mail-System-Version: don -- here's some correspondence i've saved from don knuth regarding the lowered e. i agree that it should be changed in several places, but don's not about to fix it, is my considered opinion. and by the way, i don't think you'll persuade don it's a bug, just a nasty inconvenience. -- bb -------------------- Date: 26 Nov 89 From: bbeeton ..., i'd like to ask if you could include the fix to the lowered "e" that i sent a while back (or an equivalent, or better, one) -- it would be really nice not to have names like "EDIT" appear in documentation with a lowered "e". not really a bug, just an effect that gets carried further than intended. ------- Date: 27 Nov 89 0930 PST From: Don Knuth Subject: fix to lowered E Barbara, I don't see why this fix couldn't be put into anybody's change file who really needed it. Such a thing should be explained in TeXhax, but I'm not inclined to change it in TEX.WEB. ------- 23-Aug-90 11:43:44-MDT,1108;000000000001 Return-Path: <@MATH.AMS.COM,@RELAY.CS.NET:karl@aten.cs.umb.edu> Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 23 Aug 90 11:43:41-MDT Received: from RELAY.CS.NET by MATH.AMS.COM via SMTP with TCP; Thu, 23 Aug 90 13:40:53-EDT Received: from relay2.cs.net by RELAY.CS.NET id ad28657; 23 Aug 90 13:36 EDT Received: from umb.edu by RELAY.CS.NET id al07255; 23 Aug 90 13:31 EDT Received: from aten.cs.umb.edu by cs.umb.edu (3.2/1.34) id AA29325; Thu, 23 Aug 90 11:52:16 EDT Received: by aten.cs.umb.edu (3.2/1.34) id AA04116; Thu, 23 Aug 90 11:52:15 EDT Date: Thu, 23 Aug 90 11:52:15 EDT From: Karl Berry Message-Id: <9008231552.AA04116@aten.cs.umb.edu> To: DHOSEK%hmcvax.claremont.edu@RELAY.CS.NET Cc: tex-implementors@MATH.AMS.COM In-Reply-To: Don Hosek's message of Thu, 23 Aug 1990 02:38 PDT Subject: That nasty dropped E problem--finally solved!!! Documentation bugs aren't worth nearly as much as programming bugs. (I've found about ten of the former and none of the latter...) karl@cs.umb.edu 21-Sep-90 15:31:41-MDT,4735;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Fri 21 Sep 90 15:31:12-MDT Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 21 Sep 90 17:20:17-EDT Received: by smiley.Stanford.EDU (4.0/inc-1.0) id AA05977; Fri, 21 Sep 90 14:16:24 PDT Date: Fri, 21 Sep 90 14:16:24 PDT From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9009212116.AA05977@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: Changes for Tex3.0 Hi, I've put up changes to TeX on labrea that were given to me by Don Knuth. Since this is the first time that I've done this I left the old versions of the files but renamed them to have the suffix "~" (as emacs does it). So, for example the old version of the file mf/mf.web is mf/mf.web~. If this is objectionable then you should let me know. Here is a list of files that were changed on labrea: . ./lib ./lib/logo.mf ./lib/null.mf ./lib/rtest.mf ./lib/3test.mf ./lib/6test.mf ./lib/cmbase.mft ./lib/grayf.mf ./lib/hyphen.tex ./lib/logo10.mf ./lib/logo8.mf ./lib/logo9.mf ./lib/logobf10.mf ./lib/logosl10.mf ./lib/manfnt.mf ./lib/manmac.tex ./lib/mftmac.tex ./lib/null.tex ./lib/plain.mf ./lib/plain.mft ./lib/plain.tex ./lib/slant.mf ./lib/test.mf ./lib/testfont.tex ./lib/webmac.tex ./lib/ztest.mf ./mfware ./mfware/mft.web ./mfware/gftodvi.web ./mfware/gftopk.web ./mfware/gftype.web ./tex ./tex/tex.web ./tex/trip.pl ./tex/texbook.tex ./tex/trip.fot ./tex/trip.log ./tex/trip.tex ./tex/trip.typ ./tex/tripin.log ./tex/tripman.tex ./tex/tripos.tex ./mf ./mf/mf.web ./mf/mfbook.tex ./mf/trap.fot ./mf/trap.log ./mf/trap.mf ./mf/trap.pl ./mf/trap.typ ./mf/trapin.log ./mf/trapman.tex ./texware ./texware/dvitype.web ./texware/pltotf.web ./texware/pooltype.web ./texware/tftopl.web ./web ./web/tangle.web ./web/weave.web ./web/webman.tex ./errata ./errata/cm85.bug ./errata/errata.five ./errata/errata.four ./errata/errata.one ./errata/errata.tex ./errata/errata.three ./errata/errata.two ./errata/errorlog.tex ./errata/logmac.tex ./errata/mf84.bug ./errata/tex82.bug ./local ./local/web ./local/web/Makefile ./local/web/tangext.c ./local/web/tangext.h ./local/web/tangle.ch ./local/web/tangle.p ./local/web/weave.ch ./local/web/weavext.c ./local/texware ./local/texware/Makefile ./local/texware/access.c ./local/texware/dvityext.c ./local/texware/dvityext.h ./local/texware/dvitype.ch ./local/texware/pltotf.ch ./local/texware/pooltype.ch ./local/texware/tftopl.ch ./local/mfware ./local/mfware/mft.ch ./local/mfware/Makefile ./local/mfware/gftodvi.ch ./local/mfware/gftopk.ch ./local/mfware/gftopk_ext.c ./local/mfware/gftopk_ext.h ./local/mfware/gftype.ch ./local/mfware/mft_ext.c ./local/mfware/mft_ext.h ./local/mfware/pktype.ch ./local/mfware/pktype.web ./local/tex ./local/tex/Makefile ./local/tex/dvitype.in ./local/tex/ext.c ./local/tex/ext.h ./local/tex/ini_to_trip ./local/tex/ini_to_vir ./local/tex/initex.ch ./local/tex/plain.fmt ./local/tex/plain.log ./local/tex/tex.pool ./local/tex/trip1.in ./local/tex/trip2.in ./local/mf ./local/mf/Makefile ./local/mf/ext.c ./local/mf/ext.h ./local/mf/gftype.in ./local/mf/ini_to_trap ./local/mf/inimf.ch ./local/mf/mf.pool ./local/mf/mf_arith.c ./local/mf/mf_sunwin.c ./local/mf/mf_window.h ./local/mf/plain.base ./local/mf/plain.log ./local/mf/trap1.in ./local/mf/trap2.in ./local/lib ./local/lib/art.mf ./local/lib/e.mft ./local/lib/black.mf ./local/lib/blackaps.mf ./local/lib/linew10.mf ./local/lib/gray.mf ./local/lib/grayaps.mf ./local/lib/blackimagen.mf ./local/lib/fontchart.tex ./local/lib/grayimagen.mf ./local/lib/grayimagen3.mf ./local/lib/grayimagenlight.mf ./local/lib/lcircle.mf ./local/lib/lcircle10.mf ./local/lib/lcirclew10.mf ./local/lib/letter.tex ./local/lib/line.mf ./local/lib/line10.mf ./local/lib/list.tex ./local/lib/llist.tex ./local/lib/mfman.mf ./local/lib/oneone.mf ./local/lib/picmac.tex ./local/lib/slantaps4.mf ./local/lib/slantimagen6.mf ./local/man1 ./local/man1/dvitype.1 ./local/man1/gftodvi.1 ./local/man1/gftopk.1 ./local/man1/gftype.1 ./local/man1/mf.1 ./local/man1/mft.1 ./local/man1/pktype.1 ./local/man1/pltotf.1 ./local/man1/pooltype.1 ./local/man1/tangle.1 ./local/man1/tex.1 ./local/man1/tftopl.1 ./local/man1/vftovp.1 ./local/man1/vptovf.1 ./local/man1/weave.1 ./local/man1/web.1 ./local/bdemo_ext.c ./local/Makefile ./local/etc ./local/etc/Makefile ./local/etc/vftovp.ch ./local/etc/vptovf.ch ./local/bdemo_ext.h ./local/binarydemo.p ./local/h00vars.h ./local/mfpaths.h ./local/texpaths.h ./etc ./etc/vftovp.web ./etc/vptovf.web I left the list of differences that Knuth sent in DIFFS.Sept90. BNB@math.ams.com will be sending out a more formal description of the differences in the future. Dan 26-Sep-90 23:13:31-MDT,3623;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Wed 26 Sep 90 23:13:17-MDT Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 27 Sep 90 01:06:13-EDT Date: Wed, 26 Sep 1990 21:59 PDT From: Don Hosek Subject: Descrepency between behavior of TeX 3.x and TeX 2.x To: tex-implementors@math.ams.com Message-id: <03464DFA00603710@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-implementors@math.ams.com X-VMS-To: IN%"tex-implementors@math.ams.com" In a Usenet article, Ed Overman reported the following: ---begin quoted article------------------------------------- Path: jarthur!usc!zaphod.mps.ohio-state.edu!shape.mps.ohio-state.edu!eao From: eao@shape.mps.ohio-state.edu (Ed Overman) Newsgroups: comp.text.tex Subject: inconsistency between TeX 2.9 and 3.0 Message-ID: <1990Sep27.010730.1819@zaphod.mps.ohio-state.edu> Date: 27 Sep 90 01:07:30 GMT Sender: usenet@zaphod.mps.ohio-state.edu Organization: Department of Mathematics, The Ohio State University Lines: 30 We just installed TeX 3.0 here over the weekend and there seems to be an inconsistency between the new and old versions. I get different results with the following: \let\PAR=\par \if\PAR\par (TRUE) \else (FALSE) \fi \ifx\PAR\par (TRUE) \else (FALSE) \fi \if\PAR\$ (TRUE) \else (FALSE) \fi \ifx\PAR\$ (TRUE) \else (FALSE) \fi \if\PAR\# (TRUE) \else (FALSE) \fi \ifx\PAR\# (TRUE) \else (FALSE) \fi \bye TeX 3.0 prints out: (TRUE) (TRUE) (TRUE) (FALSE) (TRUE) (FALSE) TeX 2.9 (on my Atari since our sysop took the old version off our Suns already) prints out: (TRUE) (TRUE) (FALSE) (FALSE) (FALSE) (FALSE) These cannot both be correct - can they? Can anyone tell me which is correct (I assume the old version but I am not sure I completely understand the description of \if in Chapter 20). If this is a bug has anyone else seen it? Thanks, Ed Overman -----end quoted article------------------------------------- Checking this against 2.93 on a CMS system and my VMS 3.1 system revealed the same discrepency. Since 4 different systems are involved in the parallel tests, I presume that this is, in fact, due to something in the WEB itself. So which is right? The differences can be summarized with the following distilled version: \let\PAR=\par \if\PAR\$ (TRUE) \else (FALSE) \fi (\$ and \# are defined similarly using \chardef) \if expands what follows it until it finds two unexpandable tokens. In the case of the \if statement above, we will have \PAR unexpandable to what is treated as character code 256, category code 16 (cf. THE TeXBOOK, p.209). \$ is defined with \chardef\$=`\$ Now from the behavior described above, it would seem that under TeX 2.x the expansion of \$ would be the character $ with catcode 12 (or some such) while under 3.x it's some unexpandable control sequence. A tedious search through the TeXbook indicates the following interesting passages: "[in a discussion on comparisons with \ifx] the two tokens are not macros and they both represent the same \font or \chardef or \countdef, etc." (p.210) and \chardef'd control sequences are not listed in the list of expansions on pp. 212-4. \font'd control sequences are listed in that list however and the implication in the syntax definitions is that \font and \chardef produce c.s.'s of similar natures. To me, this seems a toss-up as to which is correct. Anyone else interested in the venture? Is \$ expandable or no? (Since TeX did change, contacting DEK, would not seem unfounded). -dh 27-Sep-90 05:14:45-MDT,2472;000000000001 Return-Path: <@MATH.AMS.COM,@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 27 Sep 90 05:14:23-MDT Received: from ruuinf.cs.ruu.nl by MATH.AMS.COM via SMTP with TCP; Thu, 27 Sep 90 07:10:59-EDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA20340; Thu, 27 Sep 90 13:02:47 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA27930; Thu, 27 Sep 90 13:05:45 met Date: Thu, 27 Sep 90 13:05:45 met From: Piet van Oostrum Message-Id: <9009271105.AA27930@praxis.cs.ruu.nl> To: tex-implementors@math.ams.com To: eao@shape.mps.ohio-state.edu (Ed Overman) Subject: Re: inconsistency between TeX 2.9 and 3.0 Path: piet Newsgroups: comp.text.tex From: piet@cs.ruu.nl (Piet van Oostrum) Subject: Re: inconsistency between TeX 2.9 and 3.0 References: <1990Sep27.010730.1819@zaphod.mps.ohio-state.edu> Reply-To: piet@cs.ruu.nl (Piet van Oostrum) In-reply-to: eao@shape.mps.ohio-state.edu (Ed Overman) Organization: Dept of Computer Science, Utrecht University, The Netherlands >>>>> In article <1990Sep27.010730.1819@zaphod.mps.ohio-state.edu>, eao@shape.mps.ohio-state.edu (Ed Overman) (EO) writes: EO> We just installed TeX 3.0 here over the weekend and there seems to be EO> an inconsistency between the new and old versions. I get different EO> results with the following: [ Example replaced by the following simpler:] \if\par\% TRUE\else FALSE\fi The TeX3.0 behaviour is the correct one. Both \par and \% are not expandable (they are not macros or anything mentioned on page 213/214) So they are considered to have character codes 256 and thus to test equal. Tex 2.9 and previous versions had a bug whereby \par was considered to have character code 0 (and category code 13). So the following example erroneously came out with TRUE: \catcode`\%=13 \ifcat\par\noexpand%TRUE\else FALSE\fi The fix is described in errorlog.tex: ------------------------------------------------------------------------ * 3 Dec 1989 ... S893. Distinguish |\par| from characters on |\if| tests. (MVL). @334 ------------------------------------------------------------------------ (that's a strange way of saying it!) -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') 22-Oct-90 11:19:34-GMT,8328;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA23467; Mon, 22 Oct 90 12:19:27 MDT Date: Mon 22 Oct 90 13:32:37-EST From: bbeeton Subject: AMSFonts bug; TeX 3.1, MF 2.7 To: TeX-implementors@MATH.AMS.COM Message-Id: <656616757.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 22 October 90 Message No: 027 To: TeX implementors and distributors From: Barbara Beeton Subject: AMSFonts bug; TeX 3.1; MF 2.7 This will be a short message. I am constrained by a TUGboat printer deadlne, but it's been so long since anything has been reported, I wanted to let you know I'm still alive. A bug was reported in the AMSSYM.DEF file in the AMSFonts package. The fix has not yet been posted to the file on e-Math, but is listed below. The symptom is "unidentified control sequence" for \setboxz@h when trying to use \widetilde or \widehat. If you have not yet heard about e-Math (most of you should have received a message from Regina Girouard describing what is available there and how to retrieve it), please let me know, and I will send information. Chris Thompson has suggested that, similar to the occasional reports of files changed at labrea, I include in these messages a report of files changed at e-Math. I will try to get a baseline listing of the e-Math holdings for later comparison, and make reports as suggested. As of August 15, I had completed my scan of old mail files and double checked that all bug reports and questions forwarded to me had been delivered to Don Knuth. (Actually, the last of the pending reports had been delivered earlier, but I can say with a clear conscience that I think i found all messages that had arrived electronically and passed them on. A few have arrived since then, and I will forward them as soon as TUGboat has been delivered.) I have received from Don (on paper) a pile of annotated reports and several checks; I will forward those to the proper people as soon as TUGboat, ... In the meantime, TeX is now at version 3.1, MF is at version 2.7, and at least some of you may have seen Don's announcement that the numbers will converge to $\pi$ for TeX and $e$ for MF. (It will be published in TUGboat 11#4, but I will forward it to this list if I have time before that appears.) There was a massive update of files at labrea on September 21. On some (e.g. cm85.bug) only the dates have changed; too bad the Unix file system isn't better about keeping meaningful dates. In any case, the new errata and bug additions for TeX and MF are attached below. ######################################################################## Bug fix for AMSSYM.DEF (AMSFonts package) ************ File SYSA:[AMSFONTS.DISTRIB.2-0]AMSSYM.DEF;5 (line 33) \def\newsymbol#1#2#3#4#5{\let\next@\relax ****** File SYSA:[AMSFONTS.DISTRIB.WORK]AMSSYM.DEF;6 (line 33) \def\setboxz@h{\setbox\z@\hbox} \def\wdz@{\wd\z@} \def\newsymbol#1#2#3#4#5{\let\next@\relax ************ Number of difference sections found: 1 Number of difference records found: 2 DIFFERENCES /IGNORE=()/MERGED=1- SYSA:[AMSFONTS.DISTRIB.2-0]AMSSYM.DEF;5- SYSA:[AMSFONTS.DISTRIB.WORK]AMSSYM.DEF;6 ######################################################################## Addenda to TEX82.BUG as of 21 September 90 390. Uninitialized nullfont parameters (found by Lance Carnes, 11 May 90). @x module 552 hyphen_char[null_font]:="-"; skew_char[null_font]:=-1; @y hyphen_char[null_font]:="-"; skew_char[null_font]:=-1; bchar_label[null_font]:=non_address; font_bchar[null_font]:=non_char; font_false_bchar[null_font]:=non_char; @z 391. Disable \write{\the\prevgraf} (B. Jackowski, July 1990). @x module 422 begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @y if mode=0 then scanned_result(0)(int_val) {|prev_graf=0| within \.{\\write}} else begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @z 392. Report correct line number when buffer overflows (George Russell). @x module 538 begin if input_ln(cur_file,false) then do_nothing; firm_up_the_line; if end_line_char_inactive then decr(limit) else buffer[limit]:=end_line_char; first:=limit+1; loc:=start; line:=1; @y begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; if end_line_char_inactive then decr(limit) else buffer[limit]:=end_line_char; first:=limit+1; loc:=start; @z 393. (I sincerely hope that there won't be any more) ######################################################################## Addenda to MF84.BUG as of 21 September 90 555. Don't try system area if an area was given (see tex82.bug number 312; found by Jonathan Kew, May 1990) @x pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; @y if cur_area="" then begin pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; end; @z 556. Report correct line number when buffer overflows (CET, Jul 90). @x module 794 begin if not input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; line:=1; @y begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; @z 557. (I sincerely hope that there won't be any more) ######################################################################## Changes to ERRATA.FIVE as of 21 September 90 \bugonpage A336, lines 4--8 from the bottom (9/23/89) % was \bugonpage A336, lines 4--8 (9/23/89) \bugonpage A337, lines 2--16 (9/23/89) % was \bugonpage A336, lines 2--16 (9/23/89) ######################################################################## New errata in ERRATA.TEX as of 21 September 90 \bugonpage A124, lines 18--21 (9/5/90) \ninepoint\noindent Floating insertions can be accommodated as a special case of split insertions, by making each floating topinsert start with a small penalty, and by having zero as the associated |\floatingpenalty|; non-floating insertions like footnotes are accommodated by associating larger penalties with split insertions (see Appendix~B). \bugonpage A165, lines 2--3 (8/13/90) \ninepoint Type the formula $\bf\bar x^{\rm T}Mx={\rm0}\iff x=0$, using as few keystrokes as possible. \ (The first `0' is roman, the second is bold. The superscript `T' is roman.) \bugonpage A317, line 17 (5/17/90) \ninepoint |\pretolerance=9999 \tolerance=9999 \parindent=0pt| \bugonpage A321, lines 16--17 (8/13/90) \ninepoint\noindent \hbox to\parindent{\bf\hss18.6.\enspace}\ignorespaces |$\bf\bar x^{\rm T}Mx={\rm0}\iff x=0$|. \ (If you typed a space between |\rm| and~|0|, you wasted a keystroke; but don't feel guilty about it.) \bugonpage Exiii, replacement for last four lines (4/30/90) \textindent{\bull}``AMS Euler---A new typeface for mathematics'' by Donald~E. Knuth and Hermann Zapf, {\sl Scholarly Publishing\/ \bf21} (1989), 131--157. \ {\it The story of a design project that helps bridge the gulf between mathematics and art.} \smallskip \textindent{\bull}``Meta-Marks: Preliminary studies for a Pandora's Box of shapes'' by Neenie Billawala, Stanford Computer Science report 1259 (Stanford, California, July 1989), 132~pp. \ {\it Lavishly illus\-trated studies in parameter variation, leading to the design of a new typeface called Pandora.} ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 027 ] ------- 30-Oct-90 7:07:30-GMT,5785;000000000001 Return-Path: <@MATH.AMS.COM,@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA12724; Tue, 30 Oct 90 07:07:21 MST Received: from ruuinf.cs.ruu.nl by MATH.AMS.COM via SMTP with TCP; Tue, 30 Oct 90 09:02:52-EDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA01231; Tue, 30 Oct 90 09:32:09 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA05801; Tue, 30 Oct 90 09:33:46 -0100 Date: Tue, 30 Oct 90 09:33:46 -0100 From: Piet van Oostrum Message-Id: <9010300833.AA05801@praxis.cs.ruu.nl> To: tex-implementors@math.ams.com Cc: pzf5hz@drueds2.BITNET, schoepf@sc.zib-berlin.dbp.de, lamport@src.dec.com Subject: Bug in Latex not corrected I posted this some time ago in TeXhax, but didn't see any response, so I mail this now. This is from latex.bug: 138. A command like \index or \label could incorrectly suppress a space after the next \end command. (Reported by Johannes Braams. Partially fixed on 30 Nov 88. Problem can still occur if \index or \label command comes inside the \end's environment.) Well, it appears not to be fixed at all (Except in the comments). This is from latex.tex as it appears on labrea: (Dated 7 Dec 1989) % \begin{NAME} == % BEGIN % IF \NAME undefined THEN \@tempa == BEGIN report error END % ELSE \@tempa == (\@currenvir :=L NAME) \NAME % FI % @ignore :=G F %% Added 30 Nov 88 % \begingroup % \@currenvir :=L NAME % \NAME % END \def\begin#1{\@ifundefined{#1}{\def\@tempa{\@latexerr{Environment #1 undefined}\@eha}}{\def\@tempa{\def\@currenvir{#1}% \csname #1\endcsname}}\begingroup\@endpefalse\@tempa} ^^ No \global\@ignoretrue Now the bug report mentions that this will not solve all problems. There is only one good solution for it: Have two versions of the \@esphack macro, one with \@ignoretrue (to be used in the end of an environment) and one without (to be used in simple commands). As the second one is used the most, the first one should get another name. It is currently used only in \end@float and its siblings. Here is a suggested patch. I have tested it only with one (big) file. Of course the fix is only official if endorsed by LL. *** latex.tex.~1~ Mon Feb 12 18:02:12 1990 --- latex.tex Fri Apr 20 21:09:00 1990 *************** *** 2000,2005 **** --- 2000,2009 ---- \ifhmode\@savsf\spacefactor\fi} \def\@esphack{\relax\ifhmode\spacefactor\@savsf + {}\ifdim \@savsk >\z@ \ignorespaces + \fi \fi} + + \def\@Esphack{\relax\ifhmode\spacefactor\@savsf {}\ifdim \@savsk >\z@ \global\@ignoretrue \ignorespaces \fi \fi} *************** *** 6494,6500 **** % else \vadjust{\penalty -10004 % \vbox{} % \penalty \@floatpenalty} ! % \@esphack % fi fi % END % --- 6498,6504 ---- % else \vadjust{\penalty -10004 % \vbox{} % \penalty \@floatpenalty} ! % \@Esphack % fi fi % END % *************** *** 6515,6521 **** % if \@floatpenalty < 0 % then \@dbldeferlist :=G \@dbldeferlist * \@currbox % fi ! % if \@floatpenalty = -10002 then \@esphack fi % END % \newcount\@floatpenalty --- 6519,6525 ---- % if \@floatpenalty < 0 % then \@dbldeferlist :=G \@dbldeferlist * \@currbox % fi ! % if \@floatpenalty = -10002 then \@Esphack fi % END % \newcount\@floatpenalty *************** *** 6560,6566 **** \vbox{} %% 26 May 87 to prevent extra vertical \prevdepth \@tempdima %% space when used in vertical mode \penalty\@floatpenalty ! \else \vadjust{\penalty -\@Miv \vbox{}\penalty\@floatpenalty}\@esphack \fi\fi} --- 6564,6570 ---- \vbox{} %% 26 May 87 to prevent extra vertical \prevdepth \@tempdima %% space when used in vertical mode \penalty\@floatpenalty ! \else \vadjust{\penalty -\@Miv \vbox{}\penalty\@floatpenalty}\@Esphack \fi\fi} *************** *** 6574,6580 **** \def\end@dblfloat{\if@twocolumn \par\vskip\z@\egroup %% \par\vskip\z@ added 15 Dec 87\egroup \ifnum\@floatpenalty <\z@ \@cons\@dbldeferlist\@currbox\fi ! \ifnum \@floatpenalty =-\@Mii \@esphack\fi\else\end@float\fi} \newcount\c@topnumber \newcount\c@dbltopnumber --- 6578,6584 ---- \def\end@dblfloat{\if@twocolumn \par\vskip\z@\egroup %% \par\vskip\z@ added 15 Dec 87\egroup \ifnum\@floatpenalty <\z@ \@cons\@dbldeferlist\@currbox\fi ! \ifnum \@floatpenalty =-\@Mii \@Esphack\fi\else\end@float\fi} \newcount\c@topnumber \newcount\c@dbltopnumber *************** *** 6689,6695 **** \def\@xympar{\ifnum\@floatpenalty <\z@\@cons\@currlist\@marbox\fi \setbox\@tempboxa\vbox %% added 3 Jan 88 ! \bgroup\end@float\@esphack} \def\reversemarginpar{\global\@mparbottom\z@ \@reversemargintrue} \def\normalmarginpar{\global\@mparbottom\z@ \@reversemarginfalse} --- 6693,6699 ---- \def\@xympar{\ifnum\@floatpenalty <\z@\@cons\@currlist\@marbox\fi \setbox\@tempboxa\vbox %% added 3 Jan 88 ! \bgroup\end@float\@Esphack} \def\reversemarginpar{\global\@mparbottom\z@ \@reversemargintrue} \def\normalmarginpar{\global\@mparbottom\z@ \@reversemarginfalse} Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') 26-Oct-90 6:41:34-GMT,1519;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA12306; Fri, 26 Oct 90 14:41:29 MDT Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Fri, 26 Oct 90 16:31:30-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA19427; Fri, 26 Oct 90 13:27:05 -0700 Date: Fri, 26 Oct 90 13:27:05 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9010262027.AA19427@june.cs.washington.edu> To: BNB@MATH.AMS.COM Cc: TeX-implementors@MATH.AMS.COM In-Reply-To: bbeeton's message of Mon 22 Oct 90 13:32:37-EST <656616757.0.BNB@MATH.AMS.COM> Subject: Labrea archive files. The files for TeX proper are kept right up to date through these messages, but unfortunately there remains a problem at labrea. I have just looked once again, and the lplain and splain are still TeX2 files. There is no \language setting and no \lefthyphenmin setting. amslatex will undoubtedly be adopted as a preferable substitute in time, but for the immediate future we need to resolve the problem of unusuable lplain and splain files on the archive. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.acs.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thompson Hall, Mail Stop DR05 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 29-Oct-90 12:35:05-GMT,1381;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09025; Mon, 29 Oct 90 12:34:54 MST Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 29 Oct 90 14:25:34-EDT Date: Mon, 29 Oct 1990 11:19 PST From: Don Hosek Subject: Re: Labrea archive files. To: mackay@cs.washington.edu, pzf5hz@drueds2.BITNET, schoepf@sc.zib-berlin.dbp.de, lamport@src.dec.com Cc: tex-implementors@math.ams.com Message-Id: <986B947EC0A00236@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: IN%"mackay@cs.washington.edu" X-Vms-Cc: IN%"tex-implementors@math.ams.com",FRANK_MITTELBACH, RAINER_SCHOEPF,LESLIE_LAMPORT There exist versions of lplain.tex and splain.tex for TeX 3.x (they also work with older TeXs as well) created by Frank and Rainer and some others I think. These are on ymir.claremont.edu in [anonymous.tex.inputs.latex] and [anonymous.tex.inputs.slitex]. Leslie has said that any changes to the files that Frank and Rainer can make official changes to the files and I've been considering these as the official lplain.tex and splain.tex; there has seemed to be some difficulty getting the change to propogate if it doesn't make it to labrea; perhaps we can finally get this taken care of? -dh 29-Oct-90 17:41:21-GMT,1374;000000000001 Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10548; Mon, 29 Oct 90 17:41:11 MST Received: from june.cs.washington.edu by VAX01.AMS.COM via SMTP with TCP; Mon, 29 Oct 90 19:35:57-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA16394; Mon, 29 Oct 90 16:30:17 -0800 Date: Mon, 29 Oct 90 16:30:17 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9010300030.AA16394@june.cs.washington.edu> To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: pzf5hz@drueds2.BITNET.washington.edu, schoepf@sc.zib-berlin.dbp.de, lamport@src.dec.com, tex-implementors@math.ams.com In-Reply-To: Don Hosek's message of Mon, 29 Oct 1990 11:19 PST <9867D63E40A00236@HMCVAX.CLAREMONT.EDU> Subject: Labrea archive files. That certainly seems to resolve the problem. The splain file tracks the lplain file closely, as it ought to, and I like the dodge to make the same file work for both TeX2 and TeX3 Let's do it. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.acs.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thompson Hall, Mail Stop DR05 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 30-Oct-90 16:01:02-GMT,5743;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02474; Tue, 30 Oct 90 16:00:49 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Tue, 30 Oct 90 17:55:11-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <6727-0@sun2.nsfnet-relay.ac.uk>; Tue, 30 Oct 1990 22:42:07 +0000 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa18069; 30 Oct 90 22:38 GMT Date: Tue, 30 Oct 90 22:45:21 GMT From: Chris Thompson To: TeX-implementors@math.ams.com Subject: State of AMSFonts 2.0 Message-Id: I have a number of outstanding problems with some of the AMSFonts 2.0 package, and as they are taking a very long time to resolve, I think they deserve to be more widely known, to avoid duplication of effort. I am particularly concerned here with problems that involve actual or potential changes to the TFM files, as these have serious implications for the exchange of documents using the fonts. I will divide the fonts up accoring to the sub-directories of ams/amsfonts/sources at e-math.ams.com: extracm. No problems here. cyrillic. There was a problem with wncysc10, but Tom Ridgeway fixed this promptly: an updated cyrcsc.mf (which is where the bug resided) was installed on e-math on 23 August. The only outstanding problem I know about is one involving rounding errors in the transform used by |mirror|: this only strikes a very few mode/magnification/font combinations, and can easily be circumvented by redefining |mirror| to avoid the rounding errors. euler. The TFM files for eufb6, eufb8 & eufb9 in ams/amsfonts/tfm-files do not match those generated from the source: the widths and the checksums do not match. (I discount here a large number of other cases of inconsistency in the contents of the later parts of the 'header' parts of the TFM files.) It turns out that this is the tip of a very ugly iceberg: the values of the parameters leftsize# and rightsize# are completely inconsistent between the 10pt/7pt/5pt fonts and the 9pt/8pt/6pt fonts. It would appear that at different times these parameters (which are the same across the eu{f|r|s}{m|b} series) have taken the values 10pt 9pt 8pt 7pt 6pt 5pt (a) 0h# 33h# 100h# 200h# 333h# 500h# (b) 0h# 33h# 100h# 100h# 333h# 300h# (c) 0h# 25h# 75h# 100h# 200h# 300h# The original state (a) can only be deduced from commented-out lines. State (b) is what most of the current sources, and all the TFM files, correspond to. State (c) is present in only the eufb#.mf sources. Obviously, state (b) is not self-consistent, being non-monotonic. The most optimistic view I can take of the current state is that the 10pt/7pt/5pt fonts are in what will be their final state, while the 9pt/8pt/6pt fonts should be not be touched with the proverbial bargepole, as any fix for these problems will alter their TFM files (and in particular, the checksum). symbols. The source for the msam# fonts produces different TFM files depending on the mode/magnification. The variations are only in the heights and depths, not in the widths (and hence not the checksums). The immediate cause is of this is the setting of 'radius#' on line 1720 of asymbols.mf: radius={the result of a calculation}; radius=radius#*hppp; This setting of a #'d quantity from a un-#'d one is always an error, because it makes the #'d quantity dependant on mode/magnification (because of rounding errors, even if the un-#'d quantities haven't been rounded to pixels, blackened, overshot, or whatever). Some of you will remember a very similar bug in the LaTeX circle fonts before Don Knuth fixed them (ref. TeXhax digests 1989 #9 & #57). This quantity radius# is used in the heights and depths of characters 114='162="72 (circled R) and 115='162="73 (circled S), making them not mode/magnification-independent. However, the msam# fonts have well over 15 distinct heights and depths, so these variable values get fed into METAFONT's algorithm for choosing a compromise 15 values, and end up affecting the heights and depths of many other characters. Although this is the only bug I know of that affects the TFM files in these fonts, I have to say that the general quality of the METAFONT source for these fonts is much lower than that of the others. The accompanying documenation tells one to ignore METAFONT errors at low resolutions for all the fonts, but only for the symbol fonts (msam# and msbm#) is it actually necessary to do so for 200dpi upwards, and there is little sign that they actually disappear however high the resolution. I would welcome the experiences of other tex-implementors with these fonts, and also any account of whether they have achieved satisfactory communcation with the technical support staff at the AMS (the 'readme' file tells one to report problems to tech-support@math.ams.com). For example, I reported the eufb6/eufb8/eufb9 problem to them 2 months ago, and despite reminders have yet to receive even an acknowledgment that they aware of the problem. (Barbara is of course exempted from this criticism: when I cc the messages to her I always get a prompt and useful reply: for example she put me in touch with Tom Ridgeway at Washington in connection with the cyrillic font problems.) Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk 31-Oct-90 8:10:24-GMT,1493;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PZF5HZ@DRUEDS2.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA16251; Wed, 31 Oct 90 08:10:12 MST Message-Id: <9010311510.AA16251@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 31 Oct 90 10:06:04-EDT Received: from RUIPC1E.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8998; Wed, 31 Oct 90 10:00:39 EST Date: 10/31/90 15:51:59 GMT+1 From: MITTELBACH FRANK To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: RE: BUG IN LATEX NOT CORRECTED > > This is from latex.bug: > > 138. A command like \index or \label could incorrectly suppress a > space after the next \end command. (Reported by Johannes Braams. > Partially fixed on 30 Nov 88. Problem can still occur if \index or > \label command comes inside the \end's environment.) > > Well, it appears not to be fixed at all (Except in the comments). Well, I suppose that for some reason two different fixes to the \document macro canceled each other. The question is, do we re-add the \@ignoretrue? > > > Now the bug report mentions that this will not solve all problems. There is > only one good solution for it: I wonder whether it is really worth the effort to fix these kind of marginal errors currently if LaTeX is going to change anyway. Such global all over the place changes are normally dangerous and I don't have the time to check them out. Frank 31-Oct-90 14:09:24-GMT,1816;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01128; Wed, 31 Oct 90 14:09:15 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 31 Oct 90 16:04:42-EDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 31 Oct 90 16:05:41-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <7843-52@sun2.nsfnet-relay.ac.uk>; Wed, 31 Oct 1990 17:17:07 +0000 Received: from sun2.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa11241; 31 Oct 90 16:33 GMT Date: Wed, 31 Oct 90 16:40:14 GMT From: Chris Thompson To: TeX-implementors@math.ams.com Cc: MITTELBACH FRANK <@cunyvm.cuny.edu:PZF5HZ@drueds2.bitnet> Subject: RE: RE: LABREA ARCHIVE FILES. Message-Id: Frank Mittelbach writes > Yes please place it in the official archive since this is slowing > things up otherwise. I trust that whoever is updating the labrea files will do it in the approved Lamport fashion, as described in section 7 of latex.ins, i.e. with the final change to latex.bug. Well, of course they will, won't they? If I sound suspicious it must be the result of having had too much experience with other badly maintained archives. Maybe it's the result of mail system blockages and malfunctionings, but I am having some difficulty sorting the thread of recent messages involving LaTeX on tex-implementors. Could everyone be careful that they don't transfer a thread previously not on tex-implementors onto it without giving the background? Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk 19-Nov-90 10:36:57-GMT,777;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.stanford.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA04909; Mon, 19 Nov 90 10:36:47 MST Received: from smiley.stanford.edu by MATH.AMS.COM via SMTP with TCP; Mon, 19 Nov 90 12:29:39-EDT Received: by smiley.stanford.edu (4.1/inc-1.0) id AA03100; Mon, 19 Nov 90 09:25:11 PST Date: Mon, 19 Nov 90 09:25:11 PST From: kolk@smiley.stanford.edu (Dan Kolkowitz) Message-Id: <9011191725.AA03100@smiley.stanford.edu> To: tex-implementors@math.ams.com Subject: labrea files updated I've updated the splain.tex and lplain.tex files in ftp/tex/latex. Pierre Mackay gave me the files that replaced the old ones. I kept the old ones around in ~ftp/tex/OLD.latex. I hope it is all correct now. Dan 21-Nov-90 16:24:13-GMT,1199;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA17047; Wed, 21 Nov 90 16:24:08 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Wed, 21 Nov 90 18:14:03-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA00183; Wed, 21 Nov 90 15:09:27 -0800 Date: Wed, 21 Nov 90 15:09:27 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9011212309.AA00183@june.cs.washington.edu> To: kolk@smiley.stanford.edu Cc: tex-implementors@math.ams.com In-Reply-To: Dan Kolkowitz's message of Mon, 19 Nov 90 09:25:11 PST <9011191725.AA03100@smiley.stanford.edu> Subject: labrea files updated Perfect. Just for safety, I recopied the files and checked them. Everything is just as it should be. Many thanks. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 27-Nov-90 13:53:29-GMT,1549;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06154; Tue, 27 Nov 90 13:53:24 MST Date: Tue 27 Nov 90 15:26:24-EST From: bbeeton Subject: TeX-Preview for VMS (forwarded message) To: TeX-implementors@VAX01.AMS.COM Message-Id: <659737584.0.BNB@MATH.AMS.COM> Mail-System-Version: i'm forwarding the attached message at the request of matthias gaertner. --------------- Date: Tue, 27 Nov 90 18:19:46 +0100 (Central European Time) From: XCGNSTEX%DDATHD21.BITNET@CUNYVM.CUNY.EDU (M. GAERTNER) Subject: TeX-Preview for VMS Hi Miss Beeton, since our BITNET-Server corrupts the addresses for the TeX-implementators list, I'm writing to you with the request to forward it. My message: I'm searching a preview-program for Tektronixs and/or for VTxxx (VT200 and above). And all this for VMS, language C, FORTRAN, PASCAL or WEB. (And if possible not too close at system level, since our DEC10 is still running and running...) So, has anybody out there such a program??? Oh, btw. our Font-finding scheme is alike for DVI2LN3: All Pixel-files found under TEX$PIXEL, with the size encoded in the extention (CMR10.1500pxl). Thank you for yor help M. Gaertner Fachbereichsrechner Maschinenbau TH Darmstadt Petersenstrasse 30 D-6100 Darmstadt BITNET: XCGNSTEX@DDATHD21.BITNET (TeX) XCGNMGAE@DDATHD21.BITNET (Privat) ------- 27-Nov-90 23:43:34-GMT,1463;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:UCIR001@FRORS12.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09113; Wed, 28 Nov 90 06:43:29 MST Message-Id: <9011281343.AA09113@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 28 Nov 90 08:34:23-EDT Received: from FRORS12.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2776; Wed, 28 Nov 90 08:29:01 EST Received: from FRORS12 (UCIR001) by FRORS12.BITNET (Mailer R2.05) with BSMTP id 9730; Wed, 28 Nov 90 14:26:36 EDT Date: Wed, 28 Nov 90 14:13:18 EDT From: Gaulle Bernard Subject: DVI2TTY (C version) To: TEX-IMPLEMENTORS Eureka| After few weeks searching for Marcel J.E. MOL around the world, i've found this dutch man (don't ask me how, I don't know|) at the university of Delft. He as merged my modifications about accents and tt fonts usage, with his own version which is now: DVI2TTY V4.4 ------------ I'd be pleased to see his name on this list if it's possible to extend it a lot: Marcel J.E. Mol I can give a copy of DVI2TTY to any archiver who ask me but i prefer that he ask directly Marcel for that. (note that DVI2TTY is going together with DISDVI which is a DVITYPE-like pgm). For the benefit of all TeX users... Bernard GAULLE 17-Dec-90 7:22:25-GMT,2627;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:TEX@rmcs.cranfield.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10331; Mon, 17 Dec 90 14:22:11 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Mon, 17 Dec 90 15:56:40-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <6461-0@sun2.nsfnet-relay.ac.uk>; Mon, 17 Dec 1990 20:26:00 +0000 Received: from sun2.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa13012; 17 Dec 90 20:17 GMT Date: Mon, 17 DEC 90 20:28:48 GMT From: TEX@rmcs.cranfield.ac.uk To: TEX-IMPLEMENTORS <@nsfnet-relay.ac.uk:TEX-IMPLEMENTORS@math.ams.com> Subject: ANyone got some (small) sample .VPL files? Actually-To: Sender: "JANET TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <00000DBF_0017A370.0094156634BC9A00$36_1@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: INTERNET%COM.AMS.MATH::TEX-IMPLEMENTORS Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) I'm about to add virtual font support to my DVItoLN03 program. The only examples of Virtual Property List files that I have seen (except in the Web of vptovf) are for remapping Adobe fonts to TeX (or should that be vice versa). Such virtual fonts will be singularly useless to me for testing an LN03 program (non-PostScript) so I wonder if anyone out there has any suitable small sample VPL files that I could use. If you have, please mail me directly. If I don't hear anything within the next few days, I suppose I'll have to go off and write my own }:-< Many thanks, in advance, Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: ...!mcvax!rmcs.cranfield.ac.uk!tex + + OR ...!ukc!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 22-Dec-90 18:22:37-GMT,3465;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08331; Sat, 22 Dec 90 11:22:35 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA04470; Sat, 22 Dec 90 10:21:17 -0800 Date: Sat, 22 Dec 90 10:21:17 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9012221821.AA04470@june.cs.washington.edu> To: cnix!klaus@relay.EU.net, karl@cs.umb.edu, morgan@ics.uci.edu Cc: elisabet@max.u.washington.edu, beebe@science.utah.edu Subject: SunOS 4.1 I finally got my hands on a Sparcstation running 4.1, so that I could work out the problems with the Sunview version of sun.c in mf/MFwindows. There are two. The conflict between the definition of reset in extra.h and cg9reg.h is easy, since reset() is unused in sun.c (is it ever used anywhere? or is it just a fossil from the Pascal-H compiler on SAIL?). All we need to do is #undef reset before the inclusion of any suntool/*.h files. But that unmasks a flood of new problems, all of which are related to the fact that 4.1 (at least in the U. S.) is now an enviroment which favors _POSIX_SOURCE compilations. The suntool include files have not been upgraded to POSIX, and my suspicion is that this exclusion is deliberate, to force the use of OpenLook. They require a whole collection of BSD types which seem not to work very well inside a POSIX environment. Moreover, if _POSIX_SOURCE is defined it does no good to include because there is an #ifdef _POSIX_SOURCE which effectively turns types.h into a no-op. So the only answer is to turn of _POSIX_SOURCE temporarily, which I do thus. -------------------------------- *** old_sun.c Fri Dec 21 15:25:18 1990 --- sun.c Fri Dec 21 15:36:42 1990 *************** *** 17,24 **** --- 17,43 ---- #ifdef SUNWIN #include + /* + * In SunOS 4.1, presumably to force users into OpenLook, + * Sun has established a general _POSIX_SOURCE environment, + * but has left the suntool include files outside this + * environment. They are therefore thick with typedefs + * incompatible with the remainder of the compilation. + * We cure it thus. + */ + #undef BACK_TO_POSIX /* Play it absolutely safe */ + #ifdef _POSIX_SOURCE + #define BACK_TO_POSIX + #undef _POSIX_SOURCE + #endif + #include /* Some old BSD types for suntool h files */ + #undef reset /* We don't need it, and it conflicts with cg9reg.h */ #include #include + #ifdef BACK_TO_POSIX + #define _POSIX_SOURCE + #undef BACK_TO_POSIX + #endif static void repaint_proc(); static void resize_proc(); ---------------------------------------- I hope to have access to an OpenLook system fairly soon, and will then try to provide both a Sunview and an Xview version. The difference is not supposed to be very great. PS to klaus: Since you were not forced into the _POSIX_SOURCE environment, I can only assume that POSIX is not a part of the export version of SunOS4.1. That's a pity, if so, because POSIX is really good stuff. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 12-Jan-91 2:29:16-GMT,11165;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:XITIKGUN@DDATHD21> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13373; Mon, 14 Jan 91 03:29:09 MST Message-Id: <9101141029.AA13373@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 14 Jan 91 05:23:33-EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2201; Mon, 14 Jan 91 05:15:53 EST Received: from PCSITI.FB20.THD.DA.EUROPE by DDATHD21.BITNET via GNET with RJE with RCOM ; 14 Jan 91 11:17:34 Date: Mon Jan 14 10:30:16 MET 1991 From: XITIKGUN%DDATHD21.BITNET@CUNYVM.CUNY.EDU Subject: bug in TeXtrie.chg version 2 To: TeX-implementors@math.ams.com X-Munix-To: TeX-implementors@math.ams.com The conversion from my trie extension scheme version 2.0 (distributed last summer) contained a bug. One line from version 1.1 was not changed any more. This bug was discovered recently by Bernd Raichle from Stuttgart. It may lead to wrong hyphenations, but fortunately enough this does not happen frequently with patterns currently in use. I include the updated version 2.1. The corresponding web2c diff change will be sent separately to Karl Berry for redistribution. Sorry for any inconveniences. Klaus Guntermann xitikgun@ddathd21 -------------------------------------cut here---------textrie.chg This is textrie.chg, Version 2.1, as of 09 January 1991. Changes to allow more than 256 trie operations in TeX 3.0. history ------- version 1.0 developed the basic changes (May 1990) version 2.0 redefined the trie data structure to avoid too many unused areas in memory if alignment is required. Thanks to Peter Breitenlohner (July 1990) version 2.1 reintroduces a change lost on conversion from 1.0 to 2.0 (type of |hyf_next| must be changed). Thanks to Bernd Raichle (January 1991). Klaus Guntermann, TH Darmstadt, FR Germany xitikgun@ddathd21.bitnet @x [1] s.11 @!trie_op_size=500; {space for ``opcodes'' in the hyphenation patterns} @y @!trie_op_size=750; {space for ``opcodes'' in the hyphenation patterns} @!min_trie_op=0; {first possible trie op code for any language} @!max_trie_op=500; {largest possible trie op code for any language} @z @x [42] s.920 Comparatively few different number sequences $n_0\ldots n_k$ actually occur, since most of the |n|'s are generally zero. Therefore the number sequences are encoded in such a way that |trie_op|$(z_k)$ is only one byte long. If |trie_op(@t$z_k$@>)<>min_quarterword|, when $p_1\ldots p_k$ has matched the letters in |hc[(l-k+1)..l@,]| of language |t|, we perform all of the required operations for this pattern by carrying out the following little program: Set |v:=trie_op(@t$z_k$@>)|. Then set |v:=v+op_start[t]|, |hyf[l-hyf_distance[v]]:=@tmax@>(hyf[l-hyf_distance[v]], hyf_num[v])|, and |v:=hyf_next[v]|; repeat, if necessary, until |v=min_quarterword|. @y The theory that comparatively few different number sequences $n_0\ldots n_k$ actually occur, since most of the |n|'s are generally zero, seems to fail at least for the large German hyphenation patterns. Therefore the number sequences cannot any longer be encoded in such a way that |trie_op|$(z_k)$ is only one byte long. We have introduced a new constant |max_trie_op| for the maximum allowable hyphenation operation code value; |max_trie_op| might be different for \TeX\ and \.{INITEX} and must not exceed |max_halfword|. An opcode will occupy a halfword if |max_trie_op| exceeds |max_quarterword| or a quarterword otherwise. @^system dependencies@> If |trie_op(@t$z_k$@>)<>min_trie_op|, when $p_1\ldots p_k$ has matched the letters in |hc[(l-k+1)..l@,]| of language |t|, we perform all of the required operations for this pattern by carrying out the following little program: Set |v:=trie_op(@t$z_k$@>)|. Then set |v:=v+op_start[t]|, |hyf[l-hyf_distance[v]]:=@tmax@>(hyf[l-hyf_distance[v]], hyf_num[v])|, and |v:=hyf_next[v]|; repeat, if necessary, until |v=min_trie_op|. @z @x [42] s.920 @!trie_pointer=0..trie_size; {an index into |trie|} @y @!trie_opcode=min_trie_op..max_trie_op; {a trie opcode} @!trie_pointer=0..trie_size; {an index into |trie|} @z @x [42] s.921 @ @d trie_link(#)==trie[#].rh {``downward'' link in a trie} @d trie_char(#)==trie[#].b1 {character matched at this trie location} @d trie_op(#)==trie[#].b0 {program for hyphenation at this trie location} @y @ For more than 255 trie op codes, the three fields |trie_link|, |trie_char|, and |trie_op| will no longer fit into one memory word; thus we define |trie| as a record of arrays instead of an array of records. This will result in more economic memory usage. @d trie_link(#)==trie.trl[#] {``downward'' link in a trie} @d trie_char(#)==trie.trc[#] {character matched at this trie location} @d trie_op(#)==trie.tro[#] {program for hyphenation at this trie location} @z @x [42] s.921 @!trie:array[trie_pointer] of two_halves; {|trie_link|, |trie_char|, |trie_op|} @y @!trie: packed record@;@/ @!trl:array[trie_pointer] of halfword; {|trie_link|} case two_choices of 1: (@!tro:array[trie_pointer] of trie_opcode; {|trie_op|} @!trc:array[trie_pointer] of quarterword); {|trie_char|} 2: (@!trb:array[trie_pointer] of halfword); {|trie_back|} end; @z @x [42] s.921 @!hyf_next:array[1..trie_op_size] of quarterword; {continuation code} @y @!hyf_next:array[1..trie_op_size] of trie_opcode; {continuation code} @z The next changes merely change from the old types and constants to the new ones. This is straight forward. @x [42] s.923 begin if trie_op(z)<>min_quarterword then @y begin if trie_op(z)<>min_trie_op then @z @x [42] s.924 until v=min_quarterword; @y until v=min_trie_op; @z @x [42] s.943 |hyf_next[@t$v^\prime$@>]=min_quarterword|. @y |hyf_next[@t$v^\prime$@>]=min_trie_op|. @z @x [42] s.943 $$\hbox{|@t$v^\prime$@>:=new_trie_op(0,1,min_quarterword)|,\qquad @y $$\hbox{|@t$v^\prime$@>:=new_trie_op(0,1,min_trie_op)|,\qquad @z @x [43] s.943 @!trie_used:array[ASCII_code] of quarterword; @y @!trie_used:array[ASCII_code] of trie_opcode; @z @x [43] s.943 @!trie_op_val:array[1..trie_op_size] of quarterword; @y @!trie_op_val:array[1..trie_op_size] of trie_opcode; @z @x [43] s.943 tini @y tini@; @!max_op_used:trie_opcode; {largest opcode used for any language} @!small_op:boolean; {flag used while dumping or undumping} @z @x [43] s.944 |new_trie_op| could return |min_quarterword| (thereby simply ignoring @y |new_trie_op| could return |min_trie_op| (thereby simply ignoring @z @x [43] s.944 function new_trie_op(@!d,@!n:small_number;@!v:quarterword):quarterword; label exit; var h:-trie_op_size..trie_op_size; {trial hash location} @!u:quarterword; {trial op code} @y function new_trie_op(@!d,@!n:small_number;@!v:trie_opcode):trie_opcode; label exit; var h:-trie_op_size..trie_op_size; {trial hash location} @!u:trie_opcode; {trial op code} @z @x [43] s.944 if u=max_quarterword then overflow("pattern memory ops per language", max_quarterword-min_quarterword); incr(trie_op_ptr); incr(u); trie_used[cur_lang]:=u; @y if u=max_trie_op then overflow("pattern memory ops per language", max_trie_op-min_trie_op); incr(trie_op_ptr); incr(u); trie_used[cur_lang]:=u; if u>max_op_used then max_op_used:=u; @z @x [43] s.945 op_start[0]:=-min_quarterword; @y op_start[0]:=-min_trie_op; @z @x [43] s.946 for k:=0 to 255 do trie_used[k]:=min_quarterword; @y for k:=0 to 255 do trie_used[k]:=min_trie_op; @z @x [43] s.946 trie_op_ptr:=0; @y max_op_used:=min_trie_op; trie_op_ptr:=0; @z @x [43] s.947 @t\hskip10pt@>@!trie_o:packed array[trie_pointer] of quarterword; @y @t\hskip10pt@>@!trie_o:packed array[trie_pointer] of trie_opcode; @z @x [43] s.950 @d trie_back(#)==trie[#].lh {backward links in |trie| holes} @y @d trie_back(#)==trie.trb[#] {backward links in |trie| holes} @z @x [43] s.958 @= h.rh:=0; h.b0:=min_quarterword; h.b1:=min_quarterword; {|trie_link:=0|, |trie_op:=min_quarterword|, |trie_char:=qi(0)|} if trie_root=0 then {no patterns were given} begin for r:=0 to 256 do trie[r]:=h; @y @d clear_trie == {clear |trie[r]|} begin trie_link(r):=0; trie_op(r):=min_trie_op; trie_char(r):=min_quarterword; {|trie_char:=qi(0)|} end @= if trie_root=0 then {no patterns were given} begin for r:=0 to 256 do clear_trie; @z @x [43] s.958 repeat s:=trie_link(r); trie[r]:=h; r:=s; @y repeat s:=trie_link(r); clear_trie; r:=s; @z @x [43] s.960 @!v:quarterword; {trie op code} @y @!v:trie_opcode; {trie op code} @z @x [43] s.963 if trie_o[q]<>min_quarterword then @y if trie_o[q]<>min_trie_op then @z @x [43] s.964 trie_c[p]:=si(c); trie_o[p]:=min_quarterword; @y trie_c[p]:=si(c); trie_o[p]:=min_trie_op; @z @x [43] s.965 l:=k; v:=min_quarterword; @y l:=k; v:=min_trie_op; @z @x [43] m.966 @!h:two_halves; {template used to zero out |trie|'s holes} @y @z @x [50] s.1324 @ @= @y @ Depending on whether the largest trie op code used for any language (|max_op_used|) does or doesn't exceed |max_quarterword|, two or four op codes are packed into one memory word in the format file. @d dump_two_halves(#)== begin fmt_file^.hh.lh:=#(k); fmt_file^.hh.rh:=#(k+1); put(fmt_file); end @d dump_four_quarters(#)== begin fmt_file^.qqqq.b0:=#(k); fmt_file^.qqqq.b1:=#(k+1); fmt_file^.qqqq.b2:=#(k+2); fmt_file^.qqqq.b3:=#(k+3); put(fmt_file); end @= @z @x [50] s.1324 for k:=0 to trie_max do dump_hh(trie[k]); @y dump_int(max_op_used); small_op:=(max_op_used<=max_quarterword);@/ k:=0; while k+1= @y @d undump_two_halves(#)== begin get(fmt_file); #(k):=fmt_file^.hh.lh; #(k+1):=fmt_file^.hh.rh; end @d undump_four_quarters(#)== begin get(fmt_file); #(k):=fmt_file^.qqqq.b0; #(k+1):=fmt_file^.qqqq.b1; #(k+2):=fmt_file^.qqqq.b2; #(k+3):=fmt_file^.qqqq.b3; end @= @z @x [50] s.1325 for k:=0 to j do undump_hh(trie[k]); @y undump_size(min_trie_op)(max_trie_op)('max trie op')(max_op_used); small_op:=(max_op_used<=max_quarterword);@/ k:=0; while k+1 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07216; Thu, 17 Jan 91 02:53:33 MST Message-Id: <9101170953.AA07216@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 17 Jan 91 04:06:24-EDT Received: from FRORS12.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0619; Thu, 17 Jan 91 03:58:17 EST Received: from FRORS12 (UCIR001) by FRORS12.BITNET (Mailer R2.07) with BSMTP id 7362; Thu, 17 Jan 91 10:00:20 EDT Date: Thu, 17 Jan 91 09:56:54 EDT From: Gaulle Bernard Subject: MLTeX V3 Change file archived To: LSV IMPLEM The mulitilingual modifications from Michael FERGUSON for TeX V3 are now archived on and can be retrieved by the mean of the following message line : GET MLTEX3 CHG GUT Bernard GAULLE (GUTenberg President) 3-Feb-91 16:06:11-GMT,1439;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06848; Sun, 3 Feb 91 09:06:07 MST Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Sun, 3 Feb 91 11:03:37-EDT Date: Sun, 3 Feb 1991 04:42 PST From: Don Hosek Subject: \openin and texinputs: To: tex-implementors@math.ams.com, rokicki@neon.stanford.edu Message-Id: <99E749FBBA60127B@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: in%"tex-implementors@math.ams.com" X-Vms-Cc: tom_rokicki After a check to the source code w.r.t an apparent discrepancy in two TeX implementations' treatments of \openin and texinputs, I have determined that it is _incorrect_ for \openin15=foo.tex to find foo.tex on the texinputs: path. This means, e.g., that the LaTeX internal macro \@input should give a file does not exist message when used on a file not in the current directory since it uses \openin to check for the file's existence. It is possible to write an \@input-like macro which will check tex_inputs: as well by doing a second \openin on texinputs:filename, *but* such an approach is system dependent since texinputs will have a different value depending on the precise system (e.g., PCTeX uses TEXINPUT:, VMS TeX uses TeX_inputs: (or sometimes, incorrectly, TeX$inputs:) etc.) -dh 4-Feb-91 9:10:42-GMT,2428;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05010; Mon, 4 Feb 91 02:10:38 MST Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 03:35:47-EDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA05518; Mon, 4 Feb 91 09:31:48 +0100 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA15342; Mon, 4 Feb 91 09:31:46 +0100 Date: Mon, 4 Feb 91 09:31:46 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9102040831.AA15342@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-implementors@math.ams.com, rokicki@neon.stanford.edu, PZF5HZ@RUIPC1E.bitnet In-Reply-To: Don Hosek's message of Sun, 3 Feb 1991 04:42 PST <99E749FBBA60127B@HMCVAX.CLAREMONT.EDU> Subject: \openin and texinputs: From: Don Hosek After a check to the source code w.r.t an apparent discrepancy in two TeX implementations' treatments of \openin and texinputs, I have determined that it is _incorrect_ for \openin15=foo.tex to find foo.tex on the texinputs: path. This means, e.g., that the LaTeX internal macro \@input should give a file does not exist message when used on a file not in the current directory since it uses \openin to check for the file's existence. It is possible to write an \@input-like macro which will check tex_inputs: as well by doing a second \openin on texinputs:filename, *but* such an approach is system dependent since texinputs will have a different value depending on the precise system (e.g., PCTeX uses TEXINPUT:, VMS TeX uses TeX_inputs: (or sometimes, incorrectly, TeX$inputs:) etc.) I think that there doesn't exist a definite answer to the question whether it is correct or incorrect. The most widely applicable solution would certainly be to have two environment variables, one for \input, one for \openin. From experience I favor the use of TEXINPUTS: for \input as well as for \openin. Dr. Rainer Sch\"opf Konrad-Zuse-Zentrum f\"ur Informationstechnik Berlin Heilbronner Strasse 10 D-1000 Berlin 31 Federal Republic of Germany or 4-Feb-91 11:38:15-GMT,4210;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:TEX@rmcs.cranfield.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07542; Mon, 4 Feb 91 04:38:09 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 06:35:29-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <4057-81@sun2.nsfnet-relay.ac.uk>; Mon, 4 Feb 1991 11:29:22 +0000 Received: from sun2.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa04854; 4 Feb 91 10:53 GMT Date: Mon, 4 FEB 91 11:05:57 GMT From: TEX@rmcs.cranfield.ac.uk To: TEX-IMPLEMENTORS <@nsfnet-relay.ac.uk:TEX-IMPLEMENTORS@math.ams.com> Subject: Under what circumstances does TeX make overwide lines silently? Actually-To: Sender: "JANET TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <00005B9F_001AB710.00943B98B108F880$11_1@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: INTERNET%COM.AMS.MATH::TEX-IMPLEMENTORS Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) I've been making extensive modifications to my DVItoLN03 driver program (official announcement shortly), but was somewhat perturbed to discover that there were seemingly a large number of pages which contained lines extending into the right margin when processing the .dvi generated by TeXing the woven source. My first suspicion was that I'd upset the careful sp-to-pixel rounding computation (inherited from DVItype many years ago), but running one of the offending pages through DVItype reveals that TeX has truly exceeded its right margin, by amounts varying between 0.1422pt and 9.1411pt, _without_ TeX making any complaint about an overfull \hbox (there are some other instances, where the excess is 3.2796pt and 10.5424pt, where TeX _has_ given such a message, and moreover added a further 5pt for the overfullrule). In all cases, the offending text sticks out to the right of the page; mostly it's not very noticeable, because the problems have arisen in the formatted Pascal, so there's no block of justified text to have its symmetry disturbed. But a few of the occasions are in the ``See also sections...'' at the end of Pascal code, and the bad setting is noticeable. Has anyone met this phenomenon before; I presume it's something defined in the webmac macros --- do they permit an overrun in preference to splitting a line of Pascal which it considers belongs on one line? This might tie in with those occasions when TeX has complained about the line, because all these instances occur in the TeX narrative at the start of a Web section (reason: lines containing \tt text at end of line). One other thing that I noticed: in the index there are a number of occasions with overfull lines (columns actually). When TeX added the overfullrule, it overlapped approx half of the asterisk indicating a changed section: could this explain it failing to detect the overfull lines in ``See also sections...'', because Weave hides the width of the asterisk? Furthermore, TeX only inserts the overfullrule if such on overflow occurs in the left column of the two on the index pages. ALtogether, there seem to be a number of anomalies here! Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: ...!mcvax!rmcs.cranfield.ac.uk!tex + + OR ...!ukc!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4-Feb-91 11:38:19-GMT,919;000000000001 Return-Path: <@MATH.AMS.COM:ogawa@orion.arc.nasa.gov> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AB07542; Mon, 4 Feb 91 04:38:16 MST Received: from orion.arc.nasa.gov by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 06:40:42-EDT Received: Mon, 4 Feb 91 03:44:22 -0800 by orion.arc.nasa.gov (5.64/1.2) Date: Mon, 4 Feb 91 03:44:22 -0800 From: "Arthur Ogawa" Message-Id: <9102041144.AA20273@orion.arc.nasa.gov> To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-implementors@math.ams.com, rokicki@neon.stanford.edu In-Reply-To: Don Hosek's message of Sun, 3 Feb 1991 04:42 PST <99E749FBBA60127B@HMCVAX.CLAREMONT.EDU> Subject: \openin and texinputs: Yes, the relevant sections are 537 and 1275, which appear similar to a degree, but fall short of being identical: TeX_area is only applied to \input, not to \openin. I'll be curious to see how this comes out. 4-Feb-91 13:27:11-GMT,3284;000000000001 Return-Path: <@MATH.AMS.COM,@BULLDOG.CS.YALE.EDU:lrw!leichter@LRW.COM> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08410; Mon, 4 Feb 91 06:27:06 MST Received: from BULLDOG.CS.YALE.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 08:20:28-EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Mon, 4 Feb 91 08:09:05 EST Message-Id: <9102041309.AA22880@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Mon, 4 Feb 91 07:11:40 EDT Date: Mon, 4 Feb 91 07:11:40 EDT From: Jerry Leichter To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: RE: \openin and texinputs: After a check to the source code w.r.t an apparent discrepancy in two TeX implementations' treatments of \openin and texinputs, I have determined that it is _incorrect_ for \openin15=foo.tex to find foo.tex on the texinputs: path. This means, e.g., that the LaTeX internal macro \@input should give a file does not exist message when used on a file not in the current directory since it uses \openin to check for the file's existence. It is possible to write an \@input-like macro which will check tex_inputs: as well by doing a second \openin on texinputs:filename, *but* such an approach is system dependent since texinputs will have a different value depending on the precise system (e.g., PCTeX uses TEXINPUT:, VMS TeX uses TeX_inputs: (or sometimes, incorrectly, TeX$inputs:) etc.) In the TeXbook, I see almost no difference between the definitions of \input and \openin. Actually, the one difference I see is problematical: It is mentioned that \openin, on "most" systems, adds a ".tex". But the "defini- tion" of \input (page 214) doesn't say this. (I don't know if it says it anywhere.) The interface between TeX and a particular system necessarily has some fuzzy spots. Knowing just what "a file name" is is one of them. Once you agree that "a filename" can be manipulated by adding ".tex" - something the TeXbook already does - the gates open wide. I don't know in what sense it can be "incorrect" for any implementation to define the processing of the file name "foo.tex" as meaning "foo.tex on the texinputs path". However, it can certainly be a very useful thing to do - exactly because this kind of manipu- lation is impossible to do portably in TeX. (The fact that exact names for the "device" vary from system to system is minor: At least on many systems you can write "path:" in front of the file and be done with it. But on Unix systems, a search path is typically just an environment value, and there is NO file-system support for it; any program that wishes to follow a path must do so on its own. Since there is no way for a portable TeX program to read an environment value, Unix TeX programs would be have to be hard-coded to look in some particular list of directories.) Imposing a standard is a great idea - unless that standard requires programs to not be useful. A TeX implementation that required that macro packages be locally adjusted to the details of the local file system arrangement - even to each particular machine - would not be used by many people. How many sites have a LaTeX guru able to modify \@input to reflect the local directory paths? -- Jerry 4-Feb-91 13:54:20-GMT,981;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08623; Mon, 4 Feb 91 06:54:16 MST Date: Mon 4 Feb 91 08:49:01-EST From: bbeeton Subject: re: \openin and texinputs: To: tex-implementors@VAX01.AMS.COM Message-Id: <665675341.0.BNB@MATH.AMS.COM> Mail-System-Version: i have checked the treatment of \openin and \input in the implementations of tex available to me, which include that for tops-20. since the tops-20 implementation was done at stanford with at least some coordination directly with don knuth, i believe it is the best guide we have at the moment. the tops-20 implementation clearly searches texinputs: for \openin as well as \input . however, since i still don't consider this evidence definitive, i am sending the question to don and asking for his adjudication, which i will forward forthwith to this list. -- bb ------- 4-Feb-91 14:56:51-GMT,816;000000000001 Return-Path: <@MATH.AMS.COM:jmr@nada.kth.se> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09211; Mon, 4 Feb 91 07:56:45 MST Received: from nada.kth.se by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 09:50:56-EDT Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03506; Mon, 4 Feb 91 15:45:30 +0100 Date: Mon, 4 Feb 91 15:45:30 +0100 From: Jan Michael Rynning To: tex-implementors@math.ams.com Subject: re: \openin and texinputs: Message-Id: Strange. The TOPS-20 TeX that we run searches TeXinputs: for \input, but not for \openin, and I'm sure we haven't changed the code. Barbara, are you sure you haven't made any local changes, and that you don't have TeXinputs: in your definition of DSK:? 4-Feb-91 15:06:33-GMT,1197;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09293; Mon, 4 Feb 91 08:06:27 MST Date: Mon 4 Feb 91 10:00:58-EST From: bbeeton Subject: re: \openin and texinputs: To: jmr@nada.kth.se Cc: tex-implementors@MATH.AMS.COM Message-Id: <665679658.0.BNB@MATH.AMS.COM> In-Reply-To: Mail-System-Version: jan, you're actually on the right track, though backwards -- we have texinputs defined to be dsk: . the point is, though, that with tops-20 it's easy to define a path instead of a single directory, and it was just as easy with the sail system, so it's unclear to me whether don realized the implications of the difference. i shall phrase my inquiry to him as carefully as i can to yield a clear statement of intent. re the domain on the "to:" field from our mailer, i hadn't realized that would be a problem. it should cause no problems for me to add an explicit domain to the designation of tex-implementors right in the mailing list, and i shall do so after checking. thanks for the pointer. -- bb ------- 4-Feb-91 16:16:06-GMT,3056;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10106; Mon, 4 Feb 91 09:16:01 MST Date: Mon 4 Feb 91 11:09:48-EST From: bbeeton Subject: [Philippe.Louarn%IRISA.FR@CUNYVM.CUNY.EDU: russian TeX] To: tex-implementors@VAX01.AMS.COM Message-Id: <665683788.0.BNB@MATH.AMS.COM> In-Reply-To: <665683131.0.RFW@MATH.AMS.COM> Mail-System-Version: the following message was circulated to the gut mailing list. i believe it may be of interest to most people on this list as well. --------------- Date: Mon, 4 Feb 91 09:31:28 +0100 Reply-To: Groupe francophone des Utilisateurs TeX Sender: Groupe francophone des Utilisateurs TeX From: Philippe.Louarn%IRISA.FR@CUNYVM.CUNY.EDU Subject: russian TeX J'ai recu le mail suivant. Il doit interesse les personnes utilisant TeX pour des textes russes. Philippe Louarn - Secretariat GUTenberg, c/o Irisa, Rennes ------- Forwarded Message Date: 30 Jan 91 17:43:00 GMT+3:00 From: "MX::MALYSHEV" Subject: TeX To: "gut" ================================================================= Russian \TeX % Basil Malyshev (IHEP, USSR) and Alexander Samarin (IHEP, USSR) Currently TeX-ware is the set of programs which have a lot of tuning parameters. To install and run TeX on IBM-PC one needs to know many hardware and software parameters. Special software or powerful command interpreter is needed to organize joint work of programs with good user's interface. MS-DOS shell COMMAND.COM and alternative shell 4DOS are not enough powerfull. Another problem is that full \TeX collection (e.g. Em\TeX with extension for russian \TeX) occupies a lot of hard disk space, while a particular task requires only part of programs and fonts. We have implemented a interpreter (x)RUN with LISP-like language. It supports operations with files and environment variables, running of programs (possibly overlay), user menu interface (with/without mouse) and something else. For Em\TeX collection we have implemented an integrated shell, based on (x)RUN. This shell has the following features: - it is able to reconfigurate the environment and download required files; - changeable lists of procedures are associated with file extensions. E.g. for .TEX file one can run \TeX, \LaTeX, an editor or spelling procedure. For .DVI file one can run a previewer or printer DVI-driver. - it is possible to check the accessibility of the pixel files for printing a DVI-file and to download them from the distribution kit. - one may add his own procedures to the shell. ================================================================= B. Malyshev E-mail: malyshev@m9.ihep.su ------- End of Forwarded Message ------- 5-Feb-91 3:37:31-GMT,1070;000000000001 Return-Path: <@MATH.AMS.COM:ken@tucana.csis.dit.csiro.au> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA18393; Mon, 4 Feb 91 20:37:27 MST Received: from tucana.csis.dit.csiro.au by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 18:11:17-EDT Received: from localhost.csis.dit.csiro.au by tucana.csis.dit.csiro.au (4.1/1.0) id AA13354; Tue, 5 Feb 91 10:04:03 EST Message-Id: <9102042304.AA13354@tucana.csis.dit.csiro.au> To: tex-implementors@math.ams.com Subject: paper sizes in LaTeX Reply-To: ken@csis.dit.csiro.au (Ken Yap) X-Internet: ken@csis.dit.csiro.au X-Snail: CSIS, CSIRO DIT, PO Box 664, Canberra ACT 2601, Australia X-Phone: (06) 275-0911 (office) Fax: (06) 257-1052 Date: Tue, 05 Feb 91 10:04:00 +1100 From: ken@tucana.csis.dit.csiro.au Forgive me if I'm out of date, but are international LaTeX implementors also dealing with the paper size issue? It always seemed a parochialism to me that non-USA users have to put [a4] in their \documentstyle when this should be a preloaded local setting, like hyphen.tex. Ken 7-Feb-91 0:18:00-GMT,2906;000000000001 Return-Path: <@MATH.AMS.COM:ogawa@orion.arc.nasa.gov> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA20686; Wed, 6 Feb 91 17:17:56 MST Received: from orion.arc.nasa.gov by MATH.AMS.COM via SMTP with TCP; Wed, 6 Feb 91 19:16:55-EDT Received: Wed, 6 Feb 91 16:21:14 -0800 by orion.arc.nasa.gov (5.64/1.2) Date: Wed, 6 Feb 91 16:21:14 -0800 From: "Arthur Ogawa" Message-Id: <9102070021.AA19916@orion.arc.nasa.gov> To: CET1@phoenix.cambridge.ac.uk Cc: tex-implementors@math.ams.com In-Reply-To: Chris Thompson's message of Wed, 06 Feb 91 17:50:37 GMT Subject: \openin and texinputs: A clarification of LaTeX functionality WRT opening files may inform this discussion a bit. LaTeX has two ways of opening files for input; they differ in the way they work based on the precise difference between \openin and \input (which has been the subject of this discussion). 1. \input (with or without a delimited argument) does the same as the primitive \input. This macro will use the TeX_area internal to possibly provide a search path. Your .sty files and .bbl files are handled this way. 2. \include (or \@input) will only open a file in the current directory (modulo system dependencies, see below). This is the way LaTeX deals with reading your \included files and any files that LaTeX manages (such as .aux, .toc, etc, .idx). LaTeX does not do an \openin before doing an \openout to check whether a file is already there. It goes ahead and blithely clobbers. On the other hand, it scrupulously does an \@input for any file it generates itself. This ensures that the file it reads is the very file it wrote (clever, Leslie). Now, method (2) is important for .aux files, because I don't want LaTeX to read in .aux information for any file but the one I'm \including. And method (1) is important because I want to read my .sty and .bbl files from anywhere they may be. However, there may be cases where I want to perform some action based on whether an \input suceeded. TeX does not provide any way for me to check this; instead it provides a means of ensuring that the process never fails ("please type a file name:"). So I haven't any way to accomplish this check. However, I could if there were a way for the user to cancel out of the file name: prompt, say with a ^C (or Cancel on a windowing system). An extension to TeX that would still pass the trip test would be to provide a \ifcanceled command a la \ifeof. A note on system dependencies: any fileopen action on the Macintosh has the attributes of a search path: the poor man's search path (PMSP). This is a well-known paradigm to any one familiar with Inside Mac. The current directory is searched, followed by the application's directory, followed by the system folder. This search is done even for an \openin! 8-Feb-91 0:40:39-GMT,1155;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07348; Thu, 7 Feb 91 17:40:34 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Thu, 7 Feb 91 19:37:23-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA29159; Thu, 7 Feb 91 16:31:47 -0800 Date: Thu, 7 Feb 91 16:31:47 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9102080031.AA29159@june.cs.washington.edu> To: ken@csis.dit.csiro.au Cc: tex-implementors@math.ams.com In-Reply-To: ken@tucana.csis.dit.csiro.au's message of Tue, 05 Feb 91 10:04:00 +1100 <9102042304.AA13354@tucana.csis.dit.csiro.au> Subject: paper sizes in LaTeX I am sure I have seen a4.sty and a5.sty around somewhere. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Feb-91 1:14:36-GMT,2539;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07653; Thu, 7 Feb 91 18:14:35 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA04341; Thu, 7 Feb 91 17:13:17 -0800 Date: Thu, 7 Feb 91 17:13:17 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9102080113.AA04341@june.cs.washington.edu> To: karl@cs.umb.edu Cc: beebe@science.utah.edu, bnb@math.ams.com, spqr@ecs.southampton.ac.uk, dhosek@ymir.claremont.edu In-Reply-To: Karl Berry's message of Tue, 5 Feb 91 17:26:48 EST <9102052226.AA03082@ra.cs.umb.edu> Subject: more TeX font stuff 1) text font encoding. I can't wait. My only question is what do we call it. I am hoping that Don will accept E[xtended]CM* which is clearly different from CM* but keeps the reference to the basic style. 2) more \fontdimens For the same reasons, that more information beats ignorance every time, I applaud the notion of adding informative \fontdimen values. I haven-t tried yet, but I think this might be done without affecting the tfm checksum. I will experiment. In that case it could be done even in CM, but I would still prefer to get Don's blessing on that. 3) more mode_defs Doug Henderson and I have been talking about that. I submitted several recently, and I am working on a TUGboat article on how to go at it systematically, rather than by a sort of naval gunnery ranging approach. 4) GF specials The GF specials were thoroughly worked over about three years ago and the basic web for gftopk was actually altered to make them pass unaltered through to the pk file and to retain the METAFONT banner dating. Especially when there is a need to check whether a 300dpi font really belongs in the write-white or the write-black directories, it can be a real saver to have this info. Since they do not alter the tfm checksum, Don has given them the OK. 5) many mode_defs. U_Wash.mf now includes twenty. Moreover, if you forget their names, a simple questionmark will list all the preloaded mode_defs presently loaded. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Feb-91 1:40:37-GMT,1915;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07858; Thu, 7 Feb 91 18:40:35 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA07150; Thu, 7 Feb 91 17:39:39 -0800 Date: Thu, 7 Feb 91 17:39:39 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9102080139.AA07150@june.cs.washington.edu> To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: @cs.umb.edu:karl@ra.cs.umb.edu, beebe@science.utah.edu, bnb@math.ams.com, spqr@ecs.soton.ac.uk, x066tr@tamvm1.BITNET.washington.edu In-Reply-To: Don Hosek's message of Tue, 5 Feb 1991 18:08 PST <9CDF53C120E0053A@HMCVAX.CLAREMONT.EDU> Subject: more TeX font stuff All you need to do to get an smode version is to take the mode-def out of the collection and put % before the first and last lines. Voila, This would be the smode file "VarityperSixZeroZero.mf" % mode_def VarityperSixZeroZero = proofing:=0; % no, we're not making proofs fontmaking:=1; % yes, we are making a font tracingtitles:=0; % no, don't show titles at all pixels_per_inch:=600; % Good but not perfect blacker:=0; % Seems black enough. Lighter than 300dpi fillin:=0; % but it ought to be. Closer to true o_correction:=0.8; % Modern proportions. Real problem is % enddef; % toner irregularity Better, I think to explain how to do it, than to keep a whole lot of duplicate mode_defs. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Feb-91 17:09:58-GMT,2425;000000000001 Return-Path: <@MATH.AMS.COM:beebe@math.utah.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09848; Fri, 8 Feb 91 10:09:52 MST Received: from math.utah.edu by MATH.AMS.COM via SMTP with TCP; Fri, 8 Feb 91 12:05:51-EDT Received: from magna.math.utah.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09750; Fri, 8 Feb 91 10:00:49 MST Date: Fri, 8 Feb 91 10:00:49 MST From: Nelson H.F. Beebe To: tex-implementors@math.ams.com X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: Re: \openin and texinputs: In-Reply-To: Your message of Wed, 06 Feb 91 17:50:37 GMT Message-Id: Chris Thompson writes: >> ... >> It has occured to me that one could make an optimization by >> keeping the when >> \closein is used on a file in the state |just_open| (i.e. \read >> has never been used) and reusing it directly if a \input for the >> same name follows shortly. Has anyone ever attempted to do >> anything like this in their implementations? >> ... I've thought about this for the DVI drivers: we currently have many directories in the TEXFONTS path, and were the driver to remember that last directory in which it found a font and try that first, instead of going to the start of the TEXFONTS path list, considerable speedups would be possible. In the vast majority of cases, this would work fine. It fails, however, in those cases where files of the same name exist in more than one directory (e.g. the user might have tuned personal versions of a few fonts); the directory search order implied by TEXFONTS would then not be obeyed. Still, the idea seems interesting, and I'm likely to make the directory caching an option to the 3.0 DVI drivers. Those would use only standard fonts could then enable it in their startup files, and those with more demanding requirements would simply leave it disabled. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== 8-Feb-91 17:15:56-GMT,930;000000000001 Return-Path: Received: from Neon.Stanford.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09918; Fri, 8 Feb 91 10:15:51 MST Received: by Neon.Stanford.EDU (5.61/25-eef) id AA08916; Fri, 8 Feb 91 09:15:50 -0800 Date: Fri, 8 Feb 91 09:15:50 -0800 From: Tomas G. Rokicki Message-Id: <9102081715.AA08916@Neon.Stanford.EDU> To: beebe@math.utah.edu Subject: Re: \openin and texinputs: In my opinion, directory caching and the like should be a function of the file system. Duplicating that functionality in user code on a reasonable file system will only slow things down. Any old systems that don't do directory caching should be running a more modern file system. Of course, I feel the same way about this flib/PK libraries; if your file system charges you so much overhead for small files, the file system should be fixed. Just my opinion, of course . . . -tom 8-Feb-91 19:04:29-GMT,1619;000000000001 Return-Path: <@MATH.AMS.COM:beebe@math.utah.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA11456; Fri, 8 Feb 91 12:04:18 MST Received: from math.utah.edu by MATH.AMS.COM via SMTP with TCP; Fri, 8 Feb 91 13:59:31-EDT Received: from magna.math.utah.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA11186; Fri, 8 Feb 91 11:54:01 MST Date: Fri, 8 Feb 91 11:54:01 MST From: Nelson H.F. Beebe To: mackay@cs.washington.edu (Pierre MacKay) Cc: ken@csis.dit.csiro.au, tex-implementors@math.ams.com X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: Re: paper sizes in LaTeX In-Reply-To: Your message of Thu, 7 Feb 91 16:31:47 -0800 Message-Id: Our latex directory has a4.sty and a4wide.sty, and I can mail them to anyone who needs them. It is clear that the designer of TeX, and designers of macro packages and DVI drivers, all made the mistake of not designing for a range of paper sizes, with both built-in standard sizes, and user-definable sizes. I've remedied that in my 3.0 DVI driver development, but only for the DVI end of things. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== 13-Mar-91 17:42:17-GMT,1129;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA11045; Wed, 13 Mar 91 10:42:03 MST Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 13 Mar 91 12:36:50-EDT Received: by smiley.Stanford.EDU (4.1/inc-1.0) id AA01423; Wed, 13 Mar 91 09:31:43 PST Date: Wed, 13 Mar 91 09:31:43 PST From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9103131731.AA01423@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: TeX fixes from Knuth up on labrea Hi, Knuth gave me a new set of patches for the TeX and Metafont sources on labrea. I've applied them in the same way that I applied the last set of patches that I received: At the top level the directory OLD.pre-Mar91 contains the original files as they were before the patches (the directory structure is maintained there as well). The file DIFFS.Mar91 is the file containing the context diffs that Knuth gave me. The new files are in their normal place with new motification times. Please let me know if you encounter any problems. Thanks, Dan 16-Mar-91 16:10:04-GMT,1115;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:UCIR001@FRORS12.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02610; Sat, 16 Mar 91 09:10:01 MST Message-Id: <9103161610.AA02610@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Sat, 16 Mar 91 11:05:56-EDT Received: from FRORS12.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8180; Sat, 16 Mar 91 10:58:17 EST Received: from FRORS12.BITNET (UCIR001) by FRORS12.BITNET (Mailer R2.07) with BSMTP id 3773; Sat, 16 Mar 91 17:00:58 EDT Date: Sat, 16 Mar 91 16:51:35 EDT From: Gaulle Bernard Subject: MLTeX To: LSV IMPLEM If TeX3 plus VF plus DCfonts is THE solution for implemntors, it's certainly no t a production tool today. First DCfonts are in beta test. Secondly few drivers are ready to use VF and 256 chars fonts. So, every day we use MLTeX 2/3 in production and it's a very good solution for e.g. french hyphenation and typographic requirements. Bernard GAULLE 18-Mar-91 21:47:31-GMT,816;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13793; Mon, 18 Mar 91 14:47:26 MST Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 18 Mar 91 16:33:50-EDT Received: by smiley.Stanford.EDU (4.1/inc-1.0) id AA00468; Mon, 18 Mar 91 13:28:33 PST Date: Mon, 18 Mar 91 13:28:33 PST From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9103182128.AA00468@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: new tex.web on labrea Knuth gave me a slightly updated version of tex.web that supercedes the one put up last week. It is now on labrea. Since there are only a few 'cosmetic' differences from that previous version, at his suggestion, I won't put a diffs file up there. Dan 15-Mar-91 16:37:48-GMT,1532;000000000001 Return-Path: <@MATH.AMS.COM,@BULLDOG.CS.YALE.EDU:lrw!leichter@LRW.COM> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25990; Fri, 15 Mar 91 09:37:43 MST Received: from BULLDOG.CS.YALE.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 15 Mar 91 11:32:51-EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Fri, 15 Mar 91 11:20:45 EST Message-Id: <9103151620.AA24175@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Fri, 15 Mar 91 10:25:43 EDT Date: Fri, 15 Mar 91 10:25:43 EDT From: Jerry Leichter To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: RE: fontname mapping file for TeX Good going! Obviously, as I wrote about this before, I think it's a good idea. I have may doubts about wild-carding, but it does have one saving grace: If you don't use wild-card characters, it doesn't hurt you. (This assumes that if there are no *'s in the spec you hand to \font, you get ONLY the exact match - not an implicit trailing *, or something like that.) Even with that, I'd find real text wildcarding a bad idea. It's one thing to say "give me Times Roman 10pt normal weight character set TeX-standard from any foundary", quite another to say "give me any font whose name happens to contain the characters TMR10NTS anywhere within it". Perhaps the X font-naming conventions are good enough to support this - I don't know enough about them. Without some control over how the matching is done, pure text wildcarding is just asking for trouble. -- Jerry 15-Mar-91 17:57:57-GMT,1103;000000000001 Return-Path: <@MATH.AMS.COM,@serv02:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26497; Fri, 15 Mar 91 10:57:50 MST Received: from serv02 by MATH.AMS.COM via SMTP with TCP; Fri, 15 Mar 91 12:51:34-EDT Received: from quattro.ZIB-Berlin.DE by serv02 (4.0/SMI-4.0-serv02/13.11.90) id AA18745; Fri, 15 Mar 91 18:46:20 +0100 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA16043; Fri, 15 Mar 91 18:46:15 +0100 Date: Fri, 15 Mar 91 18:46:15 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9103151746.AA16043@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: tex-implementors@math.ams.com In-Reply-To: Tomas G. Rokicki's message of Fri, 15 Mar 91 09:22:58 -0800 <9103151722.AA00775@Neon.Stanford.EDU> Subject: \charsubdef Could someone please explain to me why the MLTeX \charsubdef modifications are still necessary? I have the understanding that with TeX 3.x, virtual fonts and the new 256 character fonts we have all the tools we need? Rainer Sch\"opf 19-Mar-91 19:05:41-GMT,26115;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA20758; Tue, 19 Mar 91 12:05:29 MST Date: Tue 19 Mar 91 13:49:40-EST From: bbeeton Subject: Updates to TeX.WEB, MF.WEB, GFtoDVI, et al. To: TeX-implementors@VAX01.AMS.COM Message-Id: <669408580.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 19 Mar 90 Message No: 028 To: TeX implementors and distributors From: Barbara Beeton Subject: Updates to TeX.WEB, MF.WEB, GFtoDVI, et al. New versions of TeX.WEB, MF.WEB and other updates have been installed at labrea, as Dan Kolkowitz has reported. For the benefit of those who may not be able to ftp these files easily, this message contains some of the more important details: New files at labrea since 3 January 91 Changes to the errata list (ERRATA.SIX) Addenda to TeX82.BUG as of 13 March 91 Addenda to MF84.BUG as of 13 March 91 Differences between TeX.WEB 3.1 and 3.14 (as of 18 March 1991) Differences between TeX.WEB 3.0 and 3.1 (as of 21 September 1990) Differences between MF.WEB 2.0 and MF.WEB 2.7 (as of 13 March 1991) Cosmetic change, GFTODVI.WEB, ver 3.0 Differences in TeX.WEB are provided in two parts since the details of the update from version 3.0 to 3.1 was never reported in one of these messages. In fact, both TeX.WEB and MF.WEB have been updated twice, with only one version change, since the previous update. The most recent changes were, as Don Knuth says in the prose at the top, only cosmetic; cosmetic changes do not usually appear in the bug listings, but should generally be made to the main WEB files anyhow in order to keep in synch. This is the last time that it will be possible to provide the difference listings in this form. These difference listings were prepared with a TOPS-20 utility, and the Math Society's DEC-20 is being unplugged and de-installed tomorrow. We now have a couple of Unix workstations, and the Unix differencing utility seems to be the best replacement (as soon as I learn how to use it). Although the VAX/VMS DIFF utility does a good job of identifying differences, it adds a line number to each difference line, often resulting in lines of more than 80 characters in length; not a robust format for sending in e-mail across random network gateways. As usual, there have been a number of updates to this mailing list since the last time I sent a message directly, so if everyone receiving this message could please acknowledge it, that will help keep the list in good shape. ######################################################################## New files at labrea.stanford.edu since 3 Jan 91 /tex: -rw-r--r-- 1 468 fsuser 52165 Mar 13 17:03 DIFFS.Mar91 -rw-r--r-- 1 468 fsuser 0 Mar 13 17:24 tex.log /tex/OLD.pre-Mar91: total 7 drwxr-xr-x 2 468 fsuser 512 Mar 13 17:14 cweb drwxr-xr-x 2 468 fsuser 512 Mar 13 17:19 errata drwxr-xr-x 6 468 fsuser 512 Mar 13 17:14 local drwxr-xr-x 2 468 fsuser 512 Mar 13 17:18 mf drwxr-xr-x 2 468 fsuser 512 Mar 13 17:16 mfware drwxr-xr-x 2 468 fsuser 512 Mar 13 17:18 tex drwxr-xr-x 2 468 fsuser 512 Mar 13 17:14 tugboat /tex/bibtex: -rw-rw-r-- 1 weening ftp 27577 Mar 15 15:45 btxmac.tex /tex/errata: -rw-rw-rw- 1 468 fsuser 15838 Mar 15 21:40 errata.six -rw-r--r-- 1 468 fsuser 2528 Mar 13 17:05 errata.tex -rw-r--r-- 1 468 fsuser 79228 Mar 13 17:05 mf84.bug -rw-r--r-- 1 468 fsuser 295236 Mar 13 17:05 tex82.bug /tex/latex: -rw-rw-r-- 1 root ftp 15834 Jan 14 18:58 addendum.tex -r--r--r-- 1 root fsuser 40243 Feb 8 21:02 latex.bug -r--r--r-- 1 root fsuser 286412 Feb 8 21:02 latex.tex -r--r--r-- 1 root fsuser 48458 Feb 8 21:02 lplain.tex -r--r--r-- 1 root fsuser 48804 Feb 8 21:03 splain.tex /tex/local/cm: -rw-rw-rw- 1 468 fsuser 3561 Mar 15 21:44 ccmic9.mf -rw-rw-rw- 1 468 fsuser 217 Mar 15 21:44 odigs.mf /tex/local/lib: -rw-r--r-- 1 468 fsuser 3133 Mar 13 17:08 art.mf -rw-rw-r-- 1 468 fsuser 33699 Mar 13 17:09 gkpmac.tex -rw-r--r-- 1 468 fsuser 1581 Mar 13 17:09 list.tex -rw-r--r-- 1 468 fsuser 2179 Mar 13 17:09 llist.tex -rw-r--r-- 1 468 fsuser 263 Mar 13 17:09 oneone.mf -rw-r--r-- 1 468 fsuser 8240 Mar 13 17:09 picmac.tex /tex/local/mf: -rw-r--r-- 1 468 fsuser 691 Mar 13 17:09 plain.log /tex/local:/tex/local/mfware: -rw-r--r-- 1 468 fsuser 28547 Mar 13 17:10 gftodvi.ch /tex/local/tex: -rw-r--r-- 1 468 fsuser 53657 Mar 13 17:10 initex.ch /tex/mf: -rw-r--r-- 1 468 fsuser 916840 Mar 13 17:06 mf.web -rw-r--r-- 1 468 fsuser 938679 Mar 13 17:06 mfbook.tex -rw-r--r-- 1 468 fsuser 18238 Mar 5 23:56 trapman.tex /tex/mfware: -rw-r--r-- 1 468 fsuser 186545 Mar 13 17:06 gftodvi.web /tex/tex: -rw-r--r-- 1 468 fsuser 1025435 Mar 18 21:20 tex.web -rw-r--r-- 1 468 fsuser 1381907 Mar 13 17:07 texbook.tex -rw-r--r-- 1 468 fsuser 2438 Mar 13 17:07 trip.fot -rw-r--r-- 1 468 fsuser 182701 Mar 13 17:07 trip.log -rw-r--r-- 1 468 fsuser 18025 Mar 13 17:07 trip.typ -rw-r--r-- 1 468 fsuser 12930 Mar 13 17:08 tripin.log /tex/tugboat: -rw-r--r-- 1 468 fsuser 30903 Mar 11 19:44 guidepro.tex -rw-r--r-- 1 468 fsuser 14810 Mar 11 19:44 ltugboat.sty -rw-r--r-- 1 468 fsuser 3785 Mar 11 19:44 ltugproc.sty -rw-r--r-- 1 468 fsuser 25567 Mar 11 19:44 tugboat.com -rw-r--r-- 1 468 fsuser 66791 Mar 11 19:44 tugboat.sty -rw-r--r-- 1 468 fsuser 8901 Mar 11 19:44 tugproc.sty ######################################################################## Addenda to TeX82.BUG as of 13 March 91 ------------- Note: When making change 376, I forgot to delete the redundant code in module 883, and I should also have changed the name of that module. These cosmetic changes (and some changes to the comments) were made in version 3.14; but TeX 3.14 is functionally equivalent to TeX 3.1 and only a tiny bit faster. ------------- 393. The absolutely final change (to be made after my death) @x module 2 @d banner=='This is TeX, Version 3.14' {printed when \TeX\ starts} @y @d banner=='This is TeX, Version $\pi$' {printed when \TeX\ starts} @z My last will and testament for TeX is that no further changes be made under any circumstances. Improved systems should not be called simply `TeX'; that name, unqualified, should refer only to the program for which I have taken personal responsibility. -- Don Knuth ######################################################################## Addenda to MF84.BUG as of 13 March 91 ------------- 557. The absolutely final change (to be made after my death) @x module 2 @d banner=='This is METAFONT, Version 2.7' {printed when \MF\ starts} @y @d banner=='This is METAFONT, Version $e$' {printed when \MF\ starts} @z My last will and testament for METAFONT is that no further changes be made under any circumstances. Improved systems should not be called simply `METAFONT'; that name, unqualified, should refer only to the program for which I have taken personal responsibility. -- Don Knuth ######################################################################## Changes to the errata list (ERRATA.SIX) [ This is NOT a difference list. ] \def\rhead{Bugs in {\tensl Computers \& Typesetting, 1990}} ... \noindent This is a list of all corrections made to {\sl Computers \& Typesetting}, Volumes A,~C, and E\null, between 30 September 1989 (when the revisions for \TeX\ Version 3.0 and \MF\ Version 2.0 were made) and December 31, 1990. ... \bugonpage A137, lines 2 and 3 from the bottom (11/9/90) {\eightssi \rightline{and you shouldn't even be reading this manual,} \rightline{which is undoubtedly all English to you.} } \bugonpage A141, line 15 from the bottom (10/18/90) \tenpoint\noindent Thus if you type `|$1\over2$|' (in a text) you get $1\over2$, namely style $S$ over style~$S'$;\cutpar ... \bugonpage C11, replacement for second quotation at bottom of page (9/27/90) \begingroup \eightpoint \let\tt=\ninett \baselineskip 10pt \parfillskip \z@ \interlinepenalty 10000 \leftskip \z@ plus 40pc minus \parindent \let\rm=\eightss \let\sl=\eightssi \everypar{\sl} \def\par{\ifhmode\/\endgraf\fi}\obeylines To anyone who has lived in a modern American city (except Boston) at least one of the underlying ideas of ^{Descartes}' analytic geometry will seem ridiculously evident. Yet, as remarked, it took mathematicians all of two thousand years to arrive at this simple thing. \author ERIC TEMPLE ^{BELL}, {\sl Mathematics: Queen and Servant of % Science\/} (1951) % p123 \endgroup \bugonpage C262, lines 19--21 (11/9/90) \ninepoint\noindent for commonly occurring idioms. For example, `{\bf stop} |"hello"|' displays `|hello|' on the terminal and waits until \ is typed. \beginlines |def |^|upto|| = step 1 until enddef; def |^|downto|| = step -1 until enddef;| \endgroup ... \bugonpage C329, line 325 (12/29/90) \ninepoint\noindent which can be used to specify a nonstandard file area or directory name for the gray\cutpar ... \bugonpage C347, left column (9/27/90) \eightpoint\noindent Bell, Eric Temple, 11. \bugonpage C349, left column (9/27/90) \eightpoint\noindent Descartes, Ren\'e, 6, 11, 19. \bugonpage C356, right column (9/27/90) \eightpoint\noindent [remove the entry for Rex Stout.] \bugonpage C358, right column (9/27/90) \eightpoint\noindent [remove the entry for Nero Wolfe.] ######################################################################## Differences between TeX.WEB 3.1 and 3.14 (as of 18 March 1991) ;COMPARISON OF TX:TEX-31.WEB.1 AND TX:TEX-314.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TEX-31.WEB.1, 1-43 (2896) % A reward of $327.68 will be paid to the first finder of any remaining bug, **** FILE TX:TEX-314.WEB.1, 1-42 (2894) % Version 3.14 was a cosmetic change for new Volume B (February 1991). % A reward of $327.68 will be paid to the first finder of any remaining bug, *************** **** FILE TX:TEX-31.WEB.1, 1-183 (10169) @d banner=='This is TeX, Version 3.1' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present **** FILE TX:TEX-314.WEB.1, 1-184 (10241) @d banner=='This is TeX, Version 3.14' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present *************** **** FILE TX:TEX-31.WEB.1, 1-1008 (48300) (If the \PASCAL\ compiler does not support non-local |@!goto|, the @^system dependencies@> **** FILE TX:TEX-314.WEB.1, 1-1009 (48373) (If the \PASCAL\ compiler does not support non-local |@!goto|\unskip, the @^system dependencies@> *************** **** FILE TX:TEX-31.WEB.1, 1-4856 (215250) {that's |text(font_id_base+equiv(n))|} end **** FILE TX:TEX-314.WEB.1, 1-4857 (215330) {that's |font_id_text(equiv(n))|} end *************** **** FILE TX:TEX-31.WEB.1, 1-8209 (361639) if (cur_cs=0)and@| **** FILE TX:TEX-314.WEB.1, 1-8210 (361714) @^recursion@> if (cur_cs=0)and@| *************** **** FILE TX:TEX-31.WEB.1, 1-9674 (418737) @p procedure conditional; **** FILE TX:TEX-314.WEB.1, 1-9675 (418825) @^recursion@> @p procedure conditional; *************** **** FILE TX:TEX-31.WEB.1, 1-14080 (611160) The box returned by |clean_box| is ``clean'' in the **** FILE TX:TEX-314.WEB.1, 1-14082 (611263) @^recursion@> The box returned by |clean_box| is ``clean'' in the *************** **** FILE TX:TEX-31.WEB.1, 1-14175 (615068) The second pass eliminates all noads and inserts the correct glue and **** FILE TX:TEX-314.WEB.1, 1-14178 (615186) @^recursion@> The second pass eliminates all noads and inserts the correct glue and *************** **** FILE TX:TEX-31.WEB.1, 1-14760 (639342) cur_style:=save_style; @; **** FILE TX:TEX-314.WEB.1, 1-14765 (639477) @^recursion@> cur_style:=save_style; @; *************** **** FILE TX:TEX-31.WEB.1, 1-15438 (669367) but we clear |aux| to zero just to be tidy. @p @t\4@>@@t@>@/ **** FILE TX:TEX-314.WEB.1, 1-15444 (669517) but we clear them to zero just to be tidy. @p @t\4@>@@t@>@/ *************** **** FILE TX:TEX-31.WEB.1, 1-17263 (749496) @; if post_break(q)<>null then @; **** FILE TX:TEX-314.WEB.1, 1-17269 (749645) @; if post_break(q)<>null then @; *************** **** FILE TX:TEX-31.WEB.1, 1-17277 (749957) if not is_char_node(s) then if next_break(cur_p)<>null then if cur_break(next_break(cur_p))=s then s:=r; r:=link(s); link(s):=null; **** FILE TX:TEX-314.WEB.1, 1-17283 (750062) r:=link(s); link(s):=null; *************** **** FILE TX:TEX-31.WEB.1, 1-17624 (764945) hyphen can be considerably more complex than that. For example, suppose that \.{abcdef} is a word in a font for which the only ligatures are \.{b\!c}, \.{c\!d}, \.{d\!e}, and \.{e\!f}. If this word is to permit hyphenation between \.b and \.c, the two patterns with and without hyphenation are **** FILE TX:TEX-314.WEB.1, 1-17628 (764937) hyphen can be considerably more complex than that. Suppose \.{abcdef} is a word in a font for which the only ligatures are \.{b\!c}, \.{c\!d}, \.{d\!e}, and \.{e\!f}. If this word permits hyphenation between \.b and \.c, the two patterns with and without hyphenation are *************** **** FILE TX:TEX-31.WEB.1, 1-19977 (866921) hyphenation. Again we have an implied ``cursor`` between characters |cur_l| and |cur_r|. The main difference is that the |lig_stack| can now **** FILE TX:TEX-314.WEB.1, 1-19981 (866890) hyphenation. Again we have an implied ``cursor'' between characters |cur_l| and |cur_r|. The main difference is that the |lig_stack| can now *************** **** FILE TX:TEX-31.WEB.1, 1-21590 (929845) begin get_token; {|get_x_token| would fail on \.{\\ifmmode}!} if (cur_cmd=math_shift)and(mode>0) then @ **** FILE TX:TEX-314.WEB.1, 1-21594 (929814) begin get_token; {|get_x_token| would fail on \.{\\ifmmode}\thinspace!} if (cur_cmd=math_shift)and(mode>0) then @ *************** **** FILE TX:TEX-31.WEB.1, 1-22413 (960656) by making its width zero. @= **** FILE TX:TEX-314.WEB.1, 1-22417 (960635) by causing its width to be zero. @= *************** **** FILE TX:TEX-31.WEB.1, 1-23152 (987557) |info(par_shape_ptr)| can hold any positive~|n| such |get_node(2*n+1)| doesn't overflow the memory capacity. **** FILE TX:TEX-314.WEB.1, 1-23156 (987543) |info(par_shape_ptr)| can hold any positive~|n| for which |get_node(2*n+1)| doesn't overflow the memory capacity. *************** **** FILE TX:TEX-31.WEB.1, 1-23239 (990682) if scan_keyword("at") then @ @.at@> **** FILE TX:TEX-314.WEB.1, 1-23243 (990673) if scan_keyword("at") then @ @.at@> *************** **** FILE TX:TEX-31.WEB.1, 1-23254 (991149) @ @= begin scan_normal_dimen; s:=cur_val; **** FILE TX:TEX-314.WEB.1, 1-23258 (991144) @ @= begin scan_normal_dimen; s:=cur_val; *************** **** FILE TX:TEX-31.WEB.1, 1-23484 (998722) @= **** FILE TX:TEX-314.WEB.1, 1-23487 (998719) @^data structure assumptions@> @= *************** **** FILE TX:TEX-31.WEB.1, 1-24036 (1017828) init for k:=0 to 255 do trie_used[k]:=min_quarterword;@+tini k:=256; while j>0 do begin undump(0)(k-1)(k); undump(1)(j)(x);@+init trie_used[k]:=qi(x);@+tini j:=j-x; op_start[k]:=qo(j); **** FILE TX:TEX-314.WEB.1, 1-24041 (1017859) init for k:=0 to 255 do trie_used[k]:=min_quarterword;@+tini@;@/ k:=256; while j>0 do begin undump(0)(k-1)(k); undump(1)(j)(x);@+init trie_used[k]:=qi(x);@+tini@;@/ j:=j-x; op_start[k]:=qo(j); *************** **** FILE TX:TEX-31.WEB.1, 1-24175 (1023526) This program doesn't bother to close the input files that may still be open. **** FILE TX:TEX-314.WEB.1, 1-24179 (1023563) @^recursion@> This program doesn't bother to close the input files that may still be open. *************** ######################################################################## Differences between TeX.WEB 3.0 and 3.1 (as of 21 September 1990) ;COMPARISON OF TX:TEX-30.WEB.1 AND TX:TEX-31.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TEX-30.WEB.1, 1-42 (2816) % A reward of $327.68 will be paid to the first finder of any remaining bug, **** FILE TX:TEX-31.WEB.1, 1-41 (2814) % Version 3.1 fixed nullfont, disabled \write{\the\prevgraf} (September 1990). % A reward of $327.68 will be paid to the first finder of any remaining bug, *************** **** FILE TX:TEX-30.WEB.1, 1-68 (4055) \def\drop{\kern-.1667em\lower.5ex\hbox{E}\kern-.125em} % middle of TeX \catcode`E=13 \uppercase{\def E{e}} \def\\#1{\hbox{\let E=\drop\it#1\/\kern.05em}} % italic type for identifiers \outer\def\N#1. \[#2]#3.{\MN#1.\vfil\eject % begin starred section **** FILE TX:TEX-31.WEB.1, 1-69 (4135) \outer\def\N#1. \[#2]#3.{\MN#1.\vfil\eject % begin starred section *************** **** FILE TX:TEX-30.WEB.1, 1-186 (10278) @d banner=='This is TeX, Version 3.0' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present **** FILE TX:TEX-31.WEB.1, 1-183 (10169) @d banner=='This is TeX, Version 3.1' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present *************** **** FILE TX:TEX-30.WEB.1, 1-8472 (372855) begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @ @= **** FILE TX:TEX-31.WEB.1, 1-8469 (372746) if mode=0 then scanned_result(0)(int_val) {|prev_graf=0| within \.{\\write}} else begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @ @= *************** **** FILE TX:TEX-30.WEB.1, 1-10358 (446031) begin if input_ln(cur_file,false) then do_nothing; firm_up_the_line; **** FILE TX:TEX-31.WEB.1, 1-10356 (446011) begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; *************** **** FILE TX:TEX-30.WEB.1, 1-10362 (446183) first:=limit+1; loc:=start; line:=1; end **** FILE TX:TEX-31.WEB.1, 1-10361 (446173) first:=limit+1; loc:=start; end *************** **** FILE TX:TEX-30.WEB.1, 1-10737 (464779) font_bc[null_font]:=1; font_ec[null_font]:=0; **** FILE TX:TEX-31.WEB.1, 1-10736 (464760) bchar_label[null_font]:=non_address; font_bchar[null_font]:=non_char; font_false_bchar[null_font]:=non_char; font_bc[null_font]:=1; font_ec[null_font]:=0; *************** **** FILE TX:TEX-30.WEB.1, 1-11673 (506824) if at all. Like |nop| commands and \\{xxx} commands, font definitions can appear before the first |bop|, or between an |eop| and a |bop|. **** FILE TX:TEX-31.WEB.1, 1-11674 (506916) if at all. Like |nop| commands, font definitions can appear before the first |bop|, or between an |eop| and a |bop|. *************** **** FILE TX:TEX-30.WEB.1, 1-18295 (794479) is |trie_op_ptr|. If the table overflows, the excess ops are ignored. Statistics printed during a dump make it possible for users to tell if this has happened. @= **** FILE TX:TEX-31.WEB.1, 1-18296 (794550) is |trie_op_ptr|. @= *************** **** FILE TX:TEX-30.WEB.1, 1-24730 (1045367) {disable \.{\\prevdepth}, \.{\\spacefactor}, \.{\\lastskip}} cur_cs:=write_loc; q:=scan_toks(false,true); {expand macros, etc.} **** FILE TX:TEX-31.WEB.1, 1-24729 (1045294) {disable \.{\\prevdepth}, \.{\\spacefactor}, \.{\\lastskip}, \.{\\prevgraf}} cur_cs:=write_loc; q:=scan_toks(false,true); {expand macros, etc.} *************** ######################################################################## Differences between MF.WEB 2.0 and MF.WEB 2.7 (as of 13 March 1991) ;COMPARISON OF TX:MF-20.WEB.1 AND TX:MF-27.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:MF-20.WEB.1, 1-22 (1390) % A few "harmless" optimizations have been made without changing versions. % A reward of $81.92 will be paid to the first finder of any remaining bug, % except bugs introduced after August 1989. **** FILE TX:MF-27.WEB.1, 1-22 (1390) % Version 2.7 made consistent with TeX version 3.1 (September 1990). % A few "harmless" optimizations have been made without changing versions. % A reward of $163.84 will be paid to the first finder of any remaining bug, % except bugs introduced after August 1989. *************** **** FILE TX:MF-20.WEB.1, 1-153 (8073) @d banner=='This is METAFONT, Version 2.0' {printed when \MF\ starts} @ Different \PASCAL s have slightly different conventions, and the present **** FILE TX:MF-27.WEB.1, 1-154 (8144) @d banner=='This is METAFONT, Version 2.7' {printed when \MF\ starts} @ Different \PASCAL s have slightly different conventions, and the present *************** **** FILE TX:MF-20.WEB.1, 1-2995 (123730) fractions. Using the recurrence $x_n=(x_{n-55}-x_{n-31})\bmod 2^{28}$, we generate batches of 55 new $x_n$'s at a time by calling |new_randoms|. **** FILE TX:MF-27.WEB.1, 1-2996 (123801) fractions. Using the recurrence $x_n=(x_{n-55}-x_{n-24})\bmod 2^{28}$, we generate batches of 55 new $x_n$'s at a time by calling |new_randoms|. *************** **** FILE TX:MF-20.WEB.1, 1-3005 (124184) and then it will fetch |randoms[j_random]|. @d next_random==if j_random=0 then new_randoms **** FILE TX:MF-27.WEB.1, 1-3006 (124255) and then it will fetch |randoms[j_random]|. The |next_random| macro actually accesses the numbers backwards; blocks of 55~$x$'s are essentially being ``flipped.'' But that doesn't make them less random. @d next_random==if j_random=0 then new_randoms *************** **** FILE TX:MF-20.WEB.1, 1-11094 (468472) numerators and denominators is to generalize the Stern-Peirce tree [cf.~{\sl The Art of Computer Programming\/ \bf2}, exercise 4.5.3--40] @^Peirce, Charles Santiago Sanders@> @^Stern, Moriz Abraham@> to a ``Stern-Peirce wreath'' as follows: Begin with four nodes arranged in a circle, containing the respective directions **** FILE TX:MF-27.WEB.1, 1-11097 (468704) numerators and denominators is to generalize the Stern-Brocot tree [cf.~{\sl Concrete Mathematics}, section 4.5] @^Brocot, Achille@> @^Stern, Moriz Abraham@> to a ``Stern-Brocot wreath'' as follows: Begin with four nodes arranged in a circle, containing the respective directions *************** **** FILE TX:MF-20.WEB.1, 1-15894 (663124) pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; end_file_reading; {remove the level that didn't work} **** FILE TX:MF-27.WEB.1, 1-15897 (663314) if cur_area="" then begin pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; end; end_file_reading; {remove the level that didn't work} *************** **** FILE TX:MF-20.WEB.1, 1-15919 (664150) begin if not input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; line:=1; end **** FILE TX:MF-27.WEB.1, 1-15924 (664383) begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; end *************** ######################################################################## Cosmetic change, GFTODVI.WEB, ver 3.0 ;COMPARISON OF TX:GFTODVI.WEB AND TX:GFTODVI.WEB.1 ;OPTIONS ARE /3 **** FILE TX:GFTODVI.WEB, 1-2553 (117187) if a |"/"| was removed at the end of the file name; this user that the user will have a chance to issue special instructions online just before **** FILE TX:GFTODVI.WEB, 1-2553 (117187) if a |"/"| was removed at the end of the file name; this means that the user will have a chance to issue special instructions online just before *************** ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 028 ] ------- 25-Mar-91 0:33:06-GMT,2273;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AB25580; Sun, 24 Mar 91 17:33:00 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Sun, 24 Mar 91 19:27:00-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA24720; Sun, 24 Mar 91 16:21:56 -0800 Date: Sun, 24 Mar 91 16:21:56 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103250021.AA24720@june.cs.washington.edu> To: rokicki@Neon.Stanford.EDU Cc: karl@cs.umb.edu, tex-fonts@math.utah.edu, tex-implementors@math.ams.com In-Reply-To: Tomas G. Rokicki's message of Fri, 15 Mar 91 09:22:58 -0800 <9103151722.AA00775@Neon.Stanford.EDU> Subject: fontname mapping file for TeX The reason against \charsubdef being a part of TeX (TM) is that however convenient it may be it violates DEK's basic insistence that for any given input there is only one dvi output. Depending on the environment, you will get various dvi outputs from a "TeX" with \charsubdef included, and the differences are subtle and interwoven into the file. I don't see that font name mapping does that. It may be that we have to decide which name goes into the postamble and the font-def commands---in the case of CM, it is obviously going to be the usual cmr10 style name--- but we can remember the time when SAIL used 6-char names while VMS and Unix were already opening them out to longer names. That certainly involved inconsistencies in both the postamble and font-defs, but you could get around it with links, etc., and in that case as in this, DEK did not feel that the inconsistencies invalidated VMS and Unix TeXs. So long as we always end up with a font which has the expected checksum in the tfm, and which maps the characters into the same positions on all systems, the question of its external file name is not so critical. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 28-Mar-91 22:23:47-GMT,1040;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02434; Thu, 28 Mar 91 15:23:40 MST Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 28 Mar 91 17:12:45-EDT Received: by smiley.Stanford.EDU (4.1/inc-1.0) id AA03135; Thu, 28 Mar 91 14:07:29 PST Date: Thu, 28 Mar 91 14:07:29 PST From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9103282207.AA03135@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: another installation Hi, Don Knuth sheepishly gave me a newer version of the same release that first appeared in early March (this is now the third one). This is now up on labrea. The diffs file, DIFFS.Mar91, contains the differences between this version and the Sept. 90 version that was on labrea. The two previous March releases should be disgarded. There is at least one important bug fix that appears in this most recent release. He assures me that this is the last 3.14 release. Dan 10-Jul-1990 14:26:45-GMT,1477;000000000001 Return-Path: <@MATH.AMS.COM,@NSFnet-Relay.AC.UK:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by science.utah.edu with TCP; Tue 10 Jul 90 08:26:33-MDT Received: from NSFnet-Relay.AC.UK by MATH.AMS.COM via SMTP with TCP; Tue, 10 Jul 90 10:11:02-EDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa10816; 10 Jul 90 14:33 BST Date: Tue, 10 Jul 90 15:01:03 BST From: Chris Thompson To: tex-implementors@math.ams.com Subject: A bug in TeX 3.0 Message-ID: I gave the details of the following bug to Barbara Beeton a few weeks ago, and I believe she has passed it on to Don Knuth, but we don't seem to have an official fix number for it yet. As it seems completely uncontentious (to me, anyway!) I think that tex-implementors should know about it. The following initialisations, which should have been added since TeX 2.992, are missing from section 552: bchar_label[null_font]:=non_address; font_bchar[null_font]:=non_char; font_false_bchar[null_font]:=non_char; The last two may not actually be necessary, although they can certainly do no harm. However the absence of the first can cause various nasty effects if an attempt is made to typeset a character from \nullfont: random locations in |font_info| get interpreted as a kern/ligature program. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk 28-Jul-1990 2:17:42-GMT,1903;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Fri 27 Jul 90 20:17:40-MDT Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 27 Jul 90 22:20:14-EDT Date: Fri, 27 Jul 1990 15:21 PDT From: Don Hosek Subject: VMS TeX tape from Maria Code To: tex-implementors@math.ams.com Message-id: X-Envelope-to: tex-implementors@math.ams.com X-VMS-To: in%"tex-implementors@math.ams.com" A twofold message: First, I'd like to let you know that I've made the necessary arrangements and come September, people ordering VMS TeX will be getting TeX 3.0 and other up-to-date files. Second, the distribution is limited to a 1200' reel (they can do 2400', but prefer the smaller size) at 1600bpi. I'll need to do some experiments to see exactly what that translates to in VMS blocks, to see exactly what I can fit on the tape, but at present this is what I anticipate putting on it: (in order of decreasing priority). WEB sources for TeX, WEB, MF, TeXware, MFware Basic TeX input files Basic MF input files Standard LaTeX files Mainz LaTeX files (eventually these will be part of the above section) CM font sources BibTeX and standard BibTeX styles Makeindex DVIOUT (PostScript driver) (unless anybody has a better PS driver) DVItoVDU (Previewer for graphics terminals) DVILN03 (Brian Hamilton Kelly's version) XDVI (X previewer) (unless DVIDecwindows--on its way--is better) AmSTeX and AmSfonts sources Contributed LaTeX files Contributed BibTeX files Contributed Plain TeX files I'll be very surprised if I make it this far... Various foreign language support files (from the Babel tree at ymir) Other TeX macro packages and random MF fonts. Nelson Beebe's driver family etc. Any comments on the priorities, etc.? -sh 14-Aug-1990 20:19:44-GMT,9297;000000000011 Return-Path: Received: from MATH.AMS.COM by science.utah.edu with TCP; Tue 14 Aug 90 14:19:32-MDT Date: Tue 14 Aug 90 16:06:22-EST From: bbeeton Subject: Some corrections; TFtoPL 3.1; catching up To: TeX-implementors Message-ID: <650664382.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 14 Aug 90 Message No: 026 To: TeX implementors and distributors From: Barbara Beeton Subject: Some corrections; TFtoPL 3.1; catching up I started putting this message together in April, but was interrupted and never sent it. Fortunately, there has not been too much activity in the intervening months that has required new versions of TeX/ware and MF/ware to be retrieved and installed; however, I recently received a message from Knuth saying that he expected to spend some of August tending to his TeX correspondence, so it's time to clear the decks. It was called to my attention that some lines in difference listings in these messages have been corrupted. Below are corrections as necessary. The corrected passages include the complete difference segments, not just individual lines. Please replace the offending segments as appropriate. (Note that if you received andy of the affected messages after the initial mailing, the original files have been corrected.) A short explanation may be useful. I use the TOPS-20 SRCCOM program to generate the difference lists. This program has a couple of flaws (it omits blank lines, for example), but it has the virtue that it does not extend lines beyond their original length, unlike the VMS DIF program, which is the only other option available to me. This makes for more reliable transmission across network gateways. After creating and validating a difference file, I transfer it to a VAX for construction of the message and mailing. This sometimes runs afoul of a TOPS-20/VMS imcompatibility, namely that the DEC-20 is a 36-bit-word machine, and ascii is packed at 5 characters to a word with one slack bit. If the slack bit happens to be turned on, that word will be lost in the 20-to-VAX transfer. In the examples corrected here, I forgot to take one more step, namely running the difference files through a program that turns off all slack bits. I realize there are undoubtedly better tools available to do this job automatically, but the local systems programming staff hasn't come up with any. Apologies for any problems caused by these errors. Although it's probably general knowledge by now, having been posted to TeXhax, Karl Berry is now "more or less maintaining" web2c. To quote his most recent message to me, "the port for TeX 3.0 and Metafont 2.0 is released, and now on ics.uci.edu and labrea.stanford.edu, as well as in Europe." Any questions can be sent to Karl at karl@cs.umb.edu on CSnet. The afore-mentioned TOPS-20 machine is scheduled to be unplugged at the end of the year. One of my biggest jobs is to migrate all the Math Society's TeX archives and records from the 20 to the VAX, and I'm spending every spare moment on that. In the process, I keep finding things that should have been announced here, so I will announce them, regardless of how late. For a start, TFtoPL was upgraded to version 3.1 last November. Differences between versions 3.0 and 3.1 below. Oren Patashnik has announced the availability of a set of TeX macros that make BibTeX work with plain TeX; the message to TeXhax will be distributed in due course, but here's a copy of the advance notice he sent me: Date: Tue, 14 Aug 1990 10:19:50 PDT From: Oren Patashnik To: texhax@cs.washington.edu Subject: BibTeX-for-plain-TeX macros There is now distributed with BibTeX a set of TeX macros that makes BibTeX work with plain TeX (and presumably with other macro packages that don't deviate too far from plain TeX). The file is btxmac.tex, stored on Labrea.Stanford.EDU's BibTeX area (pub/tex/bibtex). --Oren Patashnik Finally, it's now been about four months since I last sent a message to this list, and quite a few address changes have been made. Please help out by acknowledging receipt. (I should hear about the bounces sooner than I'd like to.) ######################################################################## Corrections to differences between WEBMAC.TEX versions 1.4 and 4.0 (message #25) **** FILE TX:WEBMAC.CM.1, 1-62 (2808) \def\A{\note{See also}} % cross-reference for multiply defined section names \def\B{\mathopen{\.{@\{}}} % begin controlled comment **** FILE TX:WEBMAC.TEX.1, 1-62 (2843) \def\A{\note{See also section}} % crossref for doubly defined section name \def\As{\note{See also sections}} % crossref for multiply defined section name \def\B{\mathopen{\.{@\{}}} % begin controlled comment *************** **** FILE TX:WEBMAC.CM.1, 1-186 (9074) \def\U{\note{Used in}} % cross-reference for uses of sections \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} **** FILE TX:WEBMAC.TEX.1, 1-190 (9406) \def\U{\note{Used in section}} % crossref for use of a section \def\Us{\note{Used in sections}} % crossref for uses of a section \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} *************** ######################################################################## Differences between TFtoPL.WEB versions 3.0 and 3.1 ;COMPARISON OF TX:TFTOPL-30.WEB.1 AND TX:TFTOPL-31.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TFTOPL-30.WEB.1, 1-15 (852) % Here is TeX material that gets inserted after \input webmac **** FILE TX:TFTOPL-31.WEB.1, 1-14 (850) % Version 3.1 (November 1989) renamed z[] to lig_z[] for better portability. % Here is TeX material that gets inserted after \input webmac *************** **** FILE TX:TFTOPL-30.WEB.1, 1-32 (1473) \centerline{(Version 3, October 1989)} \vfill} **** FILE TX:TFTOPL-31.WEB.1, 1-33 (1551) \centerline{(Version 3.1, November 1989)} \vfill} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-63 (2869) @d banner=='This is TFtoPL, Version 3' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that **** FILE TX:TFTOPL-31.WEB.1, 1-64 (2950) @d banner=='This is TFtoPL, Version 3.1' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1256 (48904) end; right; **** FILE TX:TFTOPL-31.WEB.1, 1-1257 (48987) end; {there are no other cases} right; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1409 (54539) @!z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} **** FILE TX:TFTOPL-31.WEB.1, 1-1410 (54649) @!lig_z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1471 (57148) t:=z[h]; z[h]:=zz; zz:=t; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1472 (57262) t:=lig_z[h]; lig_z[h]:=zz; zz:=t; end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1475 (57240) hash[h]:=key; class[h]:=cc; z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; **** FILE TX:TFTOPL-31.WEB.1, 1-1476 (57362) hash[h]:=key; class[h]:=cc; lig_z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1513 (58592) left_z: begin class[h]:=pending; z[h]:=eval(z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; z[h]:=eval(x,z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; z[h]:=eval(eval(x,z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=z[h]; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1514 (58718) left_z: begin class[h]:=pending; lig_z[h]:=eval(lig_z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; lig_z[h]:=eval(x,lig_z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; lig_z[h]:=eval(eval(x,lig_z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; lig_z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=lig_z[h]; end; *************** ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 026 ] ------- 15-Aug-1990 22:06:10-GMT,527;000000000001 Mail-From: BEEBE created at 15-Aug-90 16:06:09 Date: Wed 15 Aug 90 16:06:09-MDT From: "Nelson H. F. Beebe" Subject: Re: Some corrections; TFtoPL 3.1; catching up To: BNB@MATH.AMS.COM cc: Beebe@SCIENCE.utah.edu In-Reply-To: <650664382.0.BNB@MATH.AMS.COM> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12614086410.21.BEEBE@SCIENCE.utah.edu> Received your tex-implementors message about tftopl. ------- 18-Aug-1990 21:07:15-GMT,9445;000000000001 Return-Path: Received: from MATH.AMS.COM by science.utah.edu with TCP; Sat 18 Aug 90 15:07:07-MDT Date: Sat 18 Aug 90 16:55:55-EST From: "Richard DeJordy, x4029" Subject: FORWARDED MESSAGE FOLLOWS To: TeX-implementors Cc: rad Date: Tue 14 Aug 90 16:06:22-EST From: bbeeton Subject: Some corrections; TFtoPL 3.1; catching up To: TeX-implementors Message-ID: <650664382.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 14 Aug 90 Message No: 026 To: TeX implementors and distributors From: Barbara Beeton Subject: Some corrections; TFtoPL 3.1; catching up I started putting this message together in April, but was interrupted and never sent it. Fortunately, there has not been too much activity in the intervening months that has required new versions of TeX/ware and MF/ware to be retrieved and installed; however, I recently received a message from Knuth saying that he expected to spend some of August tending to his TeX correspondence, so it's time to clear the decks. It was called to my attention that some lines in difference listings in these messages have been corrupted. Below are corrections as necessary. The corrected passages include the complete difference segments, not just individual lines. Please replace the offending segments as appropriate. (Note that if you received andy of the affected messages after the initial mailing, the original files have been corrected.) A short explanation may be useful. I use the TOPS-20 SRCCOM program to generate the difference lists. This program has a couple of flaws (it omits blank lines, for example), but it has the virtue that it does not extend lines beyond their original length, unlike the VMS DIF program, which is the only other option available to me. This makes for more reliable transmission across network gateways. After creating and validating a difference file, I transfer it to a VAX for construction of the message and mailing. This sometimes runs afoul of a TOPS-20/VMS imcompatibility, namely that the DEC-20 is a 36-bit-word machine, and ascii is packed at 5 characters to a word with one slack bit. If the slack bit happens to be turned on, that word will be lost in the 20-to-VAX transfer. In the examples corrected here, I forgot to take one more step, namely running the difference files through a program that turns off all slack bits. I realize there are undoubtedly better tools available to do this job automatically, but the local systems programming staff hasn't come up with any. Apologies for any problems caused by these errors. Although it's probably general knowledge by now, having been posted to TeXhax, Karl Berry is now "more or less maintaining" web2c. To quote his most recent message to me, "the port for TeX 3.0 and Metafont 2.0 is released, and now on ics.uci.edu and labrea.stanford.edu, as well as in Europe." Any questions can be sent to Karl at karl@cs.umb.edu on CSnet. The afore-mentioned TOPS-20 machine is scheduled to be unplugged at the end of the year. One of my biggest jobs is to migrate all the Math Society's TeX archives and records from the 20 to the VAX, and I'm spending every spare moment on that. In the process, I keep finding things that should have been announced here, so I will announce them, regardless of how late. For a start, TFtoPL was upgraded to version 3.1 last November. Differences between versions 3.0 and 3.1 below. Oren Patashnik has announced the availability of a set of TeX macros that make BibTeX work with plain TeX; the message to TeXhax will be distributed in due course, but here's a copy of the advance notice he sent me: Date: Tue, 14 Aug 1990 10:19:50 PDT From: Oren Patashnik To: texhax@cs.washington.edu Subject: BibTeX-for-plain-TeX macros There is now distributed with BibTeX a set of TeX macros that makes BibTeX work with plain TeX (and presumably with other macro packages that don't deviate too far from plain TeX). The file is btxmac.tex, stored on Labrea.Stanford.EDU's BibTeX area (pub/tex/bibtex). --Oren Patashnik Finally, it's now been about four months since I last sent a message to this list, and quite a few address changes have been made. Please help out by acknowledging receipt. (I should hear about the bounces sooner than I'd like to.) ######################################################################## Corrections to differences between WEBMAC.TEX versions 1.4 and 4.0 (message #25) **** FILE TX:WEBMAC.CM.1, 1-62 (2808) \def\A{\note{See also}} % cross-reference for multiply defined section names \def\B{\mathopen{\.{@\{}}} % begin controlled comment **** FILE TX:WEBMAC.TEX.1, 1-62 (2843) \def\A{\note{See also section}} % crossref for doubly defined section name \def\As{\note{See also sections}} % crossref for multiply defined section name \def\B{\mathopen{\.{@\{}}} % begin controlled comment *************** **** FILE TX:WEBMAC.CM.1, 1-186 (9074) \def\U{\note{Used in}} % cross-reference for uses of sections \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} **** FILE TX:WEBMAC.TEX.1, 1-190 (9406) \def\U{\note{Used in section}} % crossref for use of a section \def\Us{\note{Used in sections}} % crossref for uses of a section \def\:{\par\hangindent 2em}\let\*=*\let\.=\ttentry} *************** ######################################################################## Differences between TFtoPL.WEB versions 3.0 and 3.1 ;COMPARISON OF TX:TFTOPL-30.WEB.1 AND TX:TFTOPL-31.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TFTOPL-30.WEB.1, 1-15 (852) % Here is TeX material that gets inserted after \input webmac **** FILE TX:TFTOPL-31.WEB.1, 1-14 (850) % Version 3.1 (November 1989) renamed z[] to lig_z[] for better portability. % Here is TeX material that gets inserted after \input webmac *************** **** FILE TX:TFTOPL-30.WEB.1, 1-32 (1473) \centerline{(Version 3, October 1989)} \vfill} **** FILE TX:TFTOPL-31.WEB.1, 1-33 (1551) \centerline{(Version 3.1, November 1989)} \vfill} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-63 (2869) @d banner=='This is TFtoPL, Version 3' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that **** FILE TX:TFTOPL-31.WEB.1, 1-64 (2950) @d banner=='This is TFtoPL, Version 3.1' {printed when the program starts} @ This program is written entirely in standard \PASCAL, except that *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1256 (48904) end; right; **** FILE TX:TFTOPL-31.WEB.1, 1-1257 (48987) end; {there are no other cases} right; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1409 (54539) @!z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} **** FILE TX:TFTOPL-31.WEB.1, 1-1410 (54649) @!lig_z:array[0..hash_size] of 0..257; @!hash_ptr:0..hash_size; {the number of nonzero entries in |hash|} *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1471 (57148) t:=z[h]; z[h]:=zz; zz:=t; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1472 (57262) t:=lig_z[h]; lig_z[h]:=zz; zz:=t; end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1475 (57240) hash[h]:=key; class[h]:=cc; z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; **** FILE TX:TFTOPL-31.WEB.1, 1-1476 (57362) hash[h]:=key; class[h]:=cc; lig_z[h]:=zz; incr(hash_ptr); hash_list[hash_ptr]:=h; 30:end; *************** **** FILE TX:TFTOPL-30.WEB.1, 1-1513 (58592) left_z: begin class[h]:=pending; z[h]:=eval(z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; z[h]:=eval(x,z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; z[h]:=eval(eval(x,z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=z[h]; end; **** FILE TX:TFTOPL-31.WEB.1, 1-1514 (58718) left_z: begin class[h]:=pending; lig_z[h]:=eval(lig_z[h],y); class[h]:=simple; end; right_z: begin class[h]:=pending; lig_z[h]:=eval(x,lig_z[h]); class[h]:=simple; end; both_z: begin class[h]:=pending; lig_z[h]:=eval(eval(x,lig_z[h]),y); class[h]:=simple; end; pending: begin x_lig_cycle:=x; y_lig_cycle:=y; lig_z[h]:=257; class[h]:=simple; end; {the value 257 will break all cycles, since it's not in |hash|} end; {there are no other cases} f:=lig_z[h]; end; *************** ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 026 ] ------- 23-Aug-1990 9:55:28-GMT,1572;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 23 Aug 90 03:55:22-MDT Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 23 Aug 90 05:50:01-EDT Date: Thu, 23 Aug 1990 02:38 PDT From: Don Hosek Subject: That nasty dropped E problem--finally solved!!! To: tex-implementors@math.ams.com Message-id: X-Envelope-to: tex-implementors@math.ams.com X-VMS-To: in%"tex-implementors@math.ams.com" OK, I *finally* have a solution to that old nasty dropped E problem... (after wasting much time on \afterassignment, and looking for missing spaces I hit on a much simpler solution: @x [0] DAH: Fix problems WEAVEing TeX and BibTeX. \def\drop{\kern-.1667em\lower.5ex\hbox{E}\kern-.125em} % middle of TeX \catcode`E=13 \uppercase{\def E{e}} \def\\#1{\hbox{\let E=\drop\it#1\/\kern.05em}} % italic type for identifiers @y \def\\{\catcode`\E=13 \finishid} \catcode`\E=13 \uppercase{\def E{e}} \def\finishid#1{\hbox{\let E=\cape \it#1\/\kern.05em}% \catcode`\E=11\relax} % Guess what terrible thing happens if the % \relax is left out with the text below. \catcode`\E=11 \def\drop{\kern-.1667em\lower.5ex\hbox{E}\kern-.125em} % Middle of TeX \def\cape#1{\if X#1\drop\else E\fi#1} % E's in identifiers @z And yes, THIS time it works. (By the way, this *is* a genuine TeX bug so it should ultimately find its way into the WEB source. Do I get a check? :-) -dh 23-Aug-1990 12:31:58-GMT,1462;000000000001 Return-Path: Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 23 Aug 90 06:31:55-MDT Date: Thu 23 Aug 90 08:25:23-EST From: bbeeton Subject: Re: That nasty dropped E problem--finally solved!!! To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-implementors@MATH.AMS.COM Message-ID: <651414323.0.BNB@MATH.AMS.COM> In-Reply-To: Mail-System-Version: don -- here's some correspondence i've saved from don knuth regarding the lowered e. i agree that it should be changed in several places, but don's not about to fix it, is my considered opinion. and by the way, i don't think you'll persuade don it's a bug, just a nasty inconvenience. -- bb -------------------- Date: 26 Nov 89 From: bbeeton ..., i'd like to ask if you could include the fix to the lowered "e" that i sent a while back (or an equivalent, or better, one) -- it would be really nice not to have names like "EDIT" appear in documentation with a lowered "e". not really a bug, just an effect that gets carried further than intended. ------- Date: 27 Nov 89 0930 PST From: Don Knuth Subject: fix to lowered E Barbara, I don't see why this fix couldn't be put into anybody's change file who really needed it. Such a thing should be explained in TeXhax, but I'm not inclined to change it in TEX.WEB. ------- 23-Aug-1990 17:43:44-GMT,1108;000000000001 Return-Path: <@MATH.AMS.COM,@RELAY.CS.NET:karl@aten.cs.umb.edu> Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 23 Aug 90 11:43:41-MDT Received: from RELAY.CS.NET by MATH.AMS.COM via SMTP with TCP; Thu, 23 Aug 90 13:40:53-EDT Received: from relay2.cs.net by RELAY.CS.NET id ad28657; 23 Aug 90 13:36 EDT Received: from umb.edu by RELAY.CS.NET id al07255; 23 Aug 90 13:31 EDT Received: from aten.cs.umb.edu by cs.umb.edu (3.2/1.34) id AA29325; Thu, 23 Aug 90 11:52:16 EDT Received: by aten.cs.umb.edu (3.2/1.34) id AA04116; Thu, 23 Aug 90 11:52:15 EDT Date: Thu, 23 Aug 90 11:52:15 EDT From: Karl Berry Message-Id: <9008231552.AA04116@aten.cs.umb.edu> To: DHOSEK%hmcvax.claremont.edu@RELAY.CS.NET Cc: tex-implementors@MATH.AMS.COM In-Reply-To: Don Hosek's message of Thu, 23 Aug 1990 02:38 PDT Subject: That nasty dropped E problem--finally solved!!! Documentation bugs aren't worth nearly as much as programming bugs. (I've found about ten of the former and none of the latter...) karl@cs.umb.edu 21-Sep-1990 21:31:41-GMT,4735;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Fri 21 Sep 90 15:31:12-MDT Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 21 Sep 90 17:20:17-EDT Received: by smiley.Stanford.EDU (4.0/inc-1.0) id AA05977; Fri, 21 Sep 90 14:16:24 PDT Date: Fri, 21 Sep 90 14:16:24 PDT From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9009212116.AA05977@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: Changes for Tex3.0 Hi, I've put up changes to TeX on labrea that were given to me by Don Knuth. Since this is the first time that I've done this I left the old versions of the files but renamed them to have the suffix "~" (as emacs does it). So, for example the old version of the file mf/mf.web is mf/mf.web~. If this is objectionable then you should let me know. Here is a list of files that were changed on labrea: . ./lib ./lib/logo.mf ./lib/null.mf ./lib/rtest.mf ./lib/3test.mf ./lib/6test.mf ./lib/cmbase.mft ./lib/grayf.mf ./lib/hyphen.tex ./lib/logo10.mf ./lib/logo8.mf ./lib/logo9.mf ./lib/logobf10.mf ./lib/logosl10.mf ./lib/manfnt.mf ./lib/manmac.tex ./lib/mftmac.tex ./lib/null.tex ./lib/plain.mf ./lib/plain.mft ./lib/plain.tex ./lib/slant.mf ./lib/test.mf ./lib/testfont.tex ./lib/webmac.tex ./lib/ztest.mf ./mfware ./mfware/mft.web ./mfware/gftodvi.web ./mfware/gftopk.web ./mfware/gftype.web ./tex ./tex/tex.web ./tex/trip.pl ./tex/texbook.tex ./tex/trip.fot ./tex/trip.log ./tex/trip.tex ./tex/trip.typ ./tex/tripin.log ./tex/tripman.tex ./tex/tripos.tex ./mf ./mf/mf.web ./mf/mfbook.tex ./mf/trap.fot ./mf/trap.log ./mf/trap.mf ./mf/trap.pl ./mf/trap.typ ./mf/trapin.log ./mf/trapman.tex ./texware ./texware/dvitype.web ./texware/pltotf.web ./texware/pooltype.web ./texware/tftopl.web ./web ./web/tangle.web ./web/weave.web ./web/webman.tex ./errata ./errata/cm85.bug ./errata/errata.five ./errata/errata.four ./errata/errata.one ./errata/errata.tex ./errata/errata.three ./errata/errata.two ./errata/errorlog.tex ./errata/logmac.tex ./errata/mf84.bug ./errata/tex82.bug ./local ./local/web ./local/web/Makefile ./local/web/tangext.c ./local/web/tangext.h ./local/web/tangle.ch ./local/web/tangle.p ./local/web/weave.ch ./local/web/weavext.c ./local/texware ./local/texware/Makefile ./local/texware/access.c ./local/texware/dvityext.c ./local/texware/dvityext.h ./local/texware/dvitype.ch ./local/texware/pltotf.ch ./local/texware/pooltype.ch ./local/texware/tftopl.ch ./local/mfware ./local/mfware/mft.ch ./local/mfware/Makefile ./local/mfware/gftodvi.ch ./local/mfware/gftopk.ch ./local/mfware/gftopk_ext.c ./local/mfware/gftopk_ext.h ./local/mfware/gftype.ch ./local/mfware/mft_ext.c ./local/mfware/mft_ext.h ./local/mfware/pktype.ch ./local/mfware/pktype.web ./local/tex ./local/tex/Makefile ./local/tex/dvitype.in ./local/tex/ext.c ./local/tex/ext.h ./local/tex/ini_to_trip ./local/tex/ini_to_vir ./local/tex/initex.ch ./local/tex/plain.fmt ./local/tex/plain.log ./local/tex/tex.pool ./local/tex/trip1.in ./local/tex/trip2.in ./local/mf ./local/mf/Makefile ./local/mf/ext.c ./local/mf/ext.h ./local/mf/gftype.in ./local/mf/ini_to_trap ./local/mf/inimf.ch ./local/mf/mf.pool ./local/mf/mf_arith.c ./local/mf/mf_sunwin.c ./local/mf/mf_window.h ./local/mf/plain.base ./local/mf/plain.log ./local/mf/trap1.in ./local/mf/trap2.in ./local/lib ./local/lib/art.mf ./local/lib/e.mft ./local/lib/black.mf ./local/lib/blackaps.mf ./local/lib/linew10.mf ./local/lib/gray.mf ./local/lib/grayaps.mf ./local/lib/blackimagen.mf ./local/lib/fontchart.tex ./local/lib/grayimagen.mf ./local/lib/grayimagen3.mf ./local/lib/grayimagenlight.mf ./local/lib/lcircle.mf ./local/lib/lcircle10.mf ./local/lib/lcirclew10.mf ./local/lib/letter.tex ./local/lib/line.mf ./local/lib/line10.mf ./local/lib/list.tex ./local/lib/llist.tex ./local/lib/mfman.mf ./local/lib/oneone.mf ./local/lib/picmac.tex ./local/lib/slantaps4.mf ./local/lib/slantimagen6.mf ./local/man1 ./local/man1/dvitype.1 ./local/man1/gftodvi.1 ./local/man1/gftopk.1 ./local/man1/gftype.1 ./local/man1/mf.1 ./local/man1/mft.1 ./local/man1/pktype.1 ./local/man1/pltotf.1 ./local/man1/pooltype.1 ./local/man1/tangle.1 ./local/man1/tex.1 ./local/man1/tftopl.1 ./local/man1/vftovp.1 ./local/man1/vptovf.1 ./local/man1/weave.1 ./local/man1/web.1 ./local/bdemo_ext.c ./local/Makefile ./local/etc ./local/etc/Makefile ./local/etc/vftovp.ch ./local/etc/vptovf.ch ./local/bdemo_ext.h ./local/binarydemo.p ./local/h00vars.h ./local/mfpaths.h ./local/texpaths.h ./etc ./etc/vftovp.web ./etc/vptovf.web I left the list of differences that Knuth sent in DIFFS.Sept90. BNB@math.ams.com will be sending out a more formal description of the differences in the future. Dan 27-Sep-1990 5:13:31-GMT,3623;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by science.utah.edu with TCP; Wed 26 Sep 90 23:13:17-MDT Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 27 Sep 90 01:06:13-EDT Date: Wed, 26 Sep 1990 21:59 PDT From: Don Hosek Subject: Descrepency between behavior of TeX 3.x and TeX 2.x To: tex-implementors@math.ams.com Message-id: <03464DFA00603710@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-implementors@math.ams.com X-VMS-To: IN%"tex-implementors@math.ams.com" In a Usenet article, Ed Overman reported the following: ---begin quoted article------------------------------------- Path: jarthur!usc!zaphod.mps.ohio-state.edu!shape.mps.ohio-state.edu!eao From: eao@shape.mps.ohio-state.edu (Ed Overman) Newsgroups: comp.text.tex Subject: inconsistency between TeX 2.9 and 3.0 Message-ID: <1990Sep27.010730.1819@zaphod.mps.ohio-state.edu> Date: 27 Sep 90 01:07:30 GMT Sender: usenet@zaphod.mps.ohio-state.edu Organization: Department of Mathematics, The Ohio State University Lines: 30 We just installed TeX 3.0 here over the weekend and there seems to be an inconsistency between the new and old versions. I get different results with the following: \let\PAR=\par \if\PAR\par (TRUE) \else (FALSE) \fi \ifx\PAR\par (TRUE) \else (FALSE) \fi \if\PAR\$ (TRUE) \else (FALSE) \fi \ifx\PAR\$ (TRUE) \else (FALSE) \fi \if\PAR\# (TRUE) \else (FALSE) \fi \ifx\PAR\# (TRUE) \else (FALSE) \fi \bye TeX 3.0 prints out: (TRUE) (TRUE) (TRUE) (FALSE) (TRUE) (FALSE) TeX 2.9 (on my Atari since our sysop took the old version off our Suns already) prints out: (TRUE) (TRUE) (FALSE) (FALSE) (FALSE) (FALSE) These cannot both be correct - can they? Can anyone tell me which is correct (I assume the old version but I am not sure I completely understand the description of \if in Chapter 20). If this is a bug has anyone else seen it? Thanks, Ed Overman -----end quoted article------------------------------------- Checking this against 2.93 on a CMS system and my VMS 3.1 system revealed the same discrepency. Since 4 different systems are involved in the parallel tests, I presume that this is, in fact, due to something in the WEB itself. So which is right? The differences can be summarized with the following distilled version: \let\PAR=\par \if\PAR\$ (TRUE) \else (FALSE) \fi (\$ and \# are defined similarly using \chardef) \if expands what follows it until it finds two unexpandable tokens. In the case of the \if statement above, we will have \PAR unexpandable to what is treated as character code 256, category code 16 (cf. THE TeXBOOK, p.209). \$ is defined with \chardef\$=`\$ Now from the behavior described above, it would seem that under TeX 2.x the expansion of \$ would be the character $ with catcode 12 (or some such) while under 3.x it's some unexpandable control sequence. A tedious search through the TeXbook indicates the following interesting passages: "[in a discussion on comparisons with \ifx] the two tokens are not macros and they both represent the same \font or \chardef or \countdef, etc." (p.210) and \chardef'd control sequences are not listed in the list of expansions on pp. 212-4. \font'd control sequences are listed in that list however and the implication in the syntax definitions is that \font and \chardef produce c.s.'s of similar natures. To me, this seems a toss-up as to which is correct. Anyone else interested in the venture? Is \$ expandable or no? (Since TeX did change, contacting DEK, would not seem unfounded). -dh 27-Sep-1990 11:14:45-GMT,2472;000000000001 Return-Path: <@MATH.AMS.COM,@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from MATH.AMS.COM by science.utah.edu with TCP; Thu 27 Sep 90 05:14:23-MDT Received: from ruuinf.cs.ruu.nl by MATH.AMS.COM via SMTP with TCP; Thu, 27 Sep 90 07:10:59-EDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA20340; Thu, 27 Sep 90 13:02:47 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA27930; Thu, 27 Sep 90 13:05:45 met Date: Thu, 27 Sep 90 13:05:45 met From: Piet van Oostrum Message-Id: <9009271105.AA27930@praxis.cs.ruu.nl> To: tex-implementors@math.ams.com To: eao@shape.mps.ohio-state.edu (Ed Overman) Subject: Re: inconsistency between TeX 2.9 and 3.0 Path: piet Newsgroups: comp.text.tex From: piet@cs.ruu.nl (Piet van Oostrum) Subject: Re: inconsistency between TeX 2.9 and 3.0 References: <1990Sep27.010730.1819@zaphod.mps.ohio-state.edu> Reply-To: piet@cs.ruu.nl (Piet van Oostrum) In-reply-to: eao@shape.mps.ohio-state.edu (Ed Overman) Organization: Dept of Computer Science, Utrecht University, The Netherlands >>>>> In article <1990Sep27.010730.1819@zaphod.mps.ohio-state.edu>, eao@shape.mps.ohio-state.edu (Ed Overman) (EO) writes: EO> We just installed TeX 3.0 here over the weekend and there seems to be EO> an inconsistency between the new and old versions. I get different EO> results with the following: [ Example replaced by the following simpler:] \if\par\% TRUE\else FALSE\fi The TeX3.0 behaviour is the correct one. Both \par and \% are not expandable (they are not macros or anything mentioned on page 213/214) So they are considered to have character codes 256 and thus to test equal. Tex 2.9 and previous versions had a bug whereby \par was considered to have character code 0 (and category code 13). So the following example erroneously came out with TRUE: \catcode`\%=13 \ifcat\par\noexpand%TRUE\else FALSE\fi The fix is described in errorlog.tex: ------------------------------------------------------------------------ * 3 Dec 1989 ... S893. Distinguish |\par| from characters on |\if| tests. (MVL). @334 ------------------------------------------------------------------------ (that's a strange way of saying it!) -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') 22-Oct-1990 11:19:34-GMT,8328;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA23467; Mon, 22 Oct 90 12:19:27 MDT Date: Mon 22 Oct 90 13:32:37-EST From: bbeeton Subject: AMSFonts bug; TeX 3.1, MF 2.7 To: TeX-implementors@MATH.AMS.COM Message-Id: <656616757.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 22 October 90 Message No: 027 To: TeX implementors and distributors From: Barbara Beeton Subject: AMSFonts bug; TeX 3.1; MF 2.7 This will be a short message. I am constrained by a TUGboat printer deadlne, but it's been so long since anything has been reported, I wanted to let you know I'm still alive. A bug was reported in the AMSSYM.DEF file in the AMSFonts package. The fix has not yet been posted to the file on e-Math, but is listed below. The symptom is "unidentified control sequence" for \setboxz@h when trying to use \widetilde or \widehat. If you have not yet heard about e-Math (most of you should have received a message from Regina Girouard describing what is available there and how to retrieve it), please let me know, and I will send information. Chris Thompson has suggested that, similar to the occasional reports of files changed at labrea, I include in these messages a report of files changed at e-Math. I will try to get a baseline listing of the e-Math holdings for later comparison, and make reports as suggested. As of August 15, I had completed my scan of old mail files and double checked that all bug reports and questions forwarded to me had been delivered to Don Knuth. (Actually, the last of the pending reports had been delivered earlier, but I can say with a clear conscience that I think i found all messages that had arrived electronically and passed them on. A few have arrived since then, and I will forward them as soon as TUGboat has been delivered.) I have received from Don (on paper) a pile of annotated reports and several checks; I will forward those to the proper people as soon as TUGboat, ... In the meantime, TeX is now at version 3.1, MF is at version 2.7, and at least some of you may have seen Don's announcement that the numbers will converge to $\pi$ for TeX and $e$ for MF. (It will be published in TUGboat 11#4, but I will forward it to this list if I have time before that appears.) There was a massive update of files at labrea on September 21. On some (e.g. cm85.bug) only the dates have changed; too bad the Unix file system isn't better about keeping meaningful dates. In any case, the new errata and bug additions for TeX and MF are attached below. ######################################################################## Bug fix for AMSSYM.DEF (AMSFonts package) ************ File SYSA:[AMSFONTS.DISTRIB.2-0]AMSSYM.DEF;5 (line 33) \def\newsymbol#1#2#3#4#5{\let\next@\relax ****** File SYSA:[AMSFONTS.DISTRIB.WORK]AMSSYM.DEF;6 (line 33) \def\setboxz@h{\setbox\z@\hbox} \def\wdz@{\wd\z@} \def\newsymbol#1#2#3#4#5{\let\next@\relax ************ Number of difference sections found: 1 Number of difference records found: 2 DIFFERENCES /IGNORE=()/MERGED=1- SYSA:[AMSFONTS.DISTRIB.2-0]AMSSYM.DEF;5- SYSA:[AMSFONTS.DISTRIB.WORK]AMSSYM.DEF;6 ######################################################################## Addenda to TEX82.BUG as of 21 September 90 390. Uninitialized nullfont parameters (found by Lance Carnes, 11 May 90). @x module 552 hyphen_char[null_font]:="-"; skew_char[null_font]:=-1; @y hyphen_char[null_font]:="-"; skew_char[null_font]:=-1; bchar_label[null_font]:=non_address; font_bchar[null_font]:=non_char; font_false_bchar[null_font]:=non_char; @z 391. Disable \write{\the\prevgraf} (B. Jackowski, July 1990). @x module 422 begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @y if mode=0 then scanned_result(0)(int_val) {|prev_graf=0| within \.{\\write}} else begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @z 392. Report correct line number when buffer overflows (George Russell). @x module 538 begin if input_ln(cur_file,false) then do_nothing; firm_up_the_line; if end_line_char_inactive then decr(limit) else buffer[limit]:=end_line_char; first:=limit+1; loc:=start; line:=1; @y begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; if end_line_char_inactive then decr(limit) else buffer[limit]:=end_line_char; first:=limit+1; loc:=start; @z 393. (I sincerely hope that there won't be any more) ######################################################################## Addenda to MF84.BUG as of 21 September 90 555. Don't try system area if an area was given (see tex82.bug number 312; found by Jonathan Kew, May 1990) @x pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; @y if cur_area="" then begin pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; end; @z 556. Report correct line number when buffer overflows (CET, Jul 90). @x module 794 begin if not input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; line:=1; @y begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; @z 557. (I sincerely hope that there won't be any more) ######################################################################## Changes to ERRATA.FIVE as of 21 September 90 \bugonpage A336, lines 4--8 from the bottom (9/23/89) % was \bugonpage A336, lines 4--8 (9/23/89) \bugonpage A337, lines 2--16 (9/23/89) % was \bugonpage A336, lines 2--16 (9/23/89) ######################################################################## New errata in ERRATA.TEX as of 21 September 90 \bugonpage A124, lines 18--21 (9/5/90) \ninepoint\noindent Floating insertions can be accommodated as a special case of split insertions, by making each floating topinsert start with a small penalty, and by having zero as the associated |\floatingpenalty|; non-floating insertions like footnotes are accommodated by associating larger penalties with split insertions (see Appendix~B). \bugonpage A165, lines 2--3 (8/13/90) \ninepoint Type the formula $\bf\bar x^{\rm T}Mx={\rm0}\iff x=0$, using as few keystrokes as possible. \ (The first `0' is roman, the second is bold. The superscript `T' is roman.) \bugonpage A317, line 17 (5/17/90) \ninepoint |\pretolerance=9999 \tolerance=9999 \parindent=0pt| \bugonpage A321, lines 16--17 (8/13/90) \ninepoint\noindent \hbox to\parindent{\bf\hss18.6.\enspace}\ignorespaces |$\bf\bar x^{\rm T}Mx={\rm0}\iff x=0$|. \ (If you typed a space between |\rm| and~|0|, you wasted a keystroke; but don't feel guilty about it.) \bugonpage Exiii, replacement for last four lines (4/30/90) \textindent{\bull}``AMS Euler---A new typeface for mathematics'' by Donald~E. Knuth and Hermann Zapf, {\sl Scholarly Publishing\/ \bf21} (1989), 131--157. \ {\it The story of a design project that helps bridge the gulf between mathematics and art.} \smallskip \textindent{\bull}``Meta-Marks: Preliminary studies for a Pandora's Box of shapes'' by Neenie Billawala, Stanford Computer Science report 1259 (Stanford, California, July 1989), 132~pp. \ {\it Lavishly illus\-trated studies in parameter variation, leading to the design of a new typeface called Pandora.} ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 027 ] ------- 30-Oct-1990 7:07:30-GMT,5785;000000000001 Return-Path: <@MATH.AMS.COM,@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA12724; Tue, 30 Oct 90 07:07:21 MST Received: from ruuinf.cs.ruu.nl by MATH.AMS.COM via SMTP with TCP; Tue, 30 Oct 90 09:02:52-EDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA01231; Tue, 30 Oct 90 09:32:09 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA05801; Tue, 30 Oct 90 09:33:46 -0100 Date: Tue, 30 Oct 90 09:33:46 -0100 From: Piet van Oostrum Message-Id: <9010300833.AA05801@praxis.cs.ruu.nl> To: tex-implementors@math.ams.com Cc: pzf5hz@drueds2.BITNET, schoepf@sc.zib-berlin.dbp.de, lamport@src.dec.com Subject: Bug in Latex not corrected I posted this some time ago in TeXhax, but didn't see any response, so I mail this now. This is from latex.bug: 138. A command like \index or \label could incorrectly suppress a space after the next \end command. (Reported by Johannes Braams. Partially fixed on 30 Nov 88. Problem can still occur if \index or \label command comes inside the \end's environment.) Well, it appears not to be fixed at all (Except in the comments). This is from latex.tex as it appears on labrea: (Dated 7 Dec 1989) % \begin{NAME} == % BEGIN % IF \NAME undefined THEN \@tempa == BEGIN report error END % ELSE \@tempa == (\@currenvir :=L NAME) \NAME % FI % @ignore :=G F %% Added 30 Nov 88 % \begingroup % \@currenvir :=L NAME % \NAME % END \def\begin#1{\@ifundefined{#1}{\def\@tempa{\@latexerr{Environment #1 undefined}\@eha}}{\def\@tempa{\def\@currenvir{#1}% \csname #1\endcsname}}\begingroup\@endpefalse\@tempa} ^^ No \global\@ignoretrue Now the bug report mentions that this will not solve all problems. There is only one good solution for it: Have two versions of the \@esphack macro, one with \@ignoretrue (to be used in the end of an environment) and one without (to be used in simple commands). As the second one is used the most, the first one should get another name. It is currently used only in \end@float and its siblings. Here is a suggested patch. I have tested it only with one (big) file. Of course the fix is only official if endorsed by LL. *** latex.tex.~1~ Mon Feb 12 18:02:12 1990 --- latex.tex Fri Apr 20 21:09:00 1990 *************** *** 2000,2005 **** --- 2000,2009 ---- \ifhmode\@savsf\spacefactor\fi} \def\@esphack{\relax\ifhmode\spacefactor\@savsf + {}\ifdim \@savsk >\z@ \ignorespaces + \fi \fi} + + \def\@Esphack{\relax\ifhmode\spacefactor\@savsf {}\ifdim \@savsk >\z@ \global\@ignoretrue \ignorespaces \fi \fi} *************** *** 6494,6500 **** % else \vadjust{\penalty -10004 % \vbox{} % \penalty \@floatpenalty} ! % \@esphack % fi fi % END % --- 6498,6504 ---- % else \vadjust{\penalty -10004 % \vbox{} % \penalty \@floatpenalty} ! % \@Esphack % fi fi % END % *************** *** 6515,6521 **** % if \@floatpenalty < 0 % then \@dbldeferlist :=G \@dbldeferlist * \@currbox % fi ! % if \@floatpenalty = -10002 then \@esphack fi % END % \newcount\@floatpenalty --- 6519,6525 ---- % if \@floatpenalty < 0 % then \@dbldeferlist :=G \@dbldeferlist * \@currbox % fi ! % if \@floatpenalty = -10002 then \@Esphack fi % END % \newcount\@floatpenalty *************** *** 6560,6566 **** \vbox{} %% 26 May 87 to prevent extra vertical \prevdepth \@tempdima %% space when used in vertical mode \penalty\@floatpenalty ! \else \vadjust{\penalty -\@Miv \vbox{}\penalty\@floatpenalty}\@esphack \fi\fi} --- 6564,6570 ---- \vbox{} %% 26 May 87 to prevent extra vertical \prevdepth \@tempdima %% space when used in vertical mode \penalty\@floatpenalty ! \else \vadjust{\penalty -\@Miv \vbox{}\penalty\@floatpenalty}\@Esphack \fi\fi} *************** *** 6574,6580 **** \def\end@dblfloat{\if@twocolumn \par\vskip\z@\egroup %% \par\vskip\z@ added 15 Dec 87\egroup \ifnum\@floatpenalty <\z@ \@cons\@dbldeferlist\@currbox\fi ! \ifnum \@floatpenalty =-\@Mii \@esphack\fi\else\end@float\fi} \newcount\c@topnumber \newcount\c@dbltopnumber --- 6578,6584 ---- \def\end@dblfloat{\if@twocolumn \par\vskip\z@\egroup %% \par\vskip\z@ added 15 Dec 87\egroup \ifnum\@floatpenalty <\z@ \@cons\@dbldeferlist\@currbox\fi ! \ifnum \@floatpenalty =-\@Mii \@Esphack\fi\else\end@float\fi} \newcount\c@topnumber \newcount\c@dbltopnumber *************** *** 6689,6695 **** \def\@xympar{\ifnum\@floatpenalty <\z@\@cons\@currlist\@marbox\fi \setbox\@tempboxa\vbox %% added 3 Jan 88 ! \bgroup\end@float\@esphack} \def\reversemarginpar{\global\@mparbottom\z@ \@reversemargintrue} \def\normalmarginpar{\global\@mparbottom\z@ \@reversemarginfalse} --- 6693,6699 ---- \def\@xympar{\ifnum\@floatpenalty <\z@\@cons\@currlist\@marbox\fi \setbox\@tempboxa\vbox %% added 3 Jan 88 ! \bgroup\end@float\@Esphack} \def\reversemarginpar{\global\@mparbottom\z@ \@reversemargintrue} \def\normalmarginpar{\global\@mparbottom\z@ \@reversemarginfalse} Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') 26-Oct-1990 6:41:34-GMT,1519;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA12306; Fri, 26 Oct 90 14:41:29 MDT Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Fri, 26 Oct 90 16:31:30-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA19427; Fri, 26 Oct 90 13:27:05 -0700 Date: Fri, 26 Oct 90 13:27:05 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9010262027.AA19427@june.cs.washington.edu> To: BNB@MATH.AMS.COM Cc: TeX-implementors@MATH.AMS.COM In-Reply-To: bbeeton's message of Mon 22 Oct 90 13:32:37-EST <656616757.0.BNB@MATH.AMS.COM> Subject: Labrea archive files. The files for TeX proper are kept right up to date through these messages, but unfortunately there remains a problem at labrea. I have just looked once again, and the lplain and splain are still TeX2 files. There is no \language setting and no \lefthyphenmin setting. amslatex will undoubtedly be adopted as a preferable substitute in time, but for the immediate future we need to resolve the problem of unusuable lplain and splain files on the archive. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.acs.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thompson Hall, Mail Stop DR05 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 29-Oct-1990 12:35:05-GMT,1381;000000000001 Return-Path: <@MATH.AMS.COM,@SIF.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09025; Mon, 29 Oct 90 12:34:54 MST Received: from SIF.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 29 Oct 90 14:25:34-EDT Date: Mon, 29 Oct 1990 11:19 PST From: Don Hosek Subject: Re: Labrea archive files. To: mackay@cs.washington.edu, pzf5hz@drueds2.BITNET, schoepf@sc.zib-berlin.dbp.de, lamport@src.dec.com Cc: tex-implementors@math.ams.com Message-Id: <986B947EC0A00236@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: IN%"mackay@cs.washington.edu" X-Vms-Cc: IN%"tex-implementors@math.ams.com",FRANK_MITTELBACH, RAINER_SCHOEPF,LESLIE_LAMPORT There exist versions of lplain.tex and splain.tex for TeX 3.x (they also work with older TeXs as well) created by Frank and Rainer and some others I think. These are on ymir.claremont.edu in [anonymous.tex.inputs.latex] and [anonymous.tex.inputs.slitex]. Leslie has said that any changes to the files that Frank and Rainer can make official changes to the files and I've been considering these as the official lplain.tex and splain.tex; there has seemed to be some difficulty getting the change to propogate if it doesn't make it to labrea; perhaps we can finally get this taken care of? -dh 29-Oct-1990 17:41:21-GMT,1374;000000000001 Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10548; Mon, 29 Oct 90 17:41:11 MST Received: from june.cs.washington.edu by VAX01.AMS.COM via SMTP with TCP; Mon, 29 Oct 90 19:35:57-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA16394; Mon, 29 Oct 90 16:30:17 -0800 Date: Mon, 29 Oct 90 16:30:17 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9010300030.AA16394@june.cs.washington.edu> To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: pzf5hz@drueds2.BITNET.washington.edu, schoepf@sc.zib-berlin.dbp.de, lamport@src.dec.com, tex-implementors@math.ams.com In-Reply-To: Don Hosek's message of Mon, 29 Oct 1990 11:19 PST <9867D63E40A00236@HMCVAX.CLAREMONT.EDU> Subject: Labrea archive files. That certainly seems to resolve the problem. The splain file tracks the lplain file closely, as it ought to, and I like the dodge to make the same file work for both TeX2 and TeX3 Let's do it. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.acs.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thompson Hall, Mail Stop DR05 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 30-Oct-1990 16:01:02-GMT,5743;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02474; Tue, 30 Oct 90 16:00:49 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Tue, 30 Oct 90 17:55:11-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <6727-0@sun2.nsfnet-relay.ac.uk>; Tue, 30 Oct 1990 22:42:07 +0000 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa18069; 30 Oct 90 22:38 GMT Date: Tue, 30 Oct 90 22:45:21 GMT From: Chris Thompson To: TeX-implementors@math.ams.com Subject: State of AMSFonts 2.0 Message-Id: I have a number of outstanding problems with some of the AMSFonts 2.0 package, and as they are taking a very long time to resolve, I think they deserve to be more widely known, to avoid duplication of effort. I am particularly concerned here with problems that involve actual or potential changes to the TFM files, as these have serious implications for the exchange of documents using the fonts. I will divide the fonts up accoring to the sub-directories of ams/amsfonts/sources at e-math.ams.com: extracm. No problems here. cyrillic. There was a problem with wncysc10, but Tom Ridgeway fixed this promptly: an updated cyrcsc.mf (which is where the bug resided) was installed on e-math on 23 August. The only outstanding problem I know about is one involving rounding errors in the transform used by |mirror|: this only strikes a very few mode/magnification/font combinations, and can easily be circumvented by redefining |mirror| to avoid the rounding errors. euler. The TFM files for eufb6, eufb8 & eufb9 in ams/amsfonts/tfm-files do not match those generated from the source: the widths and the checksums do not match. (I discount here a large number of other cases of inconsistency in the contents of the later parts of the 'header' parts of the TFM files.) It turns out that this is the tip of a very ugly iceberg: the values of the parameters leftsize# and rightsize# are completely inconsistent between the 10pt/7pt/5pt fonts and the 9pt/8pt/6pt fonts. It would appear that at different times these parameters (which are the same across the eu{f|r|s}{m|b} series) have taken the values 10pt 9pt 8pt 7pt 6pt 5pt (a) 0h# 33h# 100h# 200h# 333h# 500h# (b) 0h# 33h# 100h# 100h# 333h# 300h# (c) 0h# 25h# 75h# 100h# 200h# 300h# The original state (a) can only be deduced from commented-out lines. State (b) is what most of the current sources, and all the TFM files, correspond to. State (c) is present in only the eufb#.mf sources. Obviously, state (b) is not self-consistent, being non-monotonic. The most optimistic view I can take of the current state is that the 10pt/7pt/5pt fonts are in what will be their final state, while the 9pt/8pt/6pt fonts should be not be touched with the proverbial bargepole, as any fix for these problems will alter their TFM files (and in particular, the checksum). symbols. The source for the msam# fonts produces different TFM files depending on the mode/magnification. The variations are only in the heights and depths, not in the widths (and hence not the checksums). The immediate cause is of this is the setting of 'radius#' on line 1720 of asymbols.mf: radius={the result of a calculation}; radius=radius#*hppp; This setting of a #'d quantity from a un-#'d one is always an error, because it makes the #'d quantity dependant on mode/magnification (because of rounding errors, even if the un-#'d quantities haven't been rounded to pixels, blackened, overshot, or whatever). Some of you will remember a very similar bug in the LaTeX circle fonts before Don Knuth fixed them (ref. TeXhax digests 1989 #9 & #57). This quantity radius# is used in the heights and depths of characters 114='162="72 (circled R) and 115='162="73 (circled S), making them not mode/magnification-independent. However, the msam# fonts have well over 15 distinct heights and depths, so these variable values get fed into METAFONT's algorithm for choosing a compromise 15 values, and end up affecting the heights and depths of many other characters. Although this is the only bug I know of that affects the TFM files in these fonts, I have to say that the general quality of the METAFONT source for these fonts is much lower than that of the others. The accompanying documenation tells one to ignore METAFONT errors at low resolutions for all the fonts, but only for the symbol fonts (msam# and msbm#) is it actually necessary to do so for 200dpi upwards, and there is little sign that they actually disappear however high the resolution. I would welcome the experiences of other tex-implementors with these fonts, and also any account of whether they have achieved satisfactory communcation with the technical support staff at the AMS (the 'readme' file tells one to report problems to tech-support@math.ams.com). For example, I reported the eufb6/eufb8/eufb9 problem to them 2 months ago, and despite reminders have yet to receive even an acknowledgment that they aware of the problem. (Barbara is of course exempted from this criticism: when I cc the messages to her I always get a prompt and useful reply: for example she put me in touch with Tom Ridgeway at Washington in connection with the cyrillic font problems.) Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk 31-Oct-1990 8:10:24-GMT,1493;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PZF5HZ@DRUEDS2.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA16251; Wed, 31 Oct 90 08:10:12 MST Message-Id: <9010311510.AA16251@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 31 Oct 90 10:06:04-EDT Received: from RUIPC1E.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8998; Wed, 31 Oct 90 10:00:39 EST Date: 10/31/90 15:51:59 GMT+1 From: MITTELBACH FRANK To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: RE: BUG IN LATEX NOT CORRECTED > > This is from latex.bug: > > 138. A command like \index or \label could incorrectly suppress a > space after the next \end command. (Reported by Johannes Braams. > Partially fixed on 30 Nov 88. Problem can still occur if \index or > \label command comes inside the \end's environment.) > > Well, it appears not to be fixed at all (Except in the comments). Well, I suppose that for some reason two different fixes to the \document macro canceled each other. The question is, do we re-add the \@ignoretrue? > > > Now the bug report mentions that this will not solve all problems. There is > only one good solution for it: I wonder whether it is really worth the effort to fix these kind of marginal errors currently if LaTeX is going to change anyway. Such global all over the place changes are normally dangerous and I don't have the time to check them out. Frank 31-Oct-1990 14:09:24-GMT,1816;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01128; Wed, 31 Oct 90 14:09:15 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 31 Oct 90 16:04:42-EDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 31 Oct 90 16:05:41-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <7843-52@sun2.nsfnet-relay.ac.uk>; Wed, 31 Oct 1990 17:17:07 +0000 Received: from sun2.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa11241; 31 Oct 90 16:33 GMT Date: Wed, 31 Oct 90 16:40:14 GMT From: Chris Thompson To: TeX-implementors@math.ams.com Cc: MITTELBACH FRANK <@cunyvm.cuny.edu:PZF5HZ@drueds2.bitnet> Subject: RE: RE: LABREA ARCHIVE FILES. Message-Id: Frank Mittelbach writes > Yes please place it in the official archive since this is slowing > things up otherwise. I trust that whoever is updating the labrea files will do it in the approved Lamport fashion, as described in section 7 of latex.ins, i.e. with the final change to latex.bug. Well, of course they will, won't they? If I sound suspicious it must be the result of having had too much experience with other badly maintained archives. Maybe it's the result of mail system blockages and malfunctionings, but I am having some difficulty sorting the thread of recent messages involving LaTeX on tex-implementors. Could everyone be careful that they don't transfer a thread previously not on tex-implementors onto it without giving the background? Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk 19-Nov-1990 10:36:57-GMT,777;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.stanford.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA04909; Mon, 19 Nov 90 10:36:47 MST Received: from smiley.stanford.edu by MATH.AMS.COM via SMTP with TCP; Mon, 19 Nov 90 12:29:39-EDT Received: by smiley.stanford.edu (4.1/inc-1.0) id AA03100; Mon, 19 Nov 90 09:25:11 PST Date: Mon, 19 Nov 90 09:25:11 PST From: kolk@smiley.stanford.edu (Dan Kolkowitz) Message-Id: <9011191725.AA03100@smiley.stanford.edu> To: tex-implementors@math.ams.com Subject: labrea files updated I've updated the splain.tex and lplain.tex files in ftp/tex/latex. Pierre Mackay gave me the files that replaced the old ones. I kept the old ones around in ~ftp/tex/OLD.latex. I hope it is all correct now. Dan 21-Nov-1990 16:24:13-GMT,1199;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA17047; Wed, 21 Nov 90 16:24:08 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Wed, 21 Nov 90 18:14:03-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA00183; Wed, 21 Nov 90 15:09:27 -0800 Date: Wed, 21 Nov 90 15:09:27 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9011212309.AA00183@june.cs.washington.edu> To: kolk@smiley.stanford.edu Cc: tex-implementors@math.ams.com In-Reply-To: Dan Kolkowitz's message of Mon, 19 Nov 90 09:25:11 PST <9011191725.AA03100@smiley.stanford.edu> Subject: labrea files updated Perfect. Just for safety, I recopied the files and checked them. Everything is just as it should be. Many thanks. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 27-Nov-1990 13:53:29-GMT,1549;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06154; Tue, 27 Nov 90 13:53:24 MST Date: Tue 27 Nov 90 15:26:24-EST From: bbeeton Subject: TeX-Preview for VMS (forwarded message) To: TeX-implementors@VAX01.AMS.COM Message-Id: <659737584.0.BNB@MATH.AMS.COM> Mail-System-Version: i'm forwarding the attached message at the request of matthias gaertner. --------------- Date: Tue, 27 Nov 90 18:19:46 +0100 (Central European Time) From: XCGNSTEX%DDATHD21.BITNET@CUNYVM.CUNY.EDU (M. GAERTNER) Subject: TeX-Preview for VMS Hi Miss Beeton, since our BITNET-Server corrupts the addresses for the TeX-implementators list, I'm writing to you with the request to forward it. My message: I'm searching a preview-program for Tektronixs and/or for VTxxx (VT200 and above). And all this for VMS, language C, FORTRAN, PASCAL or WEB. (And if possible not too close at system level, since our DEC10 is still running and running...) So, has anybody out there such a program??? Oh, btw. our Font-finding scheme is alike for DVI2LN3: All Pixel-files found under TEX$PIXEL, with the size encoded in the extention (CMR10.1500pxl). Thank you for yor help M. Gaertner Fachbereichsrechner Maschinenbau TH Darmstadt Petersenstrasse 30 D-6100 Darmstadt BITNET: XCGNSTEX@DDATHD21.BITNET (TeX) XCGNMGAE@DDATHD21.BITNET (Privat) ------- 27-Nov-1990 23:43:34-GMT,1463;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:UCIR001@FRORS12.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09113; Wed, 28 Nov 90 06:43:29 MST Message-Id: <9011281343.AA09113@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 28 Nov 90 08:34:23-EDT Received: from FRORS12.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2776; Wed, 28 Nov 90 08:29:01 EST Received: from FRORS12 (UCIR001) by FRORS12.BITNET (Mailer R2.05) with BSMTP id 9730; Wed, 28 Nov 90 14:26:36 EDT Date: Wed, 28 Nov 90 14:13:18 EDT From: Gaulle Bernard Subject: DVI2TTY (C version) To: TEX-IMPLEMENTORS Eureka| After few weeks searching for Marcel J.E. MOL around the world, i've found this dutch man (don't ask me how, I don't know|) at the university of Delft. He as merged my modifications about accents and tt fonts usage, with his own version which is now: DVI2TTY V4.4 ------------ I'd be pleased to see his name on this list if it's possible to extend it a lot: Marcel J.E. Mol I can give a copy of DVI2TTY to any archiver who ask me but i prefer that he ask directly Marcel for that. (note that DVI2TTY is going together with DISDVI which is a DVITYPE-like pgm). For the benefit of all TeX users... Bernard GAULLE 17-Dec-1990 7:22:25-GMT,2627;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:TEX@rmcs.cranfield.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10331; Mon, 17 Dec 90 14:22:11 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Mon, 17 Dec 90 15:56:40-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <6461-0@sun2.nsfnet-relay.ac.uk>; Mon, 17 Dec 1990 20:26:00 +0000 Received: from sun2.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa13012; 17 Dec 90 20:17 GMT Date: Mon, 17 DEC 90 20:28:48 GMT From: TEX@rmcs.cranfield.ac.uk To: TEX-IMPLEMENTORS <@nsfnet-relay.ac.uk:TEX-IMPLEMENTORS@math.ams.com> Subject: ANyone got some (small) sample .VPL files? Actually-To: Sender: "JANET TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <00000DBF_0017A370.0094156634BC9A00$36_1@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: INTERNET%COM.AMS.MATH::TEX-IMPLEMENTORS Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) I'm about to add virtual font support to my DVItoLN03 program. The only examples of Virtual Property List files that I have seen (except in the Web of vptovf) are for remapping Adobe fonts to TeX (or should that be vice versa). Such virtual fonts will be singularly useless to me for testing an LN03 program (non-PostScript) so I wonder if anyone out there has any suitable small sample VPL files that I could use. If you have, please mail me directly. If I don't hear anything within the next few days, I suppose I'll have to go off and write my own }:-< Many thanks, in advance, Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: ...!mcvax!rmcs.cranfield.ac.uk!tex + + OR ...!ukc!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 22-Dec-1990 18:22:37-GMT,3465;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08331; Sat, 22 Dec 90 11:22:35 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA04470; Sat, 22 Dec 90 10:21:17 -0800 Date: Sat, 22 Dec 90 10:21:17 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9012221821.AA04470@june.cs.washington.edu> To: cnix!klaus@relay.EU.net, karl@cs.umb.edu, morgan@ics.uci.edu Cc: elisabet@max.u.washington.edu, beebe@science.utah.edu Subject: SunOS 4.1 I finally got my hands on a Sparcstation running 4.1, so that I could work out the problems with the Sunview version of sun.c in mf/MFwindows. There are two. The conflict between the definition of reset in extra.h and cg9reg.h is easy, since reset() is unused in sun.c (is it ever used anywhere? or is it just a fossil from the Pascal-H compiler on SAIL?). All we need to do is #undef reset before the inclusion of any suntool/*.h files. But that unmasks a flood of new problems, all of which are related to the fact that 4.1 (at least in the U. S.) is now an enviroment which favors _POSIX_SOURCE compilations. The suntool include files have not been upgraded to POSIX, and my suspicion is that this exclusion is deliberate, to force the use of OpenLook. They require a whole collection of BSD types which seem not to work very well inside a POSIX environment. Moreover, if _POSIX_SOURCE is defined it does no good to include because there is an #ifdef _POSIX_SOURCE which effectively turns types.h into a no-op. So the only answer is to turn of _POSIX_SOURCE temporarily, which I do thus. -------------------------------- *** old_sun.c Fri Dec 21 15:25:18 1990 --- sun.c Fri Dec 21 15:36:42 1990 *************** *** 17,24 **** --- 17,43 ---- #ifdef SUNWIN #include + /* + * In SunOS 4.1, presumably to force users into OpenLook, + * Sun has established a general _POSIX_SOURCE environment, + * but has left the suntool include files outside this + * environment. They are therefore thick with typedefs + * incompatible with the remainder of the compilation. + * We cure it thus. + */ + #undef BACK_TO_POSIX /* Play it absolutely safe */ + #ifdef _POSIX_SOURCE + #define BACK_TO_POSIX + #undef _POSIX_SOURCE + #endif + #include /* Some old BSD types for suntool h files */ + #undef reset /* We don't need it, and it conflicts with cg9reg.h */ #include #include + #ifdef BACK_TO_POSIX + #define _POSIX_SOURCE + #undef BACK_TO_POSIX + #endif static void repaint_proc(); static void resize_proc(); ---------------------------------------- I hope to have access to an OpenLook system fairly soon, and will then try to provide both a Sunview and an Xview version. The difference is not supposed to be very great. PS to klaus: Since you were not forced into the _POSIX_SOURCE environment, I can only assume that POSIX is not a part of the export version of SunOS4.1. That's a pity, if so, because POSIX is really good stuff. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 12-Jan-1991 2:29:16-GMT,11165;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:XITIKGUN@DDATHD21> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13373; Mon, 14 Jan 91 03:29:09 MST Message-Id: <9101141029.AA13373@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 14 Jan 91 05:23:33-EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2201; Mon, 14 Jan 91 05:15:53 EST Received: from PCSITI.FB20.THD.DA.EUROPE by DDATHD21.BITNET via GNET with RJE with RCOM ; 14 Jan 91 11:17:34 Date: Mon Jan 14 10:30:16 MET 1991 From: XITIKGUN%DDATHD21.BITNET@CUNYVM.CUNY.EDU Subject: bug in TeXtrie.chg version 2 To: TeX-implementors@math.ams.com X-Munix-To: TeX-implementors@math.ams.com The conversion from my trie extension scheme version 2.0 (distributed last summer) contained a bug. One line from version 1.1 was not changed any more. This bug was discovered recently by Bernd Raichle from Stuttgart. It may lead to wrong hyphenations, but fortunately enough this does not happen frequently with patterns currently in use. I include the updated version 2.1. The corresponding web2c diff change will be sent separately to Karl Berry for redistribution. Sorry for any inconveniences. Klaus Guntermann xitikgun@ddathd21 -------------------------------------cut here---------textrie.chg This is textrie.chg, Version 2.1, as of 09 January 1991. Changes to allow more than 256 trie operations in TeX 3.0. history ------- version 1.0 developed the basic changes (May 1990) version 2.0 redefined the trie data structure to avoid too many unused areas in memory if alignment is required. Thanks to Peter Breitenlohner (July 1990) version 2.1 reintroduces a change lost on conversion from 1.0 to 2.0 (type of |hyf_next| must be changed). Thanks to Bernd Raichle (January 1991). Klaus Guntermann, TH Darmstadt, FR Germany xitikgun@ddathd21.bitnet @x [1] s.11 @!trie_op_size=500; {space for ``opcodes'' in the hyphenation patterns} @y @!trie_op_size=750; {space for ``opcodes'' in the hyphenation patterns} @!min_trie_op=0; {first possible trie op code for any language} @!max_trie_op=500; {largest possible trie op code for any language} @z @x [42] s.920 Comparatively few different number sequences $n_0\ldots n_k$ actually occur, since most of the |n|'s are generally zero. Therefore the number sequences are encoded in such a way that |trie_op|$(z_k)$ is only one byte long. If |trie_op(@t$z_k$@>)<>min_quarterword|, when $p_1\ldots p_k$ has matched the letters in |hc[(l-k+1)..l@,]| of language |t|, we perform all of the required operations for this pattern by carrying out the following little program: Set |v:=trie_op(@t$z_k$@>)|. Then set |v:=v+op_start[t]|, |hyf[l-hyf_distance[v]]:=@tmax@>(hyf[l-hyf_distance[v]], hyf_num[v])|, and |v:=hyf_next[v]|; repeat, if necessary, until |v=min_quarterword|. @y The theory that comparatively few different number sequences $n_0\ldots n_k$ actually occur, since most of the |n|'s are generally zero, seems to fail at least for the large German hyphenation patterns. Therefore the number sequences cannot any longer be encoded in such a way that |trie_op|$(z_k)$ is only one byte long. We have introduced a new constant |max_trie_op| for the maximum allowable hyphenation operation code value; |max_trie_op| might be different for \TeX\ and \.{INITEX} and must not exceed |max_halfword|. An opcode will occupy a halfword if |max_trie_op| exceeds |max_quarterword| or a quarterword otherwise. @^system dependencies@> If |trie_op(@t$z_k$@>)<>min_trie_op|, when $p_1\ldots p_k$ has matched the letters in |hc[(l-k+1)..l@,]| of language |t|, we perform all of the required operations for this pattern by carrying out the following little program: Set |v:=trie_op(@t$z_k$@>)|. Then set |v:=v+op_start[t]|, |hyf[l-hyf_distance[v]]:=@tmax@>(hyf[l-hyf_distance[v]], hyf_num[v])|, and |v:=hyf_next[v]|; repeat, if necessary, until |v=min_trie_op|. @z @x [42] s.920 @!trie_pointer=0..trie_size; {an index into |trie|} @y @!trie_opcode=min_trie_op..max_trie_op; {a trie opcode} @!trie_pointer=0..trie_size; {an index into |trie|} @z @x [42] s.921 @ @d trie_link(#)==trie[#].rh {``downward'' link in a trie} @d trie_char(#)==trie[#].b1 {character matched at this trie location} @d trie_op(#)==trie[#].b0 {program for hyphenation at this trie location} @y @ For more than 255 trie op codes, the three fields |trie_link|, |trie_char|, and |trie_op| will no longer fit into one memory word; thus we define |trie| as a record of arrays instead of an array of records. This will result in more economic memory usage. @d trie_link(#)==trie.trl[#] {``downward'' link in a trie} @d trie_char(#)==trie.trc[#] {character matched at this trie location} @d trie_op(#)==trie.tro[#] {program for hyphenation at this trie location} @z @x [42] s.921 @!trie:array[trie_pointer] of two_halves; {|trie_link|, |trie_char|, |trie_op|} @y @!trie: packed record@;@/ @!trl:array[trie_pointer] of halfword; {|trie_link|} case two_choices of 1: (@!tro:array[trie_pointer] of trie_opcode; {|trie_op|} @!trc:array[trie_pointer] of quarterword); {|trie_char|} 2: (@!trb:array[trie_pointer] of halfword); {|trie_back|} end; @z @x [42] s.921 @!hyf_next:array[1..trie_op_size] of quarterword; {continuation code} @y @!hyf_next:array[1..trie_op_size] of trie_opcode; {continuation code} @z The next changes merely change from the old types and constants to the new ones. This is straight forward. @x [42] s.923 begin if trie_op(z)<>min_quarterword then @y begin if trie_op(z)<>min_trie_op then @z @x [42] s.924 until v=min_quarterword; @y until v=min_trie_op; @z @x [42] s.943 |hyf_next[@t$v^\prime$@>]=min_quarterword|. @y |hyf_next[@t$v^\prime$@>]=min_trie_op|. @z @x [42] s.943 $$\hbox{|@t$v^\prime$@>:=new_trie_op(0,1,min_quarterword)|,\qquad @y $$\hbox{|@t$v^\prime$@>:=new_trie_op(0,1,min_trie_op)|,\qquad @z @x [43] s.943 @!trie_used:array[ASCII_code] of quarterword; @y @!trie_used:array[ASCII_code] of trie_opcode; @z @x [43] s.943 @!trie_op_val:array[1..trie_op_size] of quarterword; @y @!trie_op_val:array[1..trie_op_size] of trie_opcode; @z @x [43] s.943 tini @y tini@; @!max_op_used:trie_opcode; {largest opcode used for any language} @!small_op:boolean; {flag used while dumping or undumping} @z @x [43] s.944 |new_trie_op| could return |min_quarterword| (thereby simply ignoring @y |new_trie_op| could return |min_trie_op| (thereby simply ignoring @z @x [43] s.944 function new_trie_op(@!d,@!n:small_number;@!v:quarterword):quarterword; label exit; var h:-trie_op_size..trie_op_size; {trial hash location} @!u:quarterword; {trial op code} @y function new_trie_op(@!d,@!n:small_number;@!v:trie_opcode):trie_opcode; label exit; var h:-trie_op_size..trie_op_size; {trial hash location} @!u:trie_opcode; {trial op code} @z @x [43] s.944 if u=max_quarterword then overflow("pattern memory ops per language", max_quarterword-min_quarterword); incr(trie_op_ptr); incr(u); trie_used[cur_lang]:=u; @y if u=max_trie_op then overflow("pattern memory ops per language", max_trie_op-min_trie_op); incr(trie_op_ptr); incr(u); trie_used[cur_lang]:=u; if u>max_op_used then max_op_used:=u; @z @x [43] s.945 op_start[0]:=-min_quarterword; @y op_start[0]:=-min_trie_op; @z @x [43] s.946 for k:=0 to 255 do trie_used[k]:=min_quarterword; @y for k:=0 to 255 do trie_used[k]:=min_trie_op; @z @x [43] s.946 trie_op_ptr:=0; @y max_op_used:=min_trie_op; trie_op_ptr:=0; @z @x [43] s.947 @t\hskip10pt@>@!trie_o:packed array[trie_pointer] of quarterword; @y @t\hskip10pt@>@!trie_o:packed array[trie_pointer] of trie_opcode; @z @x [43] s.950 @d trie_back(#)==trie[#].lh {backward links in |trie| holes} @y @d trie_back(#)==trie.trb[#] {backward links in |trie| holes} @z @x [43] s.958 @= h.rh:=0; h.b0:=min_quarterword; h.b1:=min_quarterword; {|trie_link:=0|, |trie_op:=min_quarterword|, |trie_char:=qi(0)|} if trie_root=0 then {no patterns were given} begin for r:=0 to 256 do trie[r]:=h; @y @d clear_trie == {clear |trie[r]|} begin trie_link(r):=0; trie_op(r):=min_trie_op; trie_char(r):=min_quarterword; {|trie_char:=qi(0)|} end @= if trie_root=0 then {no patterns were given} begin for r:=0 to 256 do clear_trie; @z @x [43] s.958 repeat s:=trie_link(r); trie[r]:=h; r:=s; @y repeat s:=trie_link(r); clear_trie; r:=s; @z @x [43] s.960 @!v:quarterword; {trie op code} @y @!v:trie_opcode; {trie op code} @z @x [43] s.963 if trie_o[q]<>min_quarterword then @y if trie_o[q]<>min_trie_op then @z @x [43] s.964 trie_c[p]:=si(c); trie_o[p]:=min_quarterword; @y trie_c[p]:=si(c); trie_o[p]:=min_trie_op; @z @x [43] s.965 l:=k; v:=min_quarterword; @y l:=k; v:=min_trie_op; @z @x [43] m.966 @!h:two_halves; {template used to zero out |trie|'s holes} @y @z @x [50] s.1324 @ @= @y @ Depending on whether the largest trie op code used for any language (|max_op_used|) does or doesn't exceed |max_quarterword|, two or four op codes are packed into one memory word in the format file. @d dump_two_halves(#)== begin fmt_file^.hh.lh:=#(k); fmt_file^.hh.rh:=#(k+1); put(fmt_file); end @d dump_four_quarters(#)== begin fmt_file^.qqqq.b0:=#(k); fmt_file^.qqqq.b1:=#(k+1); fmt_file^.qqqq.b2:=#(k+2); fmt_file^.qqqq.b3:=#(k+3); put(fmt_file); end @= @z @x [50] s.1324 for k:=0 to trie_max do dump_hh(trie[k]); @y dump_int(max_op_used); small_op:=(max_op_used<=max_quarterword);@/ k:=0; while k+1= @y @d undump_two_halves(#)== begin get(fmt_file); #(k):=fmt_file^.hh.lh; #(k+1):=fmt_file^.hh.rh; end @d undump_four_quarters(#)== begin get(fmt_file); #(k):=fmt_file^.qqqq.b0; #(k+1):=fmt_file^.qqqq.b1; #(k+2):=fmt_file^.qqqq.b2; #(k+3):=fmt_file^.qqqq.b3; end @= @z @x [50] s.1325 for k:=0 to j do undump_hh(trie[k]); @y undump_size(min_trie_op)(max_trie_op)('max trie op')(max_op_used); small_op:=(max_op_used<=max_quarterword);@/ k:=0; while k+1 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07216; Thu, 17 Jan 91 02:53:33 MST Message-Id: <9101170953.AA07216@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 17 Jan 91 04:06:24-EDT Received: from FRORS12.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0619; Thu, 17 Jan 91 03:58:17 EST Received: from FRORS12 (UCIR001) by FRORS12.BITNET (Mailer R2.07) with BSMTP id 7362; Thu, 17 Jan 91 10:00:20 EDT Date: Thu, 17 Jan 91 09:56:54 EDT From: Gaulle Bernard Subject: MLTeX V3 Change file archived To: LSV IMPLEM The mulitilingual modifications from Michael FERGUSON for TeX V3 are now archived on and can be retrieved by the mean of the following message line : GET MLTEX3 CHG GUT Bernard GAULLE (GUTenberg President) 3-Feb-1991 16:06:11-GMT,1439;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06848; Sun, 3 Feb 91 09:06:07 MST Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Sun, 3 Feb 91 11:03:37-EDT Date: Sun, 3 Feb 1991 04:42 PST From: Don Hosek Subject: \openin and texinputs: To: tex-implementors@math.ams.com, rokicki@neon.stanford.edu Message-Id: <99E749FBBA60127B@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: in%"tex-implementors@math.ams.com" X-Vms-Cc: tom_rokicki After a check to the source code w.r.t an apparent discrepancy in two TeX implementations' treatments of \openin and texinputs, I have determined that it is _incorrect_ for \openin15=foo.tex to find foo.tex on the texinputs: path. This means, e.g., that the LaTeX internal macro \@input should give a file does not exist message when used on a file not in the current directory since it uses \openin to check for the file's existence. It is possible to write an \@input-like macro which will check tex_inputs: as well by doing a second \openin on texinputs:filename, *but* such an approach is system dependent since texinputs will have a different value depending on the precise system (e.g., PCTeX uses TEXINPUT:, VMS TeX uses TeX_inputs: (or sometimes, incorrectly, TeX$inputs:) etc.) -dh 4-Feb-1991 9:10:42-GMT,2428;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05010; Mon, 4 Feb 91 02:10:38 MST Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 03:35:47-EDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA05518; Mon, 4 Feb 91 09:31:48 +0100 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA15342; Mon, 4 Feb 91 09:31:46 +0100 Date: Mon, 4 Feb 91 09:31:46 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9102040831.AA15342@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-implementors@math.ams.com, rokicki@neon.stanford.edu, PZF5HZ@RUIPC1E.bitnet In-Reply-To: Don Hosek's message of Sun, 3 Feb 1991 04:42 PST <99E749FBBA60127B@HMCVAX.CLAREMONT.EDU> Subject: \openin and texinputs: From: Don Hosek After a check to the source code w.r.t an apparent discrepancy in two TeX implementations' treatments of \openin and texinputs, I have determined that it is _incorrect_ for \openin15=foo.tex to find foo.tex on the texinputs: path. This means, e.g., that the LaTeX internal macro \@input should give a file does not exist message when used on a file not in the current directory since it uses \openin to check for the file's existence. It is possible to write an \@input-like macro which will check tex_inputs: as well by doing a second \openin on texinputs:filename, *but* such an approach is system dependent since texinputs will have a different value depending on the precise system (e.g., PCTeX uses TEXINPUT:, VMS TeX uses TeX_inputs: (or sometimes, incorrectly, TeX$inputs:) etc.) I think that there doesn't exist a definite answer to the question whether it is correct or incorrect. The most widely applicable solution would certainly be to have two environment variables, one for \input, one for \openin. From experience I favor the use of TEXINPUTS: for \input as well as for \openin. Dr. Rainer Sch\"opf Konrad-Zuse-Zentrum f\"ur Informationstechnik Berlin Heilbronner Strasse 10 D-1000 Berlin 31 Federal Republic of Germany or 4-Feb-1991 11:38:15-GMT,4210;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:TEX@rmcs.cranfield.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07542; Mon, 4 Feb 91 04:38:09 MST Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 06:35:29-EDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <4057-81@sun2.nsfnet-relay.ac.uk>; Mon, 4 Feb 1991 11:29:22 +0000 Received: from sun2.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa04854; 4 Feb 91 10:53 GMT Date: Mon, 4 FEB 91 11:05:57 GMT From: TEX@rmcs.cranfield.ac.uk To: TEX-IMPLEMENTORS <@nsfnet-relay.ac.uk:TEX-IMPLEMENTORS@math.ams.com> Subject: Under what circumstances does TeX make overwide lines silently? Actually-To: Sender: "JANET TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <00005B9F_001AB710.00943B98B108F880$11_1@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: INTERNET%COM.AMS.MATH::TEX-IMPLEMENTORS Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) I've been making extensive modifications to my DVItoLN03 driver program (official announcement shortly), but was somewhat perturbed to discover that there were seemingly a large number of pages which contained lines extending into the right margin when processing the .dvi generated by TeXing the woven source. My first suspicion was that I'd upset the careful sp-to-pixel rounding computation (inherited from DVItype many years ago), but running one of the offending pages through DVItype reveals that TeX has truly exceeded its right margin, by amounts varying between 0.1422pt and 9.1411pt, _without_ TeX making any complaint about an overfull \hbox (there are some other instances, where the excess is 3.2796pt and 10.5424pt, where TeX _has_ given such a message, and moreover added a further 5pt for the overfullrule). In all cases, the offending text sticks out to the right of the page; mostly it's not very noticeable, because the problems have arisen in the formatted Pascal, so there's no block of justified text to have its symmetry disturbed. But a few of the occasions are in the ``See also sections...'' at the end of Pascal code, and the bad setting is noticeable. Has anyone met this phenomenon before; I presume it's something defined in the webmac macros --- do they permit an overrun in preference to splitting a line of Pascal which it considers belongs on one line? This might tie in with those occasions when TeX has complained about the line, because all these instances occur in the TeX narrative at the start of a Web section (reason: lines containing \tt text at end of line). One other thing that I noticed: in the index there are a number of occasions with overfull lines (columns actually). When TeX added the overfullrule, it overlapped approx half of the asterisk indicating a changed section: could this explain it failing to detect the overfull lines in ``See also sections...'', because Weave hides the width of the asterisk? Furthermore, TeX only inserts the overfullrule if such on overflow occurs in the left column of the two on the index pages. ALtogether, there seem to be a number of anomalies here! Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: ...!mcvax!rmcs.cranfield.ac.uk!tex + + OR ...!ukc!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4-Feb-1991 11:38:19-GMT,919;000000000001 Return-Path: <@MATH.AMS.COM:ogawa@orion.arc.nasa.gov> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AB07542; Mon, 4 Feb 91 04:38:16 MST Received: from orion.arc.nasa.gov by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 06:40:42-EDT Received: Mon, 4 Feb 91 03:44:22 -0800 by orion.arc.nasa.gov (5.64/1.2) Date: Mon, 4 Feb 91 03:44:22 -0800 From: "Arthur Ogawa" Message-Id: <9102041144.AA20273@orion.arc.nasa.gov> To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-implementors@math.ams.com, rokicki@neon.stanford.edu In-Reply-To: Don Hosek's message of Sun, 3 Feb 1991 04:42 PST <99E749FBBA60127B@HMCVAX.CLAREMONT.EDU> Subject: \openin and texinputs: Yes, the relevant sections are 537 and 1275, which appear similar to a degree, but fall short of being identical: TeX_area is only applied to \input, not to \openin. I'll be curious to see how this comes out. 4-Feb-1991 13:27:11-GMT,3284;000000000001 Return-Path: <@MATH.AMS.COM,@BULLDOG.CS.YALE.EDU:lrw!leichter@LRW.COM> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08410; Mon, 4 Feb 91 06:27:06 MST Received: from BULLDOG.CS.YALE.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 08:20:28-EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Mon, 4 Feb 91 08:09:05 EST Message-Id: <9102041309.AA22880@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Mon, 4 Feb 91 07:11:40 EDT Date: Mon, 4 Feb 91 07:11:40 EDT From: Jerry Leichter To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: RE: \openin and texinputs: After a check to the source code w.r.t an apparent discrepancy in two TeX implementations' treatments of \openin and texinputs, I have determined that it is _incorrect_ for \openin15=foo.tex to find foo.tex on the texinputs: path. This means, e.g., that the LaTeX internal macro \@input should give a file does not exist message when used on a file not in the current directory since it uses \openin to check for the file's existence. It is possible to write an \@input-like macro which will check tex_inputs: as well by doing a second \openin on texinputs:filename, *but* such an approach is system dependent since texinputs will have a different value depending on the precise system (e.g., PCTeX uses TEXINPUT:, VMS TeX uses TeX_inputs: (or sometimes, incorrectly, TeX$inputs:) etc.) In the TeXbook, I see almost no difference between the definitions of \input and \openin. Actually, the one difference I see is problematical: It is mentioned that \openin, on "most" systems, adds a ".tex". But the "defini- tion" of \input (page 214) doesn't say this. (I don't know if it says it anywhere.) The interface between TeX and a particular system necessarily has some fuzzy spots. Knowing just what "a file name" is is one of them. Once you agree that "a filename" can be manipulated by adding ".tex" - something the TeXbook already does - the gates open wide. I don't know in what sense it can be "incorrect" for any implementation to define the processing of the file name "foo.tex" as meaning "foo.tex on the texinputs path". However, it can certainly be a very useful thing to do - exactly because this kind of manipu- lation is impossible to do portably in TeX. (The fact that exact names for the "device" vary from system to system is minor: At least on many systems you can write "path:" in front of the file and be done with it. But on Unix systems, a search path is typically just an environment value, and there is NO file-system support for it; any program that wishes to follow a path must do so on its own. Since there is no way for a portable TeX program to read an environment value, Unix TeX programs would be have to be hard-coded to look in some particular list of directories.) Imposing a standard is a great idea - unless that standard requires programs to not be useful. A TeX implementation that required that macro packages be locally adjusted to the details of the local file system arrangement - even to each particular machine - would not be used by many people. How many sites have a LaTeX guru able to modify \@input to reflect the local directory paths? -- Jerry 4-Feb-1991 13:54:20-GMT,981;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08623; Mon, 4 Feb 91 06:54:16 MST Date: Mon 4 Feb 91 08:49:01-EST From: bbeeton Subject: re: \openin and texinputs: To: tex-implementors@VAX01.AMS.COM Message-Id: <665675341.0.BNB@MATH.AMS.COM> Mail-System-Version: i have checked the treatment of \openin and \input in the implementations of tex available to me, which include that for tops-20. since the tops-20 implementation was done at stanford with at least some coordination directly with don knuth, i believe it is the best guide we have at the moment. the tops-20 implementation clearly searches texinputs: for \openin as well as \input . however, since i still don't consider this evidence definitive, i am sending the question to don and asking for his adjudication, which i will forward forthwith to this list. -- bb ------- 4-Feb-1991 14:56:51-GMT,816;000000000001 Return-Path: <@MATH.AMS.COM:jmr@nada.kth.se> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09211; Mon, 4 Feb 91 07:56:45 MST Received: from nada.kth.se by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 09:50:56-EDT Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03506; Mon, 4 Feb 91 15:45:30 +0100 Date: Mon, 4 Feb 91 15:45:30 +0100 From: Jan Michael Rynning To: tex-implementors@math.ams.com Subject: re: \openin and texinputs: Message-Id: Strange. The TOPS-20 TeX that we run searches TeXinputs: for \input, but not for \openin, and I'm sure we haven't changed the code. Barbara, are you sure you haven't made any local changes, and that you don't have TeXinputs: in your definition of DSK:? 4-Feb-1991 15:06:33-GMT,1197;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09293; Mon, 4 Feb 91 08:06:27 MST Date: Mon 4 Feb 91 10:00:58-EST From: bbeeton Subject: re: \openin and texinputs: To: jmr@nada.kth.se Cc: tex-implementors@MATH.AMS.COM Message-Id: <665679658.0.BNB@MATH.AMS.COM> In-Reply-To: Mail-System-Version: jan, you're actually on the right track, though backwards -- we have texinputs defined to be dsk: . the point is, though, that with tops-20 it's easy to define a path instead of a single directory, and it was just as easy with the sail system, so it's unclear to me whether don realized the implications of the difference. i shall phrase my inquiry to him as carefully as i can to yield a clear statement of intent. re the domain on the "to:" field from our mailer, i hadn't realized that would be a problem. it should cause no problems for me to add an explicit domain to the designation of tex-implementors right in the mailing list, and i shall do so after checking. thanks for the pointer. -- bb ------- 4-Feb-1991 16:16:06-GMT,3056;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10106; Mon, 4 Feb 91 09:16:01 MST Date: Mon 4 Feb 91 11:09:48-EST From: bbeeton Subject: [Philippe.Louarn%IRISA.FR@CUNYVM.CUNY.EDU: russian TeX] To: tex-implementors@VAX01.AMS.COM Message-Id: <665683788.0.BNB@MATH.AMS.COM> In-Reply-To: <665683131.0.RFW@MATH.AMS.COM> Mail-System-Version: the following message was circulated to the gut mailing list. i believe it may be of interest to most people on this list as well. --------------- Date: Mon, 4 Feb 91 09:31:28 +0100 Reply-To: Groupe francophone des Utilisateurs TeX Sender: Groupe francophone des Utilisateurs TeX From: Philippe.Louarn%IRISA.FR@CUNYVM.CUNY.EDU Subject: russian TeX J'ai recu le mail suivant. Il doit interesse les personnes utilisant TeX pour des textes russes. Philippe Louarn - Secretariat GUTenberg, c/o Irisa, Rennes ------- Forwarded Message Date: 30 Jan 91 17:43:00 GMT+3:00 From: "MX::MALYSHEV" Subject: TeX To: "gut" ================================================================= Russian \TeX % Basil Malyshev (IHEP, USSR) and Alexander Samarin (IHEP, USSR) Currently TeX-ware is the set of programs which have a lot of tuning parameters. To install and run TeX on IBM-PC one needs to know many hardware and software parameters. Special software or powerful command interpreter is needed to organize joint work of programs with good user's interface. MS-DOS shell COMMAND.COM and alternative shell 4DOS are not enough powerfull. Another problem is that full \TeX collection (e.g. Em\TeX with extension for russian \TeX) occupies a lot of hard disk space, while a particular task requires only part of programs and fonts. We have implemented a interpreter (x)RUN with LISP-like language. It supports operations with files and environment variables, running of programs (possibly overlay), user menu interface (with/without mouse) and something else. For Em\TeX collection we have implemented an integrated shell, based on (x)RUN. This shell has the following features: - it is able to reconfigurate the environment and download required files; - changeable lists of procedures are associated with file extensions. E.g. for .TEX file one can run \TeX, \LaTeX, an editor or spelling procedure. For .DVI file one can run a previewer or printer DVI-driver. - it is possible to check the accessibility of the pixel files for printing a DVI-file and to download them from the distribution kit. - one may add his own procedures to the shell. ================================================================= B. Malyshev E-mail: malyshev@m9.ihep.su ------- End of Forwarded Message ------- 5-Feb-1991 3:37:31-GMT,1070;000000000001 Return-Path: <@MATH.AMS.COM:ken@tucana.csis.dit.csiro.au> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA18393; Mon, 4 Feb 91 20:37:27 MST Received: from tucana.csis.dit.csiro.au by MATH.AMS.COM via SMTP with TCP; Mon, 4 Feb 91 18:11:17-EDT Received: from localhost.csis.dit.csiro.au by tucana.csis.dit.csiro.au (4.1/1.0) id AA13354; Tue, 5 Feb 91 10:04:03 EST Message-Id: <9102042304.AA13354@tucana.csis.dit.csiro.au> To: tex-implementors@math.ams.com Subject: paper sizes in LaTeX Reply-To: ken@csis.dit.csiro.au (Ken Yap) X-Internet: ken@csis.dit.csiro.au X-Snail: CSIS, CSIRO DIT, PO Box 664, Canberra ACT 2601, Australia X-Phone: (06) 275-0911 (office) Fax: (06) 257-1052 Date: Tue, 05 Feb 91 10:04:00 +1100 From: ken@tucana.csis.dit.csiro.au Forgive me if I'm out of date, but are international LaTeX implementors also dealing with the paper size issue? It always seemed a parochialism to me that non-USA users have to put [a4] in their \documentstyle when this should be a preloaded local setting, like hyphen.tex. Ken 7-Feb-1991 0:18:00-GMT,2906;000000000001 Return-Path: <@MATH.AMS.COM:ogawa@orion.arc.nasa.gov> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA20686; Wed, 6 Feb 91 17:17:56 MST Received: from orion.arc.nasa.gov by MATH.AMS.COM via SMTP with TCP; Wed, 6 Feb 91 19:16:55-EDT Received: Wed, 6 Feb 91 16:21:14 -0800 by orion.arc.nasa.gov (5.64/1.2) Date: Wed, 6 Feb 91 16:21:14 -0800 From: "Arthur Ogawa" Message-Id: <9102070021.AA19916@orion.arc.nasa.gov> To: CET1@phoenix.cambridge.ac.uk Cc: tex-implementors@math.ams.com In-Reply-To: Chris Thompson's message of Wed, 06 Feb 91 17:50:37 GMT Subject: \openin and texinputs: A clarification of LaTeX functionality WRT opening files may inform this discussion a bit. LaTeX has two ways of opening files for input; they differ in the way they work based on the precise difference between \openin and \input (which has been the subject of this discussion). 1. \input (with or without a delimited argument) does the same as the primitive \input. This macro will use the TeX_area internal to possibly provide a search path. Your .sty files and .bbl files are handled this way. 2. \include (or \@input) will only open a file in the current directory (modulo system dependencies, see below). This is the way LaTeX deals with reading your \included files and any files that LaTeX manages (such as .aux, .toc, etc, .idx). LaTeX does not do an \openin before doing an \openout to check whether a file is already there. It goes ahead and blithely clobbers. On the other hand, it scrupulously does an \@input for any file it generates itself. This ensures that the file it reads is the very file it wrote (clever, Leslie). Now, method (2) is important for .aux files, because I don't want LaTeX to read in .aux information for any file but the one I'm \including. And method (1) is important because I want to read my .sty and .bbl files from anywhere they may be. However, there may be cases where I want to perform some action based on whether an \input suceeded. TeX does not provide any way for me to check this; instead it provides a means of ensuring that the process never fails ("please type a file name:"). So I haven't any way to accomplish this check. However, I could if there were a way for the user to cancel out of the file name: prompt, say with a ^C (or Cancel on a windowing system). An extension to TeX that would still pass the trip test would be to provide a \ifcanceled command a la \ifeof. A note on system dependencies: any fileopen action on the Macintosh has the attributes of a search path: the poor man's search path (PMSP). This is a well-known paradigm to any one familiar with Inside Mac. The current directory is searched, followed by the application's directory, followed by the system folder. This search is done even for an \openin! 8-Feb-1991 0:40:39-GMT,1155;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07348; Thu, 7 Feb 91 17:40:34 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Thu, 7 Feb 91 19:37:23-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA29159; Thu, 7 Feb 91 16:31:47 -0800 Date: Thu, 7 Feb 91 16:31:47 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9102080031.AA29159@june.cs.washington.edu> To: ken@csis.dit.csiro.au Cc: tex-implementors@math.ams.com In-Reply-To: ken@tucana.csis.dit.csiro.au's message of Tue, 05 Feb 91 10:04:00 +1100 <9102042304.AA13354@tucana.csis.dit.csiro.au> Subject: paper sizes in LaTeX I am sure I have seen a4.sty and a5.sty around somewhere. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Feb-1991 1:14:36-GMT,2539;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07653; Thu, 7 Feb 91 18:14:35 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA04341; Thu, 7 Feb 91 17:13:17 -0800 Date: Thu, 7 Feb 91 17:13:17 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9102080113.AA04341@june.cs.washington.edu> To: karl@cs.umb.edu Cc: beebe@science.utah.edu, bnb@math.ams.com, spqr@ecs.southampton.ac.uk, dhosek@ymir.claremont.edu In-Reply-To: Karl Berry's message of Tue, 5 Feb 91 17:26:48 EST <9102052226.AA03082@ra.cs.umb.edu> Subject: more TeX font stuff 1) text font encoding. I can't wait. My only question is what do we call it. I am hoping that Don will accept E[xtended]CM* which is clearly different from CM* but keeps the reference to the basic style. 2) more \fontdimens For the same reasons, that more information beats ignorance every time, I applaud the notion of adding informative \fontdimen values. I haven-t tried yet, but I think this might be done without affecting the tfm checksum. I will experiment. In that case it could be done even in CM, but I would still prefer to get Don's blessing on that. 3) more mode_defs Doug Henderson and I have been talking about that. I submitted several recently, and I am working on a TUGboat article on how to go at it systematically, rather than by a sort of naval gunnery ranging approach. 4) GF specials The GF specials were thoroughly worked over about three years ago and the basic web for gftopk was actually altered to make them pass unaltered through to the pk file and to retain the METAFONT banner dating. Especially when there is a need to check whether a 300dpi font really belongs in the write-white or the write-black directories, it can be a real saver to have this info. Since they do not alter the tfm checksum, Don has given them the OK. 5) many mode_defs. U_Wash.mf now includes twenty. Moreover, if you forget their names, a simple questionmark will list all the preloaded mode_defs presently loaded. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Feb-1991 1:40:37-GMT,1915;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07858; Thu, 7 Feb 91 18:40:35 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA07150; Thu, 7 Feb 91 17:39:39 -0800 Date: Thu, 7 Feb 91 17:39:39 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9102080139.AA07150@june.cs.washington.edu> To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: @cs.umb.edu:karl@ra.cs.umb.edu, beebe@science.utah.edu, bnb@math.ams.com, spqr@ecs.soton.ac.uk, x066tr@tamvm1.BITNET.washington.edu In-Reply-To: Don Hosek's message of Tue, 5 Feb 1991 18:08 PST <9CDF53C120E0053A@HMCVAX.CLAREMONT.EDU> Subject: more TeX font stuff All you need to do to get an smode version is to take the mode-def out of the collection and put % before the first and last lines. Voila, This would be the smode file "VarityperSixZeroZero.mf" % mode_def VarityperSixZeroZero = proofing:=0; % no, we're not making proofs fontmaking:=1; % yes, we are making a font tracingtitles:=0; % no, don't show titles at all pixels_per_inch:=600; % Good but not perfect blacker:=0; % Seems black enough. Lighter than 300dpi fillin:=0; % but it ought to be. Closer to true o_correction:=0.8; % Modern proportions. Real problem is % enddef; % toner irregularity Better, I think to explain how to do it, than to keep a whole lot of duplicate mode_defs. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Feb-1991 17:09:58-GMT,2425;000000000001 Return-Path: <@MATH.AMS.COM:beebe@math.utah.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09848; Fri, 8 Feb 91 10:09:52 MST Received: from math.utah.edu by MATH.AMS.COM via SMTP with TCP; Fri, 8 Feb 91 12:05:51-EDT Received: from magna.math.utah.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09750; Fri, 8 Feb 91 10:00:49 MST Date: Fri, 8 Feb 91 10:00:49 MST From: Nelson H.F. Beebe To: tex-implementors@math.ams.com X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: Re: \openin and texinputs: In-Reply-To: Your message of Wed, 06 Feb 91 17:50:37 GMT Message-Id: Chris Thompson writes: >> ... >> It has occured to me that one could make an optimization by >> keeping the when >> \closein is used on a file in the state |just_open| (i.e. \read >> has never been used) and reusing it directly if a \input for the >> same name follows shortly. Has anyone ever attempted to do >> anything like this in their implementations? >> ... I've thought about this for the DVI drivers: we currently have many directories in the TEXFONTS path, and were the driver to remember that last directory in which it found a font and try that first, instead of going to the start of the TEXFONTS path list, considerable speedups would be possible. In the vast majority of cases, this would work fine. It fails, however, in those cases where files of the same name exist in more than one directory (e.g. the user might have tuned personal versions of a few fonts); the directory search order implied by TEXFONTS would then not be obeyed. Still, the idea seems interesting, and I'm likely to make the directory caching an option to the 3.0 DVI drivers. Those would use only standard fonts could then enable it in their startup files, and those with more demanding requirements would simply leave it disabled. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== 8-Feb-1991 17:15:56-GMT,930;000000000001 Return-Path: Received: from Neon.Stanford.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09918; Fri, 8 Feb 91 10:15:51 MST Received: by Neon.Stanford.EDU (5.61/25-eef) id AA08916; Fri, 8 Feb 91 09:15:50 -0800 Date: Fri, 8 Feb 91 09:15:50 -0800 From: Tomas G. Rokicki Message-Id: <9102081715.AA08916@Neon.Stanford.EDU> To: beebe@math.utah.edu Subject: Re: \openin and texinputs: In my opinion, directory caching and the like should be a function of the file system. Duplicating that functionality in user code on a reasonable file system will only slow things down. Any old systems that don't do directory caching should be running a more modern file system. Of course, I feel the same way about this flib/PK libraries; if your file system charges you so much overhead for small files, the file system should be fixed. Just my opinion, of course . . . -tom 8-Feb-1991 19:04:29-GMT,1619;000000000001 Return-Path: <@MATH.AMS.COM:beebe@math.utah.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA11456; Fri, 8 Feb 91 12:04:18 MST Received: from math.utah.edu by MATH.AMS.COM via SMTP with TCP; Fri, 8 Feb 91 13:59:31-EDT Received: from magna.math.utah.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA11186; Fri, 8 Feb 91 11:54:01 MST Date: Fri, 8 Feb 91 11:54:01 MST From: Nelson H.F. Beebe To: mackay@cs.washington.edu (Pierre MacKay) Cc: ken@csis.dit.csiro.au, tex-implementors@math.ams.com X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: Re: paper sizes in LaTeX In-Reply-To: Your message of Thu, 7 Feb 91 16:31:47 -0800 Message-Id: Our latex directory has a4.sty and a4wide.sty, and I can mail them to anyone who needs them. It is clear that the designer of TeX, and designers of macro packages and DVI drivers, all made the mistake of not designing for a range of paper sizes, with both built-in standard sizes, and user-definable sizes. I've remedied that in my 3.0 DVI driver development, but only for the DVI end of things. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== 13-Mar-1991 17:42:17-GMT,1129;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA11045; Wed, 13 Mar 91 10:42:03 MST Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 13 Mar 91 12:36:50-EDT Received: by smiley.Stanford.EDU (4.1/inc-1.0) id AA01423; Wed, 13 Mar 91 09:31:43 PST Date: Wed, 13 Mar 91 09:31:43 PST From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9103131731.AA01423@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: TeX fixes from Knuth up on labrea Hi, Knuth gave me a new set of patches for the TeX and Metafont sources on labrea. I've applied them in the same way that I applied the last set of patches that I received: At the top level the directory OLD.pre-Mar91 contains the original files as they were before the patches (the directory structure is maintained there as well). The file DIFFS.Mar91 is the file containing the context diffs that Knuth gave me. The new files are in their normal place with new motification times. Please let me know if you encounter any problems. Thanks, Dan 16-Mar-1991 16:10:04-GMT,1115;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:UCIR001@FRORS12.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02610; Sat, 16 Mar 91 09:10:01 MST Message-Id: <9103161610.AA02610@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Sat, 16 Mar 91 11:05:56-EDT Received: from FRORS12.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8180; Sat, 16 Mar 91 10:58:17 EST Received: from FRORS12.BITNET (UCIR001) by FRORS12.BITNET (Mailer R2.07) with BSMTP id 3773; Sat, 16 Mar 91 17:00:58 EDT Date: Sat, 16 Mar 91 16:51:35 EDT From: Gaulle Bernard Subject: MLTeX To: LSV IMPLEM If TeX3 plus VF plus DCfonts is THE solution for implemntors, it's certainly no t a production tool today. First DCfonts are in beta test. Secondly few drivers are ready to use VF and 256 chars fonts. So, every day we use MLTeX 2/3 in production and it's a very good solution for e.g. french hyphenation and typographic requirements. Bernard GAULLE 18-Mar-1991 21:47:31-GMT,816;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13793; Mon, 18 Mar 91 14:47:26 MST Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 18 Mar 91 16:33:50-EDT Received: by smiley.Stanford.EDU (4.1/inc-1.0) id AA00468; Mon, 18 Mar 91 13:28:33 PST Date: Mon, 18 Mar 91 13:28:33 PST From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9103182128.AA00468@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: new tex.web on labrea Knuth gave me a slightly updated version of tex.web that supercedes the one put up last week. It is now on labrea. Since there are only a few 'cosmetic' differences from that previous version, at his suggestion, I won't put a diffs file up there. Dan 15-Mar-1991 16:37:48-GMT,1532;000000000001 Return-Path: <@MATH.AMS.COM,@BULLDOG.CS.YALE.EDU:lrw!leichter@LRW.COM> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25990; Fri, 15 Mar 91 09:37:43 MST Received: from BULLDOG.CS.YALE.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 15 Mar 91 11:32:51-EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Fri, 15 Mar 91 11:20:45 EST Message-Id: <9103151620.AA24175@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Fri, 15 Mar 91 10:25:43 EDT Date: Fri, 15 Mar 91 10:25:43 EDT From: Jerry Leichter To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: RE: fontname mapping file for TeX Good going! Obviously, as I wrote about this before, I think it's a good idea. I have may doubts about wild-carding, but it does have one saving grace: If you don't use wild-card characters, it doesn't hurt you. (This assumes that if there are no *'s in the spec you hand to \font, you get ONLY the exact match - not an implicit trailing *, or something like that.) Even with that, I'd find real text wildcarding a bad idea. It's one thing to say "give me Times Roman 10pt normal weight character set TeX-standard from any foundary", quite another to say "give me any font whose name happens to contain the characters TMR10NTS anywhere within it". Perhaps the X font-naming conventions are good enough to support this - I don't know enough about them. Without some control over how the matching is done, pure text wildcarding is just asking for trouble. -- Jerry 15-Mar-1991 17:57:57-GMT,1103;000000000001 Return-Path: <@MATH.AMS.COM,@serv02:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26497; Fri, 15 Mar 91 10:57:50 MST Received: from serv02 by MATH.AMS.COM via SMTP with TCP; Fri, 15 Mar 91 12:51:34-EDT Received: from quattro.ZIB-Berlin.DE by serv02 (4.0/SMI-4.0-serv02/13.11.90) id AA18745; Fri, 15 Mar 91 18:46:20 +0100 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA16043; Fri, 15 Mar 91 18:46:15 +0100 Date: Fri, 15 Mar 91 18:46:15 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9103151746.AA16043@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: tex-implementors@math.ams.com In-Reply-To: Tomas G. Rokicki's message of Fri, 15 Mar 91 09:22:58 -0800 <9103151722.AA00775@Neon.Stanford.EDU> Subject: \charsubdef Could someone please explain to me why the MLTeX \charsubdef modifications are still necessary? I have the understanding that with TeX 3.x, virtual fonts and the new 256 character fonts we have all the tools we need? Rainer Sch\"opf 19-Mar-1991 19:05:41-GMT,26115;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA20758; Tue, 19 Mar 91 12:05:29 MST Date: Tue 19 Mar 91 13:49:40-EST From: bbeeton Subject: Updates to TeX.WEB, MF.WEB, GFtoDVI, et al. To: TeX-implementors@VAX01.AMS.COM Message-Id: <669408580.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 19 Mar 90 Message No: 028 To: TeX implementors and distributors From: Barbara Beeton Subject: Updates to TeX.WEB, MF.WEB, GFtoDVI, et al. New versions of TeX.WEB, MF.WEB and other updates have been installed at labrea, as Dan Kolkowitz has reported. For the benefit of those who may not be able to ftp these files easily, this message contains some of the more important details: New files at labrea since 3 January 91 Changes to the errata list (ERRATA.SIX) Addenda to TeX82.BUG as of 13 March 91 Addenda to MF84.BUG as of 13 March 91 Differences between TeX.WEB 3.1 and 3.14 (as of 18 March 1991) Differences between TeX.WEB 3.0 and 3.1 (as of 21 September 1990) Differences between MF.WEB 2.0 and MF.WEB 2.7 (as of 13 March 1991) Cosmetic change, GFTODVI.WEB, ver 3.0 Differences in TeX.WEB are provided in two parts since the details of the update from version 3.0 to 3.1 was never reported in one of these messages. In fact, both TeX.WEB and MF.WEB have been updated twice, with only one version change, since the previous update. The most recent changes were, as Don Knuth says in the prose at the top, only cosmetic; cosmetic changes do not usually appear in the bug listings, but should generally be made to the main WEB files anyhow in order to keep in synch. This is the last time that it will be possible to provide the difference listings in this form. These difference listings were prepared with a TOPS-20 utility, and the Math Society's DEC-20 is being unplugged and de-installed tomorrow. We now have a couple of Unix workstations, and the Unix differencing utility seems to be the best replacement (as soon as I learn how to use it). Although the VAX/VMS DIFF utility does a good job of identifying differences, it adds a line number to each difference line, often resulting in lines of more than 80 characters in length; not a robust format for sending in e-mail across random network gateways. As usual, there have been a number of updates to this mailing list since the last time I sent a message directly, so if everyone receiving this message could please acknowledge it, that will help keep the list in good shape. ######################################################################## New files at labrea.stanford.edu since 3 Jan 91 /tex: -rw-r--r-- 1 468 fsuser 52165 Mar 13 17:03 DIFFS.Mar91 -rw-r--r-- 1 468 fsuser 0 Mar 13 17:24 tex.log /tex/OLD.pre-Mar91: total 7 drwxr-xr-x 2 468 fsuser 512 Mar 13 17:14 cweb drwxr-xr-x 2 468 fsuser 512 Mar 13 17:19 errata drwxr-xr-x 6 468 fsuser 512 Mar 13 17:14 local drwxr-xr-x 2 468 fsuser 512 Mar 13 17:18 mf drwxr-xr-x 2 468 fsuser 512 Mar 13 17:16 mfware drwxr-xr-x 2 468 fsuser 512 Mar 13 17:18 tex drwxr-xr-x 2 468 fsuser 512 Mar 13 17:14 tugboat /tex/bibtex: -rw-rw-r-- 1 weening ftp 27577 Mar 15 15:45 btxmac.tex /tex/errata: -rw-rw-rw- 1 468 fsuser 15838 Mar 15 21:40 errata.six -rw-r--r-- 1 468 fsuser 2528 Mar 13 17:05 errata.tex -rw-r--r-- 1 468 fsuser 79228 Mar 13 17:05 mf84.bug -rw-r--r-- 1 468 fsuser 295236 Mar 13 17:05 tex82.bug /tex/latex: -rw-rw-r-- 1 root ftp 15834 Jan 14 18:58 addendum.tex -r--r--r-- 1 root fsuser 40243 Feb 8 21:02 latex.bug -r--r--r-- 1 root fsuser 286412 Feb 8 21:02 latex.tex -r--r--r-- 1 root fsuser 48458 Feb 8 21:02 lplain.tex -r--r--r-- 1 root fsuser 48804 Feb 8 21:03 splain.tex /tex/local/cm: -rw-rw-rw- 1 468 fsuser 3561 Mar 15 21:44 ccmic9.mf -rw-rw-rw- 1 468 fsuser 217 Mar 15 21:44 odigs.mf /tex/local/lib: -rw-r--r-- 1 468 fsuser 3133 Mar 13 17:08 art.mf -rw-rw-r-- 1 468 fsuser 33699 Mar 13 17:09 gkpmac.tex -rw-r--r-- 1 468 fsuser 1581 Mar 13 17:09 list.tex -rw-r--r-- 1 468 fsuser 2179 Mar 13 17:09 llist.tex -rw-r--r-- 1 468 fsuser 263 Mar 13 17:09 oneone.mf -rw-r--r-- 1 468 fsuser 8240 Mar 13 17:09 picmac.tex /tex/local/mf: -rw-r--r-- 1 468 fsuser 691 Mar 13 17:09 plain.log /tex/local:/tex/local/mfware: -rw-r--r-- 1 468 fsuser 28547 Mar 13 17:10 gftodvi.ch /tex/local/tex: -rw-r--r-- 1 468 fsuser 53657 Mar 13 17:10 initex.ch /tex/mf: -rw-r--r-- 1 468 fsuser 916840 Mar 13 17:06 mf.web -rw-r--r-- 1 468 fsuser 938679 Mar 13 17:06 mfbook.tex -rw-r--r-- 1 468 fsuser 18238 Mar 5 23:56 trapman.tex /tex/mfware: -rw-r--r-- 1 468 fsuser 186545 Mar 13 17:06 gftodvi.web /tex/tex: -rw-r--r-- 1 468 fsuser 1025435 Mar 18 21:20 tex.web -rw-r--r-- 1 468 fsuser 1381907 Mar 13 17:07 texbook.tex -rw-r--r-- 1 468 fsuser 2438 Mar 13 17:07 trip.fot -rw-r--r-- 1 468 fsuser 182701 Mar 13 17:07 trip.log -rw-r--r-- 1 468 fsuser 18025 Mar 13 17:07 trip.typ -rw-r--r-- 1 468 fsuser 12930 Mar 13 17:08 tripin.log /tex/tugboat: -rw-r--r-- 1 468 fsuser 30903 Mar 11 19:44 guidepro.tex -rw-r--r-- 1 468 fsuser 14810 Mar 11 19:44 ltugboat.sty -rw-r--r-- 1 468 fsuser 3785 Mar 11 19:44 ltugproc.sty -rw-r--r-- 1 468 fsuser 25567 Mar 11 19:44 tugboat.com -rw-r--r-- 1 468 fsuser 66791 Mar 11 19:44 tugboat.sty -rw-r--r-- 1 468 fsuser 8901 Mar 11 19:44 tugproc.sty ######################################################################## Addenda to TeX82.BUG as of 13 March 91 ------------- Note: When making change 376, I forgot to delete the redundant code in module 883, and I should also have changed the name of that module. These cosmetic changes (and some changes to the comments) were made in version 3.14; but TeX 3.14 is functionally equivalent to TeX 3.1 and only a tiny bit faster. ------------- 393. The absolutely final change (to be made after my death) @x module 2 @d banner=='This is TeX, Version 3.14' {printed when \TeX\ starts} @y @d banner=='This is TeX, Version $\pi$' {printed when \TeX\ starts} @z My last will and testament for TeX is that no further changes be made under any circumstances. Improved systems should not be called simply `TeX'; that name, unqualified, should refer only to the program for which I have taken personal responsibility. -- Don Knuth ######################################################################## Addenda to MF84.BUG as of 13 March 91 ------------- 557. The absolutely final change (to be made after my death) @x module 2 @d banner=='This is METAFONT, Version 2.7' {printed when \MF\ starts} @y @d banner=='This is METAFONT, Version $e$' {printed when \MF\ starts} @z My last will and testament for METAFONT is that no further changes be made under any circumstances. Improved systems should not be called simply `METAFONT'; that name, unqualified, should refer only to the program for which I have taken personal responsibility. -- Don Knuth ######################################################################## Changes to the errata list (ERRATA.SIX) [ This is NOT a difference list. ] \def\rhead{Bugs in {\tensl Computers \& Typesetting, 1990}} ... \noindent This is a list of all corrections made to {\sl Computers \& Typesetting}, Volumes A,~C, and E\null, between 30 September 1989 (when the revisions for \TeX\ Version 3.0 and \MF\ Version 2.0 were made) and December 31, 1990. ... \bugonpage A137, lines 2 and 3 from the bottom (11/9/90) {\eightssi \rightline{and you shouldn't even be reading this manual,} \rightline{which is undoubtedly all English to you.} } \bugonpage A141, line 15 from the bottom (10/18/90) \tenpoint\noindent Thus if you type `|$1\over2$|' (in a text) you get $1\over2$, namely style $S$ over style~$S'$;\cutpar ... \bugonpage C11, replacement for second quotation at bottom of page (9/27/90) \begingroup \eightpoint \let\tt=\ninett \baselineskip 10pt \parfillskip \z@ \interlinepenalty 10000 \leftskip \z@ plus 40pc minus \parindent \let\rm=\eightss \let\sl=\eightssi \everypar{\sl} \def\par{\ifhmode\/\endgraf\fi}\obeylines To anyone who has lived in a modern American city (except Boston) at least one of the underlying ideas of ^{Descartes}' analytic geometry will seem ridiculously evident. Yet, as remarked, it took mathematicians all of two thousand years to arrive at this simple thing. \author ERIC TEMPLE ^{BELL}, {\sl Mathematics: Queen and Servant of % Science\/} (1951) % p123 \endgroup \bugonpage C262, lines 19--21 (11/9/90) \ninepoint\noindent for commonly occurring idioms. For example, `{\bf stop} |"hello"|' displays `|hello|' on the terminal and waits until \ is typed. \beginlines |def |^|upto|| = step 1 until enddef; def |^|downto|| = step -1 until enddef;| \endgroup ... \bugonpage C329, line 325 (12/29/90) \ninepoint\noindent which can be used to specify a nonstandard file area or directory name for the gray\cutpar ... \bugonpage C347, left column (9/27/90) \eightpoint\noindent Bell, Eric Temple, 11. \bugonpage C349, left column (9/27/90) \eightpoint\noindent Descartes, Ren\'e, 6, 11, 19. \bugonpage C356, right column (9/27/90) \eightpoint\noindent [remove the entry for Rex Stout.] \bugonpage C358, right column (9/27/90) \eightpoint\noindent [remove the entry for Nero Wolfe.] ######################################################################## Differences between TeX.WEB 3.1 and 3.14 (as of 18 March 1991) ;COMPARISON OF TX:TEX-31.WEB.1 AND TX:TEX-314.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TEX-31.WEB.1, 1-43 (2896) % A reward of $327.68 will be paid to the first finder of any remaining bug, **** FILE TX:TEX-314.WEB.1, 1-42 (2894) % Version 3.14 was a cosmetic change for new Volume B (February 1991). % A reward of $327.68 will be paid to the first finder of any remaining bug, *************** **** FILE TX:TEX-31.WEB.1, 1-183 (10169) @d banner=='This is TeX, Version 3.1' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present **** FILE TX:TEX-314.WEB.1, 1-184 (10241) @d banner=='This is TeX, Version 3.14' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present *************** **** FILE TX:TEX-31.WEB.1, 1-1008 (48300) (If the \PASCAL\ compiler does not support non-local |@!goto|, the @^system dependencies@> **** FILE TX:TEX-314.WEB.1, 1-1009 (48373) (If the \PASCAL\ compiler does not support non-local |@!goto|\unskip, the @^system dependencies@> *************** **** FILE TX:TEX-31.WEB.1, 1-4856 (215250) {that's |text(font_id_base+equiv(n))|} end **** FILE TX:TEX-314.WEB.1, 1-4857 (215330) {that's |font_id_text(equiv(n))|} end *************** **** FILE TX:TEX-31.WEB.1, 1-8209 (361639) if (cur_cs=0)and@| **** FILE TX:TEX-314.WEB.1, 1-8210 (361714) @^recursion@> if (cur_cs=0)and@| *************** **** FILE TX:TEX-31.WEB.1, 1-9674 (418737) @p procedure conditional; **** FILE TX:TEX-314.WEB.1, 1-9675 (418825) @^recursion@> @p procedure conditional; *************** **** FILE TX:TEX-31.WEB.1, 1-14080 (611160) The box returned by |clean_box| is ``clean'' in the **** FILE TX:TEX-314.WEB.1, 1-14082 (611263) @^recursion@> The box returned by |clean_box| is ``clean'' in the *************** **** FILE TX:TEX-31.WEB.1, 1-14175 (615068) The second pass eliminates all noads and inserts the correct glue and **** FILE TX:TEX-314.WEB.1, 1-14178 (615186) @^recursion@> The second pass eliminates all noads and inserts the correct glue and *************** **** FILE TX:TEX-31.WEB.1, 1-14760 (639342) cur_style:=save_style; @; **** FILE TX:TEX-314.WEB.1, 1-14765 (639477) @^recursion@> cur_style:=save_style; @; *************** **** FILE TX:TEX-31.WEB.1, 1-15438 (669367) but we clear |aux| to zero just to be tidy. @p @t\4@>@@t@>@/ **** FILE TX:TEX-314.WEB.1, 1-15444 (669517) but we clear them to zero just to be tidy. @p @t\4@>@@t@>@/ *************** **** FILE TX:TEX-31.WEB.1, 1-17263 (749496) @; if post_break(q)<>null then @; **** FILE TX:TEX-314.WEB.1, 1-17269 (749645) @; if post_break(q)<>null then @; *************** **** FILE TX:TEX-31.WEB.1, 1-17277 (749957) if not is_char_node(s) then if next_break(cur_p)<>null then if cur_break(next_break(cur_p))=s then s:=r; r:=link(s); link(s):=null; **** FILE TX:TEX-314.WEB.1, 1-17283 (750062) r:=link(s); link(s):=null; *************** **** FILE TX:TEX-31.WEB.1, 1-17624 (764945) hyphen can be considerably more complex than that. For example, suppose that \.{abcdef} is a word in a font for which the only ligatures are \.{b\!c}, \.{c\!d}, \.{d\!e}, and \.{e\!f}. If this word is to permit hyphenation between \.b and \.c, the two patterns with and without hyphenation are **** FILE TX:TEX-314.WEB.1, 1-17628 (764937) hyphen can be considerably more complex than that. Suppose \.{abcdef} is a word in a font for which the only ligatures are \.{b\!c}, \.{c\!d}, \.{d\!e}, and \.{e\!f}. If this word permits hyphenation between \.b and \.c, the two patterns with and without hyphenation are *************** **** FILE TX:TEX-31.WEB.1, 1-19977 (866921) hyphenation. Again we have an implied ``cursor`` between characters |cur_l| and |cur_r|. The main difference is that the |lig_stack| can now **** FILE TX:TEX-314.WEB.1, 1-19981 (866890) hyphenation. Again we have an implied ``cursor'' between characters |cur_l| and |cur_r|. The main difference is that the |lig_stack| can now *************** **** FILE TX:TEX-31.WEB.1, 1-21590 (929845) begin get_token; {|get_x_token| would fail on \.{\\ifmmode}!} if (cur_cmd=math_shift)and(mode>0) then @ **** FILE TX:TEX-314.WEB.1, 1-21594 (929814) begin get_token; {|get_x_token| would fail on \.{\\ifmmode}\thinspace!} if (cur_cmd=math_shift)and(mode>0) then @ *************** **** FILE TX:TEX-31.WEB.1, 1-22413 (960656) by making its width zero. @= **** FILE TX:TEX-314.WEB.1, 1-22417 (960635) by causing its width to be zero. @= *************** **** FILE TX:TEX-31.WEB.1, 1-23152 (987557) |info(par_shape_ptr)| can hold any positive~|n| such |get_node(2*n+1)| doesn't overflow the memory capacity. **** FILE TX:TEX-314.WEB.1, 1-23156 (987543) |info(par_shape_ptr)| can hold any positive~|n| for which |get_node(2*n+1)| doesn't overflow the memory capacity. *************** **** FILE TX:TEX-31.WEB.1, 1-23239 (990682) if scan_keyword("at") then @ @.at@> **** FILE TX:TEX-314.WEB.1, 1-23243 (990673) if scan_keyword("at") then @ @.at@> *************** **** FILE TX:TEX-31.WEB.1, 1-23254 (991149) @ @= begin scan_normal_dimen; s:=cur_val; **** FILE TX:TEX-314.WEB.1, 1-23258 (991144) @ @= begin scan_normal_dimen; s:=cur_val; *************** **** FILE TX:TEX-31.WEB.1, 1-23484 (998722) @= **** FILE TX:TEX-314.WEB.1, 1-23487 (998719) @^data structure assumptions@> @= *************** **** FILE TX:TEX-31.WEB.1, 1-24036 (1017828) init for k:=0 to 255 do trie_used[k]:=min_quarterword;@+tini k:=256; while j>0 do begin undump(0)(k-1)(k); undump(1)(j)(x);@+init trie_used[k]:=qi(x);@+tini j:=j-x; op_start[k]:=qo(j); **** FILE TX:TEX-314.WEB.1, 1-24041 (1017859) init for k:=0 to 255 do trie_used[k]:=min_quarterword;@+tini@;@/ k:=256; while j>0 do begin undump(0)(k-1)(k); undump(1)(j)(x);@+init trie_used[k]:=qi(x);@+tini@;@/ j:=j-x; op_start[k]:=qo(j); *************** **** FILE TX:TEX-31.WEB.1, 1-24175 (1023526) This program doesn't bother to close the input files that may still be open. **** FILE TX:TEX-314.WEB.1, 1-24179 (1023563) @^recursion@> This program doesn't bother to close the input files that may still be open. *************** ######################################################################## Differences between TeX.WEB 3.0 and 3.1 (as of 21 September 1990) ;COMPARISON OF TX:TEX-30.WEB.1 AND TX:TEX-31.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:TEX-30.WEB.1, 1-42 (2816) % A reward of $327.68 will be paid to the first finder of any remaining bug, **** FILE TX:TEX-31.WEB.1, 1-41 (2814) % Version 3.1 fixed nullfont, disabled \write{\the\prevgraf} (September 1990). % A reward of $327.68 will be paid to the first finder of any remaining bug, *************** **** FILE TX:TEX-30.WEB.1, 1-68 (4055) \def\drop{\kern-.1667em\lower.5ex\hbox{E}\kern-.125em} % middle of TeX \catcode`E=13 \uppercase{\def E{e}} \def\\#1{\hbox{\let E=\drop\it#1\/\kern.05em}} % italic type for identifiers \outer\def\N#1. \[#2]#3.{\MN#1.\vfil\eject % begin starred section **** FILE TX:TEX-31.WEB.1, 1-69 (4135) \outer\def\N#1. \[#2]#3.{\MN#1.\vfil\eject % begin starred section *************** **** FILE TX:TEX-30.WEB.1, 1-186 (10278) @d banner=='This is TeX, Version 3.0' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present **** FILE TX:TEX-31.WEB.1, 1-183 (10169) @d banner=='This is TeX, Version 3.1' {printed when \TeX\ starts} @ Different \PASCAL s have slightly different conventions, and the present *************** **** FILE TX:TEX-30.WEB.1, 1-8472 (372855) begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @ @= **** FILE TX:TEX-31.WEB.1, 1-8469 (372746) if mode=0 then scanned_result(0)(int_val) {|prev_graf=0| within \.{\\write}} else begin nest[nest_ptr]:=cur_list; p:=nest_ptr; while abs(nest[p].mode_field)<>vmode do decr(p); scanned_result(nest[p].pg_field)(int_val); end @ @= *************** **** FILE TX:TEX-30.WEB.1, 1-10358 (446031) begin if input_ln(cur_file,false) then do_nothing; firm_up_the_line; **** FILE TX:TEX-31.WEB.1, 1-10356 (446011) begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; *************** **** FILE TX:TEX-30.WEB.1, 1-10362 (446183) first:=limit+1; loc:=start; line:=1; end **** FILE TX:TEX-31.WEB.1, 1-10361 (446173) first:=limit+1; loc:=start; end *************** **** FILE TX:TEX-30.WEB.1, 1-10737 (464779) font_bc[null_font]:=1; font_ec[null_font]:=0; **** FILE TX:TEX-31.WEB.1, 1-10736 (464760) bchar_label[null_font]:=non_address; font_bchar[null_font]:=non_char; font_false_bchar[null_font]:=non_char; font_bc[null_font]:=1; font_ec[null_font]:=0; *************** **** FILE TX:TEX-30.WEB.1, 1-11673 (506824) if at all. Like |nop| commands and \\{xxx} commands, font definitions can appear before the first |bop|, or between an |eop| and a |bop|. **** FILE TX:TEX-31.WEB.1, 1-11674 (506916) if at all. Like |nop| commands, font definitions can appear before the first |bop|, or between an |eop| and a |bop|. *************** **** FILE TX:TEX-30.WEB.1, 1-18295 (794479) is |trie_op_ptr|. If the table overflows, the excess ops are ignored. Statistics printed during a dump make it possible for users to tell if this has happened. @= **** FILE TX:TEX-31.WEB.1, 1-18296 (794550) is |trie_op_ptr|. @= *************** **** FILE TX:TEX-30.WEB.1, 1-24730 (1045367) {disable \.{\\prevdepth}, \.{\\spacefactor}, \.{\\lastskip}} cur_cs:=write_loc; q:=scan_toks(false,true); {expand macros, etc.} **** FILE TX:TEX-31.WEB.1, 1-24729 (1045294) {disable \.{\\prevdepth}, \.{\\spacefactor}, \.{\\lastskip}, \.{\\prevgraf}} cur_cs:=write_loc; q:=scan_toks(false,true); {expand macros, etc.} *************** ######################################################################## Differences between MF.WEB 2.0 and MF.WEB 2.7 (as of 13 March 1991) ;COMPARISON OF TX:MF-20.WEB.1 AND TX:MF-27.WEB.1 ;OPTIONS ARE /E /3 **** FILE TX:MF-20.WEB.1, 1-22 (1390) % A few "harmless" optimizations have been made without changing versions. % A reward of $81.92 will be paid to the first finder of any remaining bug, % except bugs introduced after August 1989. **** FILE TX:MF-27.WEB.1, 1-22 (1390) % Version 2.7 made consistent with TeX version 3.1 (September 1990). % A few "harmless" optimizations have been made without changing versions. % A reward of $163.84 will be paid to the first finder of any remaining bug, % except bugs introduced after August 1989. *************** **** FILE TX:MF-20.WEB.1, 1-153 (8073) @d banner=='This is METAFONT, Version 2.0' {printed when \MF\ starts} @ Different \PASCAL s have slightly different conventions, and the present **** FILE TX:MF-27.WEB.1, 1-154 (8144) @d banner=='This is METAFONT, Version 2.7' {printed when \MF\ starts} @ Different \PASCAL s have slightly different conventions, and the present *************** **** FILE TX:MF-20.WEB.1, 1-2995 (123730) fractions. Using the recurrence $x_n=(x_{n-55}-x_{n-31})\bmod 2^{28}$, we generate batches of 55 new $x_n$'s at a time by calling |new_randoms|. **** FILE TX:MF-27.WEB.1, 1-2996 (123801) fractions. Using the recurrence $x_n=(x_{n-55}-x_{n-24})\bmod 2^{28}$, we generate batches of 55 new $x_n$'s at a time by calling |new_randoms|. *************** **** FILE TX:MF-20.WEB.1, 1-3005 (124184) and then it will fetch |randoms[j_random]|. @d next_random==if j_random=0 then new_randoms **** FILE TX:MF-27.WEB.1, 1-3006 (124255) and then it will fetch |randoms[j_random]|. The |next_random| macro actually accesses the numbers backwards; blocks of 55~$x$'s are essentially being ``flipped.'' But that doesn't make them less random. @d next_random==if j_random=0 then new_randoms *************** **** FILE TX:MF-20.WEB.1, 1-11094 (468472) numerators and denominators is to generalize the Stern-Peirce tree [cf.~{\sl The Art of Computer Programming\/ \bf2}, exercise 4.5.3--40] @^Peirce, Charles Santiago Sanders@> @^Stern, Moriz Abraham@> to a ``Stern-Peirce wreath'' as follows: Begin with four nodes arranged in a circle, containing the respective directions **** FILE TX:MF-27.WEB.1, 1-11097 (468704) numerators and denominators is to generalize the Stern-Brocot tree [cf.~{\sl Concrete Mathematics}, section 4.5] @^Brocot, Achille@> @^Stern, Moriz Abraham@> to a ``Stern-Brocot wreath'' as follows: Begin with four nodes arranged in a circle, containing the respective directions *************** **** FILE TX:MF-20.WEB.1, 1-15894 (663124) pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; end_file_reading; {remove the level that didn't work} **** FILE TX:MF-27.WEB.1, 1-15897 (663314) if cur_area="" then begin pack_file_name(cur_name,MF_area,cur_ext); if a_open_in(cur_file) then goto done; end; end_file_reading; {remove the level that didn't work} *************** **** FILE TX:MF-20.WEB.1, 1-15919 (664150) begin if not input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; line:=1; end **** FILE TX:MF-27.WEB.1, 1-15924 (664383) begin line:=1; if input_ln(cur_file,false) then do_nothing; firm_up_the_line; buffer[limit]:="%"; first:=limit+1; loc:=start; end *************** ######################################################################## Cosmetic change, GFTODVI.WEB, ver 3.0 ;COMPARISON OF TX:GFTODVI.WEB AND TX:GFTODVI.WEB.1 ;OPTIONS ARE /3 **** FILE TX:GFTODVI.WEB, 1-2553 (117187) if a |"/"| was removed at the end of the file name; this user that the user will have a chance to issue special instructions online just before **** FILE TX:GFTODVI.WEB, 1-2553 (117187) if a |"/"| was removed at the end of the file name; this means that the user will have a chance to issue special instructions online just before *************** ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 028 ] ------- 25-Mar-1991 0:33:06-GMT,2273;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AB25580; Sun, 24 Mar 91 17:33:00 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Sun, 24 Mar 91 19:27:00-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA24720; Sun, 24 Mar 91 16:21:56 -0800 Date: Sun, 24 Mar 91 16:21:56 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103250021.AA24720@june.cs.washington.edu> To: rokicki@Neon.Stanford.EDU Cc: karl@cs.umb.edu, tex-fonts@math.utah.edu, tex-implementors@math.ams.com In-Reply-To: Tomas G. Rokicki's message of Fri, 15 Mar 91 09:22:58 -0800 <9103151722.AA00775@Neon.Stanford.EDU> Subject: fontname mapping file for TeX The reason against \charsubdef being a part of TeX (TM) is that however convenient it may be it violates DEK's basic insistence that for any given input there is only one dvi output. Depending on the environment, you will get various dvi outputs from a "TeX" with \charsubdef included, and the differences are subtle and interwoven into the file. I don't see that font name mapping does that. It may be that we have to decide which name goes into the postamble and the font-def commands---in the case of CM, it is obviously going to be the usual cmr10 style name--- but we can remember the time when SAIL used 6-char names while VMS and Unix were already opening them out to longer names. That certainly involved inconsistencies in both the postamble and font-defs, but you could get around it with links, etc., and in that case as in this, DEK did not feel that the inconsistencies invalidated VMS and Unix TeXs. So long as we always end up with a font which has the expected checksum in the tfm, and which maps the characters into the same positions on all systems, the question of its external file name is not so critical. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 28-Mar-1991 22:23:47-GMT,1040;000000000001 Return-Path: <@MATH.AMS.COM:kolk@smiley.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02434; Thu, 28 Mar 91 15:23:40 MST Received: from smiley.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 28 Mar 91 17:12:45-EDT Received: by smiley.Stanford.EDU (4.1/inc-1.0) id AA03135; Thu, 28 Mar 91 14:07:29 PST Date: Thu, 28 Mar 91 14:07:29 PST From: kolk@smiley.Stanford.EDU (Dan Kolkowitz) Message-Id: <9103282207.AA03135@smiley.Stanford.EDU> To: tex-implementors@math.ams.com Subject: another installation Hi, Don Knuth sheepishly gave me a newer version of the same release that first appeared in early March (this is now the third one). This is now up on labrea. The diffs file, DIFFS.Mar91, contains the differences between this version and the Sept. 90 version that was on labrea. The two previous March releases should be disgarded. There is at least one important bug fix that appears in this most recent release. He assures me that this is the last 3.14 release. Dan 8-Apr-1991 23:13:25-GMT,17645;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA17535; Mon, 8 Apr 91 17:13:18 MDT Date: Mon 8 Apr 91 19:00:52-EST From: bbeeton Subject: Additional changes, TeX 3.14, MF 2.7; ERRATA.TeX; security report] To: TeX-implementors@MATH.AMS.COM Message-Id: <671155252.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 8 April 90 Message No: 029 To: TeX implementors and distributors From: Barbara Beeton Subject: Additional changes, TeX 3.14, MF 2.7; ERRATA.TeX; security report This message contains only the most urgent changes. I am extremely short on time, and will be out of town from Apr 11-20 at a standards meeting in Kyoto. (I will probably be quite incoherent when I return; 14-hour time shifts and I don't get along too well.) Included here are the following Addenda to TeX82.BUG as of 26 March 91 New errata list (ERRATA.TEX) -- full list Differences between TeX.WEB 3.14 as of 18 March 1991 and as of 26 Mar 1991 Differences between MF.WEB 2.7 as of 13 March 1991 and as of 26 Mar 1991 The differences lists were run under VAX/VMS and hand-edited to provide the starting line number for each code block. This is the closest I can come to the former TOPS-20 differences lists. I was very careful to check the hand work, and didn't catch any errors. However, you should be aware that this was not entirely machine generated. I received on paper today a package of commented bug reports from Knuth. I have added the comments to the original file, and will send that as message #30. I am doing this to save time. Several people will get rewards from their reports; I will be in touch with them indivudually. Although this package arrived only today, I believe that all the bugs that Knuth accepted were fixed in the versions of March 26 referred to below. I have had another report, one that I really don't like to advertise. I have passed it along to Knuth, and also checked it out with another expert. This report dealt with a "security flaw", specifically in Unix implementations, but possibly able to be activated within other operating system environments as well. Here is the introduction to the report: Date: Tue, 26 Mar 91 12:52:33 -0500 From: Zbigniew Fiedorowicz To: tug@math.ams.com Cc: tech-support@math.ams.com Subject: TeX security problem Please pass this on to Prof. Knuth, or whoever maintains the official TeX source code: I am writing to inform you about a security flaw affecting Unix implementations of TeX (perhaps other operating systems as well). The problem is that one can easily imbed TeX commands in ordinary TeX files to write arbitrary text into a user's system files, such as .login, .cshrc, .profile, .logout, etc. When a file with such commands is typeset, they may execute silently without the user being any the wiser. This provides a mechanism for anything from harmless pranks to serious vandalism. To illustrate the problem, I enclose below a "TeX virus". To prevent this sort of thing, TeX should check commands of the form \openoutn=filename is not something like .login, ../.logout, etc. It would seem reasonable to impose the condition that the only filenames acceptable to TeX must end in the form x.xxx...x where x denotes an alphanumeric character. Zbigniew Fiedorowicz The report was accompanied by a "demo virus", both a summary of the strategy and the code. In order to contain this as well as possible, I will not send out the code or strategy without a specific request, and then, only to people whose credentials I am sure of. I asked the moderator of the VIRUS-L discussion list to look at the strategy and determine whether it is plausible. He did so, and here is his analysis. Date: Thu, 28 Mar 91 09:56:48 EST From: Kenneth R. van Wyk Ms. Beeton, Thank you for your letter regarding the use of TeX for propagating viruses. While I am only slightly familiar with TeX, I do fully understand the nature of the problem. Without even looking at the example code (though I would be happy to do so), I can imagine ways in which it could be exploited. I see the problem as being more general in scope than just viruses; indeed, a trojan horse login "program" could easily be implemented which could be used to collect usernames and passwords. This is along the lines of pranks that have been seen in (among other places, no doubt) university computing environments for years. On the other hand, I would imagine that the people who designed and implemented this feature had legitimate reasons for doing so. The report that you sent to me mentioned one alternative, which was to only allow certain classes of filenames. One other alternative which you may wish to consider is to notify the user whenever a file is to be written to in this manner and allow the user to deny access to the file. A message to the extent of "File xxx.tex is attempting to write to file .login. This could have serious security related repurcussions. Do you wish to proceed? " In summary, yes I believe that the threat is real. It could certainly and easily be used to cause damage. The damage could be in the form of a virus, but would not be limited to viruses. It could just as easily be used in an attempt to obtain another user's password or just about anything else. The problem is not insurmountable. The file output facility could be removed (in the extreme case) or an alternative approach could be used. I personally like the idea of informing the user and allowing him/her to deny the access before it happens. The decision is yours to make. Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.SEI.CMU.EDU (work) ken@OLDALE.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) In reply to the copy of the full report that I sent to Knuth, he sent back to me a sheet of Unix diffs to be forwarded to Pierre MacKay (as TUG Unix site coordinator), which I am about to do, along with all the supporting correspondence. I will ask Pierre to notify the list when he has received it, and, if he will, to answer questions on the subject. That will allow me to go away with a clear conscience. ######################################################################## Addenda to TeX82.BUG as of 26 March 91 ------------- Note: When making change 376, I forgot to delete the redundant code in module 883, and I should also have changed the name of that module. These cosmetic changes (and some changes to the comments) were made in version 3.14, in addition to the following two changes. ------------- 393. Show unprintable characters in font id's (Wayne Sullivan, Dec 1990) @x module 63 print(s); @y slow_print(s); @z @x module 262 can now be spruced up else begin print_esc(""); slow_print(text(p)); @y else begin print_esc(text(p)); @z @x and module 263 likewise else begin print_esc(""); slow_print(text(p)); end; @y else print_esc(text(p)); @z 394. Avoid range check if total_pages>65535 (Eberhard Mattes, Dec 1990) @x module 642 dvi_out(total_pages div 256); dvi_out(total_pages mod 256);@/ @y dvi_out((total_pages div 256) mod 256); dvi_out(total_pages mod 256);@/ @z ----------- 395. The absolutely final change (to be made after my death) @x module 2 @d banner=='This is TeX, Version 3.14' {printed when \TeX\ starts} @y @d banner=='This is TeX, Version $\pi$' {printed when \TeX\ starts} @z My last will and testament for TeX is that no further changes be made under any circumstances. Improved systems should not be called simply `TeX'; that name, unqualified, should refer only to the program for which I have taken personal responsibility. -- Don Knuth * Possibly nice ideas that will not be implemented . classes of marks analogous to classes of insertions . \showcontext to show the current location without stopping for error . \show commands to be less like errors . \everyeof to insert tokens before an \input file ends (strange example: \everyeof{\noexpand} will allow things like \xdef\a{\input foo}!) . generalize \leftskip and \rightskip to token lists (problems with displayed math then) . generalize \widowline and \clubline to go further into a paragraph . \lastbox to remove and box a charnode if one is there * Bad ideas that will not be implemented . several people want to be able to remove arbitrary elements of lists, but that must never be done because some of those elements (e.g. kerns for accents) depend on floating point arithmetic . if anybody wants letter spacing desperately they should put it in their own private version (e.g. generalize the hpack routine) and NOT call it TeX. ######################################################################## New errata list (ERRATA.TEX) -- full list % Bugs (sigh) in Computers \& Typesetting --- the most recent errata \input manmac \font\sltt=cmsltt10 \font\niness=cmss9 \font\ninessi=cmssi9 \proofmodefalse \raggedbottom \output{\hsize=29pc \onepageout{\unvbox255\kern-\dimen@ \vfil}} \def\today{\number\day\ \ifcase\month\or Jan\or Feb\or Mar\or Apr\or May\or Jun\or Jul\or Aug\or Sep\or Oct\or Nov\or Dec\fi \ \number\year} \def\cutpar{{\parfillskip=0pt\par}} \def\rhead{Bugs in {\tensl Computers \& Typesetting as of \today}} \def\bugonpage#1(#2) \par{\bigbreak\tenpoint \hrule width\hsize \line{\lower3.5pt\vbox to13pt{}Page #1\hfil(#2)}\hrule width\hsize \nobreak\medskip} \def\buginvol#1(#2) \par{\bigbreak\penalty-1000\tenpoint \hrule width\hsize \line{\lower3.5pt\vbox to13pt{}Volume #1\hfil(#2)}\hrule width\hsize \nobreak\medskip} \def\slMF{{\manual 89:;}\-{\manual <=>:}} % slant the logo \def\0{\raise.7ex\hbox{$\scriptstyle\#$}} \newcount\nn \newdimen\nsize \newdimen\msize \newdimen\ninept \ninept=9pt \newbox\eqbox \setbox\eqbox=\hbox{\kern2pt\eightrm=\kern2pt} \tenpoint \noindent This is a list of all corrections made to {\sl Computers \& Typesetting}, Volumes A,~C, and E\null, since 1 January 1991. Corrections made to the softcover version of {\sl The \TeX book\/} are the same as corrections to Volume~A\null. Corrections to the softcover version of {\sl The \slMF\kern1ptbook\/} are the same as corrections to Volume~C\null. Some of the corrections below have already been made in reprintings of the books. Hundreds of changes, too many to list here, have been made to Volumes B~and~D because of the upgrades to \TeX\ and \MF\null. Readers who need up-to-date information on the \TeX\ and \MF\ programs should refer to the |WEB| source files until new printings of Volumes B~and~D are issued. \looseness=-1 % volume A \bugonpage A377, the bottom 14 lines (3/26/91) \eightpoint\indent ASCII \; the macro also decides whether a space token is explicit or implicit. \begintt \newif\ifspace \newif\iffunny \newif\ifexplicit \def\stest#1{\expandafter\s\the#1! \stest} \def\s{\funnyfalse \global\explicitfalse \futurelet\next\ss} \def\ss{\ifcat\noexpand\next\stoken \spacetrue \ifx\next\stoken \let\next=\sss \else\let\next=\ssss \fi \else \let\next=\sssss \fi \next} \long\def\sss#1 #2\stest{\def\next{#1}% \ifx\next\empty \global\explicittrue \fi} \long\def\ssss#1#2\stest{\funnytrue {\uccode`#1=`~ \uppercase{\ifcat\noexpand#1}\noexpand~% active funny space \else \escapechar=\if*#1`?\else`*\fi \if#1\string#1\global\explicittrue\fi \fi}} \long\def\sssss#1\stest{\spacefalse} \endtt \bugonpage A444, lines 15--26 (3/26/91) \ninepoint \textindent{\bf14.}If the current item is an Ord atom, go directly to Rule~17 unless all of the following are true: The nucleus is a symbol; the subscript and superscript are both empty; the very next item in the math list is an atom of type Ord, Op, Bin, Rel, Open, Close, or Punct; and the nucleus of the next item is a symbol whose family is the same as the family in the present Ord atom. In such cases the present symbol is marked as a text symbol. If the font information shows a ligature between this symbol and the following one, using the specified family and the current size, then insert the ligature character and continue as specified by the font; in this process, two characters may collapse into a single Ord text symbol, and/or new Ord text characters may appear. If the font information shows a kern between the current symbol and the next, insert a kern item following the current atom. As soon as an Ord atom has been fully processed for ligatures and kerns, go to Rule~17. % volume B \hsize=35pc \def\\#1{\hbox{\it#1\/\kern.05em}} % italic type for identifiers \def\to{\mathrel{.\,.}} % double dot, used only in math mode % volume C \hsize=29pc \def\\#1{\hbox{\it#1\/\kern.05em}} % italic type for identifiers \bugonpage C262, line 15 (3/26/91) \ninepoint\noindent |string base_name, base_version; base_name="plain"; base_version="2.7";| \bugonpage C271, line 17 from the bottom (3/26/91) \ninepoint\noindent | currentpen_path shifted (z.t_) withpen penspeck enddef;| \bugonpage C347, Bront''e entry (1/29/91) \eightpoint\noindent [The accent was clobbered; her name should, of course, be Bront\"e. Fix the entries for D\"urer, M\"obius, and Stravinsky in the same way.] % Volume D \hsize=35pc \def\\#1{\hbox{\it#1\/\kern.05em}} % italic type for identifiers \def\to{\mathrel{.\,.}} % double dot, used only in math mode % volume E \hsize=29pc \def\dashto{\mathrel{\hbox{-\kern-.05em}\mkern3.9mu\hbox{-\kern-.05em}}} \bye ######################################################################## Differences between TeX.WEB 3.14 as of 18 March 1991 and as of 26 Mar 1991 ************ File SYSA:[TEX.TEX]TEX-314.WEB;1 (42) % Version 3.14 was a cosmetic change for new Volume B (February 1991). % A reward of $327.68 will be paid to the first finder of any remaining bug, ****** File PRG:[TEX.NEW]TEX-314.NEW;1 (42) % Version 3.14 fixed unprintable font names and corrected typos (March 1991). % A reward of $327.68 will be paid to the first finder of any remaining bug, ************ ************ File SYSA:[TEX.TEX]TEX-314.WEB;1 (1571) print(s); end; @ An array of digits in the range |0..15| is printed by |print_the_digs|. ****** File PRG:[TEX.NEW]TEX-314.NEW;1 (1571) slow_print(s); end; @ An array of digits in the range |0..15| is printed by |print_the_digs|. ************ ************ File SYSA:[TEX.TEX]TEX-314.WEB;1 (5576) else begin print_esc(""); slow_print(text(p)); print_char(" "); ****** File PRG:[TEX.NEW]TEX-314.NEW;1 (5576) else begin print_esc(text(p)); print_char(" "); ************ ************ File SYSA:[TEX.TEX]TEX-314.WEB;1 (5591) else begin print_esc(""); slow_print(text(p)); end; end; ****** File PRG:[TEX.NEW]TEX-314.NEW;1 (5591) else print_esc(text(p)); end; ************ ************ File SYSA:[TEX.TEX]TEX-314.WEB;1 (12693) An integer variable |k| will be declared for use by this routine. ****** File PRG:[TEX.NEW]TEX-314.NEW;1 (12692) If |total_pages>=65536|, the \.{DVI} file will lie. An integer variable |k| will be declared for use by this routine. ************ ************ File SYSA:[TEX.TEX]TEX-314.WEB;1 (12711) dvi_out(total_pages div 256); dvi_out(total_pages mod 256);@/ @; ****** File PRG:[TEX.NEW]TEX-314.NEW;1 (12711) dvi_out((total_pages div 256) mod 256); dvi_out(total_pages mod 256);@/ @; ************ Number of difference sections found: 6 Number of difference records found: 7 DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PRG:[TEX.NEW]TEX-314.DIF;1- SYSA:[TEX.TEX]TEX-314.WEB;1- PRG:[TEX.NEW]TEX-314.NEW;1 ######################################################################## Differences between MF.WEB 2.7 as of 13 March 1991 and as of 26 Mar 1991 ************ File SYSA:[TEX.MF]MF-27.WEB;2 (21835) \\{xxx} commands might appear anywhere in \.{GF} files generated by other processors. It is recommended that |x| be a string having the form of a ****** File PRG:[TEX.NEW]MF.WEB;1 (21835) \\{xxx} commands might appear within characters, in \.{GF} files generated by other processors. It is recommended that |x| be a string having the form of a ************ Number of difference sections found: 1 Number of difference records found: 2 DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=PRG:[TEX.NEW]MF-27.DIF;1- SYSA:[TEX.MF]MF-27.WEB;2- PRG:[TEX.NEW]MF.WEB;1 ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 029 ] ------- 8-Apr-1991 23:54:44-GMT,36209;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA17679; Mon, 8 Apr 91 17:54:34 MDT Date: Mon 8 Apr 91 19:38:44-EST From: bbeeton Subject: Bug reports and replies from DEK To: TeX-implementors@MATH.AMS.COM Message-Id: <671157524.0.BNB@MATH.AMS.COM> Mail-System-Version: 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} 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" 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 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 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 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 To: bbeeton Cc: Eberhard Mattes 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 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 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 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 To: Eberhard Mattes Cc: Barbara Beeton 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 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 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 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" > To: Chris Thompson > 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 > To: "Wayne G. Sullivan" > 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" > To: Chris Thompson > 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 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 ] ------- 9-Apr-1991 15:16:04-GMT,2036;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PEB@DM0MPI11.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA21810; Tue, 9 Apr 91 09:15:59 MDT Message-Id: <9104091515.AA21810@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Tue, 9 Apr 91 10:49:06-EDT Received: from DM0MPI11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4952; Tue, 09 Apr 91 10:47:23 EDT Received: from DM0MPI11 (PEB) by DM0MPI11 (Mailer R2.07) with BSMTP id 7368; Tue, 09 Apr 91 16:46:01 GMT Date: Tue, 09 Apr 91 16:29:47 GMT From: Peter Breitenlohner Organization: Max-Planck-Institut fuer Physik, Muenchen Subject: PATGEN To: TeX-implementors@math.ams.com This is in reply to Barbara Beeton's msg 30. I am willing to take care of PATGEN, and have in fact already done some work into that direction (for the VM/CMS and DOS-TP versions): 1. clean up (mostly non-ANSI Pascal) 2. upgrades for TeX 3, such as introduction of left-, right-hyphenmin In my opinion, the most important changes will however be those which make language dependent modifications unnecessary: a) if the input files (dictionary and/or patterns) contain, e.g., ^^fd, this will be converted to a unique internal code (below 128) and will be output again as ^^fd. b) any `Accent-letter' pairs, e.g., the "a, "o, "u, "s used for german, will be treated similarly. c) all that, of course, with as little loss in performance as possible d) the unique internal codes mentioned above will be assigned dynamically, at least 30 of them are available (above "Z", but below 127). That should suffice for the national characters of practically any one language. All this is clearly connected with current considerations how the national characters now available with the DC/EC fonts shall be entered for the various languages. Ultimately each national TeX users group has to make a decision for it's language. Any further ideas would be most welcome. Peter 9-Apr-1991 15:16:09-GMT,2508;000000000001 Return-Path: <@MATH.AMS.COM:karl@cs.umb.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AB21810; Tue, 9 Apr 91 09:16:05 MDT Received: from cs.umb.edu by MATH.AMS.COM via SMTP with TCP; Tue, 9 Apr 91 10:49:01-EDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA07630; Tue, 9 Apr 91 09:47:18 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA18578; Tue, 9 Apr 91 10:46:18 EDT Date: Tue, 9 Apr 91 10:46:18 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9104091446.AA18578@ra.cs.umb.edu> To: TeX-implementors@math.ams.com In-Reply-To: bbeeton's message of Mon 8 Apr 91 19:00:52-EST <671155252.0.BNB@MATH.AMS.COM> Subject: security Reply-To: karl@cs.umb.edu > I am writing to inform you about a security flaw affecting Unix > implementations of TeX (perhaps other operating systems as well). The > problem is that one can easily imbed TeX commands in ordinary TeX files > to write arbitrary text into a user's system files, such as .login, > .cshrc, .profile, .logout, etc. When a file with such commands is typeset, I see no reason for action. Any program that can write a file can do this. Appended is a message from Tim Morgan which expresses my feelings as well: To: Karl Berry Subject: trojan horses in TeX files Date: Mon, 08 Apr 91 16:22:05 -0700 From: Tim Morgan I guess you received mail from Barbara Beeton which mentions, among other things, the possibility of writing trojan horses in TeX to write on .login and other files. I don't see this as being a new problem. After all, anyone can write a program that pretends to be "login" and have it save login names and passwords. Furthermore, TeX code could write to ANY file; having a research paper overwritten would bother some people a lot more than having their .login file overwritten! More of a security threat is to write/overwrite a .rhosts file. Maybe this problem should be addressed by saying that when you're importing TeX code from someone else, you should check it for such trojan horses. This is the same thing we do now with C code that we get off the net---we don't just install it, and we tell our users the same thing. Furthermore, unlike C code, I think that any file you protect against writing by yourself will be safe from TeX code, whereas a C program could change its mode and then write on it. So you can be safe from trojan horses in TeX code by simply making .login etc be mode 444. 9-Apr-1991 17:12:08-GMT,1978;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA22293; Tue, 9 Apr 91 11:12:01 MDT Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Tue, 9 Apr 91 12:55:46-EDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA17076; Tue, 9 Apr 91 18:54:02 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA16263; Tue, 9 Apr 91 18:53:59 +0200 Date: Tue, 9 Apr 91 18:53:59 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9104091653.AA16263@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: TeX-implementors@math.ams.com Cc: karl@cs.umb.edu In-Reply-To: Karl Berry's message of Tue, 9 Apr 91 10:46:18 EDT <9104091446.AA18578@ra.cs.umb.edu> Subject: security Karl Berry writes: I see no reason for action. Any program that can write a file can do this. This is not a Unix-specific problem. Unix is certainly not the best in security one can think of, but you can have the same effect by writing into LOGIN.COM on VMS, USERPROF EXEC (or what it's called) on VM/CMS, etc. The only addition to TeX that might be a good idea is to print out not only the names of the files it is reading in but also it is writing too; in certain circumstances this is really as useful as current information. And as for files like .rhosts: if anyone is working under "root" or with similar "allow everything" permissions when he is trying out imported software does not deserve any pity. As Tim Morgan wrote: protect these files by removing write access to them (I don't know of any OS that does not allow at least this feature!). For some time now I have removed write permission from a number of important files --- not so much because of viruses, but because I'm much more likely to destroy their contents myself! Rainer Sch\"opf 9-Apr-1991 18:10:24-GMT,2823;000000000001 Return-Path: <@MATH.AMS.COM:karl@cs.umb.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA22932; Tue, 9 Apr 91 12:10:15 MDT Received: from cs.umb.edu by MATH.AMS.COM via SMTP with TCP; Tue, 9 Apr 91 13:44:47-EDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA13211; Tue, 9 Apr 91 12:44:10 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA26555; Tue, 9 Apr 91 13:43:08 EDT Date: Tue, 9 Apr 91 13:43:08 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9104091743.AA26555@ra.cs.umb.edu> To: REY@math.ams.com Cc: tex-implementors@math.ams.com In-Reply-To: Ralph Youngen's message of Tue 9 Apr 91 13:23:13-EST <671221393.0.REY@MATH.AMS.COM> Subject: security Reply-To: karl@cs.umb.edu > would be impossible, for example, to embed an Emacs macro into an ASCII file > in such a way that it would execute when someone read the file into Emacs.) As it turns out, this is possible via Emacs' `local variables' feature (not that that matters all that much to the present discussion). > Of the suggestions we've heard so far, I'm in favor of modifying TeX to > either report files being written to, Speaking as a TeX user, I certainly wouldn't always want to see the names of the files I'm \write-ing to be output. So it would have to be some option. I bet many implementations aren't prepared to do significant option handling (web2c isn't, as of right now). Also, this would break the trip test (since the original tex.web doesn't do such recording of the names). > or changing the file handling affected by TeX (such as *.COM files on > VMS systems, .* files on Unix As well as being somewhat ugly (not an overriding consideration, I suppose), this won't solve the problem. At least under Unix, you can make so-called hard links that are indistinguishable from the original file. So writing to *any* file could conceivably cause trouble. > be placing an idea into the heads of thousands of TeX users which could > lead to lots of additional mischief on the net. I think TeX users are at least as responsible as, say, C programmers. That is, a person who wants to cause mischief in this way isn't likely to be a TeX hacker in particular (I don't think); it's likely to be someone who does this in lots of different ways. Although most TeX users don't check for viruses (certainly I don't, when retrieving files), perhaps archive maintainers do. The only things I've made publically available are macros that I either wrote myself or that came from people I trust; I'm 99 44/100% sure that there are no viruses in them. I think that is the way to try to contain the damage -- putting restrictions on the TeX program itself will never do the job, because if they are sufficient to stop the viruses, they are sufficient to stop TeX from being useful, also. 9-Apr-1991 21:49:00-GMT,6376;000000000001 Return-Path: <@MATH.AMS.COM,@BULLDOG.CS.YALE.EDU:lrw!leichter@LRW.COM> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA24450; Tue, 9 Apr 91 15:48:51 MDT Received: from BULLDOG.CS.YALE.EDU by MATH.AMS.COM via SMTP with TCP; Tue, 9 Apr 91 17:28:43-EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Tue, 9 Apr 91 17:18:51 EDT Message-Id: <9104092118.AA08499@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Tue, 9 Apr 91 17:09:36 EDT Date: Tue, 9 Apr 91 17:09:36 EDT From: Jerry Leichter To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: Security I think people are missing the real potential for danger here by comparing a TeX file with Trojan horse code with a similarly-contaminated C source file. COMPILING the C program is perfectly safe. The danger is in RUNNING it. On the other hand, simply "COMPILING" the TeX file - and what else, after all, are we doing when we apply TeX to it? - is itself dangerous. People are reasonably aware that running code they know nothing about may be dangerous. Code that is dangerous when simply compiled is quite another story. It's rare, too - although not as rare as people think. All powerful text formatters can be misused in this way. I'm pretty sure troff can open files; it can probably also start up a system command in a subshell, making it even more dangerous. I recall reading a warning that an IBM text processor - SCRIPT? - could also do both these things. This was considered a severe enough problem that at least the ability to execute system commands from within SCRIPT was made an option that the user of SCRIPT had to explicitly enable when invoking it. As has been remarked, even reading a file in EMACS can be dangerous. The same applies to vi. (The dangerous feature in vi isn't even documented!) Checking files in style file archives may help avoid one particular path of distribution, but of course ANY document may be similarly dangerous. This is most unfortunate, since one of the advantages of using TeX is that one can send nicely formatted documents around for people to print as they see fit. It's great to be able to submit articles for publication as TeX source - that was one of TeX's goals. It will only take a few destructive hacks embedded in forged, mailed documents - as is well known, mail systems today are completely insecure - to make that mode of submital a thing of the past. Unfortunately, it's EXTREMELY difficult to avoid this problem. TeX is famous for its obscurity; warning people to check any TeX code before they use it will help no one. Any TeX hacker can create code that looks like it is doing something quite different from what it is, in fact, doing. Printing the names of files as they are opened is a minor help, but people aren't very good at remaining alert to this kind of thing: If you are TeX'ing up tens of sub- mitted files a day while editing a journal, you are unlikely to stay alert enough to spot the dangerous output file hidden in all the verbose output. Finally, the "dangerous" file names are just too varied from system to system, and just too hard to list even on a single system, to make it practical to special-case them in output routines. So, what's to be done? Most operating systems today have a notion of a "current directory". Suppose TeX (well, the system-specific routines) were modified so that \openout could open files ONLY in the current directory. A careful user could then ensure that his current directory was always set someplace that contained no "important" files before executing TeX. In practice, this is likely to be easy for most people, since it's common to have directories containing one's papers, etc. Certainly, there is no reason for one to run TeX in one's home directory, where (on Unix, for example) such things as .login can be found. A look at LaTeX reveals that it opens output files like .aux files using a variant on the same file specification it was handed. For example, if on a Unix system you \include{/x/y/inc}, LaTeX will try to create /x/y/inc.aux. Such usage is presumably rare - and certainly should be non-existant for any LaTeX file intended for others, on different machines with different directory layouts, to use. Other common macro packages are probably similar. In fact, in general I'll argue that ANY TeX file intended for distribution should probably avoid any attempt to access files using directory paths - not only are they system-specific, their syntax is not in general portable. For those instances where a TeX file must legitimately write to some other directory, an implementation could add some startup option to enable cross- directory \openout's. A careful user would only use the option when he trusted the contents of the TeX file. Since the TRIP test must be machine- and operating-system independent, it cannot depend on the ability to specify alternative directories in \openout - they might not EXIST on some systems! The TeXbook is (necessarily) very vague about how the argument is interpreted; even the fact that a .tex extension is added by default is only noted as something "most systems do". I'd claim that TeX with a restricted definition of is just as consistent with the TeXbook as one without. It is quite true that a link in a Unix directory, or a VMS logical name, or other things on other systems, could allow an \openout that appeared to be creating a "local" file to actually create one in some directory other than the current default one. However, these things are under the control of the person who RUNS TeX, NOT the person who writes the TeX file. There's no reason why that person should wish to create a "dangerous" link. (A VMS implementation could be written so as to ignore logical names in this context, just in case some fairly standard logical name could be misused.) This is not a complete solution. Many people will continue to place received TeX files in their top level directories and TeX them there, leaving them- selves open to .login modification and worse. I don't believe anything can be done to provide them with significant protection; ultimately, if you use a sharp knife and aren't careful, you'll cut yourself. At least with a "res- tricted \openout", it's POSSIBLE to be careful. -- Jerry 10-Apr-1991 7:33:53-GMT,1445;000000000001 Return-Path: <@MATH.AMS.COM,@FRIGGA.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02812; Wed, 10 Apr 91 01:33:48 MDT Received: from FRIGGA.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 10 Apr 91 03:10:02-EDT Date: Wed, 10 Apr 1991 00:08 PDT From: Don Hosek Subject: Re: security To: REY@MATH.AMS.COM Cc: tex-implementors@math.ams.com Message-Id: <5095DE391820193F@HMCVAX.CLAREMONT.EDU> X-Envelope-To: REY@MATH.AMS.COM, tex-implementors@math.ams.com X-Vms-To: IN%"REY@MATH.AMS.COM" X-Vms-Cc: IN%"tex-implementors@math.ams.com" I offer the following as an argument against the claim that it is sufficient to simply check the code to see if it has viral tendencies (the following, btw, is harmless and appeared in TeXhax earlier this year as a novelty piece). % Date: Thu, 7 Feb 91 12:20:50 -0500 %From: amgreene@ATHENA.MIT.EDU %Subject: A response to perl hackers \let~\catcode~`?`\ \let?\the~`#?~`~~`]?~`~\let]\let~`\.?~`~~`,?~`~~`\%?~`~~`=?~`~]=\def ],\expandafter~`[?~`~][{=%{\message[}~`\$?~`~=${\uccode`'.\uppercase {,=,%,{%'}}}~`*?~`~=*{\advance.by}]#\number~`/?~`~=/{*-1}\newcount. =\-{*-}~`-?~`~]-\-~`^?~`~=^{*1}~`\ ?~`~= {.`\ $}~`@?~`~=@{,.,"#`@^$} .`#*`'$.?~`~0-?~`~$//$^$ .``^$*?~`~$^$.?~`~0-?~`~/$-?~`~^$@*?~`~$ * ?~`~*?~`~*?~`~*?~`~$@-?~`~$ .?~`~0-?~`~-?~`~$.``^$^^$.`<-?~`~*`<$@* ?~`~$*?~`~-`(-`+$%}\batchmode 10-Apr-1991 7:33:59-GMT,1524;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AB02812; Wed, 10 Apr 91 01:33:54 MDT Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 10 Apr 91 03:15:10-EDT Date: Wed, 10 Apr 1991 00:13 PDT From: Don Hosek Subject: Re: security To: karl@cs.umb.edu Cc: tex-implementors@math.ams.com Message-Id: <51597F183820193F@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: IN%"karl@cs.umb.edu" X-Vms-Cc: IN%"tex-implementors@math.ams.com" -> or changing the file handling affected by TeX (such as *.COM files on -> VMS systems, .* files on Unix -As well as being somewhat ugly (not an overriding consideration, I -suppose), this won't solve the problem. At least under Unix, you can -make so-called hard links that are indistinguishable from the original -file. So writing to *any* file could conceivably cause trouble. Only if you're stupid. As was pointed out in another message, hard links, logicals, etc. are under the control of the user. How is the virus code to know that foo.bar is really a hard link to .profile? -Although most TeX users don't check for viruses (certainly I don't, when -retrieving files), perhaps archive maintainers do. I barely can check that I'm not putting files full of random ASCII characters up on ymir, let alone non-viral code. Fortunately, there have been no problems as far as I know. -dh 11-Apr-1991 20:02:04-GMT,3179;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:gtoal@tardis.computer-science.edinburgh.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13494; Thu, 11 Apr 91 14:01:57 MDT Message-Id: <9104112001.AA13494@math.utah.edu> Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Thu, 11 Apr 91 15:48:13-EDT Received: from tardis.computer-science.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <21709-0@sun2.nsfnet-relay.ac.uk>; Thu, 11 Apr 1991 20:42:49 +0100 Date: Thu Apr 11 20:43:39 GMT 1991 To: tex-implementors <@nsfnet-relay.ac.uk:tex-implementors@math.ams.com> Subject: Re: patgen Cc: gtoal@nsfnet-relay.ac.uk From: gtoal@tardis.computer-science.edinburgh.ac.uk To: TeX-implementors@com.ams.math Peter Breitenlohner writes: >This is in reply to Barbara Beeton's msg 30. >I am willing to take care of PATGEN, and have in fact already done >some work into that direction (for the VM/CMS and DOS-TP versions): >1. clean up (mostly non-ANSI Pascal) >2. upgrades for TeX 3, such as introduction of left-, right-hyphenmin >In my opinion, the most important changes will however be those >which make language dependent modifications unnecessary: >a) if the input files (dictionary and/or patterns) contain, e.g., > ^^fd, this will be converted to a unique internal code (below 128) > and will be output again as ^^fd. >b) any `Accent-letter' pairs, e.g., the "a, "o, "u, "s used for german, > will be treated similarly. >c) all that, of course, with as little loss in performance as possible >d) the unique internal codes mentioned above will be assigned dynamically, > at least 30 of them are available (above "Z", but below 127). > That should suffice for the national characters of practically any > one language. >All this is clearly connected with current considerations how the national >characters now available with the DC/EC fonts shall be entered for the >various languages. Ultimately each national TeX users group has to make >a decision for it's language. > >Any further ideas would be most welcome. Peter Thanks for offering to look after patgen, Peter. It was disquieting to have an orphaned program in the TeX suite, especially one as important as this. I've been looking at Patgen recently with Dominik Wujastic in order to create British hyphenation patterns. (Dominik received the Oxford English hyphenation word list) I agree that work needs to be done in relation to international character sets, but I strongly urge it is thought about in some depth first. Peter's quick-hack solution of translating down to a 7-bit character set isn't really good enough. The whole question of hyphenation has to be explored now we have TeX 3. As well as ISO 8-bit alphabets, we have to think about hyphenating words with hyphens and apostrophes in them, as well as upper and lower case initial letters. I don't have the answers; I haven't even thought the problems through properly, but I do know that there is a problem which needs some thought. I'd be very reluctant for peter to release his patches as the current maintained patgen. Regards Graham 14-Apr-1991 11:35:01-GMT,2501;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PEB@DM0MPI11.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17556; Sun, 14 Apr 91 05:34:58 MDT Message-Id: <9104141134.AA17556@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Sun, 14 Apr 91 07:25:37-EDT Received: from DM0MPI11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0643; Sun, 14 Apr 91 07:25:43 EDT Received: from DM0MPI11 (PEB) by DM0MPI11 (Mailer R2.07) with BSMTP id 8295; Sun, 14 Apr 91 13:24:54 GMT Date: Sun, 14 Apr 91 12:57:52 GMT From: Peter Breitenlohner Organization: Max-Planck-Institut fuer Physik, Muenchen Subject: Re: patgen To: Tex-implementors@math.ams.com In-Reply-To: Your message of Thu Apr 11 20:43:39 GMT 1991 On Thu Apr 11 20:43:39 GMT 1991 Graham said: >Peter Breitenlohner writes: >>This is in reply to Barbara Beeton's msg 30. >>..... >>Any further ideas would be most welcome. Peter > >Thanks for offering to look after patgen, Peter. It was disquieting to >..... >Graham > Unfortunately my previous message was probably somewhat misleading. I am confident we all agree that PATGEN should offer a possibility to use the `national characters' of any one language (using the latin alphabet) without language dependent modifications of the program. I wanted to emphasize this point, and to offer a few of my personal thoughts in that direction. As I have had some exchange with Dominic Wujastic on this subject, I am well aware that the whole subject needs more discussion. Therefore my previous message. I never intended to make any such changes in the official PATGEN without wide agreement on how to do them. Just another idea: Maybe the best way for an adequate treatment of different languages would be to read a short file with the external representation of everything to be considered a character in a hyphenable word; ordinary letters ('a'..'z', 'A'..'Z') excluded or maybe included?? PATGEN's translation tables would then be set up accordingly. This scheme might even find unanimous agreement provided there is no loss in efficiency when reading the whole dictionary so many times. Unfortunately I do not (yet?) see an efficient way to implement this scheme. If such a scheme were generally acceptable (I want your opinion on that, so please reply, either to me or to this list), I would certainly try to find an efficient way to do it. Regards Peter 18-Apr-1991 9:37:39-GMT,2902;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16119; Thu, 18 Apr 91 03:37:35 MDT Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Thu, 18 Apr 91 04:58:09-EDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA06041; Thu, 18 Apr 91 10:34:44 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA29653; Thu, 18 Apr 91 10:34:40 +0200 Date: Thu, 18 Apr 91 10:34:40 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9104180834.AA29653@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: TeX-implementors@math.ams.com Subject: [LIST_SERVER@tex.ac.uk: Font arrangements in directory trees] This went recently over the UK list... Return-Path: Date: Thu, 18 APR 91 07:53:40 GMT From: LIST_SERVER@tex.ac.uk To: SCHOEPF <@nsfnet-relay.ac.uk:SCHOEPF@SC.ZIB-BERLIN.de> Subject: Font arrangements in directory trees Reply-To: ZLSIIAL , UKTeX Reviewers Originally-Sent: Thu, 18 Apr 91 08:33:41 BST Originally-To: uktex @ tex Original-Ident: <18 Apr 91 08:33:41 BST ZLSIIAL@UK.AC.MCC.CMS> Originally-From: ZLSIIAL@UK.AC.MANCHESTER-COMPUTING-CENTRE.CMS X-Serial: 00000343 I am sorry to have had to miss the recent UK-TUG meeting in Nottingham (on TeX in the Unix environment). One subject which I hoped to discuss with other TeX administrators is the potential directory structure for font bitmaps. When we first got a TeX for a Unix system, it was a free but 'shrink-wrapped' distribution from our manufacturer. The directory structure for font bitmaps was something like this: /usr/lib/tex/fontbits/laser/300/cmr5.pk cmr6.pk 360/cmr5.pk cmr6.pk where the fonts are arranged by their available sizes. I have always been puzzled by this arrangement, and when I recompiled the whole system myself, I changed all the dvi utilities to use instead this arrangement: /usr/lib/tex/fontbits/laser/cmr5/300pk 360pk cmr6/300pk 360pk which is in fact easier to integrate into the search algorithms in which one also looks for cmr5.300pk, for example. We have now been using this system quite happily for about two years. It is easier for users to find what fonts are available. Is there any argument for having the old arrangement (other than the fact that at the moment the existing versions of most dvi tools are written that way)? A. V. Le Blanc ZLSIIAL@uk.ac.mcc.cms 18-Apr-1991 13:09:54-GMT,3455;000000000001 Return-Path: <@MATH.AMS.COM,@post-office.uh.edu:bed_gdg@SHSU.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16638; Thu, 18 Apr 91 07:09:48 MDT Received: from post-office.uh.edu by MATH.AMS.COM via SMTP with TCP; Thu, 18 Apr 91 08:52:31-EDT Received: from SHSU.BITNET (MXMAILER@SHSU) by Post-Office.UH.EDU with PMDF#10188; Thu, 18 Apr 1991 07:51 CDT Received: by SHSU.BITNET (MX V2.2-1) id 25467; Thu, 18 Apr 1991 07:50:13 CDT Date: Thu, 18 Apr 1991 07:50:13 CDT From: "George D. Greenwade" Subject: RE: [LIST_SERVER@tex.ac.uk: Font arrangements in directory trees] To: schoepf@sc.ZIB-Berlin.DE Cc: TeX-Implementors@math.ams.com, ZLSIIAL@cms.mcc.ac.uk Message-Id: <009474DA.73670140.25467@SHSU.BITNET> In <9104180834.AA29653@sc.zib-berlin.dbp.de> on Thu, 18 Apr 91 10:34:40 +0200 "Rainer Schoepf" forwarded to TeX-Implementors the following (originally from A. V. Le Blanc ): >The directory structure for font bitmaps was something like this: > /usr/lib/tex/fontbits/laser/300/cmr5.pk > ... > where the fonts are arranged by their available sizes. I have always been > puzzled by this arrangement, and when I recompiled the whole system myself, > I changed all the dvi utilities to use instead this arrangement: > /usr/lib/tex/fontbits/laser/cmr5/300pk > ... > which is in fact easier to integrate into the search algorithms in which > one also looks for cmr5.300pk, for example. We have now been using this > system quite happily for about two years. It is easier for users to find > what fonts are available. > > Is there any argument for having the old arrangement (other than the fact > that at the moment the existing versions of most dvi tools are written that > way)? The main advantage of the existing system is that everything associated with size "300" is retained together (in our case, not only the pk's but also the pxl's, tfm's and everything else), so it is easier to identify quickly what is in the 300 class. This markedly reduces the VMS searchpath for fonts, although there is a trade-off between the complexity of a searchpath and the ability to IO if the root directory exceeds certain sizes. In our installation (VMS), we have experimented with this and found no degradation in IO and file access under the existing system as compared to a system similar to yours. Given any algorithm, users can find what they want rather easily once they know it and it remains stable. Also, while I am not tied to any convention if an alternate can be shown to be superior (and not OS specific), the fact that existing versions of tools are for the most part designed around the "old arrangement" is not trivial to fix across all systems using TeX (which is why the addition of CLD files for VMS applications has been more than welcomed by us on VMS). Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg%shsu.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 18-Apr-1991 13:10:00-GMT,1475;000000000001 Return-Path: <@MATH.AMS.COM,@ruuinf.cs.ruu.nl:piet@cs.ruu.nl> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB16638; Thu, 18 Apr 91 07:09:55 MDT Received: from ruuinf.cs.ruu.nl by MATH.AMS.COM via SMTP with TCP; Thu, 18 Apr 91 09:03:24-EDT Received: from gnu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA24256; Thu, 18 Apr 91 15:01:12 +0100 Received: by alchemy.cs.ruu.nl (15.11/15.6) id AA00847; Thu, 18 Apr 91 15:02:05 met Date: Thu, 18 Apr 91 15:02:05 met From: Piet van Oostrum Message-Id: <9104181302.AA00847@alchemy.cs.ruu.nl> To: "George D. Greenwade" Cc: TeX-Implementors@math.ams.com Subject: RE: [LIST_SERVER@tex.ac.uk: Font arrangements in directory trees] References: <009474DA.73670140.25467@SHSU.BITNET> >>>>> "George D. Greenwade" (GDG) writes: GDG> The main advantage of the existing system is that everything associated GDG> with size "300" is retained together (in our case, not only the pk's but GDG> also the pxl's, tfm's and everything else), so it is easier to identify tfm's should not depend on the resolution of the printer. So they belong in a size-independent path. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') 18-Apr-1991 14:30:18-GMT,2053;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk,@directory.nottingham.ac.uk:cczdao@mips.ccc.nottingham.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16869; Thu, 18 Apr 91 08:30:12 MDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Thu, 18 Apr 91 09:23:19-EDT Received: from directory.nottingham.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <13617-0@sun2.nsfnet-relay.ac.uk>; Thu, 18 Apr 1991 14:19:01 +0100 Received: from mips.nott.ac.uk by dir.nott.ac.uk with SMTP (PP) id <1143-0@dir.nott.ac.uk>; Thu, 18 Apr 1991 14:18:48 +0100 To: "George D. Greenwade" Cc: schoepf@sc.zib-berlin.de, TeX-Implementors@math.ams.com, ZLSIIAL@cms.manchester-computing-centre.ac.uk Subject: Re: [LIST_SERVER@tex.ac.uk: Font arrangements in directory trees] In-Reply-To: Message from bed_gdg@bitnet.shsu of 18 Apr 91 7:50:13 CDT X-Organization: Cripps Computing Centre, University of Nottingham X-Postal: University Park, Nottingham NG7 2RD, England X-Phone: +44 (602) 484848 ext 2064 Date: Thu, 18 Apr 91 14:20:31 +0100 Message-Id: <28620.671980831@mips> From: David Osborne In message <009474DA.73670140.25467@SHSU.BITNET> of 18 Apr 91 7:50:13 CDT, "George D. Greenwade" said: > The main advantage of the existing system is that everything associated > with size "300" is retained together (in our case, not only the pk's but > also the pxl's, tfm's and everything else) Just a comment... the tfm's are independent of the resolution of the output device, so could conveniently be in a directory of their own. It would be legitimate, though perhaps uncommon, to have a tfm file for a font for which one didn't have a gf/pk/pxl file, if it were intended to transfer the dvi file to another system for previewing or printing. --dave David Osborne, Cripps Computing Centre, University of Nottingham Nottingham NG7 2RD, UK (Phone: +44 602 484848 x2064) 19-Apr-1991 19:27:58-GMT,1844;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27275; Fri, 19 Apr 91 13:27:51 MDT Received: from manta.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Fri, 19 Apr 91 15:14:56-EDT Received: by manta.cs.washington.edu (5.64/7.0a) id AA10035; Fri, 19 Apr 91 12:13:51 -0700 Date: Fri, 19 Apr 91 12:13:51 -0700 From: mackay@manta.cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9104191913.AA10035@manta.cs.washington.edu> To: leichter@LRW.COM Cc: TEX-IMPLEMENTORS@MATH.AMS.COM In-Reply-To: Jerry Leichter's message of Tue, 9 Apr 91 17:09:36 EDT <9104092118.AA08499@BULLDOG.CS.YALE.EDU> Subject: Security I wholeheartedly agree that all (or at least 99 44/100 percent) of output files should be opened in the current working directory, I spent some effort on the change files for mfware years ago to do that. It is not even convenient to default to one or another of the input directories, since it can often be desirable to take input >From a completely protected directory. But this is a matter of convenience, rather than of security, because the per-process notion of current working directory is subject to change by some very simple shell commands. So I am all for making the normal choice of output directory the current working directory in every case (unless there is some real reason to do otherwise) but I do not think it will solve any security problems. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 19-Apr-1991 19:28:04-GMT,1799;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB27275; Fri, 19 Apr 91 13:27:59 MDT Received: from manta.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Fri, 19 Apr 91 15:01:41-EDT Received: by manta.cs.washington.edu (5.64/7.0a) id AA10025; Fri, 19 Apr 91 11:59:23 -0700 Date: Fri, 19 Apr 91 11:59:23 -0700 From: mackay@manta.cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9104191859.AA10025@manta.cs.washington.edu> To: schoepf@sc.ZIB-Berlin.DE Cc: TeX-implementors@math.ams.com, karl@cs.umb.edu In-Reply-To: Rainer Schoepf's message of Tue, 9 Apr 91 18:53:59 +0200 <9104091653.AA16263@sc.zib-berlin.dbp.de> Subject: security In essence, I agree with both Karl and Rainer. I have done worse things to myself by carelessly leaving valuable files unprotected against write access than almost any virus could do to me. But the cure for the worst elements of the problem is simple, and has DEK's blessing. So we might as well make it, since TeX does not attempt any special reference to hidden configure files with initial character .s Half the problem comes from leaving your special configuration files out of sight and out of mind. The first thing I do in any .cshrc file I am going to use is alias ls to "ls -Fsa" It means it has to be unaliased for certain operations, but that is a very slight price to pay. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 22-Apr-1991 18:03:22-GMT,1891;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17806; Mon, 22 Apr 91 12:03:18 MDT Date: Mon 22 Apr 91 13:42:13-EST From: bbeeton Subject: dek's comments on "when is *t*x tex?" To: TeX-implementors@MATH.AMS.COM Message-Id: <672345733.0.BNB@MATH.AMS.COM> Mail-System-Version: karl berry posed some questions on this subject that i forwarded to knuth for his opinion. included below are excerpts from karl's points and dek's responses. --bb Date: Tue, 26 Mar 91 14:38:12 EST From: karl@cs.umb.edu (Karl Berry) It's clear that the result of adding a new primitive (\charsubdef, say) to TeX cannot be called TeX. dek> Right It's clear that the result of just increasing a parameter that is already in tex.web (mem_max, say) is still TeX. dek> Right What about increasing a parameter that requires more work than just increasing the parameter? For example, Klaus' stuff to increase the size of the hyphenation trie. Is that still TeX? dek> Yes definitely. Also changing help messages to local vernacular dek> is specifically allowed. What [about] increasing parameters that *are* specified in the TeXbook, e.g., the number of math families (this is hypothetical, I don't know of anyone who's actually done it)? Again, there are no user visible changes -- you just get to have more than 16 families. dek> No. This is an absolute limit ... user visible too (consider dek> e.g. \delcode) dek: A gray area comes in when you try to load more than 256 fonts or have more than 128 input files open simultaneously; I guess a super-large TeX to handle that would be OK but anybody who relies on such things should expect her/his programs to be not very portable until 2020 or so ... ------- 22-Apr-1991 18:46:49-GMT,1420;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18065; Mon, 22 Apr 91 12:46:45 MDT Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Mon, 22 Apr 91 14:21:38-EDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA16025; Mon, 22 Apr 91 20:20:43 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA03631; Mon, 22 Apr 91 20:20:40 +0200 Date: Mon, 22 Apr 91 20:20:40 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9104221820.AA03631@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: BNB@MATH.AMS.COM Cc: TeX-implementors@MATH.AMS.COM In-Reply-To: bbeeton's message of Mon 22 Apr 91 13:42:13-EST <672345733.0.BNB@MATH.AMS.COM> Subject: dek's comments on "when is *t*x tex?" I can think of more questionable items: 1. What about including support for more than code page (say, on MS-DOS systems) where the number of the code page to use is given to IniTeX on the command line and recorded in the format file? (no new primitive, just a command line switch!) 2. What about a new hashing algorithm that allows dynamic extension of the hash table, say by using ordinary linked lists instead of coalescing the lists with the hash table as TeX does now? Rainer 26-Apr-1991 18:00:38-GMT,2066;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01315; Fri, 26 Apr 91 12:00:33 MDT Date: Fri 26 Apr 91 13:42:35-EST From: bbeeton Subject: update on bibtex revision To: tex-implementors@MATH.AMS.COM, latex-l@dhdurz1.bitnet Message-Id: <672691355.0.BNB@MATH.AMS.COM> Mail-System-Version: i've received the attached message from oren patashnik. i think that tying bibtex 1.0 to latex 3.0 is a good thing. however, oren will be ending his active development after that point is reached. if anyone is seriously interested in assuming the role of developer beyond that point, please make your interest known to oren and me. if no promising offers surface very quickly from this forum, i will publish a similar request in tugboat. -- bb -------------------- Date: Wed, 24 Apr 91 7:11:39 PDT From: Oren Patashnik To: bnb@math.ams.com Subject: BibTeX update/question Progress on BibTeX 1.0 is inching along. (I've been in touch with Frank Mittelbach, and currently it seems best that BibTeX 1.0 and LaTeX 3.0 come out at about the same time.) Now I've been assuming all along that, after 1.0 comes out, BibTeX, like TeX, will be frozen. But the "BibTeX Reconsidered" article in TUGboat makes it sound as if there's interest in an evolving BibTeX (especially if LaTeX will continue to evolve). I'm willing to maintain a frozen BibTeX, just as Don is maintaining the frozen TeX, but if BibTeX is to continue to evolve someone else will have to take it over, in which case we'll have to figure out an appropriate transition. What form BibTeX 1.0 takes is at least partly dependent on its future. What's your understanding of what the TeX community wants? (I haven't talked to Frank since I read the article---I thought I'd check first with you at TUG to see if you have a sense of what's best. Feel free to send this to anyone who might have useful thoughts on the matter.) --Oren ------- 26-Apr-1991 19:01:30-GMT,1570;000000000001 Return-Path: <@MATH.AMS.COM:karney@theory.pppl.gov> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01555; Fri, 26 Apr 91 13:01:27 MDT Received: from theory.pppl.gov by MATH.AMS.COM via SMTP with TCP; Fri, 26 Apr 91 14:52:40-EDT Received: by theory.pppl.gov (4.1/1.15) id AA11613; Fri, 26 Apr 91 14:51:02 EDT Date: Fri, 26 Apr 91 14:51:02 EDT From: karney@theory.pppl.gov (Charles Karney) Message-Id: <9104261851.AA11613@theory.pppl.gov> To: tex-implementors@math.ams.com, opbibtex@neon.stanford.edu Subject: BibTeX update I echo the need for further development of BibTeX beyond 1.0. My biggest complaint about the current BibTeX is the language used in .bst files. I have spent a lot of time tinkering with TeX, LaTeX, makeindex, and BibTeX. I find this tinkering pleasurable and rewarding, except when it comes to BibTeX. I now dread making changes to .bst file. The language is awkward and verbose; the documentation is meagre; changing minor things requires the creation of yet another 20k .bst file. I usually tell users who need a slightly different format to edit the .bbl file. I don't have any concrete suggestions for how this can be improved. Possibly some template driven approach would be easier for the average user to deal with. Just replacing the stack-based language with something resembling C or Pascal would help. Charles Karney Plasma Physics Laboratory E-mail: Karney@Princeton.EDU Princeton University Phone: +1 609 243 2607 Princeton, NJ 08543-0451 FAX: +1 609 243 2662 28-Apr-1991 21:06:36-GMT,5214;000000000001 Return-Path: <@MATH.AMS.COM:opbibtex@Neon.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12758; Sun, 28 Apr 91 15:06:31 MDT Received: from Neon.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Sun, 28 Apr 91 16:54:40-EDT Received: by Neon.Stanford.EDU (5.61/25-eef) id AA03587; Sun, 28 Apr 91 13:52:55 -0700 Date: Sun, 28 Apr 91 13:52:53 PDT From: Oren Patashnik To: karney@theory.pppl.gov (Charles Karney) Cc: tex-implementors@math.ams.com Subject: Re: BibTeX update In-Reply-To: Your message of Fri, 26 Apr 91 14:51:02 EDT Message-Id: Thanks for your comments about the future of BibTeX. I'll add a few comments of my own, along with some more information about plans for 1.0. > I echo the need for further development of BibTeX beyond 1.0. My biggest > complaint about the current BibTeX is the language used in .bst files. I > have spent a lot of time tinkering with TeX, LaTeX, makeindex, and BibTeX. > I find this tinkering pleasurable and rewarding, except when it comes to > BibTeX. I now dread making changes to .bst file. The language is awkward > and verbose; I agree that it's not the easiest language to program in. (Although I don't think it's particularly verbose; `cumbersome' is the adjective I'd use.) On the other hand, the language is very simple and very straightforward---it has almost no weird side effects. I claim, for example, that in about an hour I can make a moderately small change to an existing style, debug it, and test it, and then be very sure it's correct. For Leslie Lamport to make a comparable change to an existing LaTeX style might take the same amount of time, but he'll never be as sure as I am (at least not in any additional amount of time he'd be willing to spend) that his new style does what he wants. I'll comment more on the language shortly. > the documentation is meagre; Although for 1.0 I plan to update the "Designing BibTeX Styles" document---primarily by giving a few more examples, increasing it to 15 or 20 pages from the current 10---I plan no major changes. I view the current documentation as being close to adequate for its intended audience, someone who's comfortable programming in a postfix stack language. (In the next version of the documentation, I plan to say explicitly who the intended audience is.) I'd appreciate knowing if you disagree about the adequacy for that audience, and I'd appreciate any specific suggestions for improvements you might have. > changing minor things requires the creation of yet another 20k .bst file. Yes, that's true. Several people have asked for some kind of mechanism for making minor changes to a style, and although I have no current plans for such change (I don't view a bunch of commonly used 20k files sitting around in some directory as much of a problem), I'm still open to suggestions for how and why that should be implemented. > I usually tell users who need a slightly different format to edit the > .bbl file. If the style will be used just once, and if the user will have to run BibTeX only a few times, that advice seems reasonable; but otherwise, it's probably a mistake. Any style that's only `slightly different' >From another can be programmed fairly quickly, given the other style; furthermore, there's a good chance that others have needed the desired style. So there's a good chance that a quick request to comp.text.tex will yield either the new style itself or a listing of the changes needed to produce the style. > I don't have any concrete suggestions for how this can be improved. > Possibly some template driven approach would be easier for the average > user to deal with. For 1.0 I have tentative plans to expand the btxbst.doc (template) file a bit, and probably to write a program to accompany BibTeX that will produce a style from a user's specification of the desired features. (That program would take the place of the C Preprocessor, which is the current program through which the standard styles, for example, are produced.) But I don't plan on including a huge, comprehensive list of features in btxbst.doc. > Just replacing the stack-based language with something resembling C or > Pascal would help. This suggestion gets at what I consider to be the main point in deciding BibTeX's future. If BibTeX styles are meant to be things that an `average user' can create, then there's no question, it seems to me, that the .bst language should be changed in some future version of BibTeX. But since LaTeX styles aren't meant to be things that an average user can create, BibTeX styles probably shouldn't be either. Of course the question arises: "But then who will create the BibTeX styles that people want?" I don't know the answer, but I suspect that the future of BibTeX depends on it. (My gut feeling is that, since a cadre of TeX/LaTeX hackers has formed to satisfy the needs of the user community, and since BibTeX's .bst language is much simpler than TeX, eventually a cadre of .bst hackers will form to satisfy the needs of the user community; but I'm certainly not sure of that assessment.) --Oren 29-Apr-1991 12:38:02-GMT,3338;000000000001 Return-Path: <@MATH.AMS.COM,@post-office.uh.edu:bed_gdg@SHSU.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14752; Mon, 29 Apr 91 06:37:58 MDT Received: from post-office.uh.edu by MATH.AMS.COM via SMTP with TCP; Mon, 29 Apr 91 08:23:04-EDT Received: from SHSU.BITNET (MXMAILER@SHSU) by Post-Office.UH.EDU with PMDF#10188; Mon, 29 Apr 1991 07:22 CDT Received: by SHSU.BITNET (MX V2.2-1) id 9833; Mon, 29 Apr 1991 07:16:58 CDT Date: Mon, 29 Apr 1991 07:16:58 CDT From: "George D. Greenwade" Subject: Re: BibTeX update (comp.text.tex suggestion) To: opbibtex@Neon.Stanford.EDU Cc: tex-implementors@math.ams.com Message-Id: <00947D7A.A0D25C80.9833@SHSU.BITNET> In (Sun, 28 Apr 91 13:52:53 PDT), Oren Patashnik says: > > the documentation is meagre; > > ... I view the current documentation as being close to adequate for its > intended audience, someone who's comfortable programming in a postfix stack > language. (In the next version of the documentation, I plan to say > explicitly who the intended audience is.) I'd appreciate knowing if you > disagree about the adequacy for that audience, and I'd appreciate any > specific suggestions for improvements you might have. I would hope that the audience could be expanded to include .bst hackers by at least giving a clue as to what to look for. Some sites just don't have programming people around to help on this and users are generally left to fend for themselves (also, this is especially true for many of the PC-based users out there). > ... furthermore, there's a good chance that others have needed the desired > style. So there's a good chance that a quick request to comp.text.tex will > yield either the new style itself or a listing of the changes needed to > produce the style. Please, please, please tell people to post to INFO-TeX@SHSU.BITNET (admittedly, this is very biased, coming from the list owner). INFO-TeX gets to comp.text.tex so long as there is a message Subj: line -- promise! -- so you will get the same effect, but a larger audience (among others, those in BITNET land who can't access USENET). Since January, we have had four posts stating "I tried this on comp.text.tex and no reply in (two, three, or four) weeks, so I am posting it to INFO-TeX ...." In every case, a reply was posted back within 1.5 hours (one in 15 minutes!) from an INFO-TeX'er without comp.text.tex access (yes, I actually checked on this!). Ultimately, comp.text.tex needlessly saw the same post twice (and verified my suspicions about the need for and benefits deriving from a BITNET/Internet-based discussion list on TeX). Enough preaching and attempted selling. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg%shsu.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 29-Apr-1991 15:53:29-GMT,815;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15285; Mon, 29 Apr 91 09:53:25 MDT Date: Mon 29 Apr 91 11:40:45-EST From: bbeeton Subject: comp.text.tex To: tex-implementors@MATH.AMS.COM Message-Id: <672939645.0.BNB@MATH.AMS.COM> Mail-System-Version: i think i mentioned this before, but i'll piggy-back onto george greenwade's posting. does anyone know how comp.text.tex can be accessed if one hasn't got a unix/usenet connection? and does anyone know if there are any archives for this monster? (not that i need that much more reading, but really, if i am to be a responsible tugboat editor, i ought to be keeping up with all the regular forums.) thanks. -- bb ------- 29-Apr-1991 20:57:06-GMT,5059;000000000001 Return-Path: <@MATH.AMS.COM,@BULLDOG.CS.YALE.EDU:lrw!leichter@LRW.COM> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21428; Mon, 29 Apr 91 14:57:01 MDT Received: from BULLDOG.CS.YALE.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 29 Apr 91 16:45:22-EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Mon, 29 Apr 91 16:38:02 EDT Message-Id: <9104292038.AA10532@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Mon, 29 Apr 91 08:49:50 EDT Date: Mon, 29 Apr 91 08:49:50 EDT From: Jerry Leichter To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: Re: BibTeX update As long as the issue of BibTeX futures seems to be under discussion, I'd like to take this opportunity to mention my pet peeve: The very useful, but un- usably weak, method used to define abbreviations for journal names. The LaTeXbook, on page 143, mentions that "Some abbreviations are predefined by the bibliography style. These always include the [months].... Bibliogra- phy styles usually contain abbreviations of commonly referenced journals. Consult your Local Guide [for local definitions]." Few people seem to be aware of this feature. The standard BibTeX styles con- tain an ad hoc set of journal name definitions, never documented anywhere. For the record, here they are: acmcs: ACM Comput. Surv. acta: Acta Inf. cacm: Commun. ACM ibmjrd: IBM J. Res. Dev. ibmsj: IBM Syst.~J. ieeese: IEEE Trans. Softw. Eng. ieeetc: IEEE Trans. Comput. ieeetcad: IEEE Trans. Comput.-Aided Design Integrated Circuits ipl: Inf. Process. Lett. jacm: J.~ACM jcss: J.~Comput. Syst. Sci. scp: Sci. Comput. Programming sicomp: SIAM J. Comput. tocs: ACM Trans. Comput. Syst. tods: ACM Trans. Database Syst. tog: ACM Trans. Gr. toms: ACM Trans. Math. Softw. toois: ACM Trans. Office Inf. Syst. toplas: ACM Trans. Prog. Lang. Syst. tcs: Theoretical Comput. Sci. I have yet to find a site that adds local journal abbreviations, though I suppose they exist. I contend that they are a bad idea, however: They make .bib files non-portable. As a work-around, I've used BibTeX's @string operator to defined a header "bibliography" file (containing no actual bibliographic entries) that I always include before any of my other bibliography files. Every time I use a journal name, I add it to this header. This approach works up to a point, but it has one major problem: It cannot provide different representations with different bibliography styles, as the built-in abbrevations do. (For example, the list of definitions I included above is taken from abbrv.bst. Had I taken them >From a style like alpha, the translation of, say, jacm would be very differ- ent: "Journal of the ACM", rather than "J.~ACM".) Sure, I could maintain different versions of my header file - but this rapidly becomes a chore that I would not wish to undertake. I understand that there are standard abbreviated names, like jacm, used by libraries. In principle, one could add all of them to the standard bst files and be done with the problem - at least until some new journals came along. Unfortunately, this is impractical: .bst files have to be read and inter- preted every time BibTeX is run, and adding thousands of lines of journal definitions (the vast majority of which would, of course, never be used in any given run) would make BibTeX runs too slow. (It's also not at all clear that BibTeX would have enough memory to support this!) Further, it's not a good idea to build large, changeable databases into a large number of bibliography files; it makes updating too hard. The ideal solution would separate standard lists of predefinitions from the style files themselves. Suppose that there were available regularly updated "journal database" files. These would contain mappings from standard journal name abbreviations to text strings. There would be at least two variant forms, corresponding to the "full" names used in alpha.bst and the "abbrevia- ted" names in abbrv.bst. (It's possible that the transformation between these two representations is automatable, but I doubt it.) The "bst" language would be extended to allow a bibliography style to look up a definition in a "jour- nal database". One would hope that the database could be organized as some kind of indexed file, so that lookups could be done very quickly; but even if that proves to be difficult on some machines, one could still try to be clever - for example, making one pass over the .bib file to locate all undefined macro names, collecting and sorting them all, then resolving them all in one pass through a sorted database file. In practice, however, on any system that allows random reading into a file, it is simple to build an indexed file. For example, one can build and sort the database file, then build an auxilli- ary pointer file containing whatever data is needed to seek to every n'th entry in the file, together with the name of the macro that one will find there. -- Jerry 6-May-1991 21:33:47-GMT,2102;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00723; Mon, 6 May 91 15:33:44 MDT Date: Mon 6 May 91 17:33:18-EST From: bbeeton Subject: [Pony Express Mailer : Undeliverable message] To: beebe@math.utah.edu Message-Id: <673565598.0.BNB@MATH.AMS.COM> Mail-System-Version: i think this problem has fixed itself. --------------- Return-Path: <> Date: Mon 6 May 91 07:19:53-EDT From: Pony Express Mailer Subject: Undeliverable message To: BNB@MATH.AMS.COM Reply-To: Pony Express is unable to deliver mail to the following recipients: Beebe @ Math.Utah.edu Reason for failure is: Invalid SMTP reply: cannot open database /etc/aliases 220 math.utah.edu Sendmail 4.1/SMI-4.1-utah-csc-server ready at Mon, 6 May 91 05:20:08 MDT Undelivered message follows: ---------------------------------------- Date: Mon 6 May 91 06:53:52-EST From: bbeeton Subject: Re: comp.text.tex To: schoepf@sc.ZIB-Berlin.DE Cc: tex-implementors@MATH.AMS.COM Message-ID: <673527232.0.BNB@MATH.AMS.COM> In-Reply-To: <9105061043.AA18374@sc.zib-berlin.dbp.de> Mail-System-Version: i'd like to thank everyone who responded with suggestions on how we can access comp.text.tex. as rainer suggests, there are administrative reasons for not using the ultrix machine. this machine is supposed to be for the use of mathematicians (ams members) to carry on discussions relevant to their mathematical research; use of its resources for things not relevant to the central purpose are discouraged. there seem to be plenty of sources for suitable vms software. our biggest problem is finding a feed; the two most likely sources -- brown university and the university of michigan -- are unsatisfactory; brown is apparently unwilling, and michigan doesn't receive everything we're interested in. so we're still looking. -- bb ------- 9-May-1991 13:54:00-GMT,1398;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23576; Thu, 9 May 91 07:53:56 MDT Date: Thu 9 May 91 09:42:09-EST From: Ron Whitney Subject: \newlinechar within \special To: tex-implementors@VAX01.AMS.COM Message-Id: <673796529.0.RFW@VAX01.AMS.COM> Mail-System-Version: Recently I've seen an inconsistency in the way a couple of versions of TeX for the PC handle \newlinechar within \special commands. One (Fuchs, \mu-TeX) gives the same treatment in this case as it does with \write-streams. The others use a more literal interpretation of Knuth's statement on p.228 of The TeXBook regarding what TeX does as it writes out \special information: " TeX doesn't look at the token list to see if it makes sense; the list is simply copied to the output." So if one has \newlinechar=`\^^J, \special{ooh^^Jaah} puts this 9-character sequence into the .dvi file instead of "oohaah". (Of course, the ^^J gets contracted to single token first, then gets blown back up to the 3.) I would have said that \mu-TeX's treatment is the proper one, but perhaps it's understood that the string within the \special is not to be tampered with other than to eat the tokens and then spit them out. Is this an old issue? Is it open to interpretation? ------- 9-May-1991 17:28:51-GMT,1347;000000000001 Return-Path: <@VAX01.AMS.COM:karl@cs.umb.edu> Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24301; Thu, 9 May 91 11:28:45 MDT Received: from cs.umb.edu by VAX01.AMS.COM via SMTP with TCP; Thu, 9 May 91 13:13:58-EDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA08063; Thu, 9 May 91 13:10:27 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA18555; Thu, 9 May 91 13:09:08 EDT Date: Thu, 9 May 91 13:09:08 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9105091709.AA18555@ra.cs.umb.edu> To: RFW@vax01.ams.com Cc: tex-implementors@vax01.ams.com In-Reply-To: Ron Whitney's message of Thu 9 May 91 09:42:09-EST <673796529.0.RFW@VAX01.AMS.COM> Subject: \newlinechar within \special Reply-To: karl@cs.umb.edu ron> I would have said that \mu-TeX's treatment is the proper one, but > perhaps it's understood that the string within the \special is not to > be tampered with other than to eat the tokens and then spit them out. > Is this an old issue? Is it open to interpretation? trip.tex seems not to test this. I guess it's open to interpretation, although Knuth should probably be asked. My personal opinion is that ^^J should get turned into a newline character(s); it's easy to turn this feature off (in fact, I suppose it's off by default in plain), after all. karl@cs.umb.edu 9-May-1991 23:18:31-GMT,1946;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26549; Thu, 9 May 91 17:18:23 MDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Thu, 9 May 91 19:08:53-EDT Received: from phoenix.cambridge.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <28990-0@sun2.nsfnet-relay.ac.uk>; Thu, 9 May 1991 23:53:42 +0100 Date: Thu, 09 May 91 23:54:07 BST From: Chris Thompson To: tex-implementors@math.ams.com Cc: Ron Whitney , Karl Berry Subject: Re: \newlinechar within \special Message-Id: I am afraid that I don't really understand what the postings by Ron Whitney and Karl Berry are saying. The suitably processed token list in a \special ends up in the DVI file. So what does it mean to replace characters equal to \newlinechar in this conext by "newline"? What or whose "newline"? DVI files aren't text files. And if you are going to say "ASCII CR, of course" or "ASCII LF, of course", be prepared to fight off the other 50% of the world :-) If you are going to say "should depend on the implementation", then don't: the contents of the DVI file produced are meant to be implementation-independant. Reference-level TeX does not treat characters equal to \newlinechar specially in \special's; they appear unchanged in the DVI file. The mechanical reason for this is that although |special_out| writes the token list to the string pool (|selector:=new_string|), the special treatment of \newlinechar in TeX sections 58--60 only applies when |selector Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29096; Fri, 10 May 91 09:20:50 MDT Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Fri, 10 May 91 11:09:46-EDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA24211; Fri, 10 May 91 17:09:15 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA03249; Fri, 10 May 91 17:09:12 +0200 Date: Fri, 10 May 91 17:09:12 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9105101509.AA03249@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: TEX-IMPLEMENTORS@MATH.AMS.COM Cc: PZF5HZ@RUIPC1E.BITNET In-Reply-To: MITTELBACH FRANK's message of 05/10/91 15:42:35 GMT+1 <9105101457.AA22827@ufer.ZIB-Berlin.DE> Subject: RE: RE: \NEWLINECHAR WITHIN \SPECIAL and \message Frank writes: I think that Chris remark that dvi files are to be device independent is questionable as far as specials are concerned. In fact the special is supposed to pass some string to the dvi driver and this means that this program is supposed to understand it. Now this means that the driver needs to interprete the bytes inside the special in the same way as the TeX that writes them out. But if we assume that this is done under some ascii conversion table then why not accept ascii . Not that I see many applications for this. Do I miss something? Yes, you do--at least as far as the new line character is concerned. The point here is that normally the meaning of the \newlinechar is "TeX's internal end-of-line marker", full stop. When writing to a text file (irregardless of the code table) this has a definite meaning, namely: start a new line here, full stop. When it comes to \specials, the notion of "lines" seems at least questionable, even more since the sequence of characters inside a \special need not be anything legible. \specials are device-dependent, true. But the consequence of your argumentation is that the same device (say, a PostScript printer) would see a different command on a Unix workstation and an IBM mainframe. Keep in mind that the \special string is not written under the control of the character conversion tables. The whole discussion reminded me of some related business with the newline char of TeX which I think is a bug although one can surely plea for a questionable feature. Compare the output of \newlinechar=`\@ \message{foo@bar} to \newlinechar=`\^^J \message{foo^^Jbar} The first message is broken into two lines the second comes out as is. New, this is something different, since it applies to text files where (as I said above) the notion of "start a new line here" is perfectly sensible. In my eyes this is a bug and should be fixed, even if this behaviour is in conformance with the TeXbook. Rainer Sch\"opf 10-May-1991 18:01:29-GMT,2010;000000000001 Return-Path: <@MATH.AMS.COM,@pucc.PRINCETON.EDU:WSULIVAN@IRLEARN.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05017; Fri, 10 May 91 12:01:25 MDT Message-Id: <9105101801.AA05017@math.utah.edu> Received: from pucc.PRINCETON.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 10 May 91 13:49:49-EDT Received: from IRLEARN.UCD.IE by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7491; Fri, 10 May 91 13:47:27 EDT Received: by IRLEARN (Mailer R2.07) id 0311; Fri, 10 May 91 18:44:51 GMT Date: Fri, 10 May 91 18:11:33 GMT From: "Wayne G. Sullivan" Subject: EOL in messages etc. To: tex-implementors@math.ams.com ^^J in \message does not work because \message expands the string before printing it, so the character ASCII 10 becomes ^^J in most implementations. I suspect Knuth did this because he expected messages to be short. For longer 'messages' one can use \immediate\write16, which allows one to write multiple lines using ^^J as a new line character if desired. For error messages of several lines one could combine \write16's with a final error message, or better, put the extra junk in \errhelp (which will also do new lines with ^^J) rather than overburden the user with verbose error messages. \special may be used for many purposes: the user should conform to the existing syntax rather than expect \special to be designed for a particular application. Since the data from the DVI file must be processed anyway, the DVI device driver can be made to convert the sequence ^^J into whatever end-of-line indicator is used by the target device. No doubt some users would like to be able to embed entire PostScript files as \special's, but doesn't it make more sense simply to give the file name? TeX does have many idiosyncrasies, but none of them seems to me to be half so stupid as the multiplicity of ASCII end-of-line conventions ^^M ^^J ^^M^^J^^Z Wayne Sullivan 15-May-1991 7:10:10-GMT,1223;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25703; Wed, 15 May 91 01:10:08 MDT Received: from DHDURZ1 (MAILER@DHDURZ1) by CC.UTAH.EDU with PMDF#10043; Wed, 15 May 1991 01:09 MST Received: by DHDURZ1 (Mailer R2.07) id 2335; Wed, 15 May 91 09:06:40 CET Date: Wed, 15 May 91 08:56:48 EDT From: Gaulle Bernard Subject: ECM incompatibles with TRUETYPE Sender: TeX-Character-Set Mailing list To: "Nelson H.F. Beebe" Reply-To: TeX-Character-Set Mailing list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: LSV IMPLEM , LSV TUG , LSV TEXCHAR Yannis Haralambous sent me a message saying that TRUETYPE fonts require that the lowest 32 chars be left free. So there is a major problem with the future ECM fonts (actually DCM) we designed without any space left. As this information is a serious one at my point of view, i have decided to forward the problem to this list. May be, solutions will arise. Regards, Bernard GAULLE 15-May-1991 9:40:16-GMT,1746;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:gtoal@tardis.computer-science.edinburgh.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB25952; Wed, 15 May 91 03:40:12 MDT Message-Id: <9105150940.AB25952@math.utah.edu> Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 15 May 91 03:40:36-EDT Received: from tardis.computer-science.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <3060-0@sun2.nsfnet-relay.ac.uk>; Wed, 15 May 1991 08:37:42 +0100 Date: Wed May 15 07:48:29 GMT 1991 To: tex-implementors <@nsfnet-relay.ac.uk:tex-implementors@math.ams.com> Subject: Font layout (truetype) From: gtoal@tardis.computer-science.edinburgh.ac.uk I have exactly the same problem on the Acorn Archimedes (which has a font system like truetype (actually we've had it for years, and it's better and faster ;-) ) and I've had to get the dvi previewer to map all the characters in the range 0..31 to 128..128+31 - and just to be awkward 127 has to be remapped too (or it'll delete the last character output - setting TeX fonts is as simple as printing the text to the normal output stream) This is OK, but 256-element fonts won't work - so when I get around to implementing them I'll have to do so by splitting each font into two 128-element fonts. I suspect you'll have to do this too (assuming you can remap your fonts - or are you stuck with them?) Oh - of course, you mean ECM -> Extended Computer Modern. Right - well that solution will work. Just out of interest, how are you converting your ecm fonts to truetype outlines? When we did it it was a bit of a bodge to do with tracing large bitmaps. Very expensive... (took a few weeks) Graham 22-May-1991 15:51:43-GMT,1825;000000000001 Return-Path: <@MATH.AMS.COM,@niord.shsu.edu:bed_gdg@Niord.SHSU.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22857; Wed, 22 May 91 09:51:36 MDT Received: from niord.shsu.edu by MATH.AMS.COM via SMTP with TCP; Wed, 22 May 91 11:34:00-EDT Received: by Niord.SHSU.edu (MX V2.3) id 21580; Wed, 22 May 1991 10:29:54 CDT Date: Wed, 22 May 1991 10:29:54 CDT From: "George D. Greenwade" To: NORM@IONAACAD.BITNET Cc: TeX-implementors@math.ams.com Message-Id: <00948FA8.6432B6E0.21580@Niord.SHSU.edu> Subject: RE: PKtoSFP and SFPtoPK This is forwarded to TeX-implementors from a post on INFO-TeX. I thought it meritorious of this group since the implementors of TeX are here and thought it might interest the group. Sorry, but I don't know how many of this subscriber base is on INFO-TeX, nor who exactly who does and who does not get comp.text.tex (and since we still don't have a reliable connection to comp.text.tex fully in place, I cannot otherwise verify that it fully made it there -- assume, yes; verify, no). George -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Date: Wed, 22 May 1991 10:43 EDT From: Norman Walsh Subject: PKtoSFP and SFPtoPK To: INFO-TEX@SHSU.BITNET Greetings, I have just finished two TeX related programs that I think might have general interest. They convert HP softfont files into TeX PK files and vice-versa. If anyone is interested in trying them, please send me a note and I'll ship them out to you. As soon as a few people have tried them and (hopefully) not reported any errors, I'll make an effort to see that they get placed on the various archive servers. Take care, norm 23-May-1991 16:51:53-GMT,1420;000000000001 Return-Path: <@MATH.AMS.COM,@ifi.informatik.uni-stuttgart.de:mattes@azu.informatik.uni-stuttgart.de> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29444; Thu, 23 May 91 10:51:45 MDT Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.COM via SMTP with TCP; Thu, 23 May 91 12:20:44-EDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Thu, 23 May 91 18:19:02 +0200 From: Eberhard Mattes Date: Thu, 23 May 91 18:19:06 +0200 Message-Id: <9105231619.AA19510@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Thu, 23 May 91 18:19:06 +0200 To: tex-implementors@math.ams.com Subject: dek's Fixed-point Glue Setting TUGboat Vol. 3 No. 1, pp. 10 (`[Subject] An Example of WEB') describes a program for fixed-point glue setting. When fed with the values 300000 314 199686 0 it displays Test data set number 1: Glue ratio is 0.7500 (2,12,12288) 314 234 199686 149763 Totals 200000 149997 (versus 300000) which is off by a factor of two (glue ratio & 2nd column). Is this a known (and fixed?) bug or a typo (is there an electronical version of that program?) or a bug in my Pascal compiler? Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) 23-May-1991 17:13:18-GMT,956;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29567; Thu, 23 May 91 11:13:15 MDT Date: Thu 23 May 91 13:03:20-EST From: bbeeton Subject: Re: dek's Fixed-point Glue Setting To: mattes@azu.informatik.uni-stuttgart.de Cc: tex-implementors@MATH.AMS.COM Message-Id: <675018200.0.BNB@MATH.AMS.COM> In-Reply-To: <9105231619.AA19510@azu.informatik.uni-stuttgart.de> Mail-System-Version: the entire example program listing was provided to tugboat in the form of camera copy, and we do not have the web input. however, the sail system (the dec-10 system on which tex was originally developed is still (amazingly) running (it will be unplugged on june 7, after 25 years, with, reportedly, great ceremony), and there may be just one last chance to find the original file. i am forwarding the inquiry to dek. -- bb ------- 29-May-1991 23:33:46-GMT,2387;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11818; Wed, 29 May 91 17:33:42 MDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 29 May 91 19:23:00-EDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 29 May 91 19:23:58-EDT Received: from phoenix.cambridge.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <17725-0@sun2.nsfnet-relay.ac.uk>; Wed, 29 May 1991 17:09:21 +0100 Date: Wed, 29 May 91 17:11:28 BST From: Chris Thompson To: tex-implementors@math.ams.com Subject: Re: dek's glue.web Message-Id: Inspecting the file GLUE.WEB that Barbara posted here, I am reminded of a niggle I have about MF.WEB. Because standard Pascal has no shift operators, an array |two_to_the| is used to hold powers of two. If one has an extended Pascal that does support shifts, then there is an obvious optimisation that replaces |x*two_to_the[k]| by |x<>k| (for positive |x|). Such a tranformation is beyond the power of TANGLE; however, if the WEB source were to use macros |left_shift(x)(k)| and |right_shift(x)(k)|, with default definitions in terms of multiplication and division by elements of of |two_to_the|, then such a systematic transformation would be easy by redefining them. In MF.WEB, multiplication and division by elements of |two_to_the| is used only in a few places, and probably none of these are very significant in performance terms. On the other hand, in GLUE.WEB, particularly when transplanted into TeX, this transformation would have a considerable impact. As the algorithm is so clearly designed for machines with the arithmetic capabilities of 68000s (16x16->32 multiply; 32/16->16 divide; variable shifts) it seems a pity that it should be presented in a way that requires so much hand modification to put it into this form. There is a |two_to_the| array in GFTODVI.WEB as well, but it is not used for multiplication or division. On some machines it may be faster to use |if x > (1< two_to_the[k] then ...|, but this is a second-order niggle. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk 4-Jun-1991 21:12:47-GMT,3122;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PEB@DM0MPI11.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13815; Tue, 4 Jun 91 15:12:41 MDT Message-Id: <9106042112.AA13815@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Tue, 4 Jun 91 16:24:35-EDT Received: from DM0MPI11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3591; Tue, 04 Jun 91 16:21:34 EDT Received: from DM0MPI11 (PEB) by DM0MPI11 (Mailer R2.08) with BSMTP id 9238; Tue, 04 Jun 91 20:06:38 GMT Date: Tue, 04 Jun 91 19:25:17 GMT From: Peter Breitenlohner Organization: Max-Planck-Institut fuer Physik, Muenchen Subject: Re: portability of binary files To: Tex-implementors@math.ams.com Two days ago Rainer Schoepf said: ........ >systems (e.g., record structured vs. stream). But binary files tend to >be non-portable anyway... ........ This is precisely not true for most TeX-related binary files. I have invested some effort in order that the VM/CMS versions of TeX, MF, GFtoPK, DVItype, & Co. can read .gf, .pk, .tfm, .vf, and .dvi files in practically all formats realizable with the CMS file system, regardless whether they were created by these VM/CMS versions (all except .tfm with fixed records of length 1024, and standard padding) or transfered via FTP (or Kermit or You_Name_It): typically variable records with maximum length (of real data) 512, or 8192, or 256, or ... with the last record shorter or even each record with a different length. Since this was done we have no problems whatsoever with such binary files and FTP VM=>DOS, or VM<=DOS, or ... I have done this because it was, in my opinion, an absolute necessity. The effort to achieve this was only moderaty: (1) think once how to do it, (2) some `system-dependent-changes' in all programs, these are however very similar in most cases, and (3) possibly a marginal loss in cpu performance. One drawback is very VM specific: you can't do `random-reading' unless the records have a fixed length and this length as well as the total number of records are known to the program. In practice this means no random-reading: a minor point in DVItype but a nuisance in GFtoPK (one has to read through the whole file once to find the postamble and a second time to process the character definitions). The gain is an enormous increase in human productivity: e.g., run TeX and preview on a PC, transfer the dvi file to the mainframe and have it printed on a laser printer. I would strongly recommend that the implementors on other systems would do something similar where ever necessary. Then the TeX-related binary files would be portable in practice and not only in principle. Given the very accurate description of every bit in these files it sounds ridiculous that `a .dvi file can't be tranfered from this to such system because the file structures are incompatible', as all of us have already heared once too often. What else could be more different than the CMS and DOS/Unix file structures? (I am talking of file contents, not file names!) Regards Peter 18-Jun-1991 21:16:31-GMT,2681;000000000001 Return-Path: <@MATH.AMS.COM,@Niord.SHSU.edu:bed_gdg@SHSU.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11801; Tue, 18 Jun 91 15:16:27 MDT Received: from Niord.SHSU.edu by MATH.AMS.COM via SMTP with TCP; Tue, 18 Jun 91 17:07:09-EDT Received: by SHSU.edu (MX V2.3-1) id 23712; Tue, 18 Jun 1991 16:03:59 CDT Date: Tue, 18 Jun 1991 16:03:59 CDT From: "George D. Greenwade" To: TeX-implementors@math.ams.com, goathunter@wkuvx.bitnet Cc: johngalt%uaccit@arizona.bitnet, ted@nieland.dayton.us Message-Id: <0094A50E.8A00A3C0.23712@SHSU.edu> Subject: VMS logicals standardization I believe TeX-implementors is the proper place for this (in addition to the interested parties I have cc'ed). As you are probably aware, we have available for access a few VMS-based TeX tools. I have come across a few questions from around the world of retrievers about the use of logicals for TeX under VMS. I have been having a conversation about this with two of the cc'ed parties (John Galt and Hunter Goatley) and hope to interest Ted Nieland as well for DECUS. The general question has been whether or not there should be a VMS platform-suggested set of TeX logicals. Hunter replied to me: > I think it's a good question. Part of it stems from the fact that there's > the DECUS TeX collection (which uses the TEX_ logicals) and the collection > from Northlake (which uses the TEX$ logicals). Also, the DECUS TeX > collection used to use the TEX$ logicals, a few versions ago. As people > wrote utilities, they wrote them to work with the configuration *they* had, > which may not have been the one most people had. > I think it'd be good to try to bring it up on INFO-TeX---can we standardize > *all* the TeX logicals, or have the programs support both? Might this be implementable? If so, who decides on the standards? I trust that we can promulgate them on INFO-TeX/comp.text.tex and that future DECUS releases could help. And to Ted, couldn't the DECUS collection be a VMSINSTALlable saveset? Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@Niord.SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 18-Jun-1991 21:38:01-GMT,803;000000000001 Return-Path: <@MATH.AMS.COM:karl@cs.umb.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11897; Tue, 18 Jun 91 15:37:58 MDT Received: from cs.umb.edu by MATH.AMS.COM via SMTP with TCP; Tue, 18 Jun 91 17:33:21-EDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA24183; Tue, 18 Jun 91 17:30:46 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA29391; Tue, 18 Jun 91 17:30:33 EDT Date: Tue, 18 Jun 91 17:30:33 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9106182130.AA29391@ra.cs.umb.edu> To: tex-implementors@math.ams.com Subject: TeX logicals and VMS Reply-To: karl@cs.umb.edu It would be even better if the same ``logicals'' (which I take it are morally equivalent to Unix environment variables) were supported between operating systems... 18-Jun-1991 21:57:06-GMT,1208;000000000001 Return-Path: <@MATH.AMS.COM,@Niord.SHSU.edu:bed_gdg@SHSU.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11962; Tue, 18 Jun 91 15:57:02 MDT Received: from Niord.SHSU.edu by MATH.AMS.COM via SMTP with TCP; Tue, 18 Jun 91 17:52:59-EDT Received: by SHSU.edu (MX V2.3-1) id 23854; Tue, 18 Jun 1991 16:44:53 CDT Date: Tue, 18 Jun 1991 16:44:53 CDT From: "George D. Greenwade" To: karl@cs.umb.edu Cc: goathunter@wkuvx1.BITNET, johngalt%uaccit@arizona.bitnet, tex-implementors@math.ams.com Message-Id: <0094A514.4071B5E0.23854@SHSU.edu> Subject: RE: TeX logicals and VMS Karl Berry adds: > It would be even better if the same ``logicals'' (which I take it are > morally equivalent to Unix environment variables) were supported between > operating systems... Well, I would hope so, as well. I was offerring this idea for the operating system I am on simply as a Guinea pig to see if a set of VMS logicals (Unix environments, MS-DOS "set"s, etc.) could be done at all without great fuss. The idea of TeX (pick your favorite appropriate variable) names being system independent is a great idea which could help all! George 18-Jun-1991 22:24:55-GMT,2656;000000000001 Return-Path: <@MATH.AMS.COM:beebe@math.utah.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12060; Tue, 18 Jun 91 16:24:50 MDT Received: from math.utah.edu by MATH.AMS.COM via SMTP with TCP; Tue, 18 Jun 91 18:20:22-EDT Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12050; Tue, 18 Jun 91 16:19:06 MDT Date: Tue, 18 Jun 91 16:19:06 MDT From: Nelson H.F. Beebe To: tex-implementors@math.ams.com Cc: beebe@math.utah.edu X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: standardization of logicals on VMS Message-Id: George Greenwade raises the question of the desirability of standardization of logical names in TeXware and MFware on VAX VMS. This is certainly a reasonable topic for tex-implementors. I confess that on our local VMS systems, I changed the Northlake TEX$ convention to just TEX, bringing it into line with the TOPS-20, MS-DOS, and UNIX conventions. I still think that for broader compability across multiple O/S platforms, the same set of names should be used when possible. Our users have had to deal with TeX on at least 5 major O/Ses, plus several UNIX variants, and gratuitous differences in names are nothing but annoyances. On George's second question, about DECUS TeX and VMS INSTALL, I would suggest that a BACKUP saveset is far easier to deal with. VMS INSTALL has two major flaws in my view: (1) files are first copied onto one area of disk, then copied to their final home, so you need twice the amount of disk, (2) the copying of files in VMS destroys file time stamps, which I consider vital for distinguishing generations of software. I maintain TeX on 4 major OSes, and several varieties of UNIX; the TeX tree is too large to duplicate between systems and run diffs to find out what is different, and NFS mounting of multiple trees is only possible for UNIX and VMS systems under common management, and in any event, only solves the space problem, not the time problem, for generating differences. I therefore insist on keeping time stamps intact, which VMS BACKUP and UNIX tar both provide. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== 19-Jun-1991 3:27:51-GMT,2953;000000000001 Return-Path: <@MATH.AMS.COM,@DAYVB.DAYTON.SAIC.COM:ted@nieland.UUCP> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12920; Tue, 18 Jun 91 21:27:46 MDT Received: from DAYVB.DAYTON.SAIC.COM by MATH.AMS.COM via SMTP with TCP; Tue, 18 Jun 91 23:21:28-EDT Received: from nieland by Dayton.SAIC.COM (MX V2.3-1) with UUCP; Tue, 18 Jun 1991 23:18:27 EDT Received: by nieland.DAYTON.OH.US (V1.13/Amiga) id AA07835; Tue, 18 Jun 91 23:07:28 EDT Date: Tue, 18 Jun 91 23:07:28 EDT Message-Id: <9106190307.AA07835@nieland.DAYTON.OH.US> From: ted@nieland.DAYTON.OH.US To: bed_gdg@SHSU.edu Cc: tex-implementors@math.ams.com Subject: Re: VMS logicals standardization :I believe TeX-implementors is the proper place for this (in addition to the :interested parties I have cc'ed). : :As you are probably aware, we have available for access a few VMS-based TeX :tools. I have come across a few questions from around the world of :retrievers about the use of logicals for TeX under VMS. I have been having :a conversation about this with two of the cc'ed parties (John Galt and :Hunter Goatley) and hope to interest Ted Nieland as well for DECUS. The :general question has been whether or not there should be a VMS :platform-suggested set of TeX logicals. Hunter replied to me: : :> I think it's a good question. Part of it stems from the fact that there's :> the DECUS TeX collection (which uses the TEX_ logicals) and the collection :> from Northlake (which uses the TEX$ logicals). Also, the DECUS TeX :> collection used to use the TEX$ logicals, a few versions ago. As people :> wrote utilities, they wrote them to work with the configuration *they* had, :> which may not have been the one most people had. : The DECUS TeX Collection uses the TEX_ version of logicals, rather than TEX$ (which it did use for a while), in order to meet the Digital 'standards' (Digital reserves the use of logical names with a dollar sign included). Since DECUS tries to work with Digital whenever possible, this was one area that the DECUS implementors had no problem complying with Digital in the spirit of cooperation. :> I think it'd be good to try to bring it up on INFO-TeX---can we standardize :> *all* the TeX logicals, or have the programs support both? : :Might this be implementable? If so, who decides on the standards? I trust :that we can promulgate them on INFO-TeX/comp.text.tex and that future DECUS :releases could help. And to Ted, couldn't the DECUS collection be a :VMSINSTALlable saveset? : I would love to make it VMSINSTALable, but I haven't done a VMSINSTAL kit before and VMSINSTAL has it's days numbered. Also, I have never figured out how to handle certain conditions/set ups for the collection in such a way to automatically install it. I may give it a try on the next release (whenever that is). :Regards, George M. Edward (Ted) Nieland DECUS TeX Collection Editor Ted@NIELAND.DAYTON.OH.US 19-Jun-1991 4:13:46-GMT,4571;000000000001 Return-Path: <@MATH.AMS.COM,@BULLDOG.CS.YALE.EDU:lrw!leichter@LRW.COM> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13054; Tue, 18 Jun 91 22:13:42 MDT Received: from BULLDOG.CS.YALE.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 19 Jun 91 00:08:09-EDT Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Tue, 18 Jun 91 23:57:27 EDT Message-Id: <9106190357.AA02486@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Wed, 19 Jun 91 00:00:28 EDT Date: Wed, 19 Jun 91 00:00:28 EDT From: Jerry Leichter To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: re: TeX logicals and VMS Since most people reading this are likely not to be aware of how naming is typically done on VMS, I thought it might be worth it to explain where the TEX$- and TEX_-style names come from. VMS has a very general notion of logical names. A logical name is just a key into a table of key-value pairs. It is similar to a Unix environment name, except that VMS logical names can have different visibility scopes: Some are system-wide, some are visible to particular groups of users, some are visible throughout an entire job tree (group of processes "under" a single login), and some are local to a particular process. In general, a logical name in a given scope can override a value defined in a broader scope. When a piece of software such as TeX is installed system-wide, a set of system-wide logical names is often associated with it. This avoids having each process know exactly where the files are stored - if they are moved, the logicals can easily be changed. (Similar things are sometimes done on Unix using symbolic links, which VMS doesn't have.) Similarly, appropriate defaults can be provided for parameters specified via logicals. A local definition can override the default. An extraneous logical name can cause problems if it happens to duplicate the name of a file, since it may "hide" the file. Since a VMS system usually has many system-wide logical names defined - my VMS workstation, which has only a few products installed on it, has well over 200! - "namespace pollution" can be a significant problem. To keep it under control (for logical names as well as for other kinds of names), VMS has a series of naming conventions. They all center around the notion of a "facility", which is just some piece of software or group of related pieces of software. There is an office at DEC that registers facility names, both for DEC-developed products and for external developers. When a facility is registered, a short set of "initials" for it, which I'll call "fac", are assigned to it. fac is typically 2-5 letters long; for example, the VAX C compiler uses initials VAXC (and CC, for different things); the VMS Linker uses initials LNK. All logical names using those initials as a prefix are reserved to the facility. Prefixes are used in one of two forms: fac$ is the prefix for a DEC facility, while fac_ is the prefix for an externally-developed facility. Non-DEC people are not supposed to use the fac$ form, but that's a convention that's been ignored by some widely-used products. The obvious "initials" for the "TeX facility" on VMS are TEX. Since TeX is not a DEC product, the "correct" naming convention for TeX-related logicals is TEX_xxx. However, the TEX$xxx logicals have been very widely used, both within and outside of DEC. I don't know whether anyone has ever bothered to officially register a TeX facility, but in practice it really doesn't matter: The uses of TEX as the initials, in both the TEX_ and TEX$ prefix forms, are by now so widespread that it would be foolish for anyone to try to use it for anything else. The use of a system-wide logical like TEXFONTS, which doesn't follow either of these two conventions, is very strongly frowned upon in the VMS world. If there's to be a standard set of logicals on VMS, they really should at least allow for the use of VMS-standard forms. This, of course, runs right into the "consistency" problem, which is unavoidable: Since things are done differently on VMS and Unix, one has a choice between inter- and intra-system consistency. It would certainly be possible for a VMS TeX to check first for the TEXxxx form, then for the TEX_xxx or TEX$xxx form. That way, system-wide definitions could be made that would be consistent with VMS usage, but individual users could still use the forms familiar to them from Unix. Logical names lookups are fast, so performance should not be noticeably affected. -- Jerry 21-Jun-1991 19:00:35-GMT,3497;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29601; Fri, 21 Jun 91 13:00:28 MDT Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 21 Jun 91 14:48:26-EDT Date: Fri, 21 Jun 1991 11:45 PDT From: Don Hosek Subject: Re: VMS logicals standardization To: bed_gdg@SHSU.edu, tex-implementors@math.ams.com Cc: vmstex-l@uicvm.BITNET Message-Id: <46037523C8A04707@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: IN%"bed_gdg@SHSU.edu" X-Vms-Cc: TEX_IMPLEMENTORS, IN%"vmstex-l@uicvm" -Date: Tue, 18 Jun 1991 16:03:59 CDT -From: "George D. Greenwade" -I believe TeX-implementors is the proper place for this (in addition to the -interested parties I have cc'ed). Actually, there is a specialized list for TeX on VMS, vmstex-l@uicvm.uic.edu; to subscribe, send the message SUBS VMSTEX-L to LISTSERV@UICVM.UIC.EDU. You may want to consider moving discussion to that list since the majority of tex-implementors people are not VMSers. -As you are probably aware, we have available for access a few VMS-based TeX -tools. I have come across a few questions from around the world of -retrievers about the use of logicals for TeX under VMS. I have been having -a conversation about this with two of the cc'ed parties (John Galt and -Hunter Goatley) and hope to interest Ted Nieland as well for DECUS. The -general question has been whether or not there should be a VMS -platform-suggested set of TeX logicals. Hunter replied to me: -> I think it's a good question. Part of it stems from the fact that there's -> the DECUS TeX collection (which uses the TEX_ logicals) and the collection -> from Northlake (which uses the TEX$ logicals). Also, the DECUS TeX -> collection used to use the TEX$ logicals, a few versions ago. As people -> wrote utilities, they wrote them to work with the configuration *they* had, -> which may not have been the one most people had. -> I think it'd be good to try to bring it up on INFO-TeX---can we standardize -> *all* the TeX logicals, or have the programs support both? -Might this be implementable? If so, who decides on the standards? I trust -that we can promulgate them on INFO-TeX/comp.text.tex and that future DECUS -releases could help. And to Ted, couldn't the DECUS collection be a -VMSINSTALlable saveset? The nonstandardization of logicals is part of the reason why the latest change files for TeX, MF and BibTeX have all logicals specified in the CLD files. A preferred set of logicals would be a good idea, however. Regarding TeX$ vs. TeX_, the former is specifically disallowed by DEC (use of $ is reserved for DEX layered products) so all logicals should have underscores instead of dollar signs. NLS's TeX has in fact used this for several years and the PD implementations have been coming around since around '88 when I began pushing the switch from Claremont. I seem to remember that I've finally convinced Brian Hamilton Kelly (one of the more prominent holdouts) to switch over, but that might have just been wishful thinking. As for who has the power to promulgate these changes, officially, I guess it would be David Kellerman who is the official VMS TeX site coordinator although Ted Brian and I have formed an unofficial troika maintaining PD VMS through four distributions (ymir, Aston, DECUS and Stanford). -dh 21-Jun-1991 19:00:43-GMT,1207;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB29601; Fri, 21 Jun 91 13:00:36 MDT Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 21 Jun 91 14:59:57-EDT Date: Fri, 21 Jun 1991 11:56 PDT From: Don Hosek Subject: Re: TeX logicals and VMS To: karl@cs.umb.edu, tex-implementors@math.ams.com Message-Id: <47896A3DC8A04707@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: IN%"karl@cs.umb.edu" X-Vms-Cc: TEX_IMPLEMENTORS Date: Tue, 18 Jun 91 17:30:33 EDT From: karl@cs.umb.edu (Karl Berry) -It would be even better if the same ``logicals'' (which I take it are -morally equivalent to Unix environment variables) were supported between -operating systems... Except that VMS has certain standards: logicals begin with the package mnemonic, an underscore (dollar sign for DEC-layered products) and then the specific name. This is could be ignored, but would be close to the moral equivalent of using Unix-style command line switches in VMS. If I wanted Unix-style command line switches I'd be using Unix. -dh 21-Jun-1991 19:09:36-GMT,1774;000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29646; Fri, 21 Jun 91 13:09:33 MDT Date: Fri, 21 Jun 1991 12:07 PDT From: Don Hosek Subject: Re: standardization of logicals on VMS To: beebe@math.utah.edu, tex-implementors@math.ams.com Message-Id: <4914797EC8A04707@HMCVAX.CLAREMONT.EDU> X-Envelope-To: beebe@math.utah.edu X-Vms-To: IN%"beebe@math.utah.edu" X-Vms-Cc: TEX_IMPLEMENTORS -Date: Tue, 18 Jun 91 16:19:06 MDT -From: "Nelson H.F. Beebe" -Our users have had to -deal with TeX on at least 5 major O/Ses, plus several UNIX -variants, and gratuitous differences in names are nothing but -annoyances. How many of your users really switch between different operating systems with any regularity? I heard this argument about keeping Unix-style command-line switches on the Beebe drivers and wasn't convinced then. How many of you have had to try to explain to a non-technical user why they could type dviqms/pages=3:5 to print to the QMS but had to say dvialw -o3:5 to print to the PostScript printer? There's a reason why we don't use the Beebe drivers in Claremont any more. As for naming of logicals, my experience has been that users are barely aware of them, particularly on systems where they don't interface cleanly with the OS. (Try typing dir %texinput to DOS's COMMAND.COM sometime). This leaves system managers and one hopes that they have the intelligence and patience to realize that things will not and should not work identically in two different operating systems. It's far more valuable to blend in with native packages on your OS than to resemble an operating system that might not even exist at your site. -dh 21-Jun-1991 19:34:45-GMT,1914;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29775; Fri, 21 Jun 91 13:34:42 MDT Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 21 Jun 91 15:09:47-EDT Date: Fri, 21 Jun 1991 12:07 PDT From: Don Hosek Subject: Re: standardization of logicals on VMS To: beebe@math.utah.edu, tex-implementors@math.ams.com Message-Id: <4913F7CBA8A04707@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-implementors@math.ams.com X-Vms-To: IN%"beebe@math.utah.edu" X-Vms-Cc: TEX_IMPLEMENTORS -Date: Tue, 18 Jun 91 16:19:06 MDT -From: "Nelson H.F. Beebe" -Our users have had to -deal with TeX on at least 5 major O/Ses, plus several UNIX -variants, and gratuitous differences in names are nothing but -annoyances. How many of your users really switch between different operating systems with any regularity? I heard this argument about keeping Unix-style command-line switches on the Beebe drivers and wasn't convinced then. How many of you have had to try to explain to a non-technical user why they could type dviqms/pages=3:5 to print to the QMS but had to say dvialw -o3:5 to print to the PostScript printer? There's a reason why we don't use the Beebe drivers in Claremont any more. As for naming of logicals, my experience has been that users are barely aware of them, particularly on systems where they don't interface cleanly with the OS. (Try typing dir %texinput to DOS's COMMAND.COM sometime). This leaves system managers and one hopes that they have the intelligence and patience to realize that things will not and should not work identically in two different operating systems. It's far more valuable to blend in with native packages on your OS than to resemble an operating system that might not even exist at your site. -dh 24-Jul-1991 11:29:34-GMT,3503;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07929; Wed, 24 Jul 91 05:29:31 MDT Received: from linus.mitre.org by MATH.AMS.COM via SMTP with TCP; Wed, 24 Jul 91 07:22:44-EDT Return-Path: Received: from celebes.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA26191; Wed, 24 Jul 91 07:20:52 -0400 Posted-Date: Wed, 24 Jul 91 07:20:48 -0400 Received: by celebes.mitre.org (5.61/RCF-4C) id AA17706; Wed, 24 Jul 91 07:20:49 -0400 Message-Id: <9107241120.AA17706@celebes.mitre.org> To: tex-implementors@math.ams.com Cc: ramsdell@linus.mitre.org Subject: Principles for implementors Date: Wed, 24 Jul 91 07:20:48 -0400 From: ramsdell@linus.mitre.org In my use of TeX software, I face two problems that I believe are shared by many TeX users. The problems could be eliminated if TeX implementors adhere to the following two principles: 1) Implementations should be designed to be installed by people with little or no knowledge of TeX. 2) Implementations should allow organization specific extensions. Let me explain the rational for each principle by describing the situation I face at The MITRE Corporation. It happens that nearly all system administrators at MITRE do not use TeX as MITRE has a standard word processor that is adequate for their needs. The mathematicians, of course, prefer TeX. Fortunately, there is one machine on which administrators trusted people like myself, and I took the time to install TeX. Several people developed MITRE layout descriptions so as to quell the complaint that documents produced by TeX did not conform to MITRE standards. While my needs were satisfied, mathematicians using other computers were not. They faced repeating the same process, but the difference in organizational structure made it unlikely that they would be able to install software themselves. Furthermore, the mathematicians' management did not see the need for TeX and did not force the issue. In response, I built ImakeTeX, which automates the installation of TeX on a variety of Unix platforms. Besides making my job easier, it adheres to the above two principles. The result is many more machines at MITRE have TeX. John PS. Think about this: can you imagine giving the current installation instructions for AMSLaTeX to the kind of people that install software on your system? ********************************************************************* ImakeTeX ImakeTeX automates the installation of TeX on machines which run Unix. A major goal of ImakeTeX is that the installer need know very little about TeX. An installer must set a few parameters in a system description file. The description is used to generate tailored makefiles using a simple AWK script. The system was designed to make it easy for organizations to distribute a special version of TeX. For example, at MITRE, various LaTeX style files are automatically installed, as is the METAFONT version of the MITRE logo. One could easily have ImakeTeX generate an executable named etex given Karl Berry's eplain.tex macros. ImakeTeX 2.02 and all the sources needed for TeX 3.14 are available by anonymous FTP from ab20.larc.nasa.gov in the directory /pub/tex. ImakeTeX is in the file imaketex202.tar.Z and the rest of the sources are in the file labrea9103.tar.Z, which is a snapshot of the Labrea sources as of late March 1991. ImakeTeX differs from previous versions in that it translates pascal source using web2c 5.84b. 24-Jul-1991 15:42:30-GMT,1002;000000000001 Return-Path: <@MATH.AMS.COM:karl@cs.umb.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08589; Wed, 24 Jul 91 09:42:27 MDT Received: from cs.umb.edu by MATH.AMS.COM via SMTP with TCP; Wed, 24 Jul 91 11:30:42-EDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA28475; Wed, 24 Jul 91 11:28:59 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA16846; Wed, 24 Jul 91 11:28:16 EDT Date: Wed, 24 Jul 91 11:28:16 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107241528.AA16846@ra.cs.umb.edu> To: ramsdell@linus.mitre.org Cc: tex-implementors@math.ams.com In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 24 Jul 91 07:20:48 -0400 <9107241120.AA17706@celebes.mitre.org> Subject: Principles for implementors Reply-To: karl@cs.umb.edu For what it's worth, the next release of web2c (i.e., Unix TeX) will have a completely revised, and close to automatic, configuration system. I hope to incorporate the best ideas from John's ImakeTeX. 24-Jul-1991 23:54:49-GMT,1036;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:gtoal@tardis.computer-science.edinburgh.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10595; Wed, 24 Jul 91 17:54:45 MDT Message-Id: <9107242354.AA10595@math.utah.edu> Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 24 Jul 91 19:47:49-EDT Received: from tardis.computer-science.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <26949-0@sun2.nsfnet-relay.ac.uk>; Thu, 25 Jul 1991 00:36:26 +0100 Date: Wed Jul 24 23:16:13 GMT 1991 To: tex-implementors <@nsfnet-relay.ac.uk:tex-implementors@math.ams.com> Subject: Change of address Cc: gtoal@nsfnet-relay.ac.uk From: gtoal@tardis.computer-science.edinburgh.ac.uk Sorry - there didn't seem to be a ...-request for this group. gtoal@tardis.cs.ed.ac.uk is no more (after Friday) -- I'm moving to gtoal@ed.ac.uk (which most people mail me as already; this group seems to be the exception which I just spotted today) Thanks Graham 9-Aug-1991 14:39:07-GMT,3225;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09225; Fri, 9 Aug 91 08:39:04 MDT Date: Fri 9 Aug 91 10:32:31-EST From: bbeeton Subject: Quick update on e-math.ams.com To: TeX-implementors@VAX01.AMS.COM Message-Id: <681748351.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 9 August 91 Message No: 031 To: TeX implementors and distributors From: Barbara Beeton Subject: Quick update on e-math.ams.com Within the past few weeks, the e-math archive at AMS has been completely refreshed. Highlights of the update include: - AMS-TeX version 2.1 -- bug fixes and some minor enhancements The file ams/amstex/amstex.bug gives the detail of changes. - AMS-LaTeX version 1.1 -- bug fixes Current versions of the Mittelbach/Schoepf new font selection scheme files are now posted, as well as the reference versions of latex.tex and lplain.tex . The BibTeX style amslpha.bst is now a true "alpha" style, and produces bibliographic input according to AMS style requirements. The file ams/amslatex/amslatex.bug gives the detail of changes. - AMSFonts version 2.1 -- substantial bug fixes, including elimination of the problems that caused the ms* fonts to get different checksums and .tfm dimensions at different resolutions. .mf sources for the AMSfonts are now packaged as a compressed tar file, in ams/amsfonts-sources.tar.Z , in addition to the ordinary ascii .mf files. .pk files are now available in resolutions of 180, 240 and 400dpi in addition to the 118 and 300dpi available previously. - Author guidelines for submitting electronic manuscripts to the AMS using AMS-LaTeX are new. A consistent change to all macro and text files originating at AMS is the installation of new identification blocks, based on the BibTeX format recommended by Nelson Beebe. I have received a note from Don Knuth concerning a bug (in Plain) reported in June: "... the correction will go in officially in fall when I make the next update." I will be out of town from August 15-September 3, and from September 20- October 16. (Among other commitments, I will be attending the TeX91 and Gutenberg meetings in Paris.) I will not be accessible by e-mail during that time, so any messages received then will wait until my return. ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 031 ] ------- 19-Aug-1991 8:59:12-GMT,1264;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11003; Mon, 19 Aug 91 02:59:09 MDT Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Mon, 19 Aug 91 04:50:13-EDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA20210; Mon, 19 Aug 91 10:46:30 +0200 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA12092; Mon, 19 Aug 91 10:46:28 +0200 Date: Mon, 19 Aug 91 10:46:28 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9108190846.AA12092@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA21012; Mon, 19 Aug 91 10:46:25 +0200 Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: lutz@bisun.nbg.sub.org Cc: TeX-Implementors@math.ams.com In-Reply-To: Lutz Birkhahn's message of Thu, 15 Aug 1991 22:21:02 +0200 <9108152021.AA21439@bisun.nbg.sub.org> Subject: Confusion with Pandora fonts Lutz Birkhahn asks about the state of the art for the pandora fonts. May I add the suggestion that these be rearranged according to the 256 character table for TeX fonts? Rainer 20-Aug-1991 1:14:14-GMT,1299;000000000001 Return-Path: <@MATH.AMS.COM,@LINUS.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18228; Mon, 19 Aug 91 19:14:11 MDT Received: from LINUS.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 19 Aug 91 21:11:42-EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01G9KM1VHG0W9PMZVJ@HMCVAX.CLAREMONT.EDU>; Mon, 19 Aug 1991 18:08 PDT Date: Mon, 19 Aug 1991 18:08 PDT From: Don Hosek Subject: Re: Confusion with Pandora fonts To: mackay@manta.cs.washington.edu Cc: tex-implementors@math.ams.com Message-Id: <01G9KM1VHG0W9PMZVJ@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"mackay@manta.cs.washington.edu" X-Vms-Cc: IN%"tex-implementors@math.ams.com" ymir.claremont.edu has a complete and consistent set of files for pandora in [anonymous.tex.mf.pandora]. I believe that I got the files from score shortly before its demise but then again, maybe not. However, pandora is far from being a workable font for anything other than novelty uses. Aside from the issue that it supplies only text characters and is a rather heavy typeface, it is also missing italic corrections which for a font with as strong of a slant as it has gives rather poor results on output. -dh 20-Aug-1991 19:25:23-GMT,796;000000000001 Return-Path: <@MATH.AMS.COM:GUENTHER@TIGGER.CSC.WSU.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23187; Tue, 20 Aug 91 13:25:20 MDT Received: from TIGGER.CSC.WSU.EDU by MATH.AMS.COM via SMTP with TCP; Tue, 20 Aug 91 15:18:37-EDT Date: Tue, 20 Aug 1991 12:11:25 -0700 (PDT) From: GUENTHER@TIGGER.CSC.WSU.EDU (Dean Guenther) Message-Id: <910820121125.1821@TIGGER.CSC.WSU.EDU> Subject: Confusion with Pandora fonts To: TeX-Implementors@math.ams.com X-Vmsmail-To: smtp%"TeX-Implementors@math.ams.com" I seem to recall Neenie saying several years ago (when she did her paper on Pandora) that her intent was to leave the finite version at the University of Washington. I've sent a note to Neenie's sun.com address asking for her input. -- Dean Guenther 24-Jul-1991 11:29:34-GMT,3503;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07929; Wed, 24 Jul 91 05:29:31 MDT Received: from linus.mitre.org by MATH.AMS.COM via SMTP with TCP; Wed, 24 Jul 91 07:22:44-EDT Return-Path: Received: from celebes.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA26191; Wed, 24 Jul 91 07:20:52 -0400 Posted-Date: Wed, 24 Jul 91 07:20:48 -0400 Received: by celebes.mitre.org (5.61/RCF-4C) id AA17706; Wed, 24 Jul 91 07:20:49 -0400 Message-Id: <9107241120.AA17706@celebes.mitre.org> To: tex-implementors@math.ams.com Cc: ramsdell@linus.mitre.org Subject: Principles for implementors Date: Wed, 24 Jul 91 07:20:48 -0400 From: ramsdell@linus.mitre.org In my use of TeX software, I face two problems that I believe are shared by many TeX users. The problems could be eliminated if TeX implementors adhere to the following two principles: 1) Implementations should be designed to be installed by people with little or no knowledge of TeX. 2) Implementations should allow organization specific extensions. Let me explain the rational for each principle by describing the situation I face at The MITRE Corporation. It happens that nearly all system administrators at MITRE do not use TeX as MITRE has a standard word processor that is adequate for their needs. The mathematicians, of course, prefer TeX. Fortunately, there is one machine on which administrators trusted people like myself, and I took the time to install TeX. Several people developed MITRE layout descriptions so as to quell the complaint that documents produced by TeX did not conform to MITRE standards. While my needs were satisfied, mathematicians using other computers were not. They faced repeating the same process, but the difference in organizational structure made it unlikely that they would be able to install software themselves. Furthermore, the mathematicians' management did not see the need for TeX and did not force the issue. In response, I built ImakeTeX, which automates the installation of TeX on a variety of Unix platforms. Besides making my job easier, it adheres to the above two principles. The result is many more machines at MITRE have TeX. John PS. Think about this: can you imagine giving the current installation instructions for AMSLaTeX to the kind of people that install software on your system? ********************************************************************* ImakeTeX ImakeTeX automates the installation of TeX on machines which run Unix. A major goal of ImakeTeX is that the installer need know very little about TeX. An installer must set a few parameters in a system description file. The description is used to generate tailored makefiles using a simple AWK script. The system was designed to make it easy for organizations to distribute a special version of TeX. For example, at MITRE, various LaTeX style files are automatically installed, as is the METAFONT version of the MITRE logo. One could easily have ImakeTeX generate an executable named etex given Karl Berry's eplain.tex macros. ImakeTeX 2.02 and all the sources needed for TeX 3.14 are available by anonymous FTP from ab20.larc.nasa.gov in the directory /pub/tex. ImakeTeX is in the file imaketex202.tar.Z and the rest of the sources are in the file labrea9103.tar.Z, which is a snapshot of the Labrea sources as of late March 1991. ImakeTeX differs from previous versions in that it translates pascal source using web2c 5.84b. 24-Jul-1991 15:42:30-GMT,1002;000000000001 Return-Path: <@MATH.AMS.COM:karl@cs.umb.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08589; Wed, 24 Jul 91 09:42:27 MDT Received: from cs.umb.edu by MATH.AMS.COM via SMTP with TCP; Wed, 24 Jul 91 11:30:42-EDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA28475; Wed, 24 Jul 91 11:28:59 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA16846; Wed, 24 Jul 91 11:28:16 EDT Date: Wed, 24 Jul 91 11:28:16 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107241528.AA16846@ra.cs.umb.edu> To: ramsdell@linus.mitre.org Cc: tex-implementors@math.ams.com In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 24 Jul 91 07:20:48 -0400 <9107241120.AA17706@celebes.mitre.org> Subject: Principles for implementors Reply-To: karl@cs.umb.edu For what it's worth, the next release of web2c (i.e., Unix TeX) will have a completely revised, and close to automatic, configuration system. I hope to incorporate the best ideas from John's ImakeTeX. 24-Jul-1991 23:54:49-GMT,1036;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:gtoal@tardis.computer-science.edinburgh.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10595; Wed, 24 Jul 91 17:54:45 MDT Message-Id: <9107242354.AA10595@math.utah.edu> Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Wed, 24 Jul 91 19:47:49-EDT Received: from tardis.computer-science.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <26949-0@sun2.nsfnet-relay.ac.uk>; Thu, 25 Jul 1991 00:36:26 +0100 Date: Wed Jul 24 23:16:13 GMT 1991 To: tex-implementors <@nsfnet-relay.ac.uk:tex-implementors@math.ams.com> Subject: Change of address Cc: gtoal@nsfnet-relay.ac.uk From: gtoal@tardis.computer-science.edinburgh.ac.uk Sorry - there didn't seem to be a ...-request for this group. gtoal@tardis.cs.ed.ac.uk is no more (after Friday) -- I'm moving to gtoal@ed.ac.uk (which most people mail me as already; this group seems to be the exception which I just spotted today) Thanks Graham 9-Aug-1991 14:39:07-GMT,3225;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09225; Fri, 9 Aug 91 08:39:04 MDT Date: Fri 9 Aug 91 10:32:31-EST From: bbeeton Subject: Quick update on e-math.ams.com To: TeX-implementors@VAX01.AMS.COM Message-Id: <681748351.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 9 August 91 Message No: 031 To: TeX implementors and distributors From: Barbara Beeton Subject: Quick update on e-math.ams.com Within the past few weeks, the e-math archive at AMS has been completely refreshed. Highlights of the update include: - AMS-TeX version 2.1 -- bug fixes and some minor enhancements The file ams/amstex/amstex.bug gives the detail of changes. - AMS-LaTeX version 1.1 -- bug fixes Current versions of the Mittelbach/Schoepf new font selection scheme files are now posted, as well as the reference versions of latex.tex and lplain.tex . The BibTeX style amslpha.bst is now a true "alpha" style, and produces bibliographic input according to AMS style requirements. The file ams/amslatex/amslatex.bug gives the detail of changes. - AMSFonts version 2.1 -- substantial bug fixes, including elimination of the problems that caused the ms* fonts to get different checksums and .tfm dimensions at different resolutions. .mf sources for the AMSfonts are now packaged as a compressed tar file, in ams/amsfonts-sources.tar.Z , in addition to the ordinary ascii .mf files. .pk files are now available in resolutions of 180, 240 and 400dpi in addition to the 118 and 300dpi available previously. - Author guidelines for submitting electronic manuscripts to the AMS using AMS-LaTeX are new. A consistent change to all macro and text files originating at AMS is the installation of new identification blocks, based on the BibTeX format recommended by Nelson Beebe. I have received a note from Don Knuth concerning a bug (in Plain) reported in June: "... the correction will go in officially in fall when I make the next update." I will be out of town from August 15-September 3, and from September 20- October 16. (Among other commitments, I will be attending the TeX91 and Gutenberg meetings in Paris.) I will not be accessible by e-mail during that time, so any messages received then will wait until my return. ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 031 ] ------- 19-Aug-1991 8:59:12-GMT,1264;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11003; Mon, 19 Aug 91 02:59:09 MDT Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Mon, 19 Aug 91 04:50:13-EDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA20210; Mon, 19 Aug 91 10:46:30 +0200 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA12092; Mon, 19 Aug 91 10:46:28 +0200 Date: Mon, 19 Aug 91 10:46:28 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9108190846.AA12092@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA21012; Mon, 19 Aug 91 10:46:25 +0200 Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: lutz@bisun.nbg.sub.org Cc: TeX-Implementors@math.ams.com In-Reply-To: Lutz Birkhahn's message of Thu, 15 Aug 1991 22:21:02 +0200 <9108152021.AA21439@bisun.nbg.sub.org> Subject: Confusion with Pandora fonts Lutz Birkhahn asks about the state of the art for the pandora fonts. May I add the suggestion that these be rearranged according to the 256 character table for TeX fonts? Rainer 20-Aug-1991 1:14:14-GMT,1299;000000000001 Return-Path: <@MATH.AMS.COM,@LINUS.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18228; Mon, 19 Aug 91 19:14:11 MDT Received: from LINUS.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Mon, 19 Aug 91 21:11:42-EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01G9KM1VHG0W9PMZVJ@HMCVAX.CLAREMONT.EDU>; Mon, 19 Aug 1991 18:08 PDT Date: Mon, 19 Aug 1991 18:08 PDT From: Don Hosek Subject: Re: Confusion with Pandora fonts To: mackay@manta.cs.washington.edu Cc: tex-implementors@math.ams.com Message-Id: <01G9KM1VHG0W9PMZVJ@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"mackay@manta.cs.washington.edu" X-Vms-Cc: IN%"tex-implementors@math.ams.com" ymir.claremont.edu has a complete and consistent set of files for pandora in [anonymous.tex.mf.pandora]. I believe that I got the files from score shortly before its demise but then again, maybe not. However, pandora is far from being a workable font for anything other than novelty uses. Aside from the issue that it supplies only text characters and is a rather heavy typeface, it is also missing italic corrections which for a font with as strong of a slant as it has gives rather poor results on output. -dh 20-Aug-1991 19:25:23-GMT,796;000000000001 Return-Path: <@MATH.AMS.COM:GUENTHER@TIGGER.CSC.WSU.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23187; Tue, 20 Aug 91 13:25:20 MDT Received: from TIGGER.CSC.WSU.EDU by MATH.AMS.COM via SMTP with TCP; Tue, 20 Aug 91 15:18:37-EDT Date: Tue, 20 Aug 1991 12:11:25 -0700 (PDT) From: GUENTHER@TIGGER.CSC.WSU.EDU (Dean Guenther) Message-Id: <910820121125.1821@TIGGER.CSC.WSU.EDU> Subject: Confusion with Pandora fonts To: TeX-Implementors@math.ams.com X-Vmsmail-To: smtp%"TeX-Implementors@math.ams.com" I seem to recall Neenie saying several years ago (when she did her paper on Pandora) that her intent was to leave the finite version at the University of Washington. I've sent a note to Neenie's sun.com address asking for her input. -- Dean Guenther 11-Sep-1991 9:33:03-GMT,1563;000000000001 Return-Path: <@VAX01.AMS.COM,@ruuinf.cs.ruu.nl:piet@cs.ruu.nl> Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03227; Wed, 11 Sep 91 03:32:59 MDT Received: from ruuinf.cs.ruu.nl by VAX01.AMS.COM via SMTP with TCP; Wed, 11 Sep 91 05:27:19-EDT Received: from gnu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA23365; Wed, 11 Sep 91 10:55:22 +0100 Received: by alchemy.cs.ruu.nl (15.11/15.6) id AA17763; Wed, 11 Sep 91 11:23:50 met Date: Wed, 11 Sep 91 11:23:50 met From: Piet van Oostrum Message-Id: <9109110923.AA17763@alchemy.cs.ruu.nl> To: bbeeton Cc: TeX-implementors@VAX01.AMS.COM Subject: Re: Quick update on e-math.ams.com References: <681748351.0.BNB@MATH.AMS.COM> >>>>> bbeeton (BB) writes: BB> Date: 9 August 91 Message No: 031 BB> To: TeX implementors and distributors BB> From: Barbara Beeton BB> Subject: Quick update on e-math.ams.com BB> - AMSFonts version 2.1 -- substantial bug fixes, including elimination BB> of the problems that caused the ms* fonts to get different checksums BB> and .tfm dimensions at different resolutions. Someone on this side of the ocean noticed that the ftm files have not been updated. Is this an omission or didn't they change? Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') 11-Sep-1991 14:53:42-GMT,879;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05473; Wed, 11 Sep 91 08:53:35 MDT Date: Wed 11 Sep 91 10:37:36-EST From: bbeeton Subject: Re: Quick update on e-math.ams.com To: piet@cs.ruu.nl Cc: tex-implementors@MATH.AMS.COM Message-Id: <684599856.0.BNB@MATH.AMS.COM> In-Reply-To: <9109110923.AA17763@alchemy.cs.ruu.nl> Mail-System-Version: piet van oostrum asks about the status of the .tfm files on e-math.ams.com. i have just checked. all of them are dated june 25, and ralph youngen has verified that they are all current for amsfonts version 2.1. this is exactly the same situation in effect on august 9 when i checked before sending the first message to tex-implementors. so i really don't understand the problem. -- bb ------- 11-Sep-1991 14:53:46-GMT,1569;000000000001 Return-Path: <@MATH.AMS.COM,@ruuinf.cs.ruu.nl:piet@cs.ruu.nl> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB05473; Wed, 11 Sep 91 08:53:43 MDT Received: from ruuinf.cs.ruu.nl by MATH.AMS.COM via SMTP with TCP; Wed, 11 Sep 91 10:45:16-EDT Received: from gnu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA29940; Wed, 11 Sep 91 16:13:06 +0100 Received: by alchemy.cs.ruu.nl (15.11/15.6) id AA27397; Wed, 11 Sep 91 16:41:40 met Date: Wed, 11 Sep 91 16:41:40 met From: Piet van Oostrum Message-Id: <9109111441.AA27397@alchemy.cs.ruu.nl> To: bbeeton Cc: tex-implementors@MATH.AMS.COM Subject: Re: Quick update on e-math.ams.com References: <9109110923.AA17763@alchemy.cs.ruu.nl> <684599856.0.BNB@MATH.AMS.COM> >>>>> bbeeton (BB) writes: BB> piet van oostrum asks about the status of the .tfm files on BB> e-math.ams.com. BB> i have just checked. all of them are dated june 25, and BB> ralph youngen has verified that they are all current for BB> amsfonts version 2.1. BB> this is exactly the same situation in effect on august 9 when BB> i checked before sending the first message to tex-implementors. BB> so i really don't understand the problem. Sorry, I think I wasn't clear enough. Actually I got the question from someone else and did not understand it properly. The person noticed that the msbm*.tfm files were identical to the 2.0 version. Is that incidental or were they not updated? Thanks and regards, Piet van Oostrum 11-Sep-1991 18:41:52-GMT,1842;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB07070; Wed, 11 Sep 91 12:41:49 MDT Date: Wed 11 Sep 91 14:25:04-EST From: bbeeton Subject: Re: Quick update on e-math.ams.com To: piet@cs.ruu.nl Cc: tex-implementors@MATH.AMS.COM Message-Id: <684613504.0.BNB@MATH.AMS.COM> In-Reply-To: <9109111441.AA27397@alchemy.cs.ruu.nl> Mail-System-Version: i've checked out the msbm*.tfm files for both versions 2.0 and 2.1. they are indeed the same, but that is coincidental. here's why. the problems that were fixed with v.2.1 were of the following sorts: - the number of distinct heights and depths per font exceeded the allowable number (16); this resulted in different roundoff effects when one font was generated for different magnifications or resolutions, and consequently different checksums. however, since the .tfm file distributed with v.2.0 was the one generated with the mag1000/300dpi version, and the changes necessary to force the rounding of heights and depths to fall within the acceptable limits affected neither the assignment of particular h/d or checksum in the "base" version, the old and new .tfm files are the same. - at very low resolutions, there were cases in which metafont reported paths which crossed, and some of the shapes were nearly unrecognizable. again, the modifications to the code to fix these path errors had no effect on the metrics or the checksum, hence no differences in the msbm*.tfm files. if they were checked, there are sure to be differences in the euler and cmbsy fonts' .tfm files. but, to repeat, there is no cause for concern in the similarity of the msbm*.tfm files. (but it never hurts to check.) -- bb ------- 12-Sep-1991 16:36:19-GMT,8193;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM ([130.44.1.5]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15366; Thu, 12 Sep 91 10:34:43 MDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Thu, 12 Sep 91 12:24:19-EDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Thu, 12 Sep 91 12:25:42-EDT Received: from phoenix.cambridge.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <18797-0@sun2.nsfnet-relay.ac.uk>; Thu, 12 Sep 1991 17:06:50 +0100 Date: Thu, 12 Sep 91 17:09:22 BST From: Chris Thompson To: tex-implementors@math.ams.com Cc: Piet van Oostrum Subject: State of AMSFonts 2.1 Message-Id: Piet's recent postings reminded me that I meant to send a summary of the differences between AMSFonts 2.0 and AMSFonts 2.1 back in July, but for some reason this didn't happen :-) You many recall that I had some fairly strong words to say about AMSFonts 2.0 (posting to tex-implementors of 30 Oct 90). I am glad to be able to report that the state of AMSFonts 2.1 is vastly better. I can find no inconsistencies in the TFM files depending on mode/mag (as was the case for msam#) nor between the distributed TFM files and those generated from the MF source (as was the case for the Euler fonts) There are some remaining problems, which I will describe below. I have reported them to Ralph Youngen, who assures me that they will get fixed in AMSFonts 2.2: there is no reason why the fixes should involve changing the TFM files (except in a trivial way, in the case of msbm#). First, the differences between 2.0 and 2.1, with particular emphasis on the TFM files (ams/amsfonts/READ.ME and ams/amsfonts/sources/READ.ME are required reading here): CYRILLIC: no changes to the sources (subsequent to the fixes in the summer of 1990) other than the addition of the BibTeX-style headers and the addition of "V2.1" tag to the "font_identifier"s. The changes in the header sections caused by the latter are the only changes to the TFM files. EXTRACM: As for the cyrillic fonts, but there are also some tweaks to the parameters in cmex9.mf. The TFM file is not affected by these (and the bitmaps only at very high resolutions). SYMBOLS: The sources have changed substantially. One no longer gets the plethora of errors that one was supposed to "ignore", at least at resolutions of 200dpi upwards. The bitmaps have changed here and there; I haven't made a systematic study of this. The TFM files for msam# are no longer have variable heights and depths depending on the mode/mag; moreover the widths (and therefore checksums) are unaltered from 2.0. The TFM files for msbm# are completely unaltered: not even a "V2.1" tag in the header; this is a bugette (see below). EULER: This is the location of the most serious incompatibilities between 2.0 and 2.1, but this was probably inevitable given the previous state. All the TFM files have changed widths and checksums (as well as other things), *except* for eufm10, eurm10, eusm10 (only 10pt, and *not* the bold versions) and all the euex# fonts. In these cases the only changes in the TFM files are the "V2.1" in the header. The following are the outstanding problems I mentioned above and have reported to Ralph Youngen. (I omit a couple of niggles about some aspects of the source files.) 1. Bad "chardx" values in the SYMBOLS fonts. The GF (or PK) files for the msam# and msbm# fonts contain "chardx" values for several characters that are completely spurious (they bear no relationship to the TFM width of the character, and have no consistency between fonts, modes, or magnifications). This will affect the positioning of such characters by DVI drivers that use this information: the discrepancy should be no more than "maxdrift" for drivers that use "DVItype rules". The characters involved are: msam# fonts: "2C, "39, "4B, "4C msbm# fonts: "41 to "5A inclusive, "7C (all those in xbcaps.mf) The problem is caused by the lack of any call to |adjust_fit|, or equivalent, in the definitions of these characters. Because these fonts use the macros of cmbase.mf, such a call is required in order to set the internal quantities l and r; otherwise these remain set to left-over values from the previous character, and subsequently at |endchar| time the calculation r:=r+shrink_fit; w:=r-l; leads to meaningless values of w (and thus chardx). In the msbm# fonts one can observe that the spurious "chardx" values for the blackboard bold capitals A to Z form an arithmetic progression, whose common difference is itself the value of |shrink_fit| left over from a previous character! 2. Bad (but not so bad) "chardx" values in the EULER fonts. Prompted by the above discovery, I thought I ought to check the Cyrillic and Euler fonts for similar problems. I can find no problem in the former, but several characters in the Euler fonts have "chardx" values several pixels larger than their scaled TFM widths: eurb# fonts: "00, "54, "56, "57, "59 eurm# fonts: "00, "50, "54, "56, "57, "59 eusb# fonts: "54 eusm# fonts: "46, "48, "4E, "54 These are, in fact, precisely the characters that have calls of |mathcorr| in their definition, which is defined in eubase.mf as def mathcorr(expr subwidth_sharp) = % DEK charic:=subwidth_sharp; charwd:=charwd-charic; enddef; However, "chardx" has been set according to the value of "charwd" before this adjustment: I suspect that a resetting of "chardx" in |mathcorr| is required. 3. Short header section in msbm#.tfm files. The TFM files for the msbm# fonts, both those at e-math and those I generate here, have only the minimal 2-word header section. (I noticed this because I didn't find the expected mismatch with the 2.0 TFM files due to the appending of "V2.1" to the |font_identifer|!) This is because the "bye" at the end of amsyb.mf is never reached; instead the "end" at the end of xbbold.mf is executed. Getting the longer headers in any case depends on having a redefinition of "bye" along the lines of pp.320-321 of the METAFONTbook, of course. As regards the potential impact of the bad chardx values, I will quote parts of a message I sent to Ralph: The potentially most serious [bugs] are the chardx ones, but it is difficult to know how serious. You are right in assuming, I think, that any DVI driver that uses chardx values at all will implement at least an approximation to "DVItype rules", and use a |max_drift| to limit discrepacies. (|max_drift| was introduced in DVItype 2.6, in June 1984, so anyone copying DVItype has had since then!) In DVItype itself, max_drift is set to 2 pixels, but larger values at high resolutions would not be unreasonable. Because the offending characters in the msam# and msbm# fonts have such completely bogus chardx values, the whole of max_drift is likely to be used up at once. As these characters will be used almost exclusively in math mode, probably the most visible irregularities will occur in the positioning of superscripts and subscripts applied to them, as there will be insufficient horizontal spacing to "reset" the hh vs. h error. (I have doubts about the value of the "prefered width" mechanism in the typesetting of math mode in any case, despite its benefits for running text. Of course, a DVI driver can't distinguish math mode from horizontal mode.) The fact that you haven't received any complaints about positioning of the characters may mean (1) the ways the fonts are used means that positioning is nearly always reset after the character anyway, (2) that most drivers don't use the chardx values, or (3) people aren't fussy enough about the appearance of their output! I'll think about consulting the tex-implementors list w.r.t. point (2). Well, now I have! Comments? Chris Thompson Cambridge University Computing Service JANET: cet1@uk.ac.cam.phx Internet: cet1@phx.cam.ac.uk 12-Sep-1991 19:17:07-GMT,1982;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16762; Thu, 12 Sep 91 13:16:58 MDT Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 12 Sep 91 15:06:54-EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GAHS9UIJO09JD945@HMCVAX.CLAREMONT.EDU>; Thu, 12 Sep 1991 12:02 PDT Date: Thu, 12 Sep 1991 12:02 PDT From: Don Hosek Subject: Can anybody explain this? To: tex-implementors@math.ams.com Message-Id: <01GAHS9UIJO09JD945@HMCVAX.CLAREMONT.EDU> X-Vms-To: TEX_IMPLEMENTORS In article <9109120247.AA02911@triples.math.mcgill.ca>, barr@TRIPLES.MATH.MCGILL.CA writes: > This is as good a place as any to clear up a > misunderstanding. At least, I misuderstood. TeX will hyphenate a word > that contains an accent; it just won't hyphenate a word _after_ an > accent. Try \showhyphens{universit\'e \'education} to see this. I have > just read the second paragraph on page 454 of the BOOK where this is > supposedly explained and, I must say, even after knowing what happens, I > find this point unclear. After reading this, I thought that it seemed kind of strange that TeX would claim behaviour like this which I'd never seen, so I did an experiment: |*\showhyphens{universit\'e} | |Underfull \hbox (badness 10000) detected at line 0 |[] []\tenrm uni-ver-sit^^Se | |*\hsize=0pt | |*universit\'e | |*\par | |Overfull \hbox (62.30563pt too wide) detected at line 0 |[][]\tenrm universit^^Se | A bit of inconsistency in finding break points, eh? The \showhyphens output seems consistent with the Appendix H description of what TeX calls a word while the \hsize=0pt paragraph corresponds to my experience. Anyone care to take a shot at an explanation? -dh -- Don Hosek dhosek@ymir.claremont.edu Quixote Digital Typography 714-621-1291 12-Sep-1991 19:27:39-GMT,4718;000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16809; Thu, 12 Sep 91 13:26:24 MDT Received: by SHSU.edu (MX V2.3-1) id 28051; Thu, 12 Sep 1991 14:25:48 CDT Date: Thu, 12 Sep 1991 14:25:48 CDT From: "George D. Greenwade" To: WSULIVAN@IRLEARN.UCD.IE Cc: tex-archive@math.utah.edu Message-Id: <0094E895.11B19940.28051@SHSU.edu> Subject: RE: file-archives On Thu, 12 Sep 91 09:49:41 GMT, Wayne G. Sullivan posted: > Don Hosek recommends against using a file-archiving program for text files > because of the different ways in which systems handle test files. None the > less, it would be extremely convenient to be able to request a collection > of files, e.g., the Sauter parameterization files, as a single > file-archive. Agreed; there are serious trade-offs. From an ftp perspective, keeping a package or the component parts of a package in one directory makes sense, but a single (preferably compressed) file which includes the complete set is even nicer. > It seems that ZOO is the best candidate for a file-archiving program which > can work under many of the current operating systems. I have seen reports > on an upgrade of ZOO whose compression is comparable with the best > currently available -- I do not yet have this version though. Why not use > this version of ZOO as the basis for a standard file-archive program for > use with TeX? Possibly this is an option. However (and this is a big however), I've yet to see a zoo package for VMS which performs as advertised. Possibly we VMS-heads out here prefer backup savesets so we've just never had anyone willing to devote time to it; possibly in my surfing around the various bandwidths I just haven't found it yet. While zoo may work for the U*ix crowd and be portable to the PC crowd, I've got a platform which (to the best of my current knowledge) isn't supported by any consistent version of zoo. I hope someone will enlighten me and apologies in advance for my ignorance on this (it's gotta be available since everyone says it's so widespread -- or is VMS a dead OS?). > There are other problems: file names, directory structure and encoding for > transmission by mail. And consistent handling of split files. One of my biggest bounce problems on FILESERV is the user who can't get more than 100,000 bytes per message -- so what is the solution? Prior splitting and the hassle of concatenation for everyone or telling a rather large part of the audience out there that you gotta have a mailer/gateway which won't barf on a single file of what I consider to be an otherwise manageable size? Unfortunately, the cost is borne by most everyone as I make every honest attempt to keep files within some size parameter until I find I have to further reduce that parameter. I realize that for purely ftp sites this is trivial; for us (and Don, whose MAILSERV statistics and file splitting design I have never seen, assuming it does split automagically -- need to talk to Don!) handling both sides of archiving is a very real issue. [some topics deleted] > File names and directory structures are beyond simple solutions. Why is this a problem??? If you're talking about padding, encoding, compressing, decompressing, decoding, and depadding based on system type, all you need is one more table lookup! Realistically, how many directory structures exist? Not really all that many! Include in your process information about the OS at the site where the bundling was done, then have it as an equivalency in the table at the site where the unbundling is done. pub/foo/bar.tex is easily [.pub.foo]bar.tex, for example (well, technically [pub.foo]bar.tex, but let's not create root-level directories with this or we'll have a whole lot of system managers unhappy). I know that TGV has some semblance of this type of logic now in place under MultiNet 3.0D, so it's do-able; just hasn't been done! Nelson, do you have any graduate students there at Utah in need of a project? 8-) Regards from the sidelines, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 12-Sep-1991 19:37:15-GMT,1086;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16863; Thu, 12 Sep 91 13:37:12 MDT Date: Thu 12 Sep 91 15:28:45-EST From: bbeeton Subject: Re: Can anybody explain this? To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-implementors@VAX01.AMS.COM Message-Id: <684703725.0.BNB@MATH.AMS.COM> In-Reply-To: <01GAHS9UIJO09JD945@HMCVAX.CLAREMONT.EDU> Mail-System-Version: i am not sure where to look for the documentation on this, but i am quite sure that tex doesn't bother to try to hyphenate the first word on a line. this opinion is informed by the fact that in the geographical section of the math society's membership list, where some location names exceed the column width, the macro code had to be constructed with a forced space (and equal backspace) at the beginning of the field to kick in the hyphenation routine, and a comment documents the requirement. \hsize=0pt is equivalent to this condition, hence no attempt at hyphenation. -- bb ------- 12-Sep-1991 20:19:12-GMT,855;000000000001 Return-Path: <@VAX01.AMS.COM:rokicki@Neon.Stanford.EDU> Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17058; Thu, 12 Sep 91 14:19:09 MDT Received: from Neon.Stanford.EDU by VAX01.AMS.COM via SMTP with TCP; Thu, 12 Sep 91 16:13:24-EDT Received: by Neon.Stanford.EDU (5.61/25-eef) id AA25718; Thu, 12 Sep 91 13:09:57 -0700 Date: Thu, 12 Sep 91 13:09:57 -0700 From: Tomas G. Rokicki Message-Id: <9109122009.AA25718@Neon.Stanford.EDU> To: BNB@MATH.AMS.COM Cc: DHOSEK@HMCVAX.CLAREMONT.EDU, tex-implementors@VAX01.AMS.COM In-Reply-To: bbeeton's message of Thu 12 Sep 91 15:28:45-EST <684703725.0.BNB@MATH.AMS.COM> Subject: Can anybody explain this? TeX only looks for `words' (candidates for hyphenation) after glue; the first word on a line doesn't generally start with glue. -tom 13-Sep-1991 13:53:55-GMT,1631;000000000001 Return-Path: <@MATH.AMS.COM,@sun2.nsfnet-relay.ac.uk:CET1@phoenix.cambridge.ac.uk> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23916; Fri, 13 Sep 91 07:53:51 MDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Fri, 13 Sep 91 09:35:02-EDT Received: from sun2.nsfnet-relay.ac.uk by MATH.AMS.COM via SMTP with TCP; Fri, 13 Sep 91 09:36:46-EDT Received: from phoenix.cambridge.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <9161-0@sun2.nsfnet-relay.ac.uk>; Fri, 13 Sep 1991 12:41:54 +0100 Date: Fri, 13 Sep 91 12:44:23 BST From: Chris Thompson To: tex-implementors@math.ams.com Subject: Re: Can anybody explain this? Message-Id: In-Reply-To: <684703725.0.BNB@MATH.AMS.COM> Barbara writes: > i am not sure where to look for the documentation on this, but > i am quite sure that tex doesn't bother to try to hyphenate the > first word on a line. TeX doesn't usually apply automatic hyphenation to the first word of a *paragraph*, because it does not follow glue (the parindent is an empty box, not kern or glue). Variation on Don Hosek's example: > *\ universit\'e\par > > Overfull \hbox (20.0pt too wide) detected at line 0 > []| > > Overfull \hbox (17.22226pt too wide) detected at line 0 > \tenrm uni-| > > Overfull \hbox (16.69446pt too wide) detected at line 0 > \tenrm ver-| > > Overfull \hbox (15.05557pt too wide) detected at line 0 > \tenrm sit^^Se | Chris Thompson Cambridge University Computing Service JANET: cet1@uk.ac.cam.phx Internet: cet1@phx.cam.ac.uk 13-Sep-1991 15:09:02-GMT,1138;000000000001 Return-Path: <@VAX01.AMS.COM,@UICVM.UIC.EDU:WSULIVAN@IRLEARN.UCD.IE> Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24269; Fri, 13 Sep 91 09:08:57 MDT Message-Id: <9109131508.AA24269@math.utah.edu> Received: from UICVM.UIC.EDU by VAX01.AMS.COM via SMTP with TCP; Fri, 13 Sep 91 10:51:45-EDT Received: from IRLEARN.UCD.IE by UICVM.UIC.EDU (IBM VM SMTP V2R1) with BSMTP id 8303; Fri, 13 Sep 91 09:47:57 CDT Received: from IRLEARN.UCD.IE (WSULIVAN) by IRLEARN.UCD.IE (Mailer R2.08) with BSMTP id 3262; Fri, 13 Sep 91 15:47:35 GMT Date: Fri, 13 Sep 91 15:43:26 GMT From: "Wayne G. Sullivan" Subject: hyphenation in narrow columns To: tex-implementors@VAX01.AMS.COM The difficulty with hyphenation of the first word also arises in macros for margin paragraphs. There is the added complication that a \strut used to achieve correct vertical spacing also inhibits hyphenation, so something like the following is needed: \leavevmode\strut\hskip\z@skip (text) \hskip\z@skip\strut Without the second \hskip\z@skip, the last word of (text) cannot be hyphenated. 25-Sep-1991 11:26:12-GMT,4817;000000000001 Return-Path: <@MATH.AMS.COM,@ifi.informatik.uni-stuttgart.de:raichle@azu.informatik.uni-stuttgart.de> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17569; Wed, 25 Sep 91 05:26:08 MDT Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.COM via SMTP with TCP; Wed, 25 Sep 91 07:18:28-EDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Wed, 25 Sep 91 13:10:17 +0200 From: Bernd Raichle Date: Wed, 25 Sep 91 13:13:55 +0200 Message-Id: <9109251113.AA06202@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Wed, 25 Sep 91 13:13:55 +0200 To: tex-implementors@math.ams.com Cc: raichle@azu.informatik.uni-stuttgart.de Subject: Bug in TeX's ligature builder?! (No, it's documented.) In a letter to DEK in November 1989 (i.e., before TeX 3.0; appeared in TeXhax 90, Issue 5) Frank Mittelbach summarized some requirements of a new TeX version. For example, he mentioned manipulations of the "Ligatures and kerning tables" and the need to "Reconsider paragraphs after page-breaking". Other users had and have similar wishes and requirements. But nobody mentioned a bug, or better --- because this "bug" is documented in the TeXbook --- the inconsistent and (for the beginner) mysterious behaviour when TeX builds ligatures and inserts kerning. Try the following in plain TeX and look at the output. I have used the fl-ligature as an example. (TeX's behaviour for kerning between two characters is exactly the same.) ------------------------------ CUT ------------------------------ \hsize=5cm % linebreak for more than three words \hyphenation{Au-flage}% for demonstration (correct german is Auf-la-ge) Auflage\par % (1) show `fl' ligature Auf{}lage Auf\relax lage\par % (2) simple way to avoid the ligature \pretolerance=10000 % no second pass Auf{}lage Auf{}lage Auf{}lage Auf{}lage Auf{}lage\par % (3) no ligatures \pretolerance=-1 % force second pass Auf{}lage % no(!) ligature, because there's no preceding glue Auf{}lage Auf{}lage Auf{}lage Auf{}lage\par % (4) ligatures Auf{}lage % (5) no(!) ligature, there's no preceding glue Auf\kern0pt lage % no lig, explicit kern Auf\/lage % no lig, explicit kern $\rm Auflage$ % example of ligature in math mode $\rm Auf{}lage$ % no lig, in math mode \hbox{Auf{}lage} % no lig, in packed hbox Auf{}lage\vrule width0pt\ % no lig, followed by a rule node Auf{}lage\kern0ptAuf{}lage % 1st ligature, 2nd no ligature Auf{}lage\par % ligature \bye ------------------------------ CUT ------------------------------ Example (1) shows the normal fl ligature, in example (2) I suppress the ligature with an empty group (see TeXbook, exercise 5.1 and answer) or a \relax (both are non-character tokens). In example (3) I use empty groups to suppress the ligatures. The same(!) input paragraph in example (4) contains ligatures. The only and very important difference between (3) and (4) is the value of \pretolerance. (Note that the first word in (4) has no fl-ligature!) Example (5) gives a quick overview of TeX's behaviour, when the same word (= the same input!) is used in a different context. You can think of other examples: hbox the word... and unhbox it. Try the same with the ''-ligature (i.e. compare '' with '{}'), etc. Very short explanation of this behaviour: when TeX is in hmode, ligatures and kernings are build out of the (current input) token list. Non-character tokens (like { or \relax) influence ligatures and kerning. When TeX is in math mode or after hyphenation is done in the second pass of the line_break algorithm, ligatures and kernings are build out of the node list representing the current paragraph (or math list). This node list doesn't contain representations for tokens like { or \relax anymore. Because not all parts of the node list are tried for hyphenation, not all of the supressed ligatures are reconstituted. TeX has a powerful linebreak algorithm, a powerful hyphenation capability and powerful ligature and kerning tables. But the connection between them shows IMHO design bugs, if you want to use them and expect the same output from the same input. Comments, etc. ...?? (... are expected!!) -bernd PS: I have ideas how to make ligatures/kerning more consistent. But the result, after the necessary changes (in a few places) are applied, is a "TeX" which fails the Trip-Test. __________________________________________________________________________ Bernd Raichle, Student der Universit"at Stuttgart | "Le langage est source privat: Stettener Str. 73, D-W-7300 Esslingen | de malentendus" email: raichle@azu.informatik.uni-stuttgart.de | (A. de Saint-Exupery) 19-Sep-1991 21:13:14-GMT,5042;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10601; Thu, 19 Sep 91 15:13:10 MDT Date: Thu 19 Sep 91 17:00:03-EST From: Ralph Youngen Subject: [Ralph Youngen : incremental posting to e-MATH.ams] To: tex-implementors@MATH.AMS.COM Cc: REY@MATH.AMS.COM Message-Id: <685314003.0.REY@MATH.AMS.COM> In-Reply-To: REY Mail-System-Version: Chris Thompson points out that I should also forward messages like the one below to the TeX-Implementors list, so I am doing so. Chris was also nice enough to point out that even though I said to check the ams/amstex/amstex.bug file for details on the changes, the amstex.bug file was exactly the same as the one posted last July. So much for updating your archive on Friday the 13th! I have just posted a new version, so the reference to amstex.bug listed below should really read: 11945 Sep 19 16:25 amstex.bug --------------- Return-Path: Date: Mon 16 Sep 91 17:28:29-EST From: Ralph Youngen Subject: incremental posting to e-MATH.ams.com To: tex-archive@math.utah.edu, info-tex@shsu.bitnet, texhax@cs.washington.edu, UKTeX%uk.ac.tex@nsfnet-relay.ac.uk, tex-euro@dhdurz1.bitnet Cc: dlr@MATH.AMS.COM, rmg@MATH.AMS.COM, ttk@MATH.AMS.COM, esw@MATH.AMS.COM, mjd@MATH.AMS.COM, ngb@MATH.AMS.COM, jul@MATH.AMS.COM, bnb@MATH.AMS.COM, REY@MATH.AMS.COM Message-ID: <685056509.0.REY@MATH.AMS.COM> Mail-System-Version: I wish to thank everyone who has used the recent versions of the AMS products and reported bugs or suggestions to the AMS Technical Support group. The purpose of this mail is to announce an incremental posting of new versions of several files in our TeX distribution on e-MATH.ams.com, subsequent to our major upgrades which were posted on July 2. The version numbers for the products themselves will remain unchanged: AMSFonts and AMS-TeX are version 2.1, and AMS-LaTeX is version 1.1. However, the version numbers embedded into any updated files (listed below) have been incremented by adding a letter to the version number. For example, ams/amsfonts/doc/userdoc.tex is at version 2.1a, but ams/amslatex/doc/amslatex.tex is at version 1.1b because it has been updated twice since version 1.1 of AMS-LaTeX was released. Changes to AMSFonts 2.1 are in the documentation only. Changes to AMS-LaTeX 1.1 are in the documentation, as well as a some bug fixes. See the amslatex.bug file for details. Changes to AMS-TeX 2.1 are in the documentation, as well as a few bug fixes. See the amstex.bug file for details. Changed to files in the author-info area are bug fixes which caused TeX errors to occur in previous versions. Additionally, at the request of several people, we have made tar archives of the AMSFonts pk files available for retrieval by FTP. These tar archives are broken down by resolution and can be found in the main /ams area where the other tar archives live. See the ams/READ.ME file for more details. Below is a list of all files that have changed on e-MATH since the major posting on July 2, 1991 (excluding tar archives). We ask that archive maintainers please consult this list and retrieve these files from e-MATH to update the ams area on your own archive. Archive maintainers should feel free to report any problems or questions concerning this update directly to me at rey@math.ams.com. Bug reports, general questions, or suggestions should continue to be sent to tech-support@math.ams.com. Thank you. Ralph Youngen Supervisor, Technical Support American Mathematical Society Internet: REY@MATH.AMS.COM --------------------------------------------------------------------------- ams/amsfonts: 6495 Sep 13 15:18 READ.ME ams/amsfonts/doc: 20351 Sep 13 15:17 userdoc.def 29498 Sep 13 15:17 userdoc.ins 53989 Sep 13 15:17 userdoc.tex ams/amslatex: 19887 Sep 13 15:20 amslatex.bug ams/amslatex/doc: 62362 Aug 7 09:45 amsart.doc 15660 Aug 7 09:45 amsbook.doc 16643 Sep 13 15:19 amslatex.aux 158726 Sep 13 15:20 amslatex.tex 8853 Sep 13 15:20 amslatex.toc 88056 Aug 7 09:48 testart.tex ams/amslatex/inputs: 25709 Aug 7 10:03 amsart.sty 9575 Aug 7 10:03 amsbook.sty 9431 Sep 13 15:19 amsfonts.sty 11304 Sep 13 15:21 fontdef.ams ams/amstex: 5112 Aug 7 10:31 amsppt1.tex 7115 Sep 13 15:23 amstex.bug ams/amstex/doc: 73452 Sep 13 15:22 amsguide.tex 21688 Sep 13 15:22 amstinst.tex ams/author-info/guidelines: 19695 Aug 7 10:14 amsl-art.tex 17716 Aug 7 10:14 amst-art.tex 63170 Aug 7 10:14 amst-gid.tex 12113 Aug 7 10:14 amst-mon.tex ams/author-info/sty-files: 28478 Sep 13 15:23 memo.pkg-amstex ------- 10-Oct-1991 16:48:40-GMT,1269;000000000001 Return-Path: <@MATH.AMS.COM,@ifi.informatik.uni-stuttgart.de:mattes@azu.informatik.uni-stuttgart.de> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03066; Thu, 10 Oct 91 10:48:34 MDT Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.COM via SMTP with TCP; Thu, 10 Oct 91 12:36:00-EDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Thu, 10 Oct 91 17:28:14 +0100 From: Eberhard Mattes Date: Thu, 10 Oct 91 17:32:19 +0100 Message-Id: <9110101632.AA11100@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Thu, 10 Oct 91 17:32:19 +0100 To: tex-implementors@math.ams.com Subject: LaTeX overwrites input file Citation from latex.tex: > % Changed definition of \include to allow space at end of file name-- > % otherwise, typing \include{foo } would cause LaTeX to overwrite > % foo.tex. Change made 24 May 89, suggested by Rainer Sch\"opf and > % Frank Mittelbach Overwriting also occurs if \include{picture.pic} is used under some operating systems: MS-DOS, for instance, truncates picture.pic.aux to picture.pic. How could this be fixed? Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) 10-Oct-1991 16:48:44-GMT,1421;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PEB@DM0MPI11.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB03066; Thu, 10 Oct 91 10:48:41 MDT Message-Id: <9110101648.AB03066@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 10 Oct 91 12:22:17-EDT Received: from DM0MPI11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1284; Thu, 10 Oct 91 04:06:43 EDT Received: from DM0MPI11 (PEB) by DM0MPI11 (Mailer R2.08) with BSMTP id 8366; Thu, 10 Oct 91 09:07:12 GMT Date: Thu, 10 Oct 91 08:55:54 GMT From: Peter Breitenlohner Organization: Max-Planck-Institut fuer Physik, Muenchen Subject: PATGEN 2.0 To: Tex-implementors@math.ams.com I have now finished a new Version 2.0 of PATGEN adapted for `8-bit TeX' as well as a VM/CMS and a (preliminary) DOS-TP change file. The new program gets all information about the external representation of the `letters' used by a particular language from a `translate file'. The external representation of an upper or lower case letter may consist of one or more characters. Therefore there should be absolutely no necessity for language dependent modifications. It would be nice if some of you would a) prepare change files for other systems b) do some testing (I only did a bare minimum). Whoever is willing to do either of these please contact me. Peter 11-Oct-1991 1:46:53-GMT,1566;000000000001 Return-Path: <@MATH.AMS.COM,@LUCY.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06734; Thu, 10 Oct 91 19:46:50 MDT Received: from LUCY.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 10 Oct 91 21:37:27-EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GBLA2F0I2O9S3Q1T@HMCVAX.CLAREMONT.EDU>; Thu, 10 Oct 1991 18:33 PDT Date: Thu, 10 Oct 1991 18:33 PDT From: Don Hosek Subject: Re: LaTeX overwrites input file To: mattes@azu.informatik.uni-stuttgart.de, tex-implementors@math.ams.com Message-Id: <01GBLA2F0I2O9S3Q1T@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"mattes@azu.informatik.uni-stuttgart.de" X-Vms-Cc: TEX_IMPLEMENTORS -Overwriting also occurs if \include{picture.pic} is used under some -operating systems: MS-DOS, for instance, truncates picture.pic.aux -to picture.pic. -How could this be fixed? Well, one should follow the instructions for LaTeX which specifies that LaTeX will supply the extension (cf. p. 188). Not worded as strongly as I do in my book (in preparation), but clear. I suppose it would be possible to do something along the lines of \def\checkforext#1.#2\@nil{\def\foo{#2} \ifx\foo\empty % No extension given \else % extension given, beginning in #1 \fi} \def\include#1{\checkforext#1.\@nil etc.} but I'm not sure that it's worth the effort. The fact that one is using an extension of pic implies that the approach to the use of \include may be a little flawed (or not). -dh 22-Oct-1991 19:38:57-GMT,1103;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:BROUARD@FRINED51.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27722; Tue, 22 Oct 91 13:38:54 MDT Message-Id: <9110221938.AA27722@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Tue, 22 Oct 91 14:08:10-EDT Received: from FRINED51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2860; Tue, 22 Oct 91 14:05:07 EDT Date: 22 OCT 91 18:55:38.18-GMT From: BROUARD%FRINED51.BITNET@CUNYVM.CUNY.EDU Subject: How can I subscribe To: TEX-IMPLEMENTORS@MATH.AMS.COM I am building a new distribution for PC and UNIX (RS6000, DEC) for GUTenberg. Eric Picheral will also modify his actual SUN distribution so that we will be coherent. A lot of question arise about hyphenation patterns loading and other things. The discussion have take place on LaTeX-L which is not its aim. How can I subscribe to your list to discuss the problems encountered with languages (with diacritical signs). Nicolas Brouard Institut national d'\'etudes d\'emographiques Paris 23-Oct-1991 14:26:13-GMT,3126;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:BROUARD@FRINED51.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB05489; Wed, 23 Oct 91 08:26:09 MDT Message-Id: <9110231426.AB05489@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 23 Oct 91 10:13:47-EDT Received: from FRINED51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0551; Wed, 23 Oct 91 10:10:47 EDT Date: 23 OCT 91 15:04:12.00-GMT From: BROUARD%FRINED51.BITNET@CUNYVM.CUNY.EDU Subject: VFFONTS environnement To: TEX-IMPLEMENTORS@MATH.AMS.COM Looking at site.h from the German (IBMRS6000 but here is not the problem) distribution, I found #define VFFONTS ".:/usr/lpp/tex/fonts/PSvfs" even if you change lpp into local/lib, my question concerns: 1) What is this VFFONTS useful for, when building TEX and MF? It is probably used by some texware but don't know wich ones. 2) Sure it is useful to have a VF directory defined, and for example for dvips ou xdvi if this last is able to read virtual fonts. But what is the official name? VFFONTS? Ok, but why does a VFFONTS_SUBDIR not exist? If it exists, we can define VFFONTS as .:/usr/local/lib/tex/fonts/vf and have a subdirectory or link like /usr/local/lib/tex/fonts/vf/PSvfs. Not true? We decided at GUTenberg to incorporate the SUBDIRS facilities to have clean directories (UNIX). For PCs, the directories will be clean in the ZIP files, but during installation, all we be put in TEXINPUTS because we cannot change the compilers and also because I have heard that it takes time to look in sub_dir (I don't know why?). The user will be only able to use the environments to choose more that one directory. 3) Sometimes there is an "s" like TEXTFMS or FONTTFMS for PCs, or fonts/tfms, but for "vf" the is no "s" in site.h-dist. Is there a rule? 4) At last I would say that VFs does not only concern PostScript fonts but any fonts, particularly Cork fonts. So, please, destroy the PSvfs in the site.h or the GermanIBM distribution. I have heard that the DC fonts are distributed with all 8 bits pks. This means that the bit maps of , etc are mutliply defined. This is not good for PC where disk space is rare. DC fonts should be defined with parcimony, if the character like can be designed with an and a quote <'> we only need the vf and the ftm not the pk. In particular, in french, pk files are only needed for french-guillemets (and may be another exception). So why not define DC pks which will be empty for a lot of character i.e the characters wich can be built with vfs. We will probably reduce the DC pk sizes for more than 70%. This proposition, probably discussed a lot somewhere (I am new on this list) means that all drivers (screen or laser) have to be able to process virtual fonts. But the implementation of DC fonts means also the world wild use of virtual drivers. Regards, Nicolas Brouard 23-Oct-1991 18:11:41-GMT,3386;000000000001 Return-Path: <@MATH.AMS.COM,@rs2.hrz.th-darmstadt.de:gunterma@iti.informatik.th-darmstadt.de> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07422; Wed, 23 Oct 91 12:11:33 MDT Received: from rs2.hrz.th-darmstadt.de by MATH.AMS.COM via SMTP with TCP; Wed, 23 Oct 91 11:27:26-EDT Received: from hp5.iti.informatik.th-darmstadt.de by rs2.hrz.th-darmstadt.de with SMTP id AA04512 (5.65c/IDA-1.4.4 for ); Wed, 23 Oct 1991 16:24:18 +0100 Received: from hp12.iti.informatik.th-darmstadt.de by hp5.iti.informatik.th-darmstadt.de (15.11/Server-1.0/HRZ-THD) id AA04969; Wed, 23 Oct 91 16:24:34 mez Received: by hp12.iti.informatik.th-darmstadt.de (15.11/Client-1.0/HRZ-THD) id AA11548; Wed, 23 Oct 91 16:24:45 mez From: Klaus Guntermann Message-Id: <9110231524.AA11548@hp12.iti.informatik.th-darmstadt.de> Subject: Re: VFFONTS environnement To: tex-implementors@math.ams.com Date: Wed, 23 Oct 91 16:24:44 MEZ X-Mailer: ELM [version 2.3 PL11] Nicolas Brouard (brouard@frined51> wrote: > Looking at site.h from the German (IBMRS6000 but here is not the problem) > distribution, I found > #define VFFONTS ".:/usr/lpp/tex/fonts/PSvfs" ... > 1) What is this VFFONTS useful for, when building TEX and MF? > It is probably used by some texware but don't know wich ones. VFFONTS was introduced to the benefit of the tool dvicopy, prepared by Peter Breitenlohner. The web2c port was done by us in Darmstadt (Germany). To have dvicopy compiled with the general web2c features this extension went into site.h (coordinated by Karl Berry). > 2) Sure it is useful to have a VF directory defined, and for example > for dvips ou xdvi if this > last is able to read virtual fonts. But what is the official > name? VFFONTS? Ok, but why does a VFFONTS_SUBDIR not exist? The name is more or less `official'. It is in the web2c distribution (period). Whether or not one uses SUBDIR searching, is a matter of taste. I do NOT prefer it because the file system determines the sequence of search and I can easily run into problems if I have files with the same name in different subdirectories with different contents. I prefer much more setting an explicit search path for each application (not searching any LaTeX directories when running a Plain TeX job). > 3) Sometimes there is an "s" like TEXTFMS or FONTTFMS for PCs, or > fonts/tfms, but for "vf" the is no "s" in site.h-dist. Is there a rule? >From my point of view this has grown, and was not designed. But now the current state is wide spread and hard to change without risking to be killed. > 4) At last I would say that VFs does not only concern PostScript fonts > but any fonts, particularly Cork fonts. So, please, destroy the PSvfs in > the site.h or the GermanIBM distribution. Why? Everybody has to modify (or at least check) the settings in site.h and can freely change the value. If you don't like it, feel free to change it for your implementation. And maybe Uwe Untermarzoner already has changed his settings to reflect the decisions taken in the German meeting at Dresden, recently (if there were any changes necessary, I do not recall that). I hope this at least clarified why VFFONTS is in site.h. Klaus Guntermann Fachbereich Informatik Technische Hochschule Darmstadt 23-Oct-1991 18:11:46-GMT,2418;000000000001 Return-Path: <@MATH.AMS.COM:karl@cs.umb.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB07422; Wed, 23 Oct 91 12:11:42 MDT Received: from cs.umb.edu by MATH.AMS.COM via SMTP with TCP; Wed, 23 Oct 91 12:24:02-EDT Received: from claude.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA11489; Wed, 23 Oct 91 12:21:00 EDT Received: by claude.cs.umb.edu (4.1/1.34) id AA13079; Wed, 23 Oct 91 12:20:59 EDT Date: Wed, 23 Oct 91 12:20:59 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9110231620.AA13079@claude.cs.umb.edu> To: BROUARD%FRINED51.BITNET@cunyvm.cuny.edu Cc: TEX-IMPLEMENTORS@math.ams.com In-Reply-To: BROUARD%FRINED51.BITNET@CUNYVM.CUNY.EDU's message of 23 OCT 91 15:04:12.00-GMT <9110231432.AA06957@cs.umb.edu> Subject: VFFONTS environnement Reply-To: karl@cs.umb.edu (It's probably better to send distribution-specific questions like this to the person responsible for the distribution, in this case me, instead of tex-implementors.) > #define VFFONTS ".:/usr/lpp/tex/fonts/PSvfs" That's not what the standard web2c distribution has as a default. But whatever. > 1) What is this VFFONTS useful for, when building TEX and MF? TeX and MF don't use it. vftovp and dvicopy do. > But what is the official name? VFFONTS? Yes. Probably someone somewhere has written a program that uses another name, but all the programs I use, at least, use that. > Ok, but why does a VFFONTS_SUBDIR not exist? Oversight. Next release of web2c (and, I hope, dvips) will have it. > all we be put in TEXINPUTS because we cannot change the compilers Complain. > I have heard that it takes time to look in sub_dir No more time than to specify all those directories in your path. It's true that if you don't have your fonts set up in such a way that searching subdirectories make sense, it can take a long time. (TeX has to check each one of thousands of font files to see if it's a directory.) > Sometimes there is an "s" like TEXTFMS or FONTTFMS for PCs, or > fonts/tfms, but for "vf" the is no "s" in site.h-dist. Is there a rule? All the names in the web2c distribution are at least somewhat consistent, as far as I know. (TEXFONTS, TEXINPUTS, ..) TEXTFMS and FONTTFMS aren't used. > At last I would say that VFs does not only concern PostScript fonts I agree. > destroy the PSvfs in the site.h or the GermanIBM distribution. It's not in web2c. karl@cs.umb.edu 24-Oct-1991 10:15:13-GMT,1732;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:BROUARD@FRINED51.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15988; Thu, 24 Oct 91 04:15:09 MDT Message-Id: <9110241015.AA15988@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 24 Oct 91 06:08:30-EDT Received: from FRINED51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9599; Thu, 24 Oct 91 01:40:19 EDT Date: 23 OCT 91 18:43:54.85-GMT From: BROUARD%FRINED51.BITNET@CUNYVM.CUNY.EDU Subject: VFFONTS environment To: TEX-IMPLEMENTORS@MATH.AMS.COM Thank you for your answers. About sub_directories, things are not clear I aggree. At first I realized, only now, that it is not a recursive search in all directories but only at level one. Using this facility make directories cleaner but not really clean. Using this feature, the rule should be not to have two files with identical names. If this happens, for example with ilatex/article.sty and standard-latex/article.sty, it reflects a real problem which has to be solved rapidly within the TeX community (not many years after). After having pointed out a weakness in the GermanIBM distribution (PSvfs) I also want to say that the distribution is in many points remarkable and that is for that reason that we want to adapt it to french. Binary and sources are included, well documented. After having extract the files from tape to disk, a simple link_install without any copy can be done. The use of /usr/lpp/tex makes the product like an IBM product (not an IBM product) and ready to use. It can be distributed widely by an association like GUTenberg or by IBM distributors. This is our aim. Nicolas Brouard 25-Oct-1991 6:33:44-GMT,1132;000000000001 Return-Path: <@MATH.AMS.COM:jmr@nada.kth.se> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24328; Fri, 25 Oct 91 00:33:41 MDT Received: from nada.kth.se by MATH.AMS.COM via SMTP with TCP; Fri, 25 Oct 91 02:25:49-EDT Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16893; Fri, 25 Oct 91 07:22:06 +0100 Date: Fri, 25 Oct 91 07:22:04 +0100 From: Jan Michael Rynning To: Tomas G. Rokicki Cc: beebe@math.utah.edu, tex-implementors@math.ams.com Subject: Re: TFM directories In-Reply-To: Your message of Thu, 24 Oct 91 17:05:53 -0700 Message-Id: Tom Rokicki writes: > TEXFONTS is for TFM; TEXPACKED is for PK. This is what all of my > drivers use, always have used, always will use. I can't find any references to TEXPACKED in the source code of Tom's dvips version 5.47. Excerpt from resident.c, part of dvips 5.47: > if (getenv("TEXPKS")) > pkpath = getenvup("TEXPKS", pkpath) ; > else if (getenv("PKFONTS")) > pkpath = getenvup("PKFONTS", pkpath) ; Jan 25-Oct-1991 0:15:37-GMT,1133;000000000001 Return-Path: <@MATH.AMS.COM:rokicki@Neon.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22367; Thu, 24 Oct 91 18:15:33 MDT Received: from Neon.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 24 Oct 91 20:08:48-EDT Received: by Neon.Stanford.EDU (5.61/25-eef) id AA00501; Thu, 24 Oct 91 17:05:53 -0700 Date: Thu, 24 Oct 91 17:05:53 -0700 From: Tomas G. Rokicki Message-Id: <9110250005.AA00501@Neon.Stanford.EDU> To: beebe@math.utah.edu Subject: Re: TFM directories Cc: tex-implementors@math.ams.com TEXFONTS is for TFM; TEXPACKED is for PK. This is what all of my drivers use, always have used, always will use. I think it's important to get the standards straight on this; when processing a lot of files, getting fonts over a network, it's real good not to have to probe too many directories. Especially when doing something like searching up and down for a font that is within 1/2 of a percent; the number of directories is multiplied by the number of fonts that are `acceptably close', and that by the number of fonts in a document. -tom 25-Oct-1991 17:28:28-GMT,1882;000000000001 Return-Path: <@MATH.AMS.COM:karl@cs.umb.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28553; Fri, 25 Oct 91 11:28:24 MDT Received: from cs.umb.edu by MATH.AMS.COM via SMTP with TCP; Fri, 25 Oct 91 13:08:50-EDT Received: from claude.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA21557; Fri, 25 Oct 91 13:05:13 EDT Received: by claude.cs.umb.edu (4.1/1.34) id AA21861; Fri, 25 Oct 91 13:05:11 EDT Date: Fri, 25 Oct 91 13:05:11 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9110251705.AA21861@claude.cs.umb.edu> To: tex-implementors@math.ams.com In-Reply-To: Tomas G. Rokicki's message of Thu, 24 Oct 91 17:05:53 -0700 <9110250005.AA00501@Neon.Stanford.EDU> Subject: TFM directories Reply-To: karl@cs.umb.edu The web2c distribution, dvips, and xdvi use (I think) the same set of search environment variables (or at least they will when the next versions are released; there might a few inconsistencies now): TEXFONTS, followed by subdirectories of TEXFONTS_SUBDIR, only for TFM's; TEXPKS, followed by PKFONTS, followed by TEXFONTS, followed by subdirectories of TEXFONTS_SUBDIR, for PKs; GFFONTS, followed by TEXFONTS, followed by subdirectories of TEXFONTS_SUBDIR, for GF's. VFFONTS, followed TEXFONTS, followed by subdirectories of TEXFONTS_SUBDIR, for VF's. I may have found an efficient way to be able to search for subdirectories recursively; right now, the subdirectory searching is only one level deep. So the algorithm might change in that (upward-compatible) respect in the next release. As Tom says, it's true that it's very good not to have probe a lot of directories for files. But this is independent of the number of environment variable names. So while it would be obviously be cleanest to have all drivers accept the same names, as long as there is a common subset, users should be able to make do. 25-Oct-1991 18:16:47-GMT,2011;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:BROUARD@FRINED51.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28920; Fri, 25 Oct 91 12:16:43 MDT Message-Id: <9110251816.AA28920@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 25 Oct 91 14:05:07-EDT Received: from FRINED51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7719; Fri, 25 Oct 91 04:55:50 EDT Date: 25 OCT 91 09:52:36.83-GMT From: BROUARD%FRINED51.BITNET@CUNYVM.CUNY.EDU Subject: TEXPKS not TEXPACKED To: TEX-IMPLEMENTORS@MATH.AMS.COM In the worldwide distribution of dvips5.47, the documentation says, page 28, that the environment is TEXPKS, not TEXPACKED. Sure, the document entitled, "DVIPS: a TeX Driver" is unsigned, but it is the only one that we have. TEXPACKED is 9 characters long not 8, so don't forget PCs and TEXPKS (with an "S" at the end) should be ok. Incidentally, for the next PC GUTenberg distribution, and as the new Beebe driver family is not finished, I will keep the TEXFONTS notation for pk and FONTTFMS for tfm (Wayne's notation) or what? Should I compile again the now very old 2.10 family to change TEXFONTS in TEXPKS, have new sources and new .exe? No. I must probably keep the Beebe family for non PostScript drivers. Another solution could be to have only dvips5.47 as dvi driver. Big advantage being to have most of \special and in particular to be able to process EEPIC output by more and more graphics softwares like last GNUPLOT3.0 (3D) or Xfig. And in a second step to use ghostscript (last one is 2.3) to output on laserjet or deskjet or even epson (dvips foo -o "|gs -sDEVICE=hplj -" for example on UNIX but GNUPLOT and Ghostscript are also available on DOS), but on a small PC it will be probably a too long process when you have a hplj. What do you think of that: only a PostScript driver and ghostscript (with more additional drivers that actually distributed) behind? Nicolas Brouard 1-Nov-1991 18:56:58-GMT,21960;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB02059; Fri, 1 Nov 91 11:56:48 MST Date: Fri 1 Nov 91 13:03:35-EST From: bbeeton Subject: Publication info for C & T; messages from DEK, part 1 To: tex-implementors@MATH.AMS.COM Message-Id: <689018615.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 1 November 91 Message No: 032 To: TeX implementors and distributors From: Barbara Beeton Subject: Publication info for C & T; messages from DEK, part 1 On my return from several weeks of out-of-town meetings, I found waiting for me a large package from DEK (about 1cm of paper, plus half a dozen checks, or checques, depending which side of the Atlantic you were on when you learned to spell English). No major rewards in this batch, although there will be a version 3.141 probably in January, after some updates have been checked out a bit more thoroughly and DEK returns from a couple months in Sweden. I am just about ready to distribute the checks and the supporting documentation to the original submitters. I will also post here the details of the submissions and the replies; this involves deciphering DEK's handwritten notes and typing them in so that they make sense. The first installment is included below. I was also asked to find out the current status of several volumes in the Computers & Typesetting series, in particular, whether volumes B and D (**: The Program) now contain the version 3 (etc.) updates. As this information is likely to be of general interest, the report from Addison-Wesley is given below. As usual after such a long break in "official" messages, there have been quite a few address updates and a few additions. So, once again, acknowledgements would be appreciated, to make sure the mail is getting through. ######################################################################## status of volumes in the series Computers & Typesetting, by Donald E. Knuth information received from Addison-Wesley, 23 October 1991 printing ref.no. vol. title edition number date hardbound: 13447 A The TeXbook 1 11th June 1, 1991 13437 B TeX: The Program 1 4th May 1, 1991 13445 C The METAFONTbook 1 4th Sept, 1991 13438 D METAFONT: The Program 1 4th Oct, 1991 13446 E Computer Modern Typefaces 1 3rd Aug, 1987 soft/spiral bound: 13448 The TeXbook 1 20th May 1, 1991 13444 The METAFONTbook 1 6th Feb, 1991 note: all printings are marked "with corrections" ######################################################################## Date: Mon 24 Jun 91 13:28:03-EST Subject: bug report (plain.tex) for don don, here's a bug in plain that has been flushed out by phil taylor. Date: Fri, 21 JUN 91 20:54:14 BST From: CHAA006@vax.rhbnc.ac.uk "Philip Taylor (RHBNC) " Subject: Bug in PLAIN Hi, Barbara et al ... I have just spent nine hours searching for a bug in my code ... I finally thought to check Plain.TeX (fmtversion{3.0}) and found ... \def\multispan#1{\omit \mscount#1 \loop\ifnum\mscount>\@ne \sp@n\repeat} \def\sp@n{\span\omit\advance\mscount\m@ne} which explained everything ... It's simply that the first line ends `#1', rather than `#1\relax'; if \multispan is invoked with a \countdef'd register, as in \multispan \columns \hrulefill \cr an extra and totally unwanted space intrudes before the \hrulefill. Is this a known bug, or has it just failed to emerge from the woodwork before ? ** Phil. this little test demonstrates the problem "loud and clear". \def\testmspan#1{% \halign{##\hfil&&\qquad##\hfil\cr XX&\multispan{#1}XXXXX&XX\cr XX&XX&XX&XX&XX\cr}} \testmspan{3} \newcount\columns \columns=3 \testmspan{\columns} \catcode`\@=11 \def\multispan#1{\omit \mscount#1\relax \loop\ifnum\mscount>\@ne \sp@n\repeat} \catcode`\@=12 \testmspan{\columns} \bye i wonder how many people have noticed something slightly wrong but never went out of their way to check? -- bb [ reply from dek: $2.56 (which works out to about 28\cents{} per hour) Thanks very much! will be fixed in plain version 3.1 ] ######################################################################## Date: Sun 15 Sep 91 15:03:54-EST Subject: bugs and questions for don don, here are some bug reports and other comments that have been accumulating. i should have sent most of them earlier, but most of these aren't "easy" ones, and i've been out of town so much [ dek: ^^^^ rather an understatement ... but nothing to match the earlier stuff on hyphenation & ligatures. ] that i just never got them organized. -- bb [ dek: No problem -- good thing in fat, because I just finished a big project that was causing me to turn off all other mail -- and I'm just about tostart another -- so Sep 17 was the day I chose to look at TeX stuff. ] -------------------- Contents: question on "final" update to TeX and MF TeXbook errata and questions easy items handling of space tokens still a bug in p. 377 footnote incompatibility of positive/negative integer values file name overflow of string pool TeX handling of \newlinechar within \special size of \smash'ed boxes verifying that 8-bit input is supported incompatibilities between \input and \openin WEB system dealing with repeating code in .WEB files ************************************************************************ Question on "final" update to TeX and MF Who will be authorized to change the version numbers of TeX and MF to $\pi$ and $e$ respectively? It might be a good idea just to have this information "on the record"; perhaps a message to be placed on file in the TUG office would suffice. [ dek: I put such a message into TEX82.BUG and MF84.BUG some time ago, so I presume any archive keeper could make the change. (Actually it also implies changes to Volumes B and D also, and in the `Running' chapters of Volumes A and C; so I have added a phrase to TEX82.BUG and MF84.BUG. I guess the authorized person will be my literary executor, given that my program is supposed to be literate? ] ************************************************************************ TeXbook errata and questions -- easy items Date: Thu, 27 Jun 91 23:11:47 BST From: CET1@phoenix.cambridge.ac.uk Subject: A TeXbook possible-bug from Robert Hunt, etc > Submitted: 20:44:00 12 Apr 91 > From: Robert Hunt > To: cet1 > Subject: TeX > > I've just discovered a _very_ minor problem with the TeXbook, but I thought I'd > point it out to you anyway, while there's already an outstanding problem being > considered. I certainly don't think it's a real "bug" but it's certainly worth > telling Knuth! I've just noticed that the only place in the TeXbook where it > informs you that exactly one space token is ignored after a closing $$ is in > the answer to Exercise 14.30, on page 316. It surely ought to mention this in > some other places as well: in particular, it should be on page 287, and > possibly on page 189 (though Knuth is unlikely to want to do this as it'd be > difficult to avoid having to rearrange lots of text to fit!). I think that there is something in this, although I suspect that the canonical place it should be documented is on page 293 (treatment of $ and $$ when encountered in math mode), not page 287. Anyway, I think [ dek: ^^^^^^^^^^^^ right it deserves to have Don look at it: as far as I can make out there haven't been any TeXbook changes that affect Robert's claim. [ dek: Aha, there _is_ room on page 293! $2.56 ] i still have outstanding the various error reports about the p.377 footnote. I will try to get back to you on this *soon* (sigh). Chris Thompson ------- Date: Mon, 9 Sep 91 13:19:21 PDT From: raymond@math.berkeley.edu (Raymond Chen) Subject: TeXbook errata Please pass these on to DEK, as I ran across them in my marginal notes after I mailed off my letter... They're all index items, and they're not really errata. add `\note: 318'. Many times I've wanted to find that macro and couldn't. though perhaps keeping it under `footnotes: 121' is good enough. [ dek: \check ] add `72' to \hss, even though it doesn't appear explicitly, since that is where we learn exactly how much glue an \hss produces. (Curiously, \hfil, \hfill, and \hfilneg are indexed for that page. \hss is the odd man out.) [ dek: 32\cents ] add `93' to `hyphenation', since that's where the most obvious method of suppressing hyphenation is presented. (I get asked this quite a bit, and it's annoying not to be able to say, ``Just check the index.'') [ dek: $2.56 included in check sent directly to him in response to his letter ] My proposals to change the index are usually rejected, but if DEK feels like considering them, he can do so. --rjc ------- Date: Sun, 18 AUG 91 17:57:27 +0100 From: CA_ROWLEY@vax.acs.open.ac.uk Subject: Bug in TeXbook whilst idly perusing Chap 24, looking for yet more amazing syntax and overloading (of the latter, \font was a new one for me!), [ dek: you knew about \span ] i discovered in black and white in the middle of page 275 the bold statement: "but in all cases this sign (=) is optional" now you and i know that Don knows perfectly well that this is not true---to take a simple example (there are other more subtle ones), the assignment: \let \equalsign = = here the first equals sign is essential. [ dek: precisely _because_ it is optional! ] do you think Don wants to know about this? [ dek: a (black and white) lie? ] chris ------- Date: Wed, 21 Aug 91 12:12:15 +0200 From: Eberhard Mattes Subject: Very insignificant error in The TeXbook? p. 96: ---------------------------------------------------------------------------- Some compound words in German text change their spelling when they are split between lines. For example, `backen' becomes `bak-ken' and `Bettuch' becomes `Bett-tuch'. ---------------------------------------------------------------------------- I think `backen' isn't a compound word, if `compound word' meens a word composed of two or more words (in contrast to syllables). [ dek: $2.56 should i have used `backenfisch' instead? ] -Eberhard Mattes ------- ************************************************************************ TeXbook errata and questions -- still a bug in p. 377 footnote [ note that according to Chris Thompson, Robert Hunt had already informed him that the p. 377 bug wasn't entirely fixed; however this commentary reached me first. ] Date: Fri, 31 May 91 11:43:02 From: Mike Piff To: beebe <@nsfnet-relay.ac.uk:beebe@MATH.UTAH.edu> Subject: Space tokens % Please forward to DEK. % The scheme in the footnote on p377 of The TeXbook appears not to work. % Mike Piff [ test code was included, but was replaced by later version, below ] ----------------------------------------------------------------------------- From Dr M. J. Piff, Department of Pure Mathematics, PO Box 597, Hicks Noisy Building Site, Hounsfield Road, [ dek:^^^^^^^^^^^^^^^^^^^^^^^^^ beautiful ] SHEFFIELD S10 2UN, England. Tel. SHEFFIELD(0742) 768555 Extension 4431. JANET MPiff@UK.AC.SHEF.PA or MPiff@UK.AC.SHEF.IBM ----------------------------------------------------------------------------- ------- Date: Sat 1 Jun 91 23:32:27-EST From: bbeeton To: mpiff@pa.shef.ac.uk Cc: beebe@math.utah.edu Subject: texbook bug, footnote, p377 nelson beebe forwarded to me your bug report on the footnote on p.377 of the texbook. this was already reported just a couple of months ago. the attached correction appears in the most recent errata.tex file (the seventh such file). -- bb -------------------- \bugonpage A377, the bottom 14 lines (3/26/91) \eightpoint\indent ASCII \; the macro also decides whether a space token is explicit or implicit. \begintt \newif\ifspace \newif\iffunny \newif\ifexplicit \def\stest#1{\expandafter\s\the#1! \stest} \def\s{\funnyfalse \global\explicitfalse \futurelet\next\ss} \def\ss{\ifcat\noexpand\next\stoken \spacetrue \ifx\next\stoken \let\next=\sss \else\let\next=\ssss \fi \else \let\next=\sssss \fi \next} \long\def\sss#1 #2\stest{\def\next{#1}% \ifx\next\empty \global\explicittrue \fi} \long\def\ssss#1#2\stest{\funnytrue {\uccode`#1=`~ \uppercase{\ifcat\noexpand#1}\noexpand~% active funny space \else \escapechar=\if*#1`?\else`*\fi \if#1\string#1\global\explicittrue\fi \fi}} \long\def\sssss#1\stest{\spacefalse} \endtt ------- Date: Tue, 04 Jun 91 10:11:21 From: Mike Piff Subject: texbook bug, footnote, p377 I don't think the code you sent works. It gives an error message on \ftoken. Mine definitely works, and correctly distinguishes the SIX different space [dek:^^^^^^^^^^^^^^^^ ha ha touch\'e [and I sure thought I had tested it ... ] tokens. Mike Piff ------- Date: Wed, 05 Jun 91 10:25:12 From: Mike Piff Subject: Re: texbook bug, footnote, p377 % I attach a cleaned-up version of what I sent before. This looks more like % the footnote on p377 of The TeXbook. % Mike Piff \newif\ifspace \newif\iffunny \newif\ifexplicit \newif\ifactive \def\stest#1{\expandafter\s\the#1 \stest} % [ dek: ^ put ! here in case the token list is empty ] \def\s{\spacetrue\explicittrue\activefalse\funnyfalse\futurelet\next\ss} % [ dek: ^ ^ \global (see page 301 near bottom) ] \def\ss{\ifcat\noexpand\next\stoken \ifx\next\stoken\let\next=\sss\else\let\next=\ssss\fi \else\spacefalse\let\next=\sssss\fi\next} \long\def\seeifactive#1{\expandafter\seex\string#1\seex} \long\def\seex#1#2\seex{\def\Temp{#2}\ifx\Temp\empty\global\activetrue\fi} \long\def\sss#1 #2\stest{\def\next{#1}% \ifx\next\empty\else\explicitfalse\seeifactive{#1}\fi} % [ dek: ^^ bug if the token list has length >1 ] \long\def\ssss#1#2\stest{\funnytrue {\escapechar=\if*#1`?\else`*\fi % [ dek: ^ \relax needed here I think [Because TeX wants a space after `*! Otherwise the escapechar isn't changed until after the \if#1\string#2 .] diagonalization, eh? ] \if#1\string#1\else\global\explicitfalse\seeifactive{#1}\fi}} \long\def\sssss#1\stest{} \def\CR{\immediate\write16{}} [ dek: nice; I had decided in March to give up trying to distinguish active ones! Actually this _doesn't_ quite work, but it is my fault (a bug in 3.0: \string^^88 comes out of length 1 when ^^88 is not active, but of length 4 when it's active; according to page 213 it should be length 1 in both cases). Also it fails to distinguish _active_ _funny_ * from explicit funny *, Also there's a problem when you make |_| active because string converts that into a space token! Then \seex will have a runaway argument because an undelimited parameter #1 can't be a space token. +-------+ | Aargh | +-------+ _Also_ a problem when \next is \futurelet to be \if ... ] \def\report{% \ifspace \ifexplicit \message{explicit}% \else \message{implicit}% \ifactive \message{active}% \fi \fi \iffunny\message{funny}\else\message{normal}\fi \message{space}% \else \message{nonspace} \fi \CR } % and now, a few tests of the various possibilities \newtoks\Test \def\1{\let\stoken= }\1 % \catcode`\!=\active \def\2{\let!= }\2 % ! active let to space \uccode` =`* \uppercase{\uppercase{\def\fspace{ }\let\ftoken= } } % \fspace expands to *space, \ftoken let to *space \catcode`[=\active \edef\3{\let\noexpand[=\fspace\fspace}\3% [active let to *space [ dek: where used? ] \CR \Test={ } % explicit normal space \stest\Test\report \Test=\expandafter{\fspace} % explicit funny space \stest\Test\report \Test={\stoken} %implicit normal space \stest\Test\report \Test={\ftoken} % implicit funny space \stest\Test\report \Test={!} % active normal space \stest\Test\report \catcode`|=\active \let|= \ftoken % active funny space \Test={|} \stest\Test\report \end [ dek: see enclosed test [p377.tex, p377.log] which I think _really_ puts the thing through its paces [actually I did additional tests too because the enclosed trials always set \escapechar to `?] ] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ p377 dated September 20, 1991 at 1014 % decoding space tokens (footnote on page A377) % solution found with help of Mike Piff \newif\ifspace \newif\iffunny \newif\ifexplicit \newif\ifactive \def\stest#1{\funnyfalse \expandafter\s\the#1! \stest} \def\s{\global\explicitfalse \global\activefalse \futurelet\next\ss} \def\ss{\ifcat\noexpand\next\stoken\let\nxt\sx\else\let\nxt\ns\fi\nxt} \def\sx{\spacetrue\ifx\next\stoken\let\nxt\sss\else\let\nxt=\ssss\fi\nxt} \long\def\sss#1 #2\stest{\def\next{#1}% \ifx\next\empty\global\explicittrue \else\testactive#1\s\fi} \long\def\ssss#1#2\stest{\funnytrue{\escapechar=\if*#1`?\else`*\fi\relax \if#1\string#1\uccode`#1=`~ % we assume that ~ is an active character \uppercase{\ifcat\noexpand#1}\noexpand~\global\activetrue \else\global\explicittrue\fi \else\testactive#1\s\fi}} \long\def\ns#1\stest{\spacefalse} \long\def\testactive#1#2\s{\expandafter\tact\string#1\s\tact} \long\def\tact#1#2\tact{\def\next{#2}\ifx\next\xs\global\activetrue \else\ifx\next\empty \global\activetrue\fi\fi} \def\xs{\s} \def\report#1{\message{#1:}% \ifspace \message{\ifexplicit ex\elseim\fi plicit}% \ifactive\message{active}% \message{\iffunny funny\else normal\fi space}% \else\message{nonspace} \fi \CR} \def\CR{\immediate\write16{}} \newtoks\Test \def\1{\let\stoken= }\1 % implicit normal space token \catcode`\!=\active \def\2{\let!= }\2 % active normal space token \uccode` =`* \uppercase{\uppercase{\def\fspace{ }\let\ftoken= } } % \fspace expands to explicit funny space, \ftoken is implicit funny *space \uccode` =0 \CR \test={ } \stest\test\report1 % explicit normal space \test=\expandafter{\fspace} \stest\test\report2 % explicit funny space \test={\stoken} \stest\test\report3 % implicit normal space \test={\ftoken} \stest\test\report4 % implicit funny space \test={!} \stest\test\report5 % implicit active normal space \catcode`\^^99=\active \let^^99= \ftoken \test={^^99\par} \stest\test\report6 % implicit active funny space {\catcode`\*=\active \let*= ^^99 \test={*} \stest\test\report7 % implicit active funny space } \test={} \stest\test\report8 % nonspace \test={{ }} \stest\test\report9 % nonspace \test={\if} \stest\test\report{10} % dangerous nonspace \test={ \par} \stest\test\report{11} % explicit normal space {\catcode`\ =\active\let =\stoken\stoken% \test={ }% \stest\test\report{12} % implicit active normal space } {\catcode`\ =\active\let =\stoken\ftoken% \test={ }% \stest\test\report{13} % implicit active funny space } \bye (end of file) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This is TeX, Version 3.14a for SunOS (preloaded format=plain 91.9.20) 20 SEP 1991 10:13 [ dek: ^^^^^ Note! [Same variations do _not_ work with version 3.14; 3.14a is an experimental "\alpha test" for next release] ] **p377.tex (p377.tex \test=\toks12 1: explicit normalspace 2: explicit funnyspace 3: implicit normalspace 4: implicit funnyspace 5: implicit active normalspace 6: implicit active funnyspace 7: implicit active funnyspace 8: nonspace 9: nonspace 10: nonspace 11: explicit normalspace 12: implicit active normalspace 13: implicit active funnyspace ) No pages of output. (end of file) ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 032 ] ------- 1-Nov-1991 18:56:47-GMT,21066;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02059; Fri, 1 Nov 91 11:56:31 MST Date: Fri 1 Nov 91 13:06:38-EST From: bbeeton Subject: messages from DEK, part 2 To: tex-implementors@MATH.AMS.COM Message-Id: <689018798.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 1 November 91 Message No: 033 To: TeX implementors and distributors From: Barbara Beeton Subject: Messages from DEK, part 2 Here is the second installment of DEK's September comments. ######################################################################## Incompatibility of positive/negative integer values Date: Tue, 20 Aug 91 16:58:09 MDT From: Nelson H.F. Beebe Subject: Perhaps a bug (design flaw) in TeX I think that the `feature' described below qualifies as a design flaw in TeX, and should be reported to Don Knuth if it has not come up before; I came across it while testing the statement on p. 178, l. -11, of @string{SV = "Spring{\-}er-Ver{\-}lag"} @Book{Seroul:beginners-tex, author = "Raymond Seroul and Silvio Levy", title = "A Beginner's Book of {\TeX}", publisher = SV, year = "1991", ISBN = "0-387-97562-4, 3-540-7562-4", note = "This is a translation and adaption by Silvio Levy of \cite{Seroul:tex}.", } about the maximum and minimum integers that TeX can handle. [The text has an error there; I've just completed a comprehensive errata list for it.] TeX does not permit the input of the most negative 32-bit integer (-2^{31}) on two's complement machines, but you can generate it by subtraction ((-2^{-31}+1) - 1) and output it correctly. This makes the statement at the top of p. 118 of the TeXbook a lie: registers are capable of containing the number -2147483648, NOT -2147483647, provided the host architecture has two's complement arithmetic, which is true for almost all machines today, and certainly the vast majority of TeX implementations. UNIVAC and CDC mainframes had one's complement arithmetic, but also had words of more than 32 bits, and as far as I am aware, only some calculators may use sign-magnitude representation; both of these systems have signed zeros, and extreme values that are equal in magnitude. I believe that a programming language, which TeX surely is, ought to be able to read what it can write. This asymmetry could be avoided if the code in section 445 of TeX: The Program accumulated the number as a negative value, then flipped the sign if necessary. Authors of textbooks, computer programs, and language run-time libraries, should not make this mistake, yet the error continues to be repeated. While TeX detects overflow from multiplication, it does not detect overflow from negation. Here is an example: This is TeX, C Version 3.0 % Try the value -(2^{31}) (most negative two's complement number) *\count0=-2147483648 ! Number too big. <*> \count0=-2147483648 % Input the value -(2^{31}-1) *\count0=-2147483647 *\showthe\count0 > -2147483647. % Now generate the most negative two's complement number *\advance \count0 by -1 *\showthe\count0 > -2147483648. % Now demonstrate that integer overflow is undetected on sign inversion: \count1=-\count0 *\showthe\count1 > -2147483648. % However, integer overflow is caught on multiplication: \multiply\count0 by \count0 ! Arithmetic overflow. <*> \multiply\count0 by \count0 ======================================================================== [ dek: TeX is _not_ a programming language in the general sense of supporting arithmetic at extreme values. There are lots of _dimen_ values that TeX can write but not read. Probably a flaw, but a permanent one. In general, arithmetic in TeX is not supposed to push the handling conditions; making that all work would cause significant performance penalty. ] ************************************************************************ File name overflow of string pool [ Since this report, I have seen a couple of other reports on this topic in the electronic discussion lists, mostly from Europe. While not a bug, it can certainly be a serious inconvenience. A couple of the reports have mentioned building nonstandard versions of TeX with a separate pool of file names; not good for compatibility. ] Date: Fri, 12 Jul 91 19:06 +0200 From: "Johannes L. Braams" Subject: Bug/misfeature in TeX? We have run into a problem with TeX. We have an application where we would like to \input about 2400 files. We can't do that because TeX runs out of string pool space. This application is rather important because it concerns the reports the lab has to make each quarter of a year. When I studied TeX the program to find out what happens when a file is being \input I found that the name of the file is stored in string pool. AND it never gets removed from the string pool (as far as I could find out). What I don't understand is why filenames are written to string pool in the first place. Isn't it possible to use some kind of stack or array mechanism to store filenames? It should then be possible to free the memory used to store a filename when the file gets closed and the filename is no longer needed. Do you know the answer or someone who does? Or is this a bug? I would rather call it a design flaw actually. Regards, Johannes Braams PTT Research Neher Laboratorium, P.O. box 421, 2260 AK Leidschendam, The Netherlands. Phone : +31 70 3325051 E-mail : JL_Braams@pttrnl.nl Fax : +31 70 3326477 ------- Date: Mon, 15 Jul 91 01:59:22 BST From: Chris Thompson Subject: Re: Bug/misfeature in TeX? I agree that it's a design flaw, not a bug. People do keep falling over it from time to time, though, so maybe Don could be asked to think about it again. I suspect, however, that there is no easy fix, for reasons I will explain below. Johannes asks why the names go in the string pool in the first place: the answer to that is "why not?"... it is the convenient place to keep more or less arbitrarily long strings. The space occupied by things added to the string pool can be reclaimed, provided it is done straight away, before other parts of TeX have been exercised that may add other strings (especially, control sequence names) to the pool. There are two types of file name to think about (neither of which are reclaimed at the moment, with one partial---and wrong---exception): 1. The 1, 2 or 3 strings generated by |scan_file_name|. Usually these are used in some implementation-dependant way to open a file, and maybe then as arguments to |*_make_name_string|, and are then never needed again; and all this would usually happen straight away. Exception: deferred (non-\immediate) \openout's. 2. The string generated by |*_make_name_string|. For things like the log and DVI files, this has to be kept for ever (printing them is almost the last thing TeX does). The interesting case, however, is \input. The string is printed (immediately), and then stored in the |name_field| of the current input stack entry. *Almost* the only thing TeX uses it for thereafter is as a number > 17 (to distinguish the case of an input level being an \input file (as opposed to terminal input or a \read level). The sole exception is in section 84 where it is used to deal with the "E" response to the error prompt: in distribution TeX as part of a message, but in practice as input to the implementation-dependant way of invoking an editor. (BEGIN ASIDE The ``partial and wrong exception'' is the code in section 537 introduced by change 283. |start_input| reclaims the space occupied by the result of |a_make_name_string|, if that is still the top string in the pool, and replaces it by the `name' part of the results of |scan_file_name|. I have had to undo this "fix" in my implementations: the *only* thing that the ``file name'' is needed for is as an argument to the editor, and it is an unwarranted assumption that a. The values of the `area' and `extension' parts of the name are irrelevant to that purpose, and b. The output of |a_make_name_string| doesn't contain extra information, available as a result of the opening process, that may also be relevant. END ASIDE) In theory the contents of the strings of type 2 for \input files could be kept on some sort of separate stack, as Johannes suggests (parallel to the |input_file| and |line_stack| arrays), but this would be quite convoluted and involve a lot of duplication of code. More plausible would be an attempt to reclaim them if they are still the top string in the pool when the file is closed (in |end_file_reading|); this isn't so unlikely in cases like Johannes'... presumably not all 2400 files can use never-before-encountered control sequences, or he will be running out of other things besides the string pool! The strings of type 1 create a difficulty, however, unless they can be got rid of just after the call of |a_make_name_string| (a certain amount of permuting of the string pool would be required to do that). If they, also, are to be got rid of when the file is closed, again subject to the condition that they are at the top of the pool, one will have to (at least) remember how many of them there were. Some of this would, in fact, be rather easier in METAFONT than TeX. METAFONT's string pool entries have a use count, and reclaiming space consists of purging consecutive entries at the top of the pool whose use counts have all fallen to zero. One could easily arrange that the strings of type 1 had use counts of zero after the opening process was over, and that the strings of type 2 for "input" files had a use count of 1 which was decremented to 0 at close time; then the right things would happen more or less automatically. However, TeX *doesn't* have such use counts, and I don't really suppose Don is going to introduce them in order to solve this problem. Chris Thompson ------- [ dek: I think the strings are also needed for font file names. For ordinary input files I put the special code into \S537 [which CET1 disabled] so that the Math Reviews could input lots of files. Of course there's a workaround (using the operating system to concatenate files!) but otherwise all I can suggest is a local change-file routine that tries to reclaim string space when closing files if the unneeded strings are still at the end of the string pool. You could introduce a new array indexed by 1..max_in_open to keep relevant status information if it isn't already present (see \S304). ] ************************************************************************ TeX -- handling of \newlinechar within \special Date: Thu 9 May 91 09:42:09-EST From: Ron Whitney Subject: \newlinechar within \special Recently I've seen an inconsistency in the way a couple of versions of TeX for the PC handle \newlinechar within \special commands. One (Fuchs, \mu-TeX) gives the same treatment in this case as it does with \write-streams. The others use a more literal interpretation of Knuth's statement on p.228 of The TeXBook regarding what TeX does as it writes out \special information: " TeX doesn't look at the token list to see if it makes sense; the list is simply copied to the output." So if one has \newlinechar=`\^^J, \special{ooh^^Jaah} puts this 9-character sequence into the .dvi file instead of "oohaah". (Of course, the ^^J gets contracted to single token first, then gets blown back up to the 3.) I would have said that \mu-TeX's treatment is the proper one, but perhaps it's understood that the string within the \special is not to be tampered with other than to eat the tokens and then spit them out. Is this an old issue? Is it open to interpretation? ------- Date: Thu, 9 May 91 13:09:08 EDT From: karl@cs.umb.edu (Karl Berry) To: RFW@vax01.ams.com Subject: \newlinechar within \special ron> I would have said that \mu-TeX's treatment is the proper one, but > perhaps it's understood that the string within the \special is not to > be tampered with other than to eat the tokens and then spit them out. > Is this an old issue? Is it open to interpretation? trip.tex seems not to test this. I guess it's open to interpretation, although Knuth should probably be asked. My personal opinion is that ^^J should get turned into a newline character(s); it's easy to turn this feature off (in fact, I suppose it's off by default in plain), after all. karl@cs.umb.edu ------- Date: Thu, 09 May 91 23:54:07 BST From: Chris Thompson Cc: Ron Whitney , Karl Berry Subject: Re: \newlinechar within \special I am afraid that I don't really understand what the postings by Ron Whitney and Karl Berry are saying. The suitably processed token list in a \special ends up in the DVI file. So what does it mean to replace characters equal to \newlinechar in this conext by "newline"? What or whose "newline"? DVI files aren't text files. And if you are going to say "ASCII CR, of course" or "ASCII LF, of course", be prepared to [ dek: ^ _or_ _both_ ] fight off the other 50% of the world :-) If you are going to say "should depend on the implementation", then don't: the contents of the DVI file produced are meant to be implementation-independant. Reference-level TeX does not treat characters equal to \newlinechar specially in \special's; they appear unchanged in the DVI file. The mechanical reason for this is that although |special_out| writes the token list to the string pool (|selector:=new_string|), the special treatment of \newlinechar in TeX sections 58--60 only applies when |selector Subject: RE: RE: \NEWLINECHAR WITHIN \SPECIAL and \message I think that Chris remark that dvi files are to be device independent is questionable as far as specials are concerned. In fact the special is supposed to pass some string to the dvi driver and this means that this program is supposed to understand it. Now this means that the driver needs to interprete the bytes inside the special in the same way as the TeX that writes them out. But if we assume that this is done under some ascii conversion table then why not accept ascii . Not that I see many applications for this. Do I miss something? The whole discussion reminded me of some related business with the newline char of TeX which I think is a bug although one can surely plea for a questionable feature. Compare the output of \newlinechar=`\@ \message{foo@bar} to \newlinechar=`\^^J \message{foo^^Jbar} The first message is broken into two lines the second comes out as is. [ dek: I guess because of certain UNIX implementations coercing all tabs to spaces, those implementation cannot possibly "see" a tab. ? Wait, tab is ^^I. What _is_ going on? Oh, I see; Mittelbach and Sch\"opf are right, see below $10.24 ] Same discrepancy happens with \errormessage which is quite unfortunate and certainly makes macro packages non portable if certain characters can't be entered directly. Whether or not this is covered by the documentation in the TeX book is difficult to say since there are quite a few places where Don leaves things open to interpretation. Frank Mittelbach ------- Date: Fri, 10 May 91 17:09:12 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Cc: PZF5HZ@RUIPC1E.BITNET Subject: RE: RE: \NEWLINECHAR WITHIN \SPECIAL and \message Frank writes: I think that Chris remark that dvi files are to be device independent is questionable as far as specials are concerned. In fact the special is supposed to pass some string to the dvi driver and this means that this program is supposed to understand it. Now this means that the driver needs to interprete the bytes inside the special in the same way as the TeX that writes them out. But if we assume that this is done under some ascii conversion table then why not accept ascii . Not that I see many applications for this. Do I miss something? Yes, you do--at least as far as the new line character is concerned. The point here is that normally the meaning of the \newlinechar is "TeX's internal end-of-line marker", full stop. When writing to a text file (irregardless of the code table) this has a definite meaning, namely: start a new line here, full stop. When it comes to \specials, the notion of "lines" seems at least questionable, even more since the sequence of characters inside a \special need not be anything legible. [ dek: Well, I don't intend 8-bit codes to be going there; I hope they are input from other files by DVI drivers. People might develop binary-coded special conventions but they are too non-portable. The main point in Chris's message is that newline is handled in three completely different ways (on PC, MAC, and UNIX) ] \specials are device-dependent, true. But the consequence of your argumentation is that the same device (say, a PostScript printer) would see a different command on a Unix workstation and an IBM mainframe. Keep in mind that the \special string is not written under the control of the character conversion tables. The whole discussion reminded me of some related business with the newline char of TeX which I think is a bug although one can surely plea for a questionable feature. Compare the output of \newlinechar=`\@ \message{foo@bar} to \newlinechar=`\^^J \message{foo^^Jbar} The first message is broken into two lines the second comes out as is. New, this is something different, since it applies to text files where (as I said above) the notion of "start a new line here" is perfectly sensible. In my eyes this is a bug and should be fixed, even if this behaviour is in conformance with the TeXbook. Rainer Sch\"opf ------- [ dek: Well I've thought about it some more and decided that \special should send 8-bit codes to DVI file without changing the printable ASCII form. This applies also to font file names in case future users want 8-bit codes in those names (nonportable but perhaps important to somebody to see the name in Cyrillic or something). I am changing TeX 3.14 to do this more logically, basically by making 8-bit codes more equal to their printable cousins. At present there are several anomalies [like the string one mentioned w.r.t. Piff's work] [also when you have file names, job names, etc. with nonstandard 8-bit codes], and I think I see how to make it all come out right, ... as a byproduct, Mittelbach's \message problem goes away too. Internally characters will not be translated to ^^A form until the last minute when they simply must be translated. ] ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 033 ] ------- 6-Nov-1991 10:40:22-GMT,2541;000000000001 Return-Path: <@MATH.AMS.COM,@serv02.ZIB-Berlin.DE:schoepf@sc.ZIB-Berlin.DE> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09904; Wed, 6 Nov 91 03:40:17 MST Received: from serv02.ZIB-Berlin.DE by MATH.AMS.COM via SMTP with TCP; Wed, 6 Nov 91 05:32:01-EDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/5.9.91 ) id AA07887; Wed, 6 Nov 91 10:20:13 +0100 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA07978; Wed, 6 Nov 91 10:20:12 +0100 Date: Wed, 6 Nov 91 10:20:12 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9111060920.AA07978@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA22370; Wed, 6 Nov 91 10:20:10 +0100 Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: tex-implementors@math.ams.com, latex-l@dhdurz1.BITNET In-Reply-To: Don Hosek's message of Tue, 5 Nov 1991 14:18 PST <01GCLCQIJV6O9KMF8T@HMCVAX.CLAREMONT.EDU> Subject: Loading additional hyphenation patterns Reply-To: Schoepf@sc.ZIB-Berlin.DE Don Hosek writes about multiple hyphenation patterns. Let me first state that this is my last message on this subject as a refuse to hear and say the same arguments for the umpteenth time. 1. Don's proposal has one important drawback: unless you rename hyphen.tex you are stuck with US english as \language 0. Reason: in TeX3 patterns are cumulative. So, once you've loaded them they are there. 2. I refuse to stick to US english as \language 0 on the simple reason that I am not american. I admit that in my installation I have 0 for US english and 1 for german, but I see no reason whatsoever to have this fixed since someone does not want to rename hyphen.tex. (And I am willing to do this!) The upcoming new version of LaTeX will no longer load hyphen.tex from inside lplain.tex, and I suggest to all other macro package writers to do the same. 3. The whole problem of multi-language support is not yet properly discussed. I *would* like to participate in a discussion based, e.g., Peter Breitenlohner's article in TUGboat. Dr. Rainer Sch"opf Konrad-Zuse-Zentrum ,,Ich mag es nicht, wenn f"ur Informationstechnik Berlin sich die Dinge so fr"uh Heilbronner Strasse 10 am Morgen schon so W-1000 Berlin 31 dynamisch entwickeln!'' Federal Republic of Germany 6-Nov-1991 10:40:26-GMT,2440;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:BROUARD@FRINED51.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB09904; Wed, 6 Nov 91 03:40:23 MST Message-Id: <9111061040.AB09904@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 6 Nov 91 05:36:57-EDT Received: from FRINED51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP V2R1) with BSMTP id 2824; Wed, 06 Nov 91 05:34:42 EST Date: 6 NOV 91 11:30:29.50-GMT From: BROUARD%FRINED51.bitnet@CUNYVM.CUNY.EDU Subject: Hyphenation patterns (not additional patterns) To: TEX-IMPLEMENTORS@MATH.AMS.COM My first impression in reading Don Hosek suggestion, is that something is missing. Where do you define the catcode of 8 bits characters and lccode and uccode before loading the patterns of languages with diacritical signs? In frenhhyph.tex ? No it has to be done explicitly for all languages and using the Cork standard. Otherwise, reading romanian and french patterns, you will do the trick twice and with probably incoherent codes. Again, with TeX 3.0 wich allows 8 bits characters and multiple hyphenations patterns, a lot of code has to be defined not only that described by Don Hosek. We also want to know which patterns are loaded, etc. So if we want something standard as Don Hosek claims, we have to put it in plain and lplain, else we will have such a discussion for many years. Up to know there seems to be only few representatives (in these lists) of countries with diacritical signs, there will more with eastern europe countries. How many people from tex-implementors and latex-l have 8 bits characters on their keyboard (i.e without using CTRL-ALT, ALT iii, compose character, etc)? How many latin publications use diacritical signs? This was the reason of TeX 3.0, but it was not finished to don't alter to much the TeX-Book, so now it is the babel war. In the solution that I suggested earlier the standard plain or lplain read a file like corklcc.tex (for Cork lccode) before loading any pattern. A first step has be done with success the Cork standard, now we must go further. Incidentally most of french people have a bad english accent, it is not chocking to compile all the english do-cu-men-ta-tion on TeX with fren-ch pa- tterns. Having a french text compiled with eng-lish patterns is awful (for us). It was a joke, but please no more english hard coded as 0. Nicolas Brouard 6-Nov-1991 11:14:01-GMT,4181;000000000001 Return-Path: <@uga.cc.uga.edu:LATEX-L@DHDURZ1.BITNET> Received: from uga.cc.uga.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09964; Wed, 6 Nov 91 04:13:58 MST Message-Id: <9111061113.AA09964@math.utah.edu> Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3156; Wed, 06 Nov 91 06:13:16 EST Received: by UGA (Mailer R2.07) id 0885; Wed, 06 Nov 91 06:05:55 EST Date: Tue, 5 Nov 91 14:18:00 PST Reply-To: LaTeX-L Mailing list Sender: LaTeX-L Mailing list From: Don Hosek Subject: Loading additional hyphenation patterns X-To: tex-implementors@math.ams.com, latex-l@dhdurz1 To: "Nelson H.F. Beebe" (The initial version of this message is going to both tex-implementors and latex-l since it started on latex-l but should really continue on tex-implementors.) A couple of weeks ago, I was flamed for my American cultural hegemony for suggesting that there was no good reason not to leave US English hyphenation patterns as pattern 0 in any format file. The arguments against this can be summarized as: (1) Why should we load English hyphenation patterns if we don't typeset English and (2) If we do typeset English, we'd rather load UK English hyphenation patterns. My direct answer to these points is that (1) you're more likely to typeset English than you think since the vast majority of accompanying documentation for TeX-related packages is written in English and (2) the argument for preference of UK patterns is more justifiable, but they aren't yet available (but _are_ under development). However, the direct answer to these points is far from my reason for proposing the scheme that I did; rather I would like to suggest a plan for multiple language definitions which has worked rather well in the multilingual environments that I use (yes, Americans are aware that there are other languages). First, the following criteria were developed for a multiple hyphenation support system: - None of the standard files should be changed. Not even to be renamed. - The scheme should work as an add-on to any format (plain, lplain, splain, amstex, lamstex, etc.) Towards this goal, the following plan seems to work pretty well. US English as defined by hyphen.tex is always present, but one doesn't _have_ to use it. First, one creates a file, say langs.tex which is best presented ab exemplo: \chardef\usenglish=0 \def\USEnglish{\language\usenglish \lefthyphenmin=2 \righthyphenmin=3} \newlanguage\french \language\french \input frhypha.tex % Load French hyphenation patterns \def\French{\language\french \lefthyphenmin=2 % I admit these values are guesses and conceivably wrong. \righthyphenmin=3} \newlanguage\german \language\german \input dehypha.tex % Load German hyphenation patterns \def\German{\language\german \lefthyphenmin=2 \righthyphenmin=3} .. [ and so on ] \USEnglish % Set the default patterns A multilingual plain is then generated by initex plain \input langs \dump multilingual lplain initex lplain \input langs \dump and so forth. The choice of US English as the default patterns is strictly arbitrary, but for historical reasons, it might not be unreasonable to assume either US or UK English as the default and expect other languages to be explicitly indicated (or not--I have no strong feelings one way or the other on this issue). The definitions of \German, \USEnglish, etc. should probably be tied in with the babel package (I don't remember, does it have a plain interface or no?). The key idea here is simply the idea of having the additional languages added in at the "local modifications" stage of format generation. Certainly, it woudl seem to be better to avoid renaming hyphen.tex as most multiple-hyphenation schemes require. -dh btw, am I the only one who wishes that \patterns had stopped being restricted to initex with TeX 3.0? Perhaps the new LaTeX should be designed to have to run under IniTeX rather than VirTeX? Don Hosek dhosek@ymir.claremont.edu Quixote Digital Typography 714-621-1291 6-Nov-1991 19:20:12-GMT,5278;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13910; Wed, 6 Nov 91 12:20:02 MST Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 6 Nov 91 13:59:42-EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GCMJXS4ADI8WVZJS@HMCVAX.CLAREMONT.EDU>; Wed, 6 Nov 1991 10:55 PST Date: Wed, 6 Nov 1991 10:55 PST From: Don Hosek Subject: Re: Hyphenation patterns (not additional patterns) To: tex-implementors@math.ams.com Message-Id: <01GCMJXS4ADI8WVZJS@HMCVAX.CLAREMONT.EDU> X-Vms-To: TEX_IMPLEMENTORS -My first impression in reading Don Hosek suggestion, is that -something is missing. Where do you define the catcode of 8 bits -characters and lccode and uccode before loading the patterns -of languages with diacritical signs? In frenhhyph.tex ? No -it has to be done explicitly for all languages and using the Cork -standard. Otherwise, reading romanian and french patterns, you will do the trick -twice and with probably incoherent codes. A shortcoming that while valid does not destroy the proposal; at the moment, the system that I described was using the character set of Tom Rokicki's afm2tfm which I personally don't like, but I haven't gotten around to changing it. - Again, with TeX 3.0 wich allows 8 bits characters and multiple hyphenations -patterns, a lot of code has to be defined not only that described by Don Hosek. -We also want to know which patterns are loaded, etc. So if we want something -standard as Don Hosek claims, we have to put it in plain and lplain, else we -will have such a discussion for many years. No. We can add it into the langs.tex file that I described. It makes more sense for it to be there any way since it's shared between plain, lplain, etc. anyway. -Up to know there seems to be -only few representatives (in these lists) of countries with diacritical signs, -there will more with eastern europe countries. How many people from -tex-implementors and latex-l have 8 bits characters on their keyboard (i.e -without using CTRL-ALT, ALT iii, compose character, etc)? How many latin -publications -use diacritical signs? This was the reason of TeX 3.0, but it was not finished -to don't alter to much the TeX-Book, so now it is the babel war. That the changes made to TeX for 3.0 are inadequate, I will not argue. I will however claim that if we're looking for a TeX solution than we need to except that certain routes are not acceptable. Michael Ferguson's \charsubdef extension is an example of an extension that makes a great deal of sense and in an unrestricted situation would be the best solution, however, it is not TeX so... As regards keyboards, I don't particularly think that it's terribly important how one enters character code 166 whether through a compose sequence, the a-umluat key or pressing down both foot pedals and rubbing one's stomach while typing the character code in base-9 notation on the auxiliary keypad. In fact, for the purposes of this discussion, even particular character sets aren't particularly relevant. Michael Ferguson (are you listening Michael?) had come up with a scheme where 8-bit hyphenation patterns could be expressed independently of the actual character set used through some clever macro expansion. -In the solution that I suggested earlier the standard plain -or lplain read a file like corklcc.tex (for Cork lccode) before loading -any pattern. A first step has be done with success the Cork standard, now we -must go further. No argument on this point. I do something similar with my code, but not necessarily in the most logical place (which would, I believe, be langs.tex or its equivalent). -Incidentally most of french people have a bad english accent, it is not -chocking to compile all the english do-cu-men-ta-tion on TeX with fren-ch pa- -tterns. Having a french text compiled with eng-lish patterns is awful -(for us). It was a joke, but please no more english hard coded as 0. But with TeX 3.0, it doesn't matter whether you have Tagalog as language 0: as long as the French patterns are loaded and selected you'll get proper French hyphenation in your document. As an aside, I've gotten the impression that certain files were to be considered "sacred" and untouchable except by DEK. These included the obvious *.WEB files plus plain.tex and hyphen.tex. It's this basis that I've arranged my scheme around. On another aside, I must say that after reading Rainer's reply to my posting that it doesn't matter much what I suggest since there's an assumption that as an American I don't understand and appreciate the problems of European typesetting. This view is, IMHO, a large pile of excrement. I am not monolingual and as I've said before, in my work which is almost exclusively a wide variety of TeX applications, I typeset a broader selection of languages than probably anyone else on any of these discussion lists. However, if by virtue of having been born in the wrong country speaking the wrong language and hyphenating at the wrong places my comments are to be considered valueless by the European TeX community, than just say so and I'll shut up. -dh 6-Nov-1991 19:20:17-GMT,1428;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB13910; Wed, 6 Nov 91 12:20:13 MST Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 6 Nov 91 13:29:02-EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GCMIX3YII88WVZJS@HMCVAX.CLAREMONT.EDU>; Wed, 6 Nov 1991 10:26 PST Date: Wed, 6 Nov 1991 10:26 PST From: Don Hosek Subject: Re: Loading additional hyphenation patterns To: J.L.Braams%pttrnl.nl@pucc.PRINCETON.EDU, tex-implementors@math.ams.com Message-Id: <01GCMIX3YII88WVZJS@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"J.L.Braams%pttrnl.nl@pucc.PRINCETON.EDU" X-Vms-Cc: TEX_IMPLEMENTORS -> btw, am I the only one who wishes that \patterns had stopped -> being restricted to initex with TeX 3.0? Perhaps the new LaTeX -> should be designed to have to run under IniTeX rather than -> VirTeX? - I'm not so sure that is such a good idea. Processing the patterns - does take quite some time. It would be hard to explain to the - users why processing their documents suddenly takes so much more - time. Well the most commonly used patterns could still be preloaded and only unliklely patterns (say, Turkish or Bashkirian) would be loaded in this fashion. But the point is not terribly important. -dh 6-Nov-1991 20:56:30-GMT,1109;000000000001 Return-Path: <@MATH.AMS.COM,@neuron.cs.tamu.edu:bart@cs.tamu.edu> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14546; Wed, 6 Nov 91 13:56:25 MST Received: from neuron.cs.tamu.edu by MATH.AMS.COM via SMTP with TCP; Wed, 6 Nov 91 15:53:00-EDT Received: by neuron.cs.tamu.edu (AA18009); Wed, 6 Nov 91 13:34:52 CST Date: Wed, 6 Nov 91 13:34:52 CST From: bart@cs.tamu.edu (Bart Childs) Message-Id: <9111061934.AA18009@neuron.cs.tamu.edu> To: tex-implementors@math.ams.com Subject: Whole module changes are OK Peter Breitenlohner's comment about additional modules being flagged by weave as ``changed'' did not show up on the tests I just did in any case for the three versions of weave: @d banner=='This is WEAVE, Version 4' I got this from labrea @d banner "This is CWEAVE ($Revision: 2.1$)\n" ditto Version 1.20a of fweave from lyman.pppl.gov. This is not the current one and I will have 1.21 installed this week (I hope). In every case the only extra module is the INDEX module, but it has changed though not from a change entry for its module. Bart Childs 7-Nov-1991 7:35:13-GMT,1205;000000000001 Return-Path: <@MATH.AMS.COM,@CBROWN.CLAREMONT.EDU:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18028; Thu, 7 Nov 91 00:35:09 MST Received: from CBROWN.CLAREMONT.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 7 Nov 91 02:26:12-EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GCNA2G7EDS8WW18R@HMCVAX.CLAREMONT.EDU>; Wed, 6 Nov 1991 23:23 PST Date: Wed, 6 Nov 1991 23:23 PST From: Don Hosek Subject: Question regarding patterns vs. exceptions To: tex-implementors@math.ams.com Message-Id: <01GCNA2G7EDS8WW18R@HMCVAX.CLAREMONT.EDU> X-Vms-To: TEX_IMPLEMENTORS Perhaps someone more versed with the internals of TeX than myself can answer this question for me: looking over Gerard Kuiken's extended hyphenation patterns, it is clear that most of the pattern lines apply to a single word only (or in some cases a small set of words). How does using the extended patterns compare to using the regular patterns with an extended exception dictionary? Which allows for faster typesetting? Smaller format files, etc. What English word contains the letter combination "xq"? -dh 7-Nov-1991 10:16:38-GMT,2835;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:UCIR001@FRORS12.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18416; Thu, 7 Nov 91 03:16:34 MST Resent-Message-Id: <9111071016.AA18416@math.utah.edu> Message-Id: <9111071016.AA18416@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 7 Nov 91 05:06:30-EDT Received: from FRORS12.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP V2R1) with BSMTP id 7755; Thu, 07 Nov 91 03:52:32 EST Received: from FRORS12.BITNET (UCIR001) by FRORS12.BITNET (Mailer R2.08 R208004) with BSMTP id 7411; Thu, 07 Nov 91 09:50:05 EDT Resent-Date: Thu, 07 Nov 91 09:49:40 EDT Resent-From: Gaulle Bernard Resent-To: LSV IMPLEM Date: Thu, 07 Nov 91 09:11:11 EDT From: Gaulle Bernard Subject: Re: Loading additional hyphenation patterns To: RAINER SCHOEPF In-Reply-To: Message of Wed, 6 Nov 91 10:20:12 +0100 from There were different and separate topics addressed in the previous messages. In reverse order: - Use Initex instead Virtex is quite the same thing for me that use a prototype in place of a completed prodcut: it's dangerous. Okey for testers or developers or ... but not everybody. - Multi-lingual aspects: in my opinion multi-lingual stuff is devided in two parts, 1) hyphenation and 2) other things like --of course-- typography. The first one need to be solved at a (x)plain level and the second could be implemented via a language_dependent_style_file - (x)plain is (nowadays) changed in (probably all) non-english installations. A "clean" solution remains to change the line \input hyphen by \input my_installation_dependent_hyphenation_coding It's clear that this name of file can be standardised, let's say hyconfig.tex - Johanes had an excellent idea and coded it in his Babel mechanism, i mean the idea to create a configuration file, language.dat which contains line by line a language_name and an hyphenation_file_name This is an excellent idea because for at least two reasons 1) allow to define a command \ and 2) allow the Language_designers to insert simply, properly, ... their hyphenation patterns (at least). As a corrollary to the first, there would be nomore need of \language count in users texts. The code to do this in hyconfig.tex is really quite simple and could be used --i think-- with all packages. - Patterns processing only allowed at Initex time is a pity: it force 1) users not aware, to use only english patterns in their language 2) the need of a TeX installator: this is brake in the widespread TeX uasge. Hope that DEK understands that. Regards, --bg 7-Nov-1991 12:39:22-GMT,100068;000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:BROUARD@FRINED51.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20389; Thu, 7 Nov 91 05:39:01 MST Message-Id: <9111071239.AA20389@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 7 Nov 91 06:54:08-EDT Received: from FRINED51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP V2R1) with BSMTP id 9219; Thu, 07 Nov 91 06:52:16 EST Date: 7 NOV 91 12:43:49.22-GMT From: BROUARD%FRINED51.bitnet@CUNYVM.CUNY.EDU Subject: Macintosh/Textures Haralambous solution To: TEX-IMPLEMENTORS@MATH.AMS.COM Yannis Haralambous sent to me the files he will used in the Texture TeX implementations, for patterns loading and languages macros. He has worked a lot on this field and presented a paper at EuroTeX'91. Textures want to promote TeX in the Wysiwyg Macintosh world arguing that TeX or LaTeX is the only software being able to propose multiple and correct hyphenations in a lot of languages and that is easy to move between languages. He is greek and speaks many languages (some papers have been published in TugBoat). He will distribute the Macintosh GUTenberg distribution as soon as new latex with hyphenation patterns schemes is ready. He claims a lot of insuffisances of TeX not only in macros but also in the web sources. It could be a nice idea if he could participates to one of the list discussing these problems (he is willing to). His bitnet address is yannis@frcitl71. I still don't know where the discussion should continue and post this mail to latex and implementors. The including file contains 8 bits characters as mailers should theoretically not truncate them. But a tar compressed uuencode file is also included at the end! I let you remember that the Macintosh 8 bits standard as nothing to do with iso8859 nor pc850. It has its own creazy standard like pc850. It should be better to use the tex notations ^^ff and tex commands (\'e) if available, after a comment sign: \catcode ^^ff % \'e but i have no time for doing it now. Does any one have a filter translating pc850, pc437, iso8859, macintosh, cork, tex ^^ff notations, tex macros commands in all directions, adopting a nice solution if translation is not possible? Nicolas Brouard Files included are: actives.tex dc-codes.tex dc-plain.tex french_macros.tex us_macros.tex % === This is actives.tex for Macintosh by Yannis Haralambous % this file contains 8 bits characters. %Macintosh encoding characters-->DC font \catcode`\=\active\catcode`\=\active\catcode`\=\active\catcode`\=\active\cat code`\=\active\catcode`\ =\active \catcode`\=\active\catcode`\=\active\catcode`\=\active\catcode`\=\active\cat code`\=\active\catcode`\=\active \catcode`\=\active\catcode`\=\active\catcode`\=\active\catcode`\=\active\cat code`\=\active\catcode`\=\active \catcode`\=\active\catcode`\=\active\catcode`\=\active\catcode`\=\active\cat code`\=\active\catcode`\=\active \catcode`\=\active\catcode`\=\active\catcode`\=\active\catcode`\=\active\cat code`\=\active\catcode`\=\active \catcode`\=\active\catcode`\g=\active\catcode`\+=\active\catcode`\=\active\cat code`\c=\active\catcode`\1=\active \catcode`\2=\active\catcode`\|=\active\catcode`\V=\active\catcode`\=\active\cat code`\=\active\catcode`\N=\active \catcode`\=\active\catcode`\q=\active\catcode`\5=\active\catcode`\6=\active\cat code`\]=\active\catcode`\X=\active \catcode`\D=\active\catcode`\K=\active\catcode`\J=\active\catcode`\>=\active\cat code`\h=\active\catcode`\l=\active \catcode`\m=\active\catcode`\!=\active\catcode`\-=\active\catcode`\t=\active\cat code`\#=\active\catcode`\=\active \catcode`\ =\active \def\DCdefs$% \def $\char"C4$\def $\char"C5$\def $\char"C7$\def $\char"C9$\def $\char"D1$\def $\char"D6$% \def $\char"DC$\def $\char"E1$\def $\char"E0$\def $\char"E2$\def $\char"E4$\def $\char"E3$% \def $\char"E5$\def $\char"E7$\def $\char"E9$\def $\char"E8$\def $\char"EA$\def $\char"EB$% \def $\char"ED$\def $\char"EC$\def $\char"EE$\def $\char"EF$\def $\char"F1$\def $\char"F3$% \def $\char"F2$\def $\char"F4$\def $\char"F6$\def $\char"F5$\def $\char"FA$\def $\char"F9$% \def $\char"FB$\def g$\char"FC$\def +$\char"FF$\def $\char"C6$\def c$\char"D8$\def 1$\char"E6$% \def 2$\char"F8$\def |$\char"BE$\def V$\char"BD$\def $\char"C0$\def $\char"C3$\def N$\char"D5$% \def $\char"D7$\def q$\char"F7$\def 5$\char"BC$\def 6$\char"9C$\def ]$\char"C2$\def X$\char"CA$% \def D$\char"C1$\def K$\char"CB$\def J$\char"C8$\def >$\char"CD$\def h$\char"CE$\def l$\char"CF$% \def m$\char"CC$\def !$\char"D3$\def -$\char"D4$\def t$\char"D2$\def #$\char"DA$\def $\char"DB$% \def $\char"D9$ % % \catcode`\==\active\catcode`\ =\active\catcode`\D=\active\catcode`\?=\active\cat code`\]=\active\catcode`\3=\active \catcode`\K=\active\catcode`\=\active\catcode`\J=\active\catcode`\h=\active\cat code`\l=\active\catcode`\m=\active \catcode`\!=\active\catcode`\>=\active\catcode`\-=\active\catcode`\u=\active\cat code`\#=\active\catcode`\=\active \catcode`\i=\active\catcode`\ =\active\catcode`\Q=\active\catcode`\X=\active\cat code`\d=\active\catcode`\Y=\active \catcode`\=\active\catcode`\|=\active\catcode`\7=\active\catcode`\8=\active\cat code`\9=\active\catcode`\f=\active \catcode`\<=\active\catcode`\t=\active\catcode`\w=\active\catcode`\p=\active\cat code`\z=\active\catcode`\'=\active \catcode`\(=\active\catcode`\]=\active\catcode`\a=\active\catcode`\ code`\^=\active\catcode`\=\active \catcode`\=\active\catcode`\k=\active\catcode`\,=\active\catcode`\W=\active\cat code`\=\active\catcode`\=\active \catcode`\V=\active\catcode`\=\active\catcode`\x=\active\catcode`\b=\active\cat code`\=\active\catcode`\*=\active \catcode`\s=\active\catcode`\=\active\catcode`\=\active\catcode`\=\active\cat code`\1=\active\catcode`\2=\active \catcode`\N=\active\catcode`\=\active\catcode`\y=\active\catcode`\5=\active\cat code`\6=\active\catcode`\}=\active \catcode`\;=\active\catcode`\=\active\catcode`\0=\active \def\GRdefs$% \def =$a\def $b\def D$g\def ?$d\def ]$e\def 3$z\def K$h\def $j\def J$i\def h$k\def l$l\def m$m% \def !$n\def >$x\def -$o\def u$p\def #$r\def $s\def i$c\def $t\def Q$u\def X$f\def d$q\def Y$y% \def $w\def |$'a\def 7$'e\def 8$'h\def 9$'i\def f$'o\def <$'u\def t$'w\def w$"i\def p$"u\def z$"'i% \def '$"'u\def ($A\def ]$B\def a$G\def k$J\def ,$I\def W$K\def $L% \def $M\def V$N\def $X\def x$O\def b$P\def $R\def *$S\def s$T\def $U\def $F\def $Q\def 1$Y% \def 2$W\def N$'A\def $'E\def y$'H\def 5$'I\def 6$'O\def }$'U\def ;$'W\def $"I\def 0$"U % % \endinput % === end of actives.tex for Macintosh % === This is dc-codes.tex by Yannis Haralambous \catcode"80=11\lccode"80="A0\uccode"80="80 \catcode"81=11\lccode"81="A1\uccode"81="81 \catcode"82=11\lccode"82="A2\uccode"82="82 \catcode"83=11\lccode"83="A3\uccode"83="83 \catcode"84=11\lccode"84="A4\uccode"84="84 \catcode"85=11\lccode"85="A5\uccode"85="85 \catcode"86=11\lccode"86="A6\uccode"86="86 \catcode"87=11\lccode"87="A7\uccode"87="87 \catcode"88=11\lccode"88="A8\uccode"88="88 \catcode"89=11\lccode"89="A9\uccode"89="89 \catcode"8A=11\lccode"8A="AA\uccode"8A="8A \catcode"8B=11\lccode"8B="AB\uccode"8B="8B \catcode"8C=11\lccode"8C="AC\uccode"8C="8C \catcode"8D=11\lccode"8D="AD\uccode"8D="8D \catcode"8E=11\lccode"8E="AE\uccode"8E="8E \catcode"8F=11\lccode"8F="AF\uccode"8F="8F \catcode"90=11\lccode"90="B0\uccode"90="90 \catcode"91=11\lccode"91="B1\uccode"91="91 \catcode"92=11\lccode"92="B2\uccode"92="92 \catcode"93=11\lccode"93="B3\uccode"93="93 \catcode"94=11\lccode"94="B4\uccode"94="94 \catcode"95=11\lccode"95="B5\uccode"95="95 \catcode"96=11\lccode"96="B6\uccode"96="96 \catcode"97=11\lccode"97="B7\uccode"97="97 \catcode"98=11\lccode"98="B8\uccode"98="98 \catcode"99=11\lccode"99="B9\uccode"99="99 \catcode"9A=11\lccode"9A="BA\uccode"9A="9A \catcode"9B=11\lccode"9B="BB\uccode"9B="9B \catcode"9C=11\lccode"9C="BC\uccode"9C="9C \catcode"9D=11\lccode"9D="69\uccode"9D="9D%Turkish I with dot \catcode"9E=11\lccode"9E="9E\uccode"9E="D0%d with bar \catcode"C0=11\lccode"C0="E0\uccode"C0="C0 \catcode"C1=11\lccode"C1="E1\uccode"C1="C1 \catcode"C2=11\lccode"C2="E2\uccode"C2="C2 \catcode"C3=11\lccode"C3="E3\uccode"C3="C3 \catcode"C4=11\lccode"C4="E4\uccode"C4="C4 \catcode"C5=11\lccode"C5="E5\uccode"C5="C5 \catcode"C6=11\lccode"C6="E6\uccode"C6="C6 \catcode"C7=11\lccode"C7="E7\uccode"C7="C7 \catcode"C8=11\lccode"C8="E8\uccode"C8="C8 \catcode"C9=11\lccode"C9="E9\uccode"C9="C9 \catcode"CA=11\lccode"CA="EA\uccode"CA="CA \catcode"CB=11\lccode"CB="EB\uccode"CB="CB \catcode"CC=11\lccode"CC="EC\uccode"CC="CC \catcode"CD=11\lccode"CD="ED\uccode"CD="CD \catcode"CE=11\lccode"CE="EE\uccode"CE="CE \catcode"CF=11\lccode"CF="EF\uccode"CF="CF \catcode"D0=11\lccode"D0="F0\uccode"D0="D0 \catcode"D1=11\lccode"D1="F1\uccode"D1="D1 \catcode"D2=11\lccode"D2="F2\uccode"D2="D2 \catcode"D3=11\lccode"D3="F3\uccode"D3="D3 \catcode"D4=11\lccode"D4="F4\uccode"D4="D4 \catcode"D5=11\lccode"D5="F5\uccode"D5="D5 \catcode"D6=11\lccode"D6="F6\uccode"D6="D6 \catcode"D7=11\lccode"D7="F7\uccode"D7="D7 \catcode"D8=11\lccode"D8="F8\uccode"D8="D8 \catcode"D9=11\lccode"D9="F9\uccode"D9="D9 \catcode"DA=11\lccode"DA="FA\uccode"DA="DA \catcode"DB=11\lccode"DB="FB\uccode"DB="DB \catcode"DC=11\lccode"DC="FC\uccode"DC="DC \catcode"DD=11\lccode"DD="FD\uccode"DD="DD \catcode"DE=11\lccode"DE="FE\uccode"DE="DE \catcode"DF=11\lccode"DF="FF\uccode"DF="DF % \catcode"A0=11\lccode"A0="A0\uccode"A0="80 \catcode"A1=11\lccode"A1="A1\uccode"A1="81 \catcode"A2=11\lccode"A2="A2\uccode"A2="82 \catcode"A3=11\lccode"A3="A3\uccode"A3="83 \catcode"A4=11\lccode"A4="A4\uccode"A4="84 \catcode"A5=11\lccode"A5="A5\uccode"A5="85 \catcode"A6=11\lccode"A6="A6\uccode"A6="86 \catcode"A7=11\lccode"A7="A7\uccode"A7="87 \catcode"A8=11\lccode"A8="A8\uccode"A8="88 \catcode"A9=11\lccode"A9="A9\uccode"A9="89 \catcode"AA=11\lccode"AA="AA\uccode"AA="8A \catcode"AB=11\lccode"AB="AB\uccode"AB="8B \catcode"AC=11\lccode"AC="AC\uccode"AC="8C \catcode"AD=11\lccode"AD="AD\uccode"AD="8D \catcode"AE=11\lccode"AE="AE\uccode"AE="8E \catcode"AF=11\lccode"AF="AF\uccode"AF="8F \catcode"B0=11\lccode"B0="B0\uccode"B0="90 \catcode"B1=11\lccode"B1="B1\uccode"B1="91 \catcode"B2=11\lccode"B2="B2\uccode"B2="92 \catcode"B3=11\lccode"B3="B3\uccode"B3="93 \catcode"B4=11\lccode"B4="B4\uccode"B4="94 \catcode"B5=11\lccode"B5="B5\uccode"B5="95 \catcode"B6=11\lccode"B6="B6\uccode"B6="96 \catcode"B7=11\lccode"B7="B7\uccode"B7="97 \catcode"B8=11\lccode"B8="B8\uccode"B8="98 \catcode"B9=11\lccode"B9="B9\uccode"B9="99 \catcode"BA=11\lccode"BA="BA\uccode"BA="9A \catcode"BB=11\lccode"BB="BB\uccode"BB="9B \catcode"BC=11\lccode"BC="BC\uccode"BC="9C \catcode"E0=11\lccode"E0="E0\uccode"E0="C0 \catcode"E1=11\lccode"E1="E1\uccode"E1="C1 \catcode"E2=11\lccode"E2="E2\uccode"E2="C2 \catcode"E3=11\lccode"E3="E3\uccode"E3="C3 \catcode"E4=11\lccode"E4="E4\uccode"E4="C4 \catcode"E5=11\lccode"E5="E5\uccode"E5="C5 \catcode"E6=11\lccode"E6="E6\uccode"E6="C6 \catcode"E7=11\lccode"E7="E7\uccode"E7="C7 \catcode"E8=11\lccode"E8="E8\uccode"E8="C8 \catcode"E9=11\lccode"E9="E9\uccode"E9="C9 \catcode"EA=11\lccode"EA="EA\uccode"EA="CA \catcode"EB=11\lccode"EB="EB\uccode"EB="CB \catcode"EC=11\lccode"EC="EC\uccode"EC="CC \catcode"ED=11\lccode"ED="ED\uccode"ED="CD \catcode"EE=11\lccode"EE="EE\uccode"EE="CE \catcode"EF=11\lccode"EF="EF\uccode"EF="CF \catcode"F0=11\lccode"F0="F0\uccode"F0="D0 \catcode"F1=11\lccode"F1="F1\uccode"F1="D1 \catcode"F2=11\lccode"F2="F2\uccode"F2="D2 \catcode"F3=11\lccode"F3="F3\uccode"F3="D3 \catcode"F4=11\lccode"F4="F4\uccode"F4="D4 \catcode"F5=11\lccode"F5="F5\uccode"F5="D5 \catcode"F6=11\lccode"F6="F6\uccode"F6="D6 \catcode"F7=11\lccode"F7="F7\uccode"F7="D7 \catcode"F8=11\lccode"F8="F8\uccode"F8="D8 \catcode"F9=11\lccode"F9="F9\uccode"F9="D9 \catcode"FA=11\lccode"FA="FA\uccode"FA="DA \catcode"FB=11\lccode"FB="FB\uccode"FB="DB \catcode"FC=11\lccode"FC="FC\uccode"FC="DC \catcode"FD=11\lccode"FD="FD\uccode"FD="DD \catcode"FE=11\lccode"FE="FE\uccode"FE="DE \catcode"FF=11\lccode"FF="FF\uccode"FF="DF \endinput % === end of dc-codes.tex% === This is dc-plain.tex by Yannis Haralambous (line added by NBrouard) % 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. \catcode`\$=1 % left brace is begin-group character \catcode`\=2 % right brace is end-group character \catcode`\$=3 % dollar sign is math shift \catcode`\&=4 % ampersand is alignment tab \catcode`\#=6 % hash mark is macro parameter character \catcode`\^=7 \catcode`\^^K=7 % circumflex and uparrow are for superscripts \catcode`\_=8 \catcode`\^^A=8 % underline and downarrow are for subscripts \catcode`\^^I=10 % ascii tab is a blank space \chardef\active=13 \catcode`\~=\active % tilde is active \catcode`\^^L=\active \outer\def^^L$\par % ascii form-feed is "\outer\par" \message$Preloading the plain format: codes, % We had to define the \catcodes right away, before the message line, % since \message uses the $ and  characters. % When INITEX (the TeX initializer) starts up, % it has defined the following \catcode values: % \catcode`\^^@=9 % ascii null is ignored % \catcode`\^^M=5 % ascii return is end-line % \catcode`\\=0 % backslash is TeX escape character % \catcode`\%=14 % percent sign is comment character % \catcode`\ =10 % ascii space is blank space % \catcode`\^^?=15 % ascii delete is invalid % \catcode`\A=11 ... \catcode`\Z=11 % uppercase letters % \catcode`\a=11 ... \catcode`\z=11 % lowercase letters % all others are type 12 (other) % Here is a list of the characters that have been specially catcoded: \def\dospecials$\do\ \do\\\do\$\do\\do\$\do\&% \do\#\do\^\do\^^K\do\_\do\^^A\do\%\do\~ % (not counting ascii null, tab, linefeed, formfeed, return, delete) % Each symbol in the list is preceded by \do, which can be defined % if you want to do something to every item in the list. % We make @ signs act like letters, temporarily, to avoid conflict % between user names and internal control sequences of plain format. \catcode`@=11 % INITEX sets up \mathcode x=x, for x=0..127, except that % \mathcode x=x+"7100, for x = `A to `Z and `a to `z; % \mathcode x=x+"7000, for x = `0 to `9. % The following changes define internal codes as recommended % in Appendix C of The TeXbook: \mathcode`\^^@="2201 % \cdot \mathcode`\^^A="3223 % \downarrow \mathcode`\^^B="010B % \alpha \mathcode`\^^C="010C % \beta \mathcode`\^^D="225E % \land \mathcode`\^^E="023A % \lnot \mathcode`\^^F="3232 % \in \mathcode`\^^G="0119 % \pi \mathcode`\^^H="0115 % \lambda \mathcode`\^^I="010D % \gamma \mathcode`\^^J="010E % \delta \mathcode`\^^K="3222 % \uparrow \mathcode`\^^L="2206 % \pm \mathcode`\^^M="2208 % \oplus \mathcode`\^^N="0231 % \infty \mathcode`\^^O="0140 % \partial \mathcode`\^^P="321A % \subset \mathcode`\^^Q="321B % \supset \mathcode`\^^R="225C % \cap \mathcode`\^^S="225B % \cup \mathcode`\^^T="0238 % \forall \mathcode`\^^U="0239 % \exists \mathcode`\^^V="220A % \otimes \mathcode`\^^W="3224 % \leftrightarrow \mathcode`\^^X="3220 % \leftarrow \mathcode`\^^Y="3221 % \rightarrow \mathcode`\^^Z="8000 % \ne \mathcode`\^^[="2205 % \diamond \mathcode`\^^\="3214 % \le \mathcode`\^^]="3215 % \ge \mathcode`\^^^="3211 % \equiv \mathcode`\^^_="225F % \lor \mathcode`\ ="8000 % \space \mathcode`\!="5021 \mathcode`\'="8000 % ^\prime \mathcode`\(="4028 \mathcode`\)="5029 \mathcode`\*="2203 % \ast \mathcode`\+="202B \mathcode`\,="613B \mathcode`\-="2200 \mathcode`\.="013A \mathcode`\/="013D \mathcode`\:="303A \mathcode`\;="603B \mathcode`\<="313C \mathcode`\=="303D \mathcode`\>="313E \mathcode`\?="503F \mathcode`\[="405B \mathcode`\\="026E % \backslash \mathcode`\]="505D \mathcode`\_="8000 % \_ \mathcode`\$="4266 \mathcode`\|="026A \mathcode`\="5267 \mathcode`\^^?="1273 % \smallint % INITEX sets \uccode`x=`X and \uccode `X=`X for all letters x, % and \lccode`x=`x, \lccode`X=`x; all other values are zero. % No changes to those tables are needed in plain TeX format. % INITEX sets \sfcode x=1000 for all x, except that \sfcode`X=999 % for uppercase letters. The following changes are needed: \sfcode`\)=0 \sfcode`\'=0 \sfcode`\]=0 % The \nonfrenchspacing macro will make further changes to \sfcode values. % Finally, INITEX sets all \delcode values to -1, except \delcode`.=0 \delcode`\(="028300 \delcode`\)="029301 \delcode`\[="05B302 \delcode`\]="05D303 \delcode`\<="26830A \delcode`\>="26930B \delcode`\/="02F30E \delcode`\|="26A30C \delcode`\\="26E30F % N.B. $ and  should NOT get delcodes; otherwise parameter grouping fails! % To make the plain macros more efficient in time and space, % several constant values are declared here as control sequences. % If they were changed, anything could happen; so they are private symbols. \chardef\@ne=1 \chardef\tw@=2 \chardef\thr@@=3 \chardef\sixt@@n=16 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chardef\fift@@n=15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chardef\@cclv=255 \mathchardef\@cclvi=256 \mathchardef\@m=1000 \mathchardef\@M=10000 \mathchardef\@MM=20000 % Allocation of registers % Here are macros for the automatic allocation of \count, \box, \dimen, % \skip, \muskip, and \toks registers, as well as \read and \write % stream numbers, \fam codes, and \insert numbers. \message$registers, % When a register is used only temporarily, it need not be allocated; % grouping can be used, making the value previously in the register return % after the close of the group. The main use of these macros is for % registers that are defined by one macro and used by others, possibly at % different nesting levels. All such registers should be defined through % these macros; otherwise conflicts may occur, especially when two or more % more macro packages are being used at once. % The following counters are reserved: % 0 to 9 page numbering % 10 count allocation % 11 dimen allocation % 12 skip allocation % 13 muskip allocation % 14 box allocation % 15 toks allocation % 16 read file allocation % 17 write file allocation % 18 math family allocation % 19 insert allocation % 20 the most recently allocated number % 21 constant -1 % New counters are allocated starting with 22, 23, etc. Other registers are % allocated starting with 10. This leaves 0 through 9 for the user to play % with safely, except that counts 0 to 9 are considered to be the page and % subpage numbers (since they are displayed during output). In this scheme, % \count 10 always contains the number of the highest-numbered counter that % has been allocated, \count 14 the highest-numbered box, etc. % Inserts are given numbers 254, 253, etc., since they require a \count, % \dimen, \skip, and \box all with the same number; \count 19 contains the % lowest-numbered insert that has been allocated. Of course, \box255 is % reserved for \output; \count255, \dimen255, and \skip255 can be used freely. % It is recommends that macro designers always use % \global assignments with respect to registers numbered 1, 3, 5, 7, 9, and % always non-\global assignments with respect to registers 0, 2, 4, 6, 8, 255. % This will prevent ``save stack buildup'' that might otherwise occur. \count10=21 % allocates \count registers 22, 23, ... \count11=9 % allocates \dimen registers 10, 11, ... \count12=9 % allocates \skip registers 10, 11, ... \count13=9 % allocates \muskip registers 10, 11, ... \count14=9 % allocates \box registers 10, 11, ... \count15=9 % allocates \toks registers 10, 11, ... \count16=-1 % allocates input streams 0, 1, ... \count17=-1 % allocates output streams 0, 1, ... \count18=3 % allocates math families 4, 5, ... \count19=255 % allocates insertions 254, 253, ... \countdef\insc@unt=19 % the insertion counter \countdef\allocationnumber=20 % the most recent allocation \countdef\m@ne=21 \m@ne=-1 % a handy constant \def\wlog$\immediate\write\m@ne % write on log file (only) % Here are abbreviations for the names of scratch registers % that don't need to be allocated. \countdef\count@=255 \dimendef\dimen@=0 \dimendef\dimen@i=1 % global only \dimendef\dimen@ii=2 \skipdef\skip@=0 \toksdef\toks@=0 % Now, we define \newcount, \newbox, etc. so that you can say \newcount\foo % and \foo will be defined (with \countdef) to be the next counter. % To find out which counter \foo is, you can look at \allocationnumber. % Since there's no \boxdef command, \chardef is used to define a \newbox, % \newinsert, \newfam, and so on. \outer\def\newcount$\alloc@0\count\countdef\insc@unt \outer\def\newdimen$\alloc@1\dimen\dimendef\insc@unt \outer\def\newskip$\alloc@2\skip\skipdef\insc@unt \outer\def\newmuskip$\alloc@3\muskip\muskipdef\@cclvi \outer\def\newbox$\alloc@4\box\chardef\insc@unt \let\newtoks=\relax % we do this to allow plain.tex to be read in twice \outer\def\newhelp#1#2$\newtoks#1#1\expandafter$\csname#2\endcsname \outer\def\newtoks$\alloc@5\toks\toksdef\@cclvi \outer\def\newread$\alloc@6\read\chardef\sixt@@n \outer\def\newwrite$\alloc@7\write\chardef\sixt@@n \outer\def\newfam$\alloc@8\fam\chardef\sixt@@n \def\alloc@#1#2#3#4#5$\global\advance\count1#1by\@ne \ch@ck#1#4#2% make sure there's still room \allocationnumber=\count1#1% \global#3#5=\allocationnumber \wlog$\string#5=\string#2\the\allocationnumber \outer\def\newinsert#1$\global\advance\insc@unt by\m@ne \ch@ck0\insc@unt\count \ch@ck1\insc@unt\dimen \ch@ck2\insc@unt\skip \ch@ck4\insc@unt\box \allocationnumber=\insc@unt \global\chardef#1=\allocationnumber \wlog$\string#1=\string\insert\the\allocationnumber \def\ch@ck#1#2#3$\ifnum\count1#1<#2% \else\errmessage$No room for a new #3\fi % Here are some examples of allocation. \newdimen\maxdimen \maxdimen=16383.99999pt % the largest legal \newskip\hideskip \hideskip=-1000pt plus 1fill % negative but can grow \newskip\centering \centering=0pt plus 1000pt minus 1000pt \newdimen\p@ \p@=1pt % this saves macro space and time \newdimen\z@ \z@=0pt % can be used both for 0pt and 0 \newskip\z@skip \z@skip=0pt plus0pt minus0pt \newbox\voidb@x % permanently void box register % And here's a different sort of allocation: % For example, \newif\iffoo creates \footrue, \foofalse to go with \iffoo. \outer\def\newif#1$\count@\escapechar \escapechar\m@ne \expandafter\expandafter\expandafter \edef\@if#1$true$\let\noexpand#1=\noexpand\iftrue% \expandafter\expandafter\expandafter \edef\@if#1$false$\let\noexpand#1=\noexpand\iffalse% \@if#1$false\escapechar\count@ % the condition starts out false \def\@if#1#2$\csname\expandafter\if@\string#1#2\endcsname $\uccode`1=`i \uccode`2=`f \uppercase$\gdef\if@12$ % `if' is required % Assign initial values to TeX's parameters \message$parameters, % All of TeX's numeric parameters are listed here, % but the code is commented out if no special value needs to be set. % INITEX makes all parameters zero except where noted. \pretolerance=100 \tolerance=200 % INITEX sets this to 10000 \hbadness=1000 \vbadness=1000 \linepenalty=10 \hyphenpenalty=50 \exhyphenpenalty=50 \binoppenalty=700 \relpenalty=500 \clubpenalty=150 \widowpenalty=150 \displaywidowpenalty=50 \brokenpenalty=100 \predisplaypenalty=10000 % \postdisplaypenalty=0 % \interlinepenalty=0 % \floatingpenalty=0, set during \insert % \outputpenalty=0, set before TeX enters \output \doublehyphendemerits=10000 \finalhyphendemerits=5000 \adjdemerits=10000 % \looseness=0, cleared by TeX after each paragraph % \pausing=0 % \tracingonline=0 % \tracingmacros=0 % \tracingstats=0 % \tracingparagraphs=0 % \tracingpages=0 % \tracingoutput=0 \tracinglostchars=1 % \tracingcommands=0 % \tracingrestores=0 \uchyph=1 % \globaldefs=0 % \maxdeadcycles=25 % INITEX does this % \hangafter=1 % INITEX does this, also TeX after each paragraph % \fam=0 % \mag=1000 % INITEX does this % \escapechar=`\\ % INITEX does this \defaulthyphenchar=`\- \defaultskewchar=-1 % \endlinechar=`\^^M % INITEX does this \newlinechar=-1 \delimiterfactor=901 % \time=now % TeX does this at beginning of job % \day=now % TeX does this at beginning of job % \month=now % TeX does this at beginning of job % \year=now % TeX does this at beginning of job \showboxbreadth=5 \showboxdepth=3 \hfuzz=0.1pt \vfuzz=0.1pt \overfullrule=5pt \hsize=6.5in \vsize=8.9in \maxdepth=4pt \splitmaxdepth=\maxdimen \boxmaxdepth=\maxdimen % \lineskiplimit=0pt, changed by \normalbaselines \delimitershortfall=5pt \nulldelimiterspace=1.2pt \scriptspace=0.5pt % \mathsurround=0pt % \predisplaysize=0pt, set before TeX enters $$ % \displaywidth=0pt, set before TeX enters $$ % \displayindent=0pt, set before TeX enters $$ \parindent=20pt % \hangindent=0pt, zeroed by TeX after each paragraph % \hoffset=0pt % \voffset=0pt % \baselineskip=0pt, changed by \normalbaselines % \lineskip=0pt, changed by \normalbaselines \parskip=0pt plus 1pt \abovedisplayskip=12pt plus 3pt minus 9pt \abovedisplayshortskip=0pt plus 3pt \belowdisplayskip=12pt plus 3pt minus 9pt \belowdisplayshortskip=7pt plus 3pt minus 4pt % \leftskip=0pt % \rightskip=0pt \topskip=10pt \splittopskip=10pt % \tabskip=0pt % \spaceskip=0pt % \xspaceskip=0pt \parfillskip=0pt plus 1fil \thinmuskip=3mu \medmuskip=4mu plus 2mu minus 4mu \thickmuskip=5mu plus 5mu % We also define special registers that function like parameters: \newskip\smallskipamount \smallskipamount=3pt plus 1pt minus 1pt \newskip\medskipamount \medskipamount=6pt plus 2pt minus 2pt \newskip\bigskipamount \bigskipamount=12pt plus 4pt minus 4pt \newskip\normalbaselineskip \normalbaselineskip=12pt \newskip\normallineskip \normallineskip=1pt \newdimen\normallineskiplimit \normallineskiplimit=0pt \newdimen\jot \jot=3pt \newcount\interdisplaylinepenalty \interdisplaylinepenalty=100 \newcount\interfootnotelinepenalty \interfootnotelinepenalty=100 % Definitions for preloaded fonts \def\magstephalf$1095  \def\magstep#1$\ifcase#1 \@m\or 1200\or 1440\or 1728\or 2074\or 2488\fi\relax % Fonts assigned to \preloaded are not part of "plain TeX", % but they are preloaded so that other format packages can use them. % For example, if another set of macros says "\font\ninerm=cmr9", % TeX will not have to reload the font metric information for cmr9. \message$fonts, \font\tenrm=dcr10 % roman text \font\preloaded=dcr9 \font\preloaded=dcr8 \font\sevenrm=dcr7 \font\preloaded=dcr6 \font\fiverm=dcr5 \font\teni=cmmi10 % math italic \font\preloaded=cmmi9 \font\preloaded=cmmi8 \font\seveni=cmmi7 \font\preloaded=cmmi6 \font\fivei=cmmi5 \font\tensy=cmsy10 % math symbols \font\preloaded=cmsy9 \font\preloaded=cmsy8 \font\sevensy=cmsy7 \font\preloaded=cmsy6 \font\fivesy=cmsy5 \font\tenex=cmex10 % math extension \font\preloaded=dcss10 % sans serif \font\preloaded=dcssq8 \font\preloaded=dcssi10 % sans serif italic \font\preloaded=dcssqi8 \font\tenbf=dcbx10 % boldface extended \font\preloaded=dcbx9 \font\preloaded=dcbx8 \font\sevenbf=dcbx7 \font\preloaded=dcbx6 \font\fivebf=dcbx5 \font\tentt=dctt10 % typewriter \font\preloaded=dctt9 \font\preloaded=dctt8 \font\preloaded=dcttsl10 % slanted typewriter \font\tensl=dcsl10 % slanted roman \font\preloaded=dcsl9 \font\preloaded=dcsl8 \font\tenit=dcti10 % text italic \font\preloaded=dcti9 \font\preloaded=dcti8 \font\preloaded=dcti7 \message$more fonts, \font\preloaded=dcu10 % unslanted text italic \font\preloaded=cmmib10 % bold math italic \font\preloaded=cmbsy10 % bold math symbols \font\preloaded=dccsc10 % caps and small caps \font\preloaded=dcssbx10 % sans serif bold extended \font\preloaded=dcdunh10 % Dunhill style \font\preloaded=dcr7 scaled \magstep4 % for titles \font\preloaded=dctt10 scaled \magstep2 \font\preloaded=dcssbx10 scaled \magstep2 % \font\preloaded=manfnt % METAFONT logo and dragon curve and special symbols % Additional \preloaded fonts can be specified here. % (And those that were \preloaded above can be eliminated.) \let\preloaded=\undefined % preloaded fonts must be declared anew later. \skewchar\teni='177 \skewchar\seveni='177 \skewchar\fivei='177 \skewchar\tensy='60 \skewchar\sevensy='60 \skewchar\fivesy='60 \textfont0=\tenrm \scriptfont0=\sevenrm \scriptscriptfont0=\fiverm \def\rm$\fam\z@\tenrm \textfont1=\teni \scriptfont1=\seveni \scriptscriptfont1=\fivei \def\mit$\fam\@ne \def\oldstyle$\fam\@ne\teni \textfont2=\tensy \scriptfont2=\sevensy \scriptscriptfont2=\fivesy \def\cal$\fam\tw@ \textfont3=\tenex \scriptfont3=\tenex \scriptscriptfont3=\tenex \newfam\itfam \def\it$\fam\itfam\tenit % \it is family 4 \textfont\itfam=\tenit \newfam\slfam \def\sl$\fam\slfam\tensl % \sl is family 5 \textfont\slfam=\tensl \newfam\bffam \def\bf$\fam\bffam\tenbf % \bf is family 6 \textfont\bffam=\tenbf \scriptfont\bffam=\sevenbf \scriptscriptfont\bffam=\fivebf \newfam\ttfam \def\tt$\fam\ttfam\tentt % \tt is family 7 \textfont\ttfam=\tentt %New temporary family: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \font\tencmr=cmr10 \font\sevencmr=cmr7 \font\fivecmr=cmr5 \textfont15=\tencmr \scriptfont15=\sevencmr \scriptscriptfont15=\fivecmr \def\cmr$\fam15\tencmr %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Macros for setting ordinary text \message$macros, \def\frenchspacing$\sfcode`\.\@m \sfcode`\?\@m \sfcode`\!\@m \sfcode`\:\@m \sfcode`\;\@m \sfcode`\,\@m \def\nonfrenchspacing$\sfcode`\.3000\sfcode`\?3000\sfcode`\!3000% \sfcode`\:2000\sfcode`\;1500\sfcode`\,1250  \def\normalbaselines$\lineskip\normallineskip \baselineskip\normalbaselineskip \lineskiplimit\normallineskiplimit \def\^^M$\  % control = control \def\^^I$\  % same for \def\lq$` \def\rq$' \def\lbrack$[ \def\rbrack$] \let\endgraf=\par \let\endline=\cr \def\space$  \def\empty$ \def\null$\hbox$ \let\bgroup=$ \let\egroup= % In \obeylines, we say `\let^^M=\par' instead of `\def^^M$\par' % since this allows, for example, `\let\par=\cr \obeylines \halign$...' $\catcode`\^^M=\active % these lines must end with % \gdef\obeylines$\catcode`\^^M\active \let^^M\par% \global\let^^M\par % this is in case ^^M appears in a \write \def\obeyspaces$\catcode`\ \active $\obeyspaces\global\let =\space \def\loop#1\repeat$\def\body$#1\iterate \def\iterate$\body \let\next\iterate \else\let\next\relax\fi \next \let\repeat=\fi % this makes \loop...\if...\repeat skippable \def\thinspace$\kern .16667em  \def\negthinspace$\kern-.16667em  \def\enspace$\kern.5em  \def\enskip$\hskip.5em\relax \def\quad$\hskip1em\relax \def\qquad$\hskip2em\relax \def\smallskip$\vskip\smallskipamount \def\medskip$\vskip\medskipamount \def\bigskip$\vskip\bigskipamount \def\nointerlineskip$\prevdepth-1000\p@ \def\offinterlineskip$\baselineskip-1000\p@ \lineskip\z@ \lineskiplimit\maxdimen \def\vglue$\afterassignment\vgl@\skip@= \def\vgl@$\par \dimen@\prevdepth \hrule height\z@ \nobreak\vskip\skip@ \prevdepth\dimen@ \def\hglue$\afterassignment\hgl@\skip@= \def\hgl@$\leavevmode \count@\spacefactor \vrule width\z@ \nobreak\hskip\skip@ \spacefactor\count@ \def~$\penalty\@M \  % tie \def\slash$/\penalty\exhyphenpenalty % a `/' that acts like a `-' \def\break$\penalty-\@M \def\nobreak$\penalty \@M \def\allowbreak$\penalty \z@ \def\filbreak$\par\vfil\penalty-200\vfilneg \def\goodbreak$\par\penalty-500  \def\eject$\par\break \def\supereject$\par\penalty-\@MM \def\removelastskip$\ifdim\lastskip=\z@\else\vskip-\lastskip\fi \def\smallbreak$\par\ifdim\lastskip<\smallskipamount \removelastskip\penalty-50\smallskip\fi \def\medbreak$\par\ifdim\lastskip<\medskipamount \removelastskip\penalty-100\medskip\fi \def\bigbreak$\par\ifdim\lastskip<\bigskipamount \removelastskip\penalty-200\bigskip\fi \def\line$\hbox to\hsize \def\leftline#1$\line$#1\hss \def\rightline#1$\line$\hss#1 \def\centerline#1$\line$\hss#1\hss \def\rlap#1$\hbox to\z@$#1\hss \def\llap#1$\hbox to\z@$\hss#1 \def\m@th$\mathsurround=\z@ \def\underbar#1$$\setbox\z@\hbox$#1\dp\z@\z@ \m@th \underline$\box\z@$ \newbox\strutbox \setbox\strutbox=\hbox$\vrule height8.5pt depth3.5pt width\z@ \def\strut$\relax\ifmmode\copy\strutbox\else\unhcopy\strutbox\fi \def\hidewidth$\hskip\hideskip % for alignment entries that can stick out \def\ialign$\everycr$\tabskip\z@skip\halign % initialized \halign \newcount\mscount \def\multispan#1$\omit \mscount#1 \loop\ifnum\mscount>\@ne \sp@n\repeat \def\sp@n$\span\omit\advance\mscount\m@ne \newif\ifus@ \newif\if@cr \newbox\tabs \newbox\tabsyet \newbox\tabsdone \def\cleartabs$\global\setbox\tabsyet\null \setbox\tabs\null \def\settabs$\setbox\tabs\null \futurelet\next\sett@b \let\+=\relax % in case this file is being read in twice \def\sett@b$\ifx\next\+\let\next\relax \def\next$\afterassignment\s@tt@b\let\next% \else\let\next\s@tcols\fi\next \def\s@tt@b$\let\next\relax\us@false\m@ketabbox \def\tabalign$\us@true\m@ketabbox % non-\outer version of \+ \outer\def\+$\tabalign \def\s@tcols#1\columns$\count@#1 \dimen@\hsize \loop\ifnum\count@>\z@ \@nother \repeat \def\@nother$\dimen@ii\dimen@ \divide\dimen@ii\count@ \setbox\tabs\hbox$\hbox to\dimen@ii$\unhbox\tabs% \advance\dimen@-\dimen@ii \advance\count@\m@ne \def\m@ketabbox$\begingroup \global\setbox\tabsyet\copy\tabs \global\setbox\tabsdone\null \def\cr$\@crtrue\crcr\egroup\egroup \ifus@\unvbox\z@\lastbox\fi\endgroup \setbox\tabs\hbox$\unhbox\tabsyet\unhbox\tabsdone% \setbox\z@\vbox\bgroup\@crfalse \ialign\bgroup&\t@bbox##\t@bb@x\crcr \def\t@bbox$\setbox\z@\hbox\bgroup \def\t@bb@x$\if@cr\egroup % now \box\z@ holds the column \else\hss\egroup \global\setbox\tabsyet\hbox$\unhbox\tabsyet \global\setbox\@ne\lastbox% now \box\@ne holds its size \ifvoid\@ne\global\setbox\@ne\hbox to\wd\z@$% \else\setbox\z@\hbox to\wd\@ne$\unhbox\z@\fi \global\setbox\tabsdone\hbox$\box\@ne\unhbox\tabsdone\fi \box\z@ \def\hang$\hangindent\parindent \def\textindent#1$\indent\llap$#1\enspace\ignorespaces \def\item$\par\hang\textindent \def\itemitem$\par\indent \hangindent2\parindent \textindent \def\narrower$\advance\leftskip\parindent \advance\rightskip\parindent \outer\def\beginsection#1\par$\vskip\z@ plus.3\vsize\penalty-250 \vskip\z@ plus-.3\vsize\bigskip\vskip\parskip \message$#1\leftline$\bf#1\nobreak\smallskip\noindent \outer\def\proclaim #1. #2\par$\medbreak \noindent$\bf#1.\enspace$\sl#2\par \ifdim\lastskip<\medskipamount \removelastskip\penalty55\medskip\fi \def\raggedright$\rightskip\z@ plus2em \spaceskip.3333em \xspaceskip.5em  \def\ttraggedright$\tt\rightskip\z@ plus2em  % for use with \tt only %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chardef\%=`\% \chardef\&=`\& \chardef\#=`\# \chardef\$=`\$ \chardef\ss="FF \chardef\ae="E6 \chardef\oe="F7 \chardef\o="F8 \chardef\AE="C6 \chardef\OE="D7 \chardef\O="D8 \chardef\i="19 \chardef\j="1A % dotless letters \chardef\aa="E5 \chardef\l="AA \chardef\L="8A \def\leavevmode$\unhbox\voidb@x % begins a paragraph, if necessary \def\_$\leavevmode \kern.06em \vbox$\hrule width.3em \chardef\AA="C5 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\mathhexbox#1#2#3$\leavevmode \hbox$$\m@th \mathchar"#1#2#3$ \def\dag$\mathhexbox279 \def\ddag$\mathhexbox27A \def\S$\mathhexbox278 \def\P$\mathhexbox27B \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\d#1$\oalign$#1\crcr\hidewidth.\hidewidth %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\b#1$\oalign$#1\crcr\hidewidth \vbox to.2ex$\hbox$\char"09\vss\hidewidth \def\c#1$\setbox\z@\hbox$#1\ifdim\ht\z@=1ex\accent"0B #1% \else$\ooalign$\hidewidth\char"0B\hidewidth\crcr\unhbox\z@\fi %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\copyright$$\ooalign$\hfil\raise.07ex\hbox$c\hfil\crcr\mathhexbox20D \def\dots$\relax\ifmmode\ldots\else$\m@th\ldots\,$\fi \def\TeX$T\kern-.1667em\lower.5ex\hbox$E\kern-.125emX %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\`#1$$\accent"00 #1 \def\'#1$$\accent"01 #1 \def\v#1$$\accent"07 #1 \let\^^_=\v \def\u#1$$\accent"08 #1 \let\^^S=\u \def\=#1$$\accent"09 #1 \def\^#1$$\accent"02 #1 \let\^^D=\^ \def\.#1$$\accent"0A #1 \def\H#1$$\accent"05 #1 \def\~#1$$\accent"03 #1 \def\"#1$$\accent"04 #1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\t#1$$\edef\next$\the\font\the\textfont1\accent"7F\next#1 \def\hrulefill$\leaders\hrule\hfill \def\dotfill$\cleaders\hbox$$\m@th \mkern1.5mu.\mkern1.5mu$\hfill \def\rightarrowfill$$\m@th\mathord-\mkern-6mu% \cleaders\hbox$$\mkern-2mu\mathord-\mkern-2mu$\hfill \mkern-6mu\mathord\rightarrow$ \def\leftarrowfill$$\m@th\mathord\leftarrow\mkern-6mu% \cleaders\hbox$$\mkern-2mu\mathord-\mkern-2mu$\hfill \mkern-6mu\mathord-$ \mathchardef\braceld="37A \mathchardef\bracerd="37B \mathchardef\bracelu="37C \mathchardef\braceru="37D \def\downbracefill$$\m@th\braceld\leaders\vrule\hfill\braceru \bracelu\leaders\vrule\hfill\bracerd$ \def\upbracefill$$\m@th\bracelu\leaders\vrule\hfill\bracerd \braceld\leaders\vrule\hfill\braceru$ \outer\def\bye$\par\vfill\supereject\end % Macros for math setting \message$math definitions, \let\sp=^ \let\sb=_ \def\,$\mskip\thinmuskip \def\>$\mskip\medmuskip \def\;$\mskip\thickmuskip \def\!$\mskip-\thinmuskip \def\*$\discretionary$\thinspace\the\textfont2\char2$$ $\catcode`\'=\active \gdef'$^\bgroup\prim@s \def\prim@s$\prime\futurelet\next\pr@m@s \def\pr@m@s$\ifx'\next\let\next\pr@@@s \else\ifx^\next\let\next\pr@@@t \else\let\next\egroup\fi\fi \next \def\pr@@@s#1$\prim@s \def\pr@@@t#1#2$#2\egroup $\catcode`\^^Z=\active \gdef^^Z$\not= % ^^Z is like \ne in math $\catcode`\_=\active \let_=\_ % _ is like \_ if not used for subscripts \mathchardef\alpha="010B \mathchardef\beta="010C \mathchardef\gamma="010D \mathchardef\delta="010E \mathchardef\epsilon="010F \mathchardef\zeta="0110 \mathchardef\eta="0111 \mathchardef\theta="0112 \mathchardef\iota="0113 \mathchardef\kappa="0114 \mathchardef\lambda="0115 \mathchardef\mu="0116 \mathchardef\nu="0117 \mathchardef\xi="0118 \mathchardef\pi="0119 \mathchardef\rho="011A \mathchardef\sigma="011B \mathchardef\tau="011C \mathchardef\upsilon="011D \mathchardef\phi="011E \mathchardef\chi="011F \mathchardef\psi="0120 \mathchardef\omega="0121 \mathchardef\varepsilon="0122 \mathchardef\vartheta="0123 \mathchardef\varpi="0124 \mathchardef\varrho="0125 \mathchardef\varsigma="0126 \mathchardef\varphi="0127 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \mathchardef\Gamma="7F00 \mathchardef\Delta="7F01 \mathchardef\Theta="7F02 \mathchardef\Lambda="7F03 \mathchardef\Xi="7F04 \mathchardef\Pi="7F05 \mathchardef\Sigma="7F06 \mathchardef\Upsilon="7F07 \mathchardef\Phi="7F08 \mathchardef\Psi="7F09 \mathchardef\Omega="7F0A %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \mathchardef\aleph="0240 \def\hbar$$\mathchar'26\mkern-9muh \mathchardef\imath="017B \mathchardef\jmath="017C \mathchardef\ell="0160 \mathchardef\wp="017D \mathchardef\Re="023C \mathchardef\Im="023D \mathchardef\partial="0140 \mathchardef\infty="0231 \mathchardef\prime="0230 \mathchardef\emptyset="023B \mathchardef\nabla="0272 \def\surd$$\mathchar"1270 \mathchardef\top="023E \mathchardef\bot="023F \def\angle$$\vbox$\ialign$$\m@th\scriptstyle##$\crcr \not\mathrel$\mkern14mu\crcr \noalign$\nointerlineskip \mkern2.5mu\leaders\hrule height.34pt\hfill\mkern2.5mu\crcr \mathchardef\triangle="0234 \mathchardef\forall="0238 \mathchardef\exists="0239 \mathchardef\neg="023A \let\lnot=\neg \mathchardef\flat="015B \mathchardef\natural="015C \mathchardef\sharp="015D \mathchardef\clubsuit="027C \mathchardef\diamondsuit="027D \mathchardef\heartsuit="027E \mathchardef\spadesuit="027F \mathchardef\coprod="1360 \mathchardef\bigvee="1357 \mathchardef\bigwedge="1356 \mathchardef\biguplus="1355 \mathchardef\bigcap="1354 \mathchardef\bigcup="1353 \mathchardef\intop="1352 \def\int$\intop\nolimits \mathchardef\prod="1351 \mathchardef\sum="1350 \mathchardef\bigotimes="134E \mathchardef\bigoplus="134C \mathchardef\bigodot="134A \mathchardef\ointop="1348 \def\oint$\ointop\nolimits \mathchardef\bigsqcup="1346 \mathchardef\smallint="1273 \mathchardef\triangleleft="212F \mathchardef\triangleright="212E \mathchardef\bigtriangleup="2234 \mathchardef\bigtriangledown="2235 \mathchardef\wedge="225E \let\land=\wedge \mathchardef\vee="225F \let\lor=\vee \mathchardef\cap="225C \mathchardef\cup="225B \mathchardef\ddagger="227A \mathchardef\dagger="2279 \mathchardef\sqcap="2275 \mathchardef\sqcup="2274 \mathchardef\uplus="225D \mathchardef\amalg="2271 \mathchardef\diamond="2205 \mathchardef\bullet="220F \mathchardef\wr="226F \mathchardef\div="2204 \mathchardef\odot="220C \mathchardef\oslash="220B \mathchardef\otimes="220A \mathchardef\ominus="2209 \mathchardef\oplus="2208 \mathchardef\mp="2207 \mathchardef\pm="2206 \mathchardef\circ="220E \mathchardef\bigcirc="220D \mathchardef\setminus="226E % for set difference A\setminus B \mathchardef\cdot="2201 \mathchardef\ast="2203 \mathchardef\times="2202 \mathchardef\star="213F \mathchardef\propto="322F \mathchardef\sqsubseteq="3276 \mathchardef\sqsupseteq="3277 \mathchardef\parallel="326B \mathchardef\mid="326A \mathchardef\dashv="3261 \mathchardef\vdash="3260 \mathchardef\nearrow="3225 \mathchardef\searrow="3226 \mathchardef\nwarrow="322D \mathchardef\swarrow="322E \mathchardef\Leftrightarrow="322C \mathchardef\Leftarrow="3228 \mathchardef\Rightarrow="3229 \def\neq$\not= \let\ne=\neq \mathchardef\leq="3214 \let\le=\leq \mathchardef\geq="3215 \let\ge=\geq \mathchardef\succ="321F \mathchardef\prec="321E \mathchardef\approx="3219 \mathchardef\succeq="3217 \mathchardef\preceq="3216 \mathchardef\supset="321B \mathchardef\subset="321A \mathchardef\supseteq="3213 \mathchardef\subseteq="3212 \mathchardef\in="3232 \mathchardef\ni="3233 \let\owns=\ni \mathchardef\gg="321D \mathchardef\ll="321C \mathchardef\not="3236 \mathchardef\leftrightarrow="3224 \mathchardef\leftarrow="3220 \let\gets=\leftarrow \mathchardef\rightarrow="3221 \let\to=\rightarrow \mathchardef\mapstochar="3237 \def\mapsto$\mapstochar\rightarrow \mathchardef\sim="3218 \mathchardef\simeq="3227 \mathchardef\perp="323F \mathchardef\equiv="3211 \mathchardef\asymp="3210 \mathchardef\smile="315E \mathchardef\frown="315F \mathchardef\leftharpoonup="3128 \mathchardef\leftharpoondown="3129 \mathchardef\rightharpoonup="312A \mathchardef\rightharpoondown="312B \def\joinrel$\mathrel$\mkern-3mu \def\relbar$\mathrel$\smash- % \smash, because - has the same height as + \def\Relbar$\mathrel= \mathchardef\lhook="312C \def\hookrightarrow$\lhook\joinrel\rightarrow \mathchardef\rhook="312D \def\hookleftarrow$\leftarrow\joinrel\rhook \def\bowtie$\mathrel\triangleright\joinrel\mathrel\triangleleft \def\models$\mathrel|\joinrel= \def\Longrightarrow$\Relbar\joinrel\Rightarrow \def\longrightarrow$\relbar\joinrel\rightarrow \def\longleftarrow$\leftarrow\joinrel\relbar \def\Longleftarrow$\Leftarrow\joinrel\Relbar \def\longmapsto$\mapstochar\longrightarrow \def\longleftrightarrow$\leftarrow\joinrel\rightarrow \def\Longleftrightarrow$\Leftarrow\joinrel\Rightarrow \def\iff$\;\Longleftrightarrow\; \mathchardef\ldotp="602E % ldot as a punctuation mark \mathchardef\cdotp="6201 % cdot as a punctuation mark \mathchardef\colon="603A % colon as a punctuation mark \def\ldots$\mathinner$\ldotp\ldotp\ldotp \def\cdots$\mathinner$\cdotp\cdotp\cdotp \def\vdots$\vbox$\baselineskip4\p@ \lineskiplimit\z@ \kern6\p@\hbox$.\hbox$.\hbox$. \def\ddots$\mathinner$\mkern1mu\raise7\p@\vbox$\kern7\p@\hbox$.\mkern2mu \raise4\p@\hbox$.\mkern2mu\raise\p@\hbox$.\mkern1mu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\acute$\mathaccent"7001  \def\grave$\mathaccent"7000  \def\ddot$\mathaccent"7004  \def\tilde$\mathaccent"7003  \def\bar$\mathaccent"7009  \def\breve$\mathaccent"7008  \def\check$\mathaccent"7007  \def\hat$\mathaccent"7002  \def\vec$\mathaccent"017E  \def\dot$\mathaccent"700A  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\widetilde$\mathaccent"0365  \def\widehat$\mathaccent"0362  \def\overrightarrow#1$\vbox$\ialign$##\crcr \rightarrowfill\crcr\noalign$\kern-\p@\nointerlineskip $\hfil\displaystyle$#1\hfil$\crcr \def\overleftarrow#1$\vbox$\ialign$##\crcr \leftarrowfill\crcr\noalign$\kern-\p@\nointerlineskip $\hfil\displaystyle$#1\hfil$\crcr \def\overbrace#1$\mathop$\vbox$\ialign$##\crcr\noalign$\kern3\p@ \downbracefill\crcr\noalign$\kern3\p@\nointerlineskip $\hfil\displaystyle$#1\hfil$\crcr\limits \def\underbrace#1$\mathop$\vtop$\ialign$##\crcr $\hfil\displaystyle$#1\hfil$\crcr\noalign$\kern3\p@\nointerlineskip \upbracefill\crcr\noalign$\kern3\p@\limits \def\skew#1#2#3$$#2$#3\mkern#1mu\mkern-#1mu$ \def\lmoustache$\delimiter"4000340  % top from (, bottom from ) \def\rmoustache$\delimiter"5000341  % top from ), bottom from ( \def\lgroup$\delimiter"400033A  % extensible ( with sharper tips \def\rgroup$\delimiter"500033B  % extensible ) with sharper tips \def\arrowvert$\delimiter"33C  % arrow without arrowheads \def\Arrowvert$\delimiter"33D  % double arrow without arrowheads \def\bracevert$\delimiter"33E  % the vertical bar that extends braces \def\Vert$\delimiter"26B30D  \let\|=\Vert \def\vert$\delimiter"26A30C  \def\uparrow$\delimiter"3222378  \def\downarrow$\delimiter"3223379  \def\updownarrow$\delimiter"326C33F  \def\Uparrow$\delimiter"322A37E  \def\Downarrow$\delimiter"322B37F  \def\Updownarrow$\delimiter"326D377  \def\backslash$\delimiter"26E30F  % for double coset G\backslash H \def\rangle$\delimiter"526930B  \def\langle$\delimiter"426830A  \def\rbrace$\delimiter"5267309  \let\=\rbrace \def\lbrace$\delimiter"4266308  \let\$=\lbrace \def\rceil$\delimiter"5265307  \def\lceil$\delimiter"4264306  \def\rfloor$\delimiter"5263305  \def\lfloor$\delimiter"4262304  \def\bigl$\mathopen\big \def\bigm$\mathrel\big \def\bigr$\mathclose\big \def\Bigl$\mathopen\Big \def\Bigm$\mathrel\Big \def\Bigr$\mathclose\Big \def\biggl$\mathopen\bigg \def\biggm$\mathrel\bigg \def\biggr$\mathclose\bigg \def\Biggl$\mathopen\Bigg \def\Biggm$\mathrel\Bigg \def\Biggr$\mathclose\Bigg \def\big#1$$\hbox$$\left#1\vbox to8.5\p@$\right.\n@space$ \def\Big#1$$\hbox$$\left#1\vbox to11.5\p@$\right.\n@space$ \def\bigg#1$$\hbox$$\left#1\vbox to14.5\p@$\right.\n@space$ \def\Bigg#1$$\hbox$$\left#1\vbox to17.5\p@$\right.\n@space$ \def\n@space$\nulldelimiterspace\z@ \m@th \def\choose$\atopwithdelims() \def\brack$\atopwithdelims[] \def\brace$\atopwithdelims\$\ \def\sqrt$\radical"270370  \def\mathpalette#1#2$\mathchoice$#1\displaystyle$#2% $#1\textstyle$#2$#1\scriptstyle$#2$#1\scriptscriptstyle$#2 \newbox\rootbox \def\root#1\of$\setbox\rootbox\hbox$$\m@th\scriptscriptstyle$#1$ \mathpalette\r@@t \def\r@@t#1#2$\setbox\z@\hbox$$\m@th#1\sqrt$#2$ \dimen@\ht\z@ \advance\dimen@-\dp\z@ \mkern5mu\raise.6\dimen@\copy\rootbox \mkern-10mu \box\z@ \newif\ifv@ \newif\ifh@ \def\vphantom$\v@true\h@false\ph@nt \def\hphantom$\v@false\h@true\ph@nt \def\phantom$\v@true\h@true\ph@nt \def\ph@nt$\ifmmode\def\next$\mathpalette\mathph@nt% \else\let\next\makeph@nt\fi\next \def\makeph@nt#1$\setbox\z@\hbox$#1\finph@nt \def\mathph@nt#1#2$\setbox\z@\hbox$$\m@th#1$#2$\finph@nt \def\finph@nt$\setbox\tw@\null \ifv@ \ht\tw@\ht\z@ \dp\tw@\dp\z@\fi \ifh@ \wd\tw@\wd\z@\fi \box\tw@ \def\mathstrut$\vphantom( \def\smash$\relax % \relax, in case this comes first in \halign \ifmmode\def\next$\mathpalette\mathsm@sh\else\let\next\makesm@sh \fi\next \def\makesm@sh#1$\setbox\z@\hbox$#1\finsm@sh \def\mathsm@sh#1#2$\setbox\z@\hbox$$\m@th#1$#2$\finsm@sh \def\finsm@sh$\ht\z@\z@ \dp\z@\z@ \box\z@ \def\cong$\mathrel$\mathpalette\@vereq\sim % congruence sign \def\@vereq#1#2$\lower.5\p@\vbox$\baselineskip\z@skip\lineskip-.5\p@ \ialign$$\m@th#1\hfil##\hfil$\crcr#2\crcr=\crcr \def\notin$\mathrel$\mathpalette\c@ncel\in \def\c@ncel#1#2$\ooalign$$\hfil#1\mkern1mu/\hfil$\crcr$#1#2$ \def\rightleftharpoons$\mathrel$\mathpalette\rlh@$ \def\rlh@#1$\vcenter$\hbox$\ooalign$\raise2pt \hbox$$#1\rightharpoonup$\crcr $#1\leftharpoondown$ \def\buildrel#1\over#2$\mathrel$\mathop$\kern\z@#2\limits^$#1 \def\doteq$\buildrel\textstyle.\over= \def\log$\mathop$\rm log\nolimits \def\lg$\mathop$\rm lg\nolimits \def\ln$\mathop$\rm ln\nolimits \def\lim$\mathop$\rm lim \def\limsup$\mathop$\rm lim\,sup \def\liminf$\mathop$\rm lim\,inf \def\sin$\mathop$\rm sin\nolimits \def\arcsin$\mathop$\rm arcsin\nolimits \def\sinh$\mathop$\rm sinh\nolimits \def\cos$\mathop$\rm cos\nolimits \def\arccos$\mathop$\rm arccos\nolimits \def\cosh$\mathop$\rm cosh\nolimits \def\tan$\mathop$\rm tan\nolimits \def\arctan$\mathop$\rm arctan\nolimits \def\tanh$\mathop$\rm tanh\nolimits \def\cot$\mathop$\rm cot\nolimits \def\coth$\mathop$\rm coth\nolimits \def\sec$\mathop$\rm sec\nolimits \def\csc$\mathop$\rm csc\nolimits \def\max$\mathop$\rm max \def\min$\mathop$\rm min \def\sup$\mathop$\rm sup \def\inf$\mathop$\rm inf \def\arg$\mathop$\rm arg\nolimits \def\ker$\mathop$\rm ker\nolimits \def\dim$\mathop$\rm dim\nolimits \def\hom$\mathop$\rm hom\nolimits \def\det$\mathop$\rm det \def\exp$\mathop$\rm exp\nolimits \def\Pr$\mathop$\rm Pr \def\gcd$\mathop$\rm gcd \def\deg$\mathop$\rm deg\nolimits \def\bmod$\mskip-\medmuskip\mkern5mu \mathbin$\rm mod\penalty900\mkern5mu\mskip-\medmuskip \def\pmod#1$\allowbreak\mkern18mu($\rm mod\,\,#1) \def\cases#1$\left\$\,\vcenter$\normalbaselines\m@th \ialign$$##\hfil$&\quad##\hfil\crcr#1\crcr\right. \def\matrix#1$\null\,\vcenter$\normalbaselines\m@th \ialign$\hfil$##$\hfil&&\quad\hfil$##$\hfil\crcr \mathstrut\crcr\noalign$\kern-\baselineskip #1\crcr\mathstrut\crcr\noalign$\kern-\baselineskip\, \def\pmatrix#1$\left(\matrix$#1\right) \newdimen\p@renwd \setbox0=\hbox$\tenex B \p@renwd=\wd0 % width of the big left ( \def\bordermatrix#1$\begingroup \m@th \setbox\z@\vbox$\def\cr$\crcr\noalign$\kern2\p@\global\let\cr\endline% \ialign$$##$\hfil\kern2\p@\kern\p@renwd&\thinspace\hfil$##$\hfil &&\quad\hfil$##$\hfil\crcr \omit\strut\hfil\crcr\noalign$\kern-\baselineskip% #1\crcr\omit\strut\cr% \setbox\tw@\vbox$\unvcopy\z@\global\setbox\@ne\lastbox% \setbox\tw@\hbox$\unhbox\@ne\unskip\global\setbox\@ne\lastbox% \setbox\tw@\hbox$$\kern\wd\@ne\kern-\p@renwd\left(\kern-\wd\@ne \global\setbox\@ne\vbox$\box\@ne\kern2\p@% \vcenter$\kern-\ht\@ne\unvbox\z@\kern-\baselineskip\,\right)$% \null\;\vbox$\kern\ht\@ne\box\tw@\endgroup \def\openup$\afterassignment\@penup\dimen@= \def\@penup$\advance\lineskip\dimen@ \advance\baselineskip\dimen@ \advance\lineskiplimit\dimen@ \def\eqalign#1$\null\,\vcenter$\openup\jot\m@th \ialign$\strut\hfil$\displaystyle$##$&$\displaystyle$$##$\hfil \crcr#1\crcr\, \newif\ifdt@p \def\displ@y$\global\dt@ptrue\openup\jot\m@th \everycr$\noalign$\ifdt@p \global\dt@pfalse \vskip-\lineskiplimit \vskip\normallineskiplimit \else \penalty\interdisplaylinepenalty \fi \def\@lign$\tabskip\z@skip\everycr$ % restore inside \displ@y \def\displaylines#1$\displ@y \halign$\hbox to\displaywidth$$\@lign\hfil\displaystyle##\hfil$\crcr #1\crcr \def\eqalignno#1$\displ@y \tabskip\centering \halign to\displaywidth$\hfil$\@lign\displaystyle$##$\tabskip\z@skip &$\@lign\displaystyle$$##$\hfil\tabskip\centering &\llap$$\@lign##$\tabskip\z@skip\crcr #1\crcr \def\leqalignno#1$\displ@y \tabskip\centering \halign to\displaywidth$\hfil$\@lign\displaystyle$##$\tabskip\z@skip &$\@lign\displaystyle$$##$\hfil\tabskip\centering &\kern-\displaywidth\rlap$$\@lign##$\tabskip\displaywidth\crcr #1\crcr % Definitions related to output \message$output routines, \countdef\pageno=0 \pageno=1 % first page is number 1 \newtoks\headline \headline=$\hfil % headline is normally blank \newtoks\footline \footline=$\hss\tenrm\folio\hss % footline is normally a centered page number in font \tenrm \newif\ifr@ggedbottom \def\raggedbottom$\topskip 10\p@ plus60\p@ \r@ggedbottomtrue \def\normalbottom$\topskip 10\p@ \r@ggedbottomfalse % undoes \raggedbottom \def\folio$\ifnum\pageno<\z@ \romannumeral-\pageno \else\number\pageno \fi \def\nopagenumbers$\footline$\hfil % blank out the footline \def\advancepageno$\ifnum\pageno<\z@ \global\advance\pageno\m@ne \else\global\advance\pageno\@ne \fi % increase |pageno| \newinsert\footins \def\footnote#1$\let\@sf\empty % parameter #2 (the text) is read later \ifhmode\edef\@sf$\spacefactor\the\spacefactor\/\fi #1\@sf\vfootnote$#1 \def\vfootnote#1$\insert\footins\bgroup \interlinepenalty\interfootnotelinepenalty \splittopskip\ht\strutbox % top baseline for broken footnotes \splitmaxdepth\dp\strutbox \floatingpenalty\@MM \leftskip\z@skip \rightskip\z@skip \spaceskip\z@skip \xspaceskip\z@skip \textindent$#1\footstrut\futurelet\next\fo@t \def\fo@t$\ifcat\bgroup\noexpand\next \let\next\f@@t \else\let\next\f@t\fi \next \def\f@@t$\bgroup\aftergroup\@foot\let\next \def\f@t#1$#1\@foot \def\@foot$\strut\egroup \def\footstrut$\vbox to\splittopskip$ \skip\footins=\bigskipamount % space added when footnote is present \count\footins=1000 % footnote magnification factor (1 to 1) \dimen\footins=8in % maximum footnotes per page \newinsert\topins \newif\ifp@ge \newif\if@mid \def\topinsert$\@midfalse\p@gefalse\@ins \def\midinsert$\@midtrue\@ins \def\pageinsert$\@midfalse\p@getrue\@ins \skip\topins=\z@skip % no space added when a topinsert is present \count\topins=1000 % magnification factor (1 to 1) \dimen\topins=\maxdimen % no limit per page \def\@ins$\par\begingroup\setbox\z@\vbox\bgroup % start a \vbox \def\endinsert$\egroup % finish the \vbox \if@mid \dimen@\ht\z@ \advance\dimen@\dp\z@ \advance\dimen@12\p@ \advance\dimen@\pagetotal \ifdim\dimen@>\pagegoal\@midfalse\p@gefalse\fi\fi \if@mid \bigskip\box\z@\bigbreak \else\insert\topins$\penalty100 % floating insertion \splittopskip\z@skip \splitmaxdepth\maxdimen \floatingpenalty\z@ \ifp@ge \dimen@\dp\z@ \vbox to\vsize$\unvbox\z@\kern-\dimen@% depth is zero \else \box\z@\nobreak\bigskip\fi\fi\endgroup \output$\plainoutput \def\plainoutput$\shipout\vbox$\makeheadline\pagebody\makefootline% \advancepageno \ifnum\outputpenalty>-\@MM \else\dosupereject\fi \def\pagebody$\vbox to\vsize$\boxmaxdepth\maxdepth \pagecontents \def\makeheadline$\vbox to\z@$\vskip-22.5\p@ \line$\vbox to8.5\p@$\the\headline\vss\nointerlineskip \def\makefootline$\baselineskip24\p@\line$\the\footline \def\dosupereject$\ifnum\insertpenalties>\z@ % something is being held over \line$\kern-\topskip\nobreak\vfill\supereject\fi \def\pagecontents$\ifvoid\topins\else\unvbox\topins\fi \dimen@=\dp\@cclv \unvbox\@cclv % open up \box255 \ifvoid\footins\else % footnote info is present \vskip\skip\footins \footnoterule \unvbox\footins\fi \ifr@ggedbottom \kern-\dimen@ \vfil \fi \def\footnoterule$\kern-3\p@ \hrule width 2truein \kern 2.6\p@ % the \hrule is .4pt high % Hyphenation, miscellaneous macros, and initial values for standard layout \message$active characters, national macros, hyphenation \input dc-codes.tex \def\newlanguage#1#2$\advance\language by 1\relax\def#2$#1 \newlanguage0\USenglish\language=\USenglish \input ushyphen.tex %\newlanguage1\german\language=\german %\input dhyphen.tex \newlanguage2\french\language=\french \input fhyphen.tex %\newlanguage3\swedish\language=\swedish %\input shyphen.tex %\newlanguage4\dutch\language=\dutch %\input nlhyphen.tex %\newlanguage5\spanish\language=\spanish %\input ehyphen.tex %\newlanguage6\italian\language=\italian %\input ihyphen.tex %\newlanguage7\danish\language=\danish %\input dkhyphen.tex %\newlanguage8\norwegian\language=\norwegian %\input nhyphen.tex %\newlanguage9\icelandic\language=\icelandic %\input islhyphen.tex %\newlanguage10\portuguese\language=\portoguese %\input phyphen.tex %\newlanguage11\finnish\language=\finnish %\input sfhyphen.tex %\newlanguage50\greek\language=\greek %\input grhyphen.tex %\newlanguage51\russian\language=\russian %\input rushyphen.tex \input actives.tex \input us_macros.tex %\input german_macros.tex \def\D$\message$Sorry, no German patterns or macros provided! \input french_macros.tex %\def\F$\message$Sorry, no French patterns or macros provided! %\input dutch_macros.tex \def\NL$\message$Sorry, no Dutch patterns or macros provided! %\input spanish_macros.tex \def\E$\message$Sorry, no Spanish patterns or macros provided! %\input italian_macros.tex \def\I$\message$Sorry, no Italian patterns or macros provided! %\input danish_macros.tex \def\DK$\message$Sorry, no Danish patterns or macros provided! %\input norwegian_macros.tex \def\N$\message$Sorry, no Norwegian patterns or macros provided! %\input icelandic_macros.tex \def\ISL$\message$Sorry, no Icelandic patterns or macros provided! %\input portuguese_macros.tex \def\POR$\message$Sorry, no Portuguese patterns or macros provided! %\input finnish_macros.tex \def\SF$\message$Sorry, no Finnish patterns or macros provided! %\input greek_macros.tex \def\GR$\message$Sorry, no Greek patterns or macros provided! %\input swedish_macros.tex \def\SWE$\message$Sorry, no Swedish patterns or macros provided! %\input russian_macros.tex \def\RUS$\message$Sorry, no Russian patterns or macros provided! \F \def\magnification$\afterassignment\m@g\count@ \def\m@g$\mag\count@ \hsize6.5truein\vsize8.9truein\dimen\footins8truein \def\tracingall$\tracingonline\@ne\tracingcommands\tw@\tracingstats\tw@ \tracingpages\@ne\tracingoutput\@ne\tracinglostchars\@ne \tracingmacros\tw@\tracingparagraphs\@ne\tracingrestores\@ne \showboxbreadth\maxdimen\showboxdepth\maxdimen\errorstopmode \def\showhyphens#1$\setbox0\vbox$\parfillskip\z@skip\hsize\maxdimen\tenrm \pretolerance\m@ne\tolerance\m@ne\hbadness0\showboxdepth0\ #1 \normalbaselines\rm % select roman font %\nonfrenchspacing % punctuation affects the spacing \catcode`@=12 % at signs are no longer letters \def\fmtname$dc-plain F+US\def\fmtversion$0.9 % identifies the current format % === end of dc-plain.tex% == This is french_macros.tex by Yannis Haralambous for Macintosh % this file contains 8 bits characters (Macintosh) %Yannis Haralambous %Sep 14, 1991, 2:44 PM \def\cadratin$\kern1em \def\demicadratin$\kern.5em \def\quartdecadratin$\kern.25em \catcode`\;=\active \catcode`\:=\active \catcode`\!=\active \catcode`\?=\active \catcode`\/=\active \catcode`\.=\active \def;$\relax\ifhmode\ifdim\lastskip>0pt \unskip\penalty10000\fi\quartdecadratin\fi\string; \def?$\relax\ifhmode\ifdim\lastskip>0pt \unskip\penalty10000\fi\quartdecadratin\fi\string? \def!$\relax\ifhmode\ifdim\lastskip>0pt \unskip\penalty10000\fi\quartdecadratin\fi\string! \def:$\relax\ifhmode\ifdim\lastskip>0pt \unskip\penalty10000\fi~\fi\string: \def.$\relax\ifhmode\ifdim\lastskip>0pt \unskip\penalty10000\fi~\fi\char"14$ \def/#1$\relax\char"13~#1 %Spacing of French punctuation marks \def\F$% \DCdefs \catcode`\;=\active \catcode`\:=\active \catcode`\!=\active \catcode`\?=\active \catcode`\/=\active \catcode`\.=\active \frenchspacing \language\french  % ==== end of french_macros.tex% == This is us_macros.tex by Yannis Haralambous % this file contains 8 bits characters (Macintosh) \def\US$% \DCdefs \catcode`\;=12 \catcode`\:=12 \catcode`\!=12 \catcode`\?=12 \catcode`\/=12 \catcode`\.=12 \nonfrenchspacing \language\USenglish  % === end of us_macros.texbegin 644 yannis.tar.Z M'YV0><*X<9-FSHLP8^BDL5-FC@LZ9?#X`4"QHL6+&#-JW,BQH\>*,6#`L"$2 M!`"1*&&83`ECQDJ6(6O4B`$"QLR1,F3,N$&C1LT8/6O``%#SH]&C2),JS5AG M#ITP_;PV[D4,L\P M-WKJP0VQ!Z\.B.Z(^(Z(\8@HCXCSQ,D< M/1[^9@87M`DZQQXEY"8H"(#LH=MJ@.HF)9A!@B#D-KI$#F@NB@AKD9*1`RRJ@I"(;6*0(0-H"::ZJJ&]$I; MKJL>TFL1N%HZ+`B(+`L#LB`DLJP,U"JR+*7.+KK(LC,$JZBNC"S[:;>Z-K+L MJ>BNZLBRL;8+PB/+XD`M),L&06TDRPHA[K.2+$L$M9,L.P2UE"Q;!+65+&L$ MM9;T:D2SH>IZB<3A6BKLHIA(C*V\F4C,;<6K:B(QL/)N(O&Y)(/`B<3ZRMN) MQ/'VL;&NGDCLK[R?2'RPO*=(_+"\KO0Z!,HMOV*LO?+ZLBS2-Z_ZB\1,MPQ, MKT(L+&\P6`\L[S)&3RLO,T9GW'(SQK(<-0C.&,MNR\](_/:SV&#]<\O9])K# MW<^68_3'+9MC=,PVC[OJ.493_"PZ1N_<B[AAK]K/O&#ORL_$8"_BS\AA+^+/S&.OXVO086W,?FO7^(7/AB"B. MB&86AUUT+@9'#I@BZN-G<&@:_]WOP=639IMOBCBG],3[U7,"C)Y_/(_!$_6(BH%B(*A8A$(2);B.@6\<.%B$8AHER(2!*[WP>UDZ8GJN MP24OB4@;\?N&B%8AHEX$2E5<.((4#(4HPX$@''L(0\O$L0]-`RQJ&A9?78@QH>MX6Q4X.+:O='%IVCSV,H66YHT/+\K&'.@1N#V9H&3[V$(>6 MC6,/>4"DKNRQASM8;0\G$..SMH%+.#Z+&[B\X[.Z@4L_/LL;N(SDL\"!2U.R M#I>V?-8^]B`"8RZ*']1TYJ+Z0+$'([2,;%%HF=.R`%$03.T*9\/E.9_5MA/<\UG7P.4_Z8;+@SXK;R?X MZ+.T@4N9/NL;N`3JLU9!3:;E)",I"1A0O3%:RJLVM;G>KE+6TI0=OBTL"&,J3F-D\1S&-P@)@TT.$QG)IN:U[C`LWD=;F@$8UO3I,: M2-7%-;"1#6UL@QOV#4>)]G$.@/]CG0$SISL&)H^(UC-$]LDGP?<1$7\@'"`( M%PC""6KP_1P$X0A!F$(0OA"$-03A#FF8?"&",(D@;"((HPC"*H(PBT[\/1A! M6$80IA&$;01A'$%81S1.CX\@#"0("PG"1(*PD2",I"#;1XAS99^3(.S"*-]/ M2A"F$H2-.%)5B;?EB#<)0A_"<)A@O"8G/R?XH7Y>]%[]:G69 M,AK+GC4J2T=J"'-;5*L\+:F:/8M6I+X5M7B5:JAYL5BI'IVNE$5J9E$K6K46 M6\NL5>O7+4I;M<:TKKY5:[.MK5RUWO2BU%7K4.OJ7;4V]:+H56O)+0I?M9[= MHOA5Z]MY,6"UMMRS"E9K6:\J8;76W+,:5FO//2MBI)X8M2X6;V-[L6/Q]K6N M0A9O89?L9-126;R5K:N7Q5O;NII9O&NVMIS%VW'/ZEF\S0V"H,7;W8LJ&JF/ M1BVEI=K:NG):K5W]K*G%&^2KNAJILT8MKJU-ZWM5@MLXX=:&N(TK;E&,VSC$%P6Y MC:,?-^1JR7`;TF.XG(?8B&'Z/E1S\1Y4_-^^O?_P((X0%"N(`0/B"$$[CZ!4+X MT)MW((0A"&$)0IB"J[<@A#$(80U"F(,0]B"$0;AZ$4*8A!`V(811"&$50IB% MJZ^RY6$H0QK:$('M#:ELTB3LP>.A#I[H$R+,DF5!#M[@$FTLP>;]"R=]$F# MMP>B]"RD-$Y0ATJJQ$JN!$L]14O1M"A7DTLMPTLG0(&Z`DPGH(&Z0DS>U#+( M=`(PJ"O,=`)">'?0U#+35$TM@TTB$(;<)`)9"$[BU#+E-%2+DD[K]"SM]$[/ M$D_S]"SU=%2+DD_[]"S]M%2+$E`#]2P%Y56ZDE`+]2P-]5!K(U$4]2P6A5$: MQ5$>!5(B15(FA5(JQ5(N!5-[8%6+0E,V57-[D%//LE,]]5-!=0)RJ"M%Y8>Z MDE0G0(BZ4C&PP55 M,`5=%&F&,GK,L0,]$`,R()/!H0,U>9/L$P([B9-<\`,_R3[',)3W@PQ#Z0:W M809R(%]H,`=PH%QGD!N4X09G4`=A<`;(T9*B<09L4!!HH`!CU5;`]59Q!0(= MV8Z%T8T7V99N^99PN5OG:%A,Z93KJ);O.!%QV17S"%D3F1+X^!4R<%G]V%D` M*0,W$%H$>0,Q8)!%L9<)N9"N-155\9!H$9&UQ1*W!5F0V9F=F9%PL9&/49>C M@09W^9%KF1_$9Z\,9Y<<)URX`8N(`/GR9WL0Y.KIY.K MYY.K)Y2K5Y2KAY0"J"H[X"A-21EXP`5I8`9HT`;4X:!F8!IMP`64X11SL`9I M``<^``-PL%8@``)<4`=NL*$=R@5P(!J300=YX%@BP05FD`9"J(B2J(FBJ)PH*(L MR@8N"J,PP*,URIXXJJ."X:4^>AH_(*2J$@)%>J0/FJ2_0:%,FJ'G!:4?&J(* M,*(E>J)0BJ5NT*(OFA)>:J/M^9YA()WQZ09D2@<_:I4A@*9FH`-K&@8-VJ82 M^J9+F@87*J=66J=3FJ=6RJ=^RJ4\Z@>)NJAGH`..B@R1.JD06JG(<:F9ZJ1S MVJ&<>J=4JJ.;$46[$6>[$8F[%H,9<&8;`0FYH1H;$=T9?UJ)GWN)DB,9@V M0`.%B1/X*0.9]1,RH5D'*;*+)9D-69FRM142:;(4:;-`&UB@J5URX;$>&;%V ME1@C"5VN.5VP:5VCV1>TJ5>&P5;95;39S)N9PLZYS06:CB69WSB9W:J9\#Z)W@ MR;>'2I[U:9[HN9*"&J:&2YV(:Y_XN;C[&3_O&G_W(Z^82S[UNKG?@Z^>FQ[[ M&G^"DJ#):J3+2JE*6J&8VJ1/2JM2:JN>NJ>Z&JJ`.J-?>J.$:J@[BKME:I5! M:CA$>KILVJJK&Z>RNJFQBZ=52KM9NJ6W2Z.-N[M]6ZIFZJAJ2KRI:[R6RKJQ M^KI1:J?,BZM76KN\*JJX.[TY^KACZKN*>AJ-:CB0JKVLZJ:OZKVN.ZOAVZG- MFZO/VZLQ.J.DZKZFBJJ&HZKTBZ2N"J>MJZETNKRW^JGF"[V^*L#`6BK#:BG% M>JRKRJS."JT*(*U2R;#7ZI3::J()X:UI`*[B2JXK>:ZYD:YF4*[WPZZA:Q^7 M^QU`J;DZS#Z=V\/W`[I`3#ZCV\,&^Z_4&K!6B95:*:,.>[!LE;"AL;!G:;1X MR99!F\5:O,5?!$DB[*;&9A?00,YT;+_6`,Z<0,_00,W M(%HU6\9D@;.OI;,0R;.9*1:6!19X/,@>,;2BB99S\+'ON)I@W+0G";56JUTS MVEW?Q;5>"[9B6U^L`1&O`0)G&XY[I;:0UI(O*<,T3#XT:9-`J9.JW)-&R;FO M_+FQ++I)N91/C,2GH<0#V\1<:95?6;4(>XW9>)9BC+1X0,C(3,@<^P)D,`8M M``>4(1A83,AG',AIO)G-.@.CY<8YL1,Q(,>B%9`V<TE19_ M"_)5NX%V%^AO9J+1.(`14 MP9YDH+9K0<]S\1C9Y5W0W+5N\!9E@`5WQ8YT``+9Q1LG8,\-\9%I(`9ED(V" M$5S>1049?1EOL`;MM19.X`)"X`(Z``)!``(,\1HK?-%N4`>6X1H1#0*"(A@G M#0*\X=%HX%T[K1AFN2I7.YI9NP-L-:)6K:W=Y:1:NQI6Z5T?W=$_'=1^<0=+ M/=`[K=3>-)1>5^J!I<-(AP%9!L+!D@9H0-F6/=1FQ=F>KT`-RS#Y>X`5+X-ZG3=B&W09FT%UZ M`=UH&95R0!5W@-1-.9MS4`?./0$`0.?MI_[1H"3=!T M_09WT*?_K>$"GM926^!B@.`_JN#L[05)4),JP=P(G@9IX-%A(`9#'0:(495K M``)(7`;N`2D#.%,W_!_QS01#S@68P6\<=/+,0M1K92!A$K2I&C=8DZB*/D=JKC=1W$`9Y0)PFC5Q> MO=3AVA!JKI4@<.$LP%:^/1K>Q05H7NG>U10-0>A[@-0+6^6@7;8Q#0)74-8@ MD`1.D`144`0:C0)\S=(:+1CFE0;3K0>ND0(XWEKGU=^9OA;F!0+@'>@S.M!_ M+NE\L=L:3E^_H].340<-H0-L!>%`T`,Y8.4M_N(_O=M#3=U]<=+9?C_QW00] MX!,LCN6H70;=6I^NC8TM<.'G3CYAAR@>NA@>!AL*+JO5[W M_CTE4)/+K:VNH=B#@>/4/=2DT0;6'?&I3MMKP3YL$1+>[NXY/M1B8.,X/JTZ MOO'H[@5"29`?[^*!WET0,>YN8`?3308)GQX2WI@@X`(\7^CDHP4U21-K8>#. MO1MSX%TPS\EPZ_/?$P9!O_,]SSYZ\/21K>$/K]67#N]*SU:3P09P-=&=#!5> MG0<&;Y.>;!5++0=JRU9(X!J7C=277A`=?99\G?'XI=1)O1H,@1A>?M%0F:.\ MOMN#S2!D@.V05M=_WQF3<2B8\@9<0*)US062'_F.$OFAXO@DT/A<8`*)@J>1 M/P*:[P6A+]^:_P6C'P2:7P*:[P=CB0)*V=&D8:+4B1I7[O+AS@;$F=W$>>%= M?M+$J>6]3P;$V93Q[@;$^1LP7P8.#0)%@!#$G0_W-%R`0=-J=@& M+9*-3YQD#9Z'L1L7;=+*;M0V;^RKD@>8`0*+'O&`7M4` M`O!`#\`#OT]J.4$8P/-LT@T@3A%!L84HO!<"/=UP8X).$`^L`!'`F$1"%/0+ M>@&X@(&I$&(T+.#2UH#APX/V(;YM.Q&0$T3+:=,-=>VXH4(E%^%Z@`B8`=WL%=:U M#0<5`%QNF(7,(;X)`5LH6F"`$'B%DP$.K(9?^`53H1<8`L0P)-2&C6?2G@(S MS"[I(;X1`5OH68K`*ZQ*-L\+8D-G6`2(H4[(:1N/#;R^:[@$G:$1L(6X$!>^ M0L'`#K.A%S@"T3`&=+N-!P?20#UTAD@@'[([$O6TR$`8^(>T,,6)@&)(!%[A M&:@,[`@A!D,OH`2B(0SPAAL/^5E#<=@.:>%\NX4YP;1M/`/7"S6<1`P.2XX; MJJQ7"`?:P$GD`NE.)<(`\K+QW@`TRPP:A&YAL>>`EQK`8;KP"!P>FXE*4`BJQ M!DQ#GP<'EN(4"(M:L=`9N*5(!7@B3211R*7K+<4JP!/W(8F*"'*O7`%#E.@% MK(!,A(I.3B&@N:5X!9PB0/J&JN)]J;;6X@MSHC/$`H;Q*$HVQF@2'2,MS`*& M4>B1*$1'&>_`4@1Z(@`'2):--]"6XA:0B0,14_`Z"86-EF*^`XE``3$NQ2Z` M%5.C5EJ*[0TV:D8N4`;6TT)8B@V.%>(G(_`-^\)+9`NA<31&19/W$GV2"!`* MFN4EG@!;*!I+PEH0?=@/4^DXR\@<4(`M-(HR``>\Q!1@"Z%C#GB)*D`FXC82 M):M>X@K@AC!`!@B!E\@";*$-:%;SD3L&AQ8@$V'`2W0!T7`&!(&7^`(")!%X MB3KI%K:$`:D?N0!-$@$D80;DQ[W(!7@`/&Q60^`EM@4%.0,.9(/T`1=R!A2! MERB4GF-+,`(O\32*`*-8`R9D560.KS$^V@",2*+$0+^;`__N)=)&$UD#/"2% M#([5\2A^@9?HV%8DS+(!+Y$/F$,;P"`I)&E[CC#K!BS%$FD%UR,7F`/L:+=Y M!B#XZF+=K--H4_$QE*@QL!V<(!C0:/QM3#+!,]D#SN1LZGI9CPXHO298[.`@ MAB*3\,%,0D&"B"?'`V0$`WA@!R`U<8?VA!K-8P/63KH-.%]'%5:=$RAOBE`K M2;3REET*@U>+<=U%47J7@7;2OMQ%PX&C<*/QA@`8!+TD$0R34=$,Y$$8]2;% MW9[,@L`)NZV&CG8E525\@(S&Z3RNA6]$]*[>T8N32L\%J#3;<`@3(5>3E!\. M!'!*@V;XYH"M_`_D4274RO0P':6ELTP/M-$_/C1)QP64TD^\9=.*OI`W]L== MO!X[,H!FH`ZTI[2GR18A!IR6U(':(A=0"'[)(CCLX&2J8`-, M\%`F2@S8`I!3:,`#6I!6(K_M`"#]X[],#]YQ(8;'&2`2Q@7`M`_D46+F`(H9 M`RQF>E"1-D$(4$R>M##MPXZT"42`8LX`CVD?+"0KM`$X@&(RR)+Y'T#DR]R8 MQI!E_H<"*3&-`,4SF6DHVCYC`".L7!5[D*#&9A1G>&Z]3^/IAWA8(ZKDT=OIT7" MVX#8(I[`''5B+]"-`=YVU-(>04,OX(4JR,#>:.TXG4-@*TD`JBTUQ4`"!URD M]'VF+@]3%/*T2_S^EI!A`0&&@U:<=! MA0$T`K<=3THOQ!,-R`$@L.U69N_$(KX-#]`!YND&:A*2+`'8,WMJS^W)/;NG M]_R>X%-XRH$!-*,F&_6L235`,X#/]1Q6`0( MR$\[D`;J)Y+,B?AS4`"!-J#B*B8`'9[Y4]UQJ?N)0`5H$U!W@PDE<,D@`.W" M0T]C6$U)LSD%_,(EV]Z`BYSD+6KY!;X6!M2*_(M/8V!0LH$W8$'!U5G2#9AA M,!`G+G`9]J1JO'AU\DI"J1G:!IK"#K63A(%,Z,)R4"?*-8"U*XI?`J"GHW1K M+H/*/0BHYUB=JZ-Q:G2#^@6.=/2&F1M@`WM-`E+`'X5'B=.Q6Y;*TBKP/17* M0GG#2;.#7-.S)4*!,$A%G?`C@!RJ_O&UQZFMFA+_3$EX='#RM3B:WHB?NG0# M7&^R";6ZMT)_)=V3=&K3P`G+8&T*&&7-@*)[U[7RU9%C5F M)Y)N@W<9E_S-D?92L(?GM%5A\&TC3S'P!K9B&OZFVXMX`\TIT)?NPA#@YBJE MH#*P#JB&(;I&.UG5K`-7D_SMTJ.671:::HMD#>&7XJ6P"?;(IM9:2E\I(3P& M=J086*AADP-8,/$%ODQ*UD2#1[L#Y4UJ2:BFQ%8&JCI%3>9M#*P!@J4I^1Y] M$:9)[38H-E(Y+)_="D6$K#.&SLG(V92.GAQ@"(6OJM4$#-CMS)NE"VM8-)>M MA:LVHCS>=Y%]A+2%@M*5RE)U'E'3CA>MZQ72;S5366I+-6TX#DK%U/AT&T3J M56M6(ZJ'6JFARE.-JE6+C8CA#>RW"DI4>ZI/97GV3XCJ5)GJ5%NJ=WMW352M M,=6>UE6%DQQC?U`TK66ML5I4:>I1)2\$,+OLA*%A37@FS%<6&@R_71@YDPN>!+'0R/ M(1"6MVX7.;>6;P-LY+2\D;\X1[!4H*:K`V(@*IU4,MK)4,"F4VQH39D..-,` ME2A#'CAJ9$!=TI;S(LNJWP`BV:1)-T MBM4OG-(^]]N6FE-H`0GVJ/W743HKV4JR,VG^-+.B3A@*4V,C7XL+JJTAT`$( M2UZ/6@TEK6-@U>%7C]HO!YQF8P@^C;P^!OQ$`Y)3#1BMH:&T$J?S>C<50U/R MC1^TT&G4'&JA1,,,M5)>-!O14*FJ0LFE7.5K:LZZ65&Q)B@Y;,33AP76:TTT MMG)112R)%6N>DL4ZUPM;`C4L&1"63V!5Q+[74`9F:`W%3SZA(-C2=/I1C]HW M$G-T@!I5V?\*9V=HD74#?=9.6BDXFQH8*?D3IG7)2.4!BIH$K!\EK'B7\,`F MM7'Y&WP;<+M[`I;1'<&CE^V\TANPD4HTS5&WBS?LCFM'75$,$-#=TDX68;.1 MP<2Q-8`X7<'>FF19ZX!]#-ZR!7`!3PMJ)Z&EK6[7[3&8VH:`:K%;>5NUT34Y M$:<:"P)L`''"`3:V!A!"[8((Q1WVPW^"$PR``36W]Q";0D4,=8"[Q%>]"H-DG@,C>"*R:7*L(-"0O78/K;ARO[ MFI7$9:H%5ZD*U8NK<(63QG6X5I8.`(6/6V]K)),EN1FWX?Y;B%L#6"[%)5%! ME!(2T;N'<4VNS.6X@R$&V(`>4#`'[@H-#Z-N&JF58->4*D.R%4X_-^5^,Z)+ M;V\N?5VZ/HJ*MH&G>W)G;L?%`;?-Z.[44:<$Y^IW^DJCCMG&6JCG=8-N#JB? M`['EZM6DR#CW;0U@MO@)QV[+9-:> MEF!+V[X#K(6AHV4_P;EXBVKB'11MX'>6@7F;!#4OU;5RR`ZZ#3;&^13ZRP"Z M`ROT##@*3&7=3(,AY0)/U+P@A\P[T*J<<4VK<.6BI=Z^YEU0P&W`HVMO+7A0 M@O9!Q4!EPW^\CJ>*4$*'`FW@JB!QRN$P(-M(EM3JFANX:\K2R_TY[4K0".Z9 M96S_=0#]5^-I/PTN-L(B?W;;.FV/CG7-5? M'2BT?H_1+6#*^E]E5%7@>E^4+Y2W:NOUQ*F@XZ4HX+A>7F`'Z+8K@HT(L$^C MN@9"6-Z6W3!;NM]OFTY8O^"!RUM!($X6&`-?NJIPXY):<6BMC)>\KKHI(!C0 M*]@K`R$MD+IQ:_@8:W.N6E/7$9CL&7'@?,&7=HDF6 M`M\&,_KDR-P`8L#_U5%L52#0I3IP^,4B?A?P#H;TU(;E`*1AP']6#E=0(!`# MS*_]Q<,GZN_*/CX\YOSP&Z:L5DH0'UT@(`-T:(KBOX@8P>EA49(;^O`?IJPB MMT-)8A8*!&:`I_.A*2H4PX'X.3GY)R.&%#DX45, ME>`=&+X#.9 M%`PX]D*$>GP#8&]:3XP`951DP\D+FR"MI#FMC M&3`"9L`(H`$CX%/LVA4*:HL#&:!YG$[J'JO$P`4TK^Q2#?IS#6ACF"P#UH+= MQ''J\FXVI2@L3<4=;'&)>*KR#@3R2ASB[;'J?"1*_K*!EAR3GP,2O@T)5G:A MWC>@>J_D^[)*7=DLFZIT/-&.\-&MJ@GV'5?CCXQ162P'F\F?=C+89)RLV,"H M)H:I/)GVZC@\!905:I?:Q8,AY?YD-!"4"S%BI@/F=S$'Y4K\F"UQ623,C%FA MVN+*7$-EEU1NO'Y9$>,&/*65$_*Q\LIOF:>&93PUELOR[SH#IUDMGP:_+$;Q M\5)SRSLU"8NU=RQ^,[-0C@';N"6O7C,0UG1R#.`!VQ@K\T:XB1Q<@QSX=&ON M4:*VJL#_OA&-8\`@H"5?BAG51H=OLIR=4C8B-+=,R;"D,@\$Q#C5"U)AG)H$ M)=6?M9XS(&:Z@%QIG+8@=I%TO$U2=K3N\A"]'@_XLSX@-S#@3Q47*JU0Y0(% MNB%`*:J+$K;@37P,,6"2>;VU,-`>XG<`M["/D:I-S_B+/Q5A=0W2[D.;*GWG MH!$EA&[0>$TPR"889:=^\9]540@01M0A!`SWY[2C@*:L M+UH/Q&@A3:([VEH0?XVTCD95N?J-I!0<=)@#>D\)Z:7*!:;T@G;2#]I)?Z>? M-@=BUR^NH5Q``W)`,0`$B+'#>\X"X;IE4C%]T%YN&=BYHDVN+2S+&85I7#/M MO[(;P'9KP0A(+?'Q*/7#M=H@WFI;=1=]YZC&%9(:CC@*F-I9C:N?M:S>U5:--_IJ,\#!+/71ZP/#VA6LXHIS?+[?&%>OZ4HRT@L>JH4+*!0*VE]!M+=-@>#GKL'MRB:6E,H("";T3)PKL1FA1TW7][A*+3I=@BX8.#%J4GX(`/: MY*HH4;"SL&DU1W$&^JX9(,2`(U]G;#-@;N7"CPVW3&P!J)3:,\NV@VU^E5.MU]TYS(C@N96A:`C= M0B$WA"VE!#MWE8MR;P9T0:%N`SHYP6OH)D@.$Q'NPMN=NE5C>V5TNEO#S6[5 M316N$UKY7W];1<7L@D!<;W=*R'83T"FPU^:-O+4EB?(,%BYS5^]LE]_I`N57+N3X5EJI"@PP\@K`Z6[K'DG M$'U>)+?#7':3(7^;E>W$OR.W4#"@A4H-[&\H&KD7:#JL"D?/$X5[V< M!L36OZTW/I;A5LEL>G!E&+EM>`L_#>*U(<#P&X["U0HU*N%$G%J5TMX`*1JX M"_L2E4D,>26C^V4CD$-5I=&W51S8C"S?*&P6^U!M^F.GRZ*$/N71G" M>%:2W&J\CK-Q/"YHI?+(^B\QE>R5`VXS(?0%;B=: M3+AV[`%**<`]M(RVR"\Y4J-L;UHP$(3Z=Y;4P*?-=@9Q!M7W-@\LRGS^=K-G_G&>Z^1?)J7\V*. MSI.:.M_FU:J=:[T(F#2\>IV>["6:FO])WH0)$F M3J?SH"F&8HVFV8"-/'I"W6+:X M\_+5J2!([X)*L,!UN+]6I*'W\O[=6V&D;UXIQ;Z1^?L6>/'[,9``$@#-F;=[ MU=T"G:[S2_?=-_'Z904!>[VOPW7!\!L&PU$?[(^NL!/SO([8^3I29.S7S?': M*3@NL#"[8Q?L<=O$*H8^GMZH*""7##L[9ZZ MD3)J5NJQ)W7NIY2:NFV/ZND0MU_I$(74CZ5H7\!](4O^=MR>&_Q;;L?2)EHX MM>@8E]%/FE_7M`O:)I5HV30#MN"6EDTY8+I?!I!ZW;="5==?11JKT!PT"NGN*YM*]E;T;*0WWWC7M><_M-V"[/P;['JY4]&.(Z5UP M,C[WS;X9&RQZ]]*$H2MF=R\]T^6D38SOL8N%Q[@%WP5S'(?/=GC`PP_WX^;? M)#2'5^\0>I(QMM6IBF];#P7:9*#%TX`>BN+W+8W_[@?^Q=MF\+0&6GP-H/'T M_5/`8=OK(=QE+W&6A)M0JC)HU*AX MY:V4E@^\!)Z^7_0"C]\O.BS_5*W7RTLHF'I&R8":UZC=3<#O6^]NX.?\<:OR M5RILG8$WS^;U/)]W[/*]QB-X,B^;$/R9WU.]7;EK-:%^H!/]9%CNT32[RP"M M#HD1?7+O>L*]0R'WIL[H.]2,OO-`.CT[>BT9Z3L443]V3/W*9WIH-M7;NHM. MS\Z<5L;ZVT;I&[!&!:.UYB*`,)X,9 MV`,A(0?X!$?E!<<]<+K+#\KHE8%C1:(&J)/S"S8I1DDMH&`4[[U9#8_^?C#Q MA(!/`W#`2,9=P[B-"FKHZFNI&Q=6WON]VV>CR/GZ./C<6Q4B`%3B.A%0M:]V M[8RYJZ!@(Z!-B`'<@#'GYO$G`3?[="[]U1MQ&]V("[BH;:/W-O_0G_ZV;!VA_8K;] MU5_YZ_ZQS_LC0NR/",%_N!U,WN_;BJKQ-_PB'_8WLS2'^=7(/TE M9JH?!M@"8G\KH`D(`6Z`WA]D9OO)@,W,!CC^27Z\GYQ$]\E)F)^+LJ)(9(M5 MXE:('D5!ZX M`')^?"#H)_N)`1U@#)2-E%V7('B2"9I^E@'PM^]X@)D?C@/]$'_@GA((!38S M[-@8@/GM!EV1X73E%5I=D=B7_1&"$>`&:`#>?PG@JH`*BH#GE\SF"O*"\94; M@`9@?D2`B1(7B#M.P:ZGXXR")Z`<(,<0/-V%DB7N;5!P0,/S6YD7F1(U:`6J M7"H!-GC4M'O<($_R"")^O2`'6`[N!ME@>^;NP0$W"?>V"ZZ!;1]Q9J3]!44` M%1`$&`%/@!.P-:5>Y0U_8ZAD:A?-/;7W\#=)GBJX.TU09`"_UM.X0&_@]O/U MH1>&EG>A3\TH4UM3LNJ@`'--LV,I.5>E4Z?C_"$UXYW6DA&&!J=>GX*WK3T8 MBB_&_^4IXU0VLA:4T\6%GE`$G8T9M**.`?64@2K'@PV-<'`Q`'O-]S%A6-=6XA<:#ZR857TEA'XG0H=$!= MR*,T?BO)<^8H;%%5&L,6%^HG>4%?"%X$7).?QK87ABA?'V/X%,Z%)#84FF>54YD(8G&`UV%YWAA:)Y-8;I26+X]75L7.%2]Q@JAH,! M:S@64H9\X6NX&F:&QX%6L+>P`:4A/G8'X&L`6%L(7LP`<*%H8%?DA97AUT<< M3G['X6MH&PZ'Q>%`@P?`;%%03YX&!W0&UJ')=E1*$K,0XZ6V557T0#! MH?0T]G&'!%1C".K=`80ACG0=0AHX4F_H'G:'H@&.E*]=2=+/:$)795+I$]EG M'DY_;,`6%1WB2-1A288!OH<#"`;8&QZ(]*$;@`'>AQ@@+;4?*@;_DVHH^3&( MZ2'O%R$BAWSAV(-VN%9C!9!3C[SP0T7<@!BL$690'= M-.Y3DY@]O7^\G]87^Z5]_]OT%R)*B5H?#:@#'@=8(M'7'_*(*E?--?EI?;0A M9+@8BHFJ'YE((EJ&R>&9B!LR!%H?=$+TE88$R9A(](T53F*>J"<^B6P%9^". M$#A:SWPU/MU+2*)'\_:=48F@T!9"A7TKR1$3+EDECL*U9!^X`#T9_P,O_0<_ M0*68*J4'(4"E*+M(BO^!#J`I7HHSR:@(*C('+$"ER.YY2XZB5!(I/DO,@0M` M,<4HIV)P\`/,BEU*K<@%A`"XHG*F*^H`$52N""L&!SL`[B8LI@;C>LK7JI'J97ZEUF-5*T>"U6B]`B5+?J$42KWJD'F8UZG1ZK M5]0UBP-(NN,H,(OU3>84`X$`/(`G59_X`&S!"Z0YP8LY3H`&:<0W2<"ZF*]% M62".7\`#9#P`8`!H.('(`PG@"L'M.G7JQ!NP!6\#"B$7(`95- MO[,'=`'-(K%F5GAP&2!21!#Y8F;%A5.5?8']E\E3ZK![$I"+4BFL)+>/HX`& MS&(:3"\&F8D!J1038]0!N%7Y$HGU89L.OA=@@8D&/%C1>#1&4R3*:O"5`#=[@+^E-6X*Y(/3.%<0.0X6TH/;Z82"U5MQ7"EG M)1L6H38*=73C]Y#NG`\C(QUP.%(Y@"--II22D'8#FG30I)+OGY[60 MG\H,V:%\>7M8"`F1;4"/4+DXY5A2+QT:4##Y*G``RBE`!T:T`)>8E!*3': MM25'VG3FEQ$Y@*`!7609\$4.CS0;L)68(9)KI&6V[;![D"0;&1.&`0R!'>"J M"%FRCQEI\N1R6!R)8@?4D=X%8(<&Y)%XRA[9=/61'.0?V:'$:#D.*-D7W&M: MI!\PY?PO/5D30**PB]C%6[.2X$A."AJP![P`H`JO@K!Q4`+$$')D]Q%A<;N96JEP3GIW]"3+<`! MAS]"&F6`&I"C[([_)!_)[G%%;H]!F1"TD7Z8YK9-/E#L9%,BH513R0L)":OD M+[E=80@](@>?ZDO;91DI1P``]P)8V0-^2:-YIM1MM) M=<=2`I1"P4N)0NXI)N4*>=*DE'[82IE1=B@N)0L94VI4LHM%:5,.E>7+__)$ MMGF?2D^9(/XV0"4#\[WH+RZE#1F5R)2=BE*)48(O`.4]J57R*.SDA2,SUE#V M#P4IUT&,B=&%9E;CC4[))L'NR*:73DM#C0,I%Y9 MB,F5-2.D(0=0!MD8LC(S,EF$06$(/`Z6:0YO5CLBEG?98JD7-)9"6F"Y5^J0 MKEIVX2BD=>K20H.-$`?KY$I2X6",4`$'D_E,16":D-:X256/9:API;B60IKL MDGG)531A]@98WF*%81]``C2+$)A4I9:I%9W9E03O@&D^"G$I51$'EJ6C,$IZ M=,C.[;<8K71G7:"3T,T`YLD69$KVEK^DI+8[#F,4BL4SH9`&<$`>,%S2`6": MD1(].H/DI7F97**7PJ5)N9(D:*8D`[FG)&A62KYFG;V-CF1'<]W\*(Q<4H.D M25/?UI.SD@0^U(VC@&TAB1])I8"/;7A2&A!`H$TWP$V^INLH!+W..>@V4C?$ MWJVW=?U7X1XXI1#\*V[`72;_H'H?ID9UK$B15<&5\J`49RFF[.,#]&1>F.SX M.^6.Z.-"643Z+22FDU/4[66#FZ>#X'B8GR%C0X8I:DU!C'9D+FP?"2P'IF4W M8E)PV:!`F>\5K21E/I@CCO4U#4(:%-R-LN&1;(XC&V!FKG;+)1:SY>Y9@J74*:;J6:F2_&.D2*NP6!CYO1D1MB,7,![1+^< M-I8CUG/-B55R@4E#7T!CFA0BI-C\DEH/$"`&#&<-"O,8:$J/EN8PQJMAAZ&: M]+1("FZ-Y!A)@,E)DB:F"8,U:W<1YE-Q2FWY)D!FN[)KP3X_B:ITVN!8_Y!3M-^W?1O%`K MP#\&BV$1*X"C`&SRE[+F=``WX8ZN)E!SHFP*&A400.\5DFJEK\-BVD042G$V M?LV80EJ]9_,)-3@F;\#N_4YB4^7C?KDXA>0;R3^]*>D7OCE^?8K')9W99C:7 MK^5EZ?CTFVF`@^D,LIDC#JH)9.9DZ9>NA7"R1S=9D%FJ"6;L9.;%:QZ;L"4- ME0KD)EZZEG`*FX2X?8\AYU;2<*6?!6;$I@PRG M5N"++9PEYQR@96H,`">9Z5$.G0T*SNC9]&0?R;KV;A\);M M9C]GY!Q8[Q2BU`:`4K":JBE7`IYK4U;&>927!2G2ZGU#FE+)TC9\#9 MH)R&1J=493,$4@$.;ZEY(3NBH?Z#`,IU8Z<9P*;1F,A!YZEUGH:695IY!R!D MF26JV7A&CY3GW8E6-I:W)^SY=.*=ZR2/\G/*GE&GENETFIX#39Z"=T*95Z?Q MB:>TEL#A?"FPR(R=W?F%]U5`VJ<*23S!8)X='0#O=9\8"F+Y6*IC.?2KOYH,F**)U<%U:F;GA*2)FBB*`FFO]HBKF0)NA8J8*6+YPCE&);!FV* M9/`X&>&5&&#PJ$J^DSKE;O.I*"4%J+3YD"EO+%0TP_\<*\)2.O:!MGE\I![) M0]J?R..[1BG6A[-CI+B5R0"7@G\CNPB5X$M1"4-F>5PE37E1HBY@I>8F$T"5 M/*4_%AAF)5J)=.+@*2@.7@B*`#UH'J2E*.)U*++B/C(#W(]<0(C'.D(I#N1` M23R=<&=`',H969NW9AT:8:)X>2@O.9N\4BK8C4A_`4%[8B:JB3:)\!,6L?`$ M!XA'`+7Y2'(F0"8QJ:]G?G:/2?=<'!9B2"'!M!\V9=BDP@BB2O)%Q"N89+XSR89 M/]HG(P$@RG7*C*0DN40&9!>R(GJ2GA"C$HZGH#YMHAAI1KH]<99*T%*#!ZR= M#YMP=DF^H]2![-)<9CZW):>&!Y4**UE+]ENR>P916=:11@1OU@V0`\"D,>EG M.=QXI#7I.;&2N"0<$4\J52$F.`"[!P7HI-F%4(H'(";K!&?IYO"7;Z4[6I!. M*'9`A(<\,I%V*)56+MXGYPD>H)R1G=4)VXDV?B3<9MQI*9PVU,C!,R=5=S'? M!B9[*)>*I).3EP* M-TZF@VEV06H80[SI=OF7^F&89V^YG?ECC&ERJHE")S91'K"(.@I505^*H,V3 MTT5!4`:X`#"`_=B@-)<\"!HP3PZG02E-.I3"`/-$83FX6`6,#WCYH(B7;XJ1 M@YY^E"CIK'E*NJ?G!1?``F0^4B46@>NX%`>I_RATV0#V8Z9B]<@!BLMV.HL= M%06D?SJYM`$;!2:JG#ZHG"BD`09P,'(8F73=+$0JP68):9P`%&IL>J&Z0AKJ M`&('=*@(@6R:G69G,V7B"!-Y`6=1B;*2 M]``PJHG:[82H6(07T*-^J*9-C;JB>@';$$RTDK@`0ZJ,"@/D-$#JH(`$-*ET MP$+D$T2I7,"S@BM4J":J2X"EB@!4ZD+$LFR6$&J9VCZM).+GEJJM?62>IFU6 ML(`7ET);!B868B7JA7H#&`'38YIJGF(1RI-')Z$-I(!-Z]BG=A?3:;D$DUH% M?ZIND-4$JDYG?(I;M@$%9`Q@GO10E"*D"KA,JG7`;UFHOIF!H8-W@/ZICNHI MJ03U!62`79J@V@`]E'+693*J)ZFGDZ#*`#T41T2JFJK8B3W90VFJWFFY9%N> MJK'JJ#H^)2N>:H=S!_R6[>AD\ZF62WM`J"JK_JJ3T0'JJM:JJ&H=H*HNJOA% MH_JLUB>V:AVPK):JUZH;D*WBJA+:K@JM]JK#S:Q*K!Y0XQ,6D3$J-D8./'0# MY#3H:H)HV8Q/[JJ+A`V)HNNJD5('N*NU0;RJKLZK^^HM=`-X2.?IAI.O@JJ= MY2F9KQHYER2C^EP2JKGJ;D-#`:RRR\*JK5*KKT&81DINJF)FOCH^G:L#B(%S ML"*KRJK%VK!6JP\K*A8);&2^`!BZY[2>JEB[)[ILG7M M*5>+0L6VKB39R]OJ1.YXU4W9RNZI`/8FB0/O3(1(HK5)_^0X;BK]N1IZ&EQH MI4"LD([VP72$..Y:@L()L`>(/E[GVJ2\82H2)FEZN69>C$]V9-W(*&I%4K8\ M\IG8SP"5N:XDI2OG2FF>`'FJK:F\,4\29JH9/3XH>(#H8VF.KM1CZOZ,UJNN(OUF*>R>[JKA'F7>:Z9*Z?YNNZN!5LZ]KL:.*ACR@/T/*Z!HQD0 MWV@!CL+K$S3F:]?K4"--;F"#DQ*D`#"N_T&+>C?VC"WJ%Y"O?0'>:QI@`'$! M[.O75O$A6B$.>.4Q"U)AT M3/[JH##1<+`B;"OSP>IB5H$#VZPHL`/(0L4)N;#D80G;I%@&!I%`!,-B$3U4 M/O0_K;!H9CY$^`&Q>,`T*EK$`'T?$-L/Y4-V'Q`K!_1S^5"3E+\6L)86.Y(/ M^:^PZ%,0L!ZQ`^P4*\$:.+[-"E4]I;`^DA<[@"A#1FQC`L&:L5B$:I#&Q@`8 M+!L[*%"PT=!@LL,."O+/F^;`1DJ`07$6GM:2CB:RI*P0&PAA,*FLCP)$,L$5!KQ#F*MI5J?R`"8ZLF:L0ZJ?8YT MN=K(B@A>S:K6`EIM[7!J*0"UG.S[(K!T%SQ1,%O4#@IQT6[C%A&R>)&&4A<1 MLA4:3P2O$FOJT%$+ADTE-FQ^PQM$0RT28\L;J$N3`69;T<*BA@%4T-"*%CT2 M(5N[C3CAEE$G,=T`GZTHZGJQ1FY>:FL./;0V[%)SHQ0X=>!J2]1:M"ECMX?; MJK;QT9V*OPZV,!3V4QI@HS.`0@O$ZGD,`2[:K-0`U"QQJ^>10&2`5H+"K7;+LXJW!LYUZSSML\M%0_OP M>K6WQ9JXZ'[:L,;M\R>L@!8F+7%;X&2TS^U*:][24+^-5:`=R:+-"@VPV\*B M>IY-Y-WNMS1`:UO`-KBQ$')+`TBQQ"T/*=1"N`_.`*+A0J=ZQ96BE-BW^BPG MZ^?%`8:->TM:9+>@K:KGV`DKB,E"9\/ZM4OM9,0-V21Q+'%+XWHE(-IB=./* M``LNOOK;[+C=17HK')$6A*R>1^2>-!K.&-O-@+<#+G5KW0I'-8`W)#V"0\2! ME+L=0;)>3EA$'%VYNUR8YN68M@5/6"3A2K`I+EI$R$:$<*AKH!*]JVMNFRL' MO+G=K'^+XI:YPE%B0LA*@&ENGEO>PJ+=;5,0%I6QQ&UE,!F<`6]N?SO@OK:W M@7[;"D&Y#&Z:"=.V0CENE#OG"DKIGKH<+ M3!H&,I%,*\$:N&C.7T3(GIA)L&%#8R$:$[X$Y%.)Y*-".=-M^(^':G/5/H%>K#[-9YJJ[X M5>%ZNHHN+"JKJ$>$K&`DQ'FZM2PGRUG=N#,`BL314@4ARB0+$LD`FJXH*@%* M16A3'.`4W0#`+A4;!W!%4U%O=._RNK"HV;3;&"E.D0V0[?*P'%#!B^$NNL%D MIXL+W4>+K$&$ZH)$RBTG.]`((8S% MFE$'&HZNQ,%`$P<0LMV%O0L;L2Q7[N85$QZ]-JQ6HO3B0BR/]&C=[EJ]T9YK ML6%%\6X!>VV-`5B1RMOC<$)4@1,$&\VZH*W%YN_"1@"O*/KUKKU4[\?;?X&Q M,"W5>_`J9/9KW?L4:;U=4;V+%:VWYF[>"Q%,O9I%N4O<"@9.$2[$V$ZC\1"0 M0ZPUN9%;M^0/1;V(+FQ4\HJBABUL%//ND*IM/"3WUHXMK\ZKX1A&H&X!VZS6 MO#ROM$2L=4V1[^G;&#FQHN\=D!G9J(2!,!;[$K+L2%=$&*1R(!$_LD(6/$[! M&Z"3ZKXL5*OF\@JK):Y_BZE@13?OLJL=$;Z("4?K&C2T\5#7>]#Z1@ZO9M'M MZJ^Z$_6K60BX+6[6\N-,;"O_/12N+,"09<[59K MI'2UM>H,T$-IK@N*.PO/-L`GI&'0`IRE6Q$[8A@X.NO+*]4"A%Z()W(E9=V1 MZ=81%6U"&A$MM$AS.L!87?([X+(!_=Q+1"[`; ML*``JXO1`2H#"\`_\`W<$$$:/[#KJ^&$:S0O@,,%!,%#L"3[TLB0&HY"@)LJ M04/PDLL93<$\Y!#,!1LI-QRO4^,F1NR>JP(W7^P>_P&_QNA6)L'>P'`SB> M\"*L&*TV!R@4G`D;PF(F(DP)J\*(\"6<&#FKL#`7T`>SPG]P?/LW.0H[`!

.C!"ESKL&P M=@UC*/=P,JRY;L/H*3Q+#[_`_'">!0M9!5=*0%Q)L'MR9#\QD#P\W/S#$'!]$@/$JM7I MT5.18<0+Z4&Z$J>FLYA&?"G`R`>LYY6Q2G)(9-A,91U2GRJA\$$VP3TX7#`$\^Q17J7R02H"36@56 M<8R*%8L$+,NO*6YMP,5G\4R4 M%I>F2XU"Q1;;J2*!'$-)\@9[,52`-':J[HQ)D%O-! M.0V>F!23LRN)[O:W&CER\6I`%[<$-L"Z5QD+IK/28;P0);>F#;O'EB+"=UE+ M#)8"CZ!/6,M2$<&\,(`CH8VE?IA2(ITFJ#!:L99$GK58+6*WJ?INQ-5HF(.F MJ)NJ56N6FL8[C2.<&CNUJ[%8ZAHOG8[P;`R>VL:0:7^:&Y>UG$RYB-:R5)E/ MQ`HQAJM;.L3XL573'<^3NIYP'%L6Q[3Q7CN7%G7W M;U\;^<>1B M'S-LV/&`G%_VQB#;?BQF]L>W,7:R(N^UEP*)^TM.A2UIN``\8@LM6;=ZK$S` M]>R0;$H0*P;CFN=M+365SVU7U+D&*Q)E811)HA%>PR+_>#*.CE5`&%1G;!\( M(,HPC$KR4Z`:X*9(BE&P4Z2,"DB1*#")3E`P*X&01-^SO*-6A8'(7XYU2M)$+`I MBU%XPC#5&^5M>`5Y3,J"Q;E\]LO>PMW\LY0=&D&!/&1`"]S"[_RZ]R3B`RW:F$\3-K`/O+3K*Y M#+.D3%@A86PC*52GKC!I+T<*2U/3)(E^([/R_?9=B&]'P!*),?\[D,$;NM26 MR]\R'&,#X$R/LL'XUY+)$?.WS,;`3#(384PA[V@L,Y3L,M\`%--;;*.2-LE* MOFHPYJL]=US>RQ:$#@IA'7 M)";+!G>LOXT,^=N\P'A0*84CC/`;SS8FHWYR(`LY?D.6LYWW. M6,3B[)7`LS:1XOS;L,Z#@NLL.@\W0[#K/#F?SI6SI70YE\Z9V#,-H#T7DW4[&A69L+*3J@$$AYOR!C:1;%4F MSP$H0`H`%VN,Q4&$)T$[R7/`%L`Q7I.6C1RF06]J$S07X"CLJ0I9'-">*"AO M#CS("M4Q.X%6S)$.-U')`U2P`5`;D&)S?B;()/(VAG6.*.=G8J@@^]#@&NXH MU4J#/[*E<'XZAWIA#\V%OF-7ID-27#*,E0GN&%=$BIYGLE*9@&FM:DJZ)A[1 MI"&T0JSB*4I0#>V-)BN[*UW)O#YL6+36Z7O:SPFK$:U":X<^]!C]1N)?"!ID MUFX^G'U9Q(DIS)9`@+A:GPAY0+%UZ@(89.E7<6M>2M%,5CT;$M!XA*<1N60^ M*':`DBFJ*6J,61I9[BT7CW,E36PR9KJF,O0[W9^#`AJP26_)SB40H&LR9L2F M*)U#0AJGM/R32G_2LR;.J:(P9J_T&8M+[X[KZ0+SB+6I930Z*R?-7C3T+NUP M]JZX*V1F-[G26^+P&NZ!C\ST:9I%O]%XP(*\[##3:7`Q/4K?T*BIM9J2(TLDNWT4_F;QASXBF4=(S6FA9/>;0"309<*?#T/.U1SBA?*(02 MHP6?\'3PZ5H*K^FT(-_,E?YM/L*7+P2S?&-+0P#1%P1%B2A"E,(--[)O7(MG&N80F> M@KO$FL_T=5)2&P;2M!L-$\.6P>.R,U/?$<]T=K%3<]/3]$U=38>JX#07JJGJ MU"PUNX=4F]0RHQ[-L.W1]C1M&:-1GPPT';PWP[-F]##=D^TTO5%&=DCD:UM+ M9],YH5>_UL#&5<8RPQ0XR51IB?2KGH/[+5@?32N1H3U8/E)".6 MFLBT<3HVG)Z,YK'F^OK()Z,S5BU2@P>_$[L*1NW#B;61YNE3M8W3,^XX`'NR]:^!HZD^Q]PQ[@A:\]:-;I,+/12V'H0S_(8HL7$%MJKK%0;X0\)M?2"1DL1(?'E"); MBD8"PC+IA:R@\#^IUZ4PXDYU$7+M6%YSSN?UI9-&U+?L-<3HMT#7R0IZK8*L MUQ`RQ(BIP,X8LEQ(U&FN1!U7!&#'UT2=?(6./S,+$CWU>_)H" MP9!=>M780/:-77H-V2/VDDU?V]B01NFE8IO7$+:5S60?VS5YC'9JD/5VB#R<)?=/NRV:QV_9:_/(KR=L,[;U;&)7-5NJB;`O2U!%LVEXE]TU,K:J7%> MHHUO-],)3[?$)HIKW9QZE,BG<`EZRBJ^IJ^816B?J/3T?I$LW[&D=%Y%)=TPXV=3HJ2[C1NWIJ=AYPUV>]QO=8]W^AV!(@=39/H%@?)E@W/U M?:7HWU'9_3V76I%372'),L8!P>;`G686W.[V^0U_QWH+-SLMG2K>?#4/C42S MG;ZE"9#Y6."D8:6`@?_=8NV^78CIM>)V>C))5RC34UET^/AU0,#OZ#KJ90\I M_4UL.N!7"@0N;\-J34V#R7'+I4M*"BYYYF5B9@P.!XB=8NT,.E+2I46=*#F$ M/HOEHK@((]^F(1PN:>P!>]J;M`<7^1&:*Q!0'4.9LF":<30G!_SN!+\# MCG@AF+Z1[54+;FG#=4+=7?;>J>%XRH:YF]:>C:6N5U]F/EHX=?,;<^#S'NAC M(E\*P/7(K;GV1L&F4N*&L^!+'1>>HHAHN4P<'FRFE78X8JHQ\]5Y>-G)A[/& MOF7*V85W*)NF!MZ3\9#@H?HF3XJ;X/(F*ZP:JN--ZU:"=N'$D3I@F*^9G M-2Z+^]VT^(BSIXCCOFDNWB"W4=;>LD.U4D)!(1>6OITY..@+8L0M70L-==(0 M6*UWV!Q+L"@E^DX(-Y!/LIJ112U8!7%#38(EG,!R^=BI?.&TC0.9R2@S3C+Y MFD0^Z,@%Y*)B4-.Z`6L`1#Z`]6"%U:!#DEOD>>7D]YQY8%^)XT-8VBJ[4F4R MD7/D3+@RE1K$;T<-0^Z0SSG@!5%Y&8$!%CE7'F\ M1N'8OP57!Q>'7N5'.:3Q[*PPPUEQ%L0I)2[E'HT&3F76C=.B:\WEY3]S9?'Y4!- M8"X:O`%U>8Q6FA4J_+=FKI2X:J71[AE[LIR@>9#)E\.>A#FA.1HT7;\2'\"7 M\P%&IJ@61K4G)+EXT2@B>U;!O#=S0V82YJ#@TJ*E;YM0LXUY,GQ-8@CLN&P# MV:5C2(DV[#3WTISY3LY2I/A)U@6S9%L62V+G-@@QB4^+W(58<"Y/\N83&98Z MT9'GOOE\RV+EYB=*WKDV?:%F[;(GA3]"SUYO'NWY*9\BJV?A27@I2FOZ7J*5 MV$6;W!#/)I7-2^-/U>>/6G[^E=`!/)UO:D__YXUT]W:HG`&:6R[YG.`I#*@T M?J!-H)MX<"([MI\=.HDBB(+H&CHGCJ6I-JJE>;+-FK:IJIE,RRBS)H]R/9+21/JLB3SRG-0: MSZE*5R:VIE(]:X+3X7FD-F]&:I&BQOV\FJUN^8KN7;K'!J?LN*![Y0OD.Q95 M5B;B!7&@5>*0^V#(4]`<-?U4#H2>#S775@1WW'1@D5J:SBK%Y%9!LD<``3=N MC4PU5^ER?@$*0!,`.C'`EYR>Y>DGBH.3TAAED@JF`M38!GUZ;_X8.#CNJKPJO=D MXD4:S`&MZI4B8FI+OU\G"O%*L.#JI[JKKFK&ZL0FKW[?CJVJ>J->&"Y5@J>. MAEZ]Z=E(G`[W>.J<.IW>45TW0%>GGJPW<,J1N$<0`$[3L"Q9J!_JY4VBKBBD M9]1ZY'N7^E/-NKAXIF7J`YMX$7]NW5]G-\UUXNB5Q&GCKWUA7&<"B8W@ZELZ MM*OK@`9\3=@]'4;GP?H=+1JDIDXUQ1F:)])1=5V=K:7F$*?[99-0Y11['PU' M!G&$P>;7>C(IZ=>,&<1E:GI9L!Y*C^6RNJH9O/I#"'NK7B/]-C4DT@RZJNF?LF8SB MLP-QN"1%#'>;`;&ZPMX\_]&H9+9V/9>@OL[3>:^[EN&X^S5ZSI%R0=SVS5&E,8%TDM]Z)V.3ODTY^4SZ1KS6[?OX[EC<3$!JA<&NDUXG&GGS M&<0ECU[0=3*9N]W*6<8.G!SD^71QEKYI;C[`1*E+^N6(S]#:E#B46Z*OKI4D MCV!Z6@F#=NVWF-*.T]ET!KE6LK4$@7-E3(V_5>2+N<&>5F:6?N2TG1/PSU)D MZWX](\_LV98=[[76H M,I27^T&)F5\HA=<$\];,`>PF`K06@&?P#OV#&B2:MU_];`UGKV>Z[I=+WW3FMBY]6NW;#M:N M/[5BM\J]/L#/3Z?-^=W?3&%P5C[]>C+JK2,4SJ?3`7ZZU>>#7>K7^DR9@GXJ M9[J!>Z+\G`BZ:^#1_9S\>X,"P?_O0OE8OI9SY21*V(Y_B9*3#&&^FU?JG(Q' MUS^NR"9I0^ITRP#!6DISD.Y;AS2,EJ\5['#M4.,"#'H@5EC"]GQN+`I/19Q\ M)PA.$I6F`32+(AQT808^\M+`%.V67@;1^.2<6V"R4#Y^-]H]692R5%6Y0%4\ M)U=5-8M*E]?DS-PYW0AGR8!5);N,;^Y<\]'XM\#"Q'@72DLA!EX*"L[U9@G+ MT?%[?)?2RW@E8$F3LL00+,3!(?_+A"5@5%K:%'!R<;SJ,\?K\01+(::5H&F( M"B'/R&.]G+QF$,DO760`)9\7#/*8O%92B1DLBGP=GQD^,;E!&[\7F/(1@2A_ MR2_R6HDI-@=0MXF\)W_U[O+67=6B^LCRA@$3K\_4\I8\9>7+Y\28@EJA&K3R M>SQQ$%\Q<:*\+']'T?+383*/>J7R9<`]1F+V\MR\72B.@275/%JQ=.%OQGPE M_XLM\P99*"@00/.?O#L_4XWRU@\V;\LK\]Q\1680.0;S:3B/*0@$Y/PP;\Y[ M36N`/:_-+_,C66]'`FDV[_PR7_3V!0N]&5S.IZ7*8#I_RA_TW'P.X*"PJ]`- M>`+/7[W3&#@D"@KT:6E!0`-;],C\.L_-@^5]0;=RE:13'[W3:R02!B\]IT72 M+UW*$$J?S:OTN'P9T)CP*-!%/]_3XX9!_42/=4$H.OT]O\WW]#EE9^/E])$. M_:[5E)0!(?E-W]%T-@8]3U_'SP3)2E/@VS3T_GQ')VJE@58]:C/))_6Q_$"/ MU'`CIWQ:+\DG,B&4.B_+;_)MGR(3QT,:`P.B"+5.`7T!DDB<#.9'P-7]*?$& MG,S])U#A)9541B>8D@&-2GHBRULQ8XPZ/X`\#'K]FL/7_S<7T&!>PF0K4-UG3#2#GWV`ETKS?]B=-]:3]6 MG/;[/%B"W:\D1,`2\-HGBMU]7Y_<@P!$`$`/&I#WGSU<$=V+]E0!:<_8F_;6 M/$2?S`D$[SUK/]_O]?;]=X\U&?@,_6!_VYOWNGV`S]L3^&I]2-_1CP$)_@"2 M!$P!KCUWKU(T^%)8$L#1_^M.&V%?WOOWY[W2FMX/^.N]+#_3UP$U?1G0X6,1 M4,`3(`4L^)8]B3^80P$M/8V?*%$T*GY_']JC]Q8^=8_AIZ7+#C]_XP\*4P!E MW_75]YB]@V\O!?6V_7//XE?XBKV2'^.K]4X]5?_D$R`\_G'OXYV.Y3FKJ_YMQ>$I7!M@`YDD/CZA\[F7`2I<#R/J& M&`2/`\CZT/[Z=NT#\4M<>E%ZSA\)W&G00B5['/[.1QJIX]J^\TGM'_%E3OD_F`6%?5S M!MU'"HWYINLZHE+0U5!!)!;)E^Z^O:^W7P8RBYZ6^#6M_5E@ID^QK<%F1'_S%BH0&ZY(KM/[]MT70J*6EB. M>@JW7+B]ZYD,T%W."-KRMHQ3@LO4/S:EL%#S`+T&G*49T`90\&<3&^',@$I&P`K0DI`,,LK0WVSV-'L`%723 M$IKVIUO#R&DMH:7@I`-%,<(,PW+/,&-YP6%-CJ/6YS'#N%JGQNXVP0E9RZ6T MM?AR6\?AN;4?[^#UO^CW;^TAO_V;=2$V7+>_]N^&B]I<-CR\:-M$ M"/:CK6:/VNKO?8UE"]C[]>C?^:N_E_:M/6#[UUM7H.UIH]>M"PNP8#LJR\P] M`\=++-2,2$"/H#$G2R"C+.H\G(7+LA,P)G/,3B`#D#/PC$=PSC@D.\LZ@Q:T M,[A%\U_.R#,:23U#U+SQU,$BP\\T,B;)/X,3N0C)4=!S)RT'Y;\YVJ58;-1! M^B\:R22A4<#UTP-,Z#\.$'"9HX48^_\;Q/_4$0E+_N,`'9OY7Y^D#!`:Z=B8 MHRHQ^C\"(`"0.G(\81"$1HA#`L#Z'W'('&6*20`^`*DCSI/_'PW`_$?_:__A M`#:`YBA;C`7P`T@=J6']_VHN$4`/8,W%''6/&0&N`'$`XR@'(`Y@Z)("W/_- M`&TA00"#S`APZ!(:V47)`&\`',`!8&@$"&B.JLB,`(F`.`!@E`P0[%(#5`"" M7@&K`)"0]J`T!!SU!!`#A@:R0/B M`(XF_[]M2!MP&V*.(@+P`7$`A$!$8!6P'-(&-$85HPZ!QB@<`-#D__<.:0.^ M0\Q1>*H1X"40!U"+(O\YVX*`Z+]/H`A`"+#^$P**`IUM\+_C!"BP_:<*'`7F M_TR!][_C1"HP`"@&#`4:`(4`"$!3H`$P!]``/!"(`#8FJ\#]'S!P%%@!-`5. M`#`,*`>*`#L$W8$4P%7@'I`CF`84`>T"'8!YP;Y`*%`12 M!`F!+S,^8`Z`$+@2+`%0`=0E'`K00!)@4,;&N=,Y`',`C$"*H#$*)Z@27$;! M`$H`T;I-#;]#M/$[D!2\A;"`0X"W4"ZJ%(C^2PK:0I*"\+\A@/SO'R@5M(4P M"_B`54%)@?_/`3@$H`4F!/=_74&K8"ZP*6@`[`I&!2&`5,$)(-,$*S@!S)=% M!96!5$$08!'@&=@4!`%."J*"U,"O(`%P"+`"+`)D`YN"*T"^8%30&Z@7/$99 M!<>!34$>X-$@*J@.I`H2`8L`[L"F(!$0U!`5G`<6!H<`3\`B0#ZP*?@$Q`Q& M!?V!ET$M8!%@(-@4U`+""J*"",$.(%BP(E4$:`@*`8<`%2G88%1P(G@9?`,6 M`3""K\$WX!`@/T+^&P)T!"^#><`B0$CP-9@']`U&!4V"ET%"8!'`$&@!'`(0 M`IV#4<&P$D@5O`06`3*!K\%+X!"@$^@`)`(< M!?^!YD%?%%.P_9<>]!4X3,A_MX)@(`$P/CB+>@6B_^B#MP+X'Q'`*Z@:G`\: M`(T`8T'VH`%P/Z@?1`L6!E,FOJABX'UP`I@RT0_"!0^$($`C`%V0/0@")`*8 M`,N#><'^H*]@!6@$^`NR!U>`1(`8H"_P5R`?]!7P`(T`B$'V(`_P5Z`?;`P> M"(F`OR@^(#/J&:4$'!%:!C6$T"AAE(SP"0B-T@^"!G&$6D`C`&F0/:@%)`+8 M?>"#J4$A(!&@(F4$<`W>!RM22T+](&T01_@&-`+@!N^#;T`B`&^P//@;Q!'F M`8T`P\'[8!Z0-J`?1`[B"`F!1@#FH)*0$$@$\)#`!Z6#.$)CE!'`.F@!)`(L MH[2#(T+NX('P$DB+DA%>`HD`3A/X7Q#@/%@8'!3B`->#^S]#87)$4#@5+!3> M_X(`]L'V'Z2P_R M"K6`U<)-H1?P2$@M3!+F"LN`3D))81H0'44MG!)>"M^`08`KH:20#K@E]`4& M`;J$E\(\X+MP4^@'!`12"\V$ET)"8!!`39@K3`2Z":F%<,)+H2.03B@PI([@ M"7.%>D)0X27P'[0IW`22!WV!I,`28<1P%(@H)`!.#%&!14$A0*-00Z@QM(5H M#/F`'<-?X%808F@I1/_A`CV&`<+]W\GP%]@+-!E^"H6`(A./X:A097@,S``Z M`)V!$L-F(*O08A@-O!!"#&.%)L-K8*W08K@-Q!6V_\2!$L-PH*_08E@./`>: M#(>%,$-VX+%090@/5!8>#9F%)L-[(+109;@/G!9"#*V%)L.`X)!095@0Y!9" M#+V%1\.%8+A090@1)!="#,V%)D.+H+I09:@1;!>:#.&%=T./89CP:#@2M!?Z M`HL`A$(-(>#0*E@Q7`H^!=^##D!F08E0<9B+BA3N_QB'4D'X7Q&@9-C^FQR* M!?F`ED-)0H"X*?!BB_W99)4($XBRJ<*A`-`_" M_R8&"<3[W\2`#PA!]!6,#`^(E,/]'X#0%Y4R)`!N$'T%FT,-8N>P_>B+6AU*")]1KD,2(NQ0@\@AG!UV")]1MD,/(NY0"(@B]$4M M#6=1*T+?H081>$A"A!$.#V=11$!FU`,1>:A!?`(:`9:'LR@>H?.0A`@]U"`& M":>'LZ@BH?60A(@]]"`R";>'LR@HH?>0A`@^U"!6"<>'LZ@LH?E0@X@^9"/Z MHM:''L0QH?N0A`@_I"/ZHN:'&D0VH?WP@(@_)"'*"?>'?L1GE/]0@PA`/"#R M"0>(),0_82U*&C'0XY+\%J88PXQ5@>ZO^S?-L/Y9$B^)F,1,HB9QD\A)["1Z M$C^)H,10HD;@1@49>7=)1FYAPJJE"&;DW;4;081]1J@CRA$PC&D$-:(+68TT MNEPC6)&&1TQH-E(;<8ALN5XD?)'<"-5K-\(Y^8TT2%A47J[B"%&00H(<"9*\ M0G( Received: from uga.cc.uga.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20398; Thu, 7 Nov 91 05:40:56 MST Message-Id: <9111071240.AA20398@math.utah.edu> Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2256; Thu, 07 Nov 91 07:40:08 EST Received: by UGA (Mailer R2.07) id 9635; Thu, 07 Nov 91 07:39:58 EST Date: Wed, 6 Nov 91 17:03:11 +0000 Reply-To: LaTeX-L Mailing list Sender: LaTeX-L Mailing list From: Dominik Wujastyk Subject: Re: Hyphenation patterns (not additional patterns) To: "Nelson H.F. Beebe" I don't really want to join in the discussion about \language, etc., but may I register a couple of points that arise out of my own usage? 1/ I use a full 8-bit charset all the time. My use of 33-127, 157 and 224-255 is particularly heavy. 2/ I have defined chars > 127 to be active, and \def'ed them to output characters that match my (home made) screen fonts. 3/ I have typeset a full book using this setup, as well as many papers and lectures. 4/ I got away with the book, largely because it was mostly English and there wasn't too much difficulty with hyphenation. I still had to do quite a lot of hyphenation by hand. 5/ I consider my arrangements inadequate for serious work in future. First, because I can't define proper multilingual hyphenation. I need a font that matches my character set. (The Cork character set is almost useless for me, unfortunately. I do Indian languages.) Secondly, because I *do* need to be able to use extended chars in macro names. A current situation is that I have a book with *thousands* of footnote references to other texts. These other texts' names are abbreviated to three or four characters, normally including some extended chars. I want to make these abbreviations into macros that will print themselves *and* write an entry to an index file. I can't do that, at present. Dominik 7-Nov-1991 20:20:46-GMT,2353;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23010; Thu, 7 Nov 91 13:20:34 MST Date: Thu 7 Nov 91 10:02:19-EST From: bbeeton Subject: [Dominik Wujastyk : Re: Hyphenation patterns (not add] To: tex-implementors@MATH.AMS.COM Message-Id: <689526139.0.BNB@MATH.AMS.COM> Mail-System-Version: as the discussion on multiple languages has shifted from latex-l to tex-implementors, i am forwarding this message. (dominik is not on the tex-implementors list, nor is he interested in joining it. any questions for dominik should therefore be sent directly to him.) -- bb --------------- Date: Wed, 6 Nov 91 17:03:11 +0000 Sender: LaTeX-L Mailing list From: Dominik Wujastyk Subject: Re: Hyphenation patterns (not additional patterns) I don't really want to join in the discussion about \language, etc., but may I register a couple of points that arise out of my own usage? 1/ I use a full 8-bit charset all the time. My use of 33-127, 157 and 224-255 is particularly heavy. 2/ I have defined chars > 127 to be active, and \def'ed them to output characters that match my (home made) screen fonts. 3/ I have typeset a full book using this setup, as well as many papers and lectures. 4/ I got away with the book, largely because it was mostly English and there wasn't too much difficulty with hyphenation. I still had to do quite a lot of hyphenation by hand. 5/ I consider my arrangements inadequate for serious work in future. First, because I can't define proper multilingual hyphenation. I need a font that matches my character set. (The Cork character set is almost useless for me, unfortunately. I do Indian languages.) Secondly, because I *do* need to be able to use extended chars in macro names. A current situation is that I have a book with *thousands* of footnote references to other texts. These other texts' names are abbreviated to three or four characters, normally including some extended chars. I want to make these abbreviations into macros that will print themselves *and* write an entry to an index file. I can't do that, at present. Dominik ------- 5-Nov-1991 15:33:29-GMT,20050;000000000000 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03598; Tue, 5 Nov 91 08:33:22 MST Date: Tue 5 Nov 91 09:46:55-EST From: bbeeton Subject: Messages from DEK, part 3 To: TeX-implementors@VAX01.AMS.COM Message-Id: <689352415.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 5 November 91 Message No: 034 To: TeX implementors and distributors From: Barbara Beeton Subject: Messages from DEK, part 3 The third installment of DEK's September comments. ######################################################################## TeX -- size of \smash'ed boxes Date: 24 Jun 91 18:56:42 From: jeffrey%se.chalmers.cs@se.sunet.sunic Authorised-User: Alan Jeffrey To: cet1@uk.ac.cam.phx Subject: Odd TeX behaviour Dear Chris, Here's something I asked texhax a few days ago---barbara wrote back, and suggested I ask you about it. Since you were so helpful in finding that MF bug last year I thought you'd be a good person to ask. The problem is what happens if you put a smashed box in a script for a displaystyle mathop, for example: $$ \sum^{\smash{\vrule height 1in depth 1in}} $$ produces the same as if the \smash weren't there. In general, if you take a box, change its size, and put it in a displaystyle mathop script, the size-changing info is lost. So: \setbox0\hbox{...} \ht0=... \dp0=... $$ \sum^{\box0} $$ is the same as \setbox0\hbox{...} $$ \sum^{\box0} $$ This isn't a bug, since in Appendix G, para. 13a, DEK says Set box $x$ to the superscript field... set box $y$ to the nucleus field... set box $z$ to the subscript field... Rebox all three of these boxes to width $\max(w(x),w(y),w(z))$. As far as I can tell, in doing this reboxing, the outermost level of box information is thrown away, and in particular the \ht and \dp information goes with it. So it's not a bug, but it's certainly not what you'd expect! Alan. Alan Jeffrey Tel: +46 31 72 10 98 jeffrey@cs.chalmers.se Department of Computer Sciences, Chalmers University, Gothenburg, Sweden ------- Date: Thu, 27 Jun 91 16:14:31 BST From: Chris Thompson To: Alan Jeffrey Subject: Re: [Odd TeX behaviour] Dear Alan, Thank you for your description of the odd effects with \smash in the limits of a \mathop. I *think* that Don Knuth has covered himself against the possibility of these effects being bugs, but the situation is in fact even odder than your examples illustrate. As you point out, in $$ \sum^{\smash{\vrule height 1in depth 1in}} $$ the superscript gets unsmashed by the reboxing described in step 13a of Appendix A: in terms of code, the call of |rebox| (section 715) >From |make_op| (section 750). One can prevent the recalculation of the height and depth by $$ \sum^{\hbox{$\smash{\vrule height 1in depth 1in}$}} $$ or the like. However, in $$ \sum^{\smash{\vrule width 20pt height 1in depth 1in}} $$ the smashing remains in effect! This is because |rebox| does not unpack and repack the box contents if the width is already what is required. I suppose that this is implied by the description of the `subroutine that ``reboxes'' a given box to a given width' on page 442 of the TeXbook, but it certain isn't explicitly stated. |rebox| also doesn't rebox if the box contents are the empty list; it simply changes the width to that required. This means that any explictly set \ht and \dp will survive in this case. (This would happen in the case of a \(h|v)phantom, I think.) I can't find any mention at all of this in Appendix G. Altogether, The situation seems extremely messy, even if it is according to spec. I think (Barbara?) that it should be brought to Don's attention, at least. A cleaner spec would be that |rebox| always preserves the height and depth, but I suppose that might be an incompatible change. Chris Thompson ------- Date: Fri, 28 Jun 91 09:44:11 +0200 From: Alan Jeffrey Subject: Note about reboxing. {\obeylines {\bf Reboxing math operator scripts in display style} Alan Jeffrey and Chris Thompson 27 June 1991} \hsize 31pc {\obeyspaces\global\let =\ } \catcode`\[=\active \catcode`\]=\active \def[{\bgroup\par\medskip\tt\obeylines\catcode`\$11\catcode`\\11 \catcode`\{11\catcode`\}11\catcode`\^11\obeylines\obeyspaces} \def]{\egroup\par\medskip\noindent\ignorespaces} \def\com#1{{\tt\string#1}} \medskip\noindent It turns out that \TeX's algorithm for setting subscripts and superscripts of limited operators has a rather odd feature. If you say: [ $$ \sum^{\vrule height 2ex depth 2ex} \sum^{\smash{\vrule height 2ex depth 2ex}} \sum^{\hbox{\smash{\vrule height 2ex depth 2ex}}} $$ ] then you get: $$ \sum^{\vrule height 2ex depth 2ex} \sum^{\smash{\vrule height 2ex depth 2ex}} \sum^{\hbox{\smash{\vrule height 2ex depth 2ex}}} $$ That is, the \com\smash\ has no effect unless it is contained inside another \com\hbox. In Appendix~G, para 13a of {\it The \TeX book}, the specification for reboxing a limited script is given as: {\medskip\narrower\noindent Set box $x$ to the superscript field in style $C{\uparrow}$; set box $y$ to the nucleus field in style $C$; and set box $z$ to the subscript field in style $C{\downarrow}$. Rebox all three of these boxes to width $\max(w(x), w(y), w(z))$.\par} \medskip\noindent It appears that this reboxing (performed by {\bf rebox} \S715) loses the outermost level of box information. This is confirmed by: [ $$ \sum^{\vrule width 20pt height 2ex depth 2ex} \sum^{\smash{\vrule width 20pt height 2ex depth 2ex}} \sum^{\hbox{\smash{\vrule width 20pt height 2ex depth 2ex}}} $$ ] which produces: $$ \sum^{\vrule width 20pt height 2ex depth 2ex} \sum^{\smash{\vrule width 20pt height 2ex depth 2ex}} \sum^{\hbox{\smash{\vrule width 20pt height 2ex depth 2ex}}} $$ So when the script does not require reboxing, its height and depth are not lost. The situation seems rather messy, albeit according to spec. A cleaner 8specification would be that {\bf rebox} should preserve height and depth, but this may be an incompatible change. [ dek: _Correct_ _analysis_ ] \medskip \line{\hfil\it Alan Jeffrey} \line{\hfil\it Chris Thompson} \bye ------- [ Here's another view of the same problem. ] Date: Tue, 6 Aug 91 18:55:35 EDT From: barr@triples.math.mcgill.ca To: info-tex@SHSU.edu Subject: problem with Tex Can anyone explain the discontinuity in the following, or how to make the dots go into an intermediate position? Michael Barr \def\rdiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .75em{\hss$\textstyle.$}}% _{\hbox to .75em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} \def\ldiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .75em{$\textstyle.\hss$}}% _{\hbox to .75em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} $A\ldiv B\rdiv C$ \def\rdiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .76em{\hss$\textstyle.$}}% _{\hbox to .76em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} \def\ldiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .76em{$\textstyle.\hss$}}% _{\hbox to .76em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} $A\ldiv B\rdiv C$ \def\rdiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .77em{\hss$\textstyle.$}}% _{\hbox to .77em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} \def\ldiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .77em{$\textstyle.\hss$}}% _{\hbox to .77em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} $A\ldiv B\rdiv C$ \def\rdiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .78em{\hss$\textstyle.$}}% _{\hbox to .78em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} \def\ldiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .78em{$\textstyle.\hss$}}% _{\hbox to .78em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} $A\ldiv B\rdiv C$ \def\rdiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .79em{\hss$\textstyle.$}}% _{\hbox to .79em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} \def\ldiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .79em{$\textstyle.\hss$}}% _{\hbox to .79em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} $A\ldiv B\rdiv C$ \def\rdiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .80em{\hss$\textstyle.$}}% _{\hbox to .80em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} \def\ldiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hbox to .80em{$\textstyle.\hss$}}% _{\hbox to .80em{\hss\smash{\raise1.20ex\hbox{$\textstyle.$}}}}}} $A\ldiv B\rdiv C$ \bye ------- Date: Tue, 6 Aug 91 21:54 PDT From: Donald Arseneau To: info-tex@SHSU.edu Subject: Re: problem with positioning of mathop limits Michael Barr (barr%triples.math.mcgill.ca) had a problem with jumps in the placement of the limits on an operator. > Can anyone explain the discontinuity in the following, or how to make > the dots go into an intermediate position? > > \def\rdiv{\mathrel{\mathop > {\hbox{\vrule height.55ex width0pt depth-.54ex > \smash{\hbox{\mathsurround=0pt$-$}}}}% > \limits^{\kern0pt\hbox to .77em{\hss$\textstyle.$}}% > _{\kern0pt\hbox to .77em{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hss}}}} > I've seen that problem before (with someone else's problem) and I stick by my explanation: an error in TeX. What I think is happening is a misapplication of the unboxing explained on the first page of Appendix G: "In case (c), the glue is set with no stretching or shrinking, and additional level of hboxing is omitted if it turns out to be redundant." But when that hbox has had its size (\ht, \wd, \dp) changed, or it is not set to its natural width (to, spread) it is *NOT* redundant but gets omitted anyway! The immediate solution to Michael Barr's problem is to put something outside the measured box so it cannot be omitted. Change all \hbox to to \kern0pt \hbox to and it will work. The discontinuity with the size of the measured hbox was very interesting. In all cases the boxes for the limits were set to the width of "-", 7.777pt. But TeX obviously did some measurement before discarding the important level of boxing. For \hbox to Xpt, X < 7.7777, the limits were unboxed and surrounded by \hss...\hss, giving in effect "\hss \hss . \hss", which placed the dot 1/3 of the way across the minus sign. When X > 7.7777, TeX thought the nucleus "-" was norrower than the limits and did not pad the limits with \hss, leaving them as "\hss .". After unboxing and reboxing, the limits could stretch only on one side leaving the dot at one edge of the minus sign. Donald Arseneau asnd@triumfcl (.bitnet) asnd@reg.triumf.ca ------- Date: Wed, 7 Aug 91 11:11:56 EDT From: barr@triples.math.mcgill.ca (Michael Barr) To: bnb@math.ams.com Subject: more problems with boxes If you don't subscribe to texinfo, you may have missed my query and Donald Arsenault's reply. Briefly, I was having trouble with the series: ... \def\rdiv{...} [ series as in message to info-tex ] shose output changes discontinuously as the parameter changes from .77 to .78 (not coincidentally, the width of $-$ is .77777...em). This is clearly more troubles with 13a on page 444, but I still couldn't see why I wasn't getting growth before that. (In fact, the parameter could have been 0 with no effect on the output, which I wasn't quite aware of, although I knew that down to .3em it made no difference.) It turns out that what is likely happening is explained by line -4 on page 441, which Donald says he had run into before. Apparently, TeX' rules for deciding what ``turns out to be redundant'' are not the same as you and I might decide on. He suggested that what was happening is that TeX was unboxing the \hbox and then implementing 13a (which he wasn't aware of, or at least didn't mention) by reboxing it with an \hss on either side so that the effect of my code was as if it said \hss\hss.\hss on one side and vice versa on the other, which resulted in the dots exactly 1/3 of the way (or 2/3). At this point, I have come up with \def\rdiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\hskip0pt plus3fil\textstyle.}% _{\smash{\raise1.20ex\hbox{$\textstyle.$}}\hskip0pt plus3fil}}} \def\ldiv{\mathrel{\mathop {\hbox{\vrule height.55ex width0pt depth-.54ex \smash{\hbox{\mathsurround=0pt$-$}}}}% \limits^{\textstyle.\hskip0pt plus3fil}% _{\hskip0pt plus3fil\smash{\raise1.20ex\hbox{$\textstyle.$}}}}} which is simpler and allows fine control over the spacing. If you have not yet asked DEK about the 13a problem, you might include these observations. In any case, a little more explanation is clearly wanting here. By the way, DA suggested (correctly) that a \kern0pt would prevent the unboxing. Allow me to second strongly Nelson Beebe's plea in the last three paragraphs of his editorial in the most recent tugboat. I have now spent most of a day getting through the texarcana in building one simple little sign. The number of permutations of \smash and \raise I had to try to get the vertical placement right (and only by eye, with no guarantee it will be right at another point size), the amount of time wasted on getting the horizontal placement right, they both seemed infinite. It simply shouldn't be so hard to do something so simple. The fact that adding a kern of 0pt changes everything is incomprehensible. The facts that \smash requires, while \raise forbids a brace following it are incomprehensible. The entire chapter on dirty tricks is an indictment of the program. Almost everything in that chapter is entirely reasonable and should have straightforward ways of doing them, not be the subject of dirty tricks. The lack of a simple reliable loop is unforgivable. A while ago, someone posed a question on texhax about leaving a 2"x2" box in the lower right corner of each page. So far as I know, this question got no answer, perhaps has NO reasonable answer in tex as currently constituted. Certainly, I could think of none. Nor could I think of any way of having one page narrower than another. This sort of thing is not good if we expect TeX to grow. Michael Barr ------- Date: Wed, 07 Aug 91 15:32:12 BST From: Chris Thompson To: Barbara Beeton Cc: Donald Arseneau , Michael Barr Subject: Re: [[barr@triples.math.mcgill.ca: problem with Tex]] This one is similar to the height&depth-losing problem you sent me before, but I think this one *is* unambiguously covered by Appendix G, unexpected though the effects may be. The relevant section is 13a, where the reboxing of \mathop's with limits is being described. (Code is in TeX module 750.) Reboxing is decsribed in the middle of p.442 ("There's also a subroutine..."). The nucleus is this case is 7.7778pt wide; in the first few cases the super- and sub-scripts are narrower, have \hss glue added on each side, and are reboxed (losing the old specification). In the last few cases, the nucleus is narrower and is reboxed, the super- and sub- scripts being left alone. Because there is already \hss glue in the boxes, adding more of the same fundamentally alters their appearence. (Page 442 does warn about this when it says "it centers ... unless infinite glue is present in addition to the newly added \hss".) Donald Arseneau is, I suppose, right to quote (c) from p.441: the problem is the (false?) optimizations that TeX performs in math-to-hosizontal conversion when it removes the "outermost" level of boxing on math node components. His suggested \kern0pt will indeed prevent this, of course. Donald is wrong, however, in saying > In all cases the boxes for the limits were set to the width of "-", 7.777pt. They are, in fact, so set only in the cases when the explicit widths of the super- and sub-script boxes are smaller than this; in the last three cases the boxes all end up as 7.8, 7.9 and 8.0pt wide (+/- rounding errors from the conversions from "em" to "pt"). Easily verified by using \showlists. Chris Thompson ------- (reply, 7 Aug 91, to all) chris, thanks for your analysis. the effects here are so unexpected that i think the problem is worth a good strong warning in tugboat. could you help me to prepare such a warning, with a very simple example showing what happens under the relevant circumstances, and what can be done to avoid it? if i come up with the example, can you prepare the prose, citing chapter and verse? -- bb ------- Date: Thu, 08 Aug 1991 02:25:27 PDT From: Donald Arseneau To: uk%\"CET1@PHOENIX.CAMBRIDGE.AC.UK\"@erich.triumf.ca Subject: Re: [[barr@triples.math.mcgill.ca: problem with Tex]] Arrrggghh! I could have sworn I saw those little boxes staying at 7.77777pt. I guess the description of reboxing on p442 is more complete, and it doesn't require the box to be "redundant", just a hbox. This behaviour of TeX certainly violates the principle that round-off errors shouldn't produce gross differences in the output. Donald ------- [ As suggested above, I intend to follow up with Chris to get a statement of the problem for publication as a warning in TUGboat. ] [ dek: ^^^^^^^^^^^^^^^ right. If these things had been brought up years ago, TeX might have changed [e.g. rebox preserving height/depth, \smash always adding another level of boxing <-- but that might overflow memory] The unboxing etc. turns out to be extremely important for posting of superscripts on accented variables ... Anyway, no changes now, on grounds of compatibility etc. ] ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 034 ] ------- 5-Nov-1991 15:33:35-GMT,16543;000000000000 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB03598; Tue, 5 Nov 91 08:33:29 MST Date: Tue 5 Nov 91 09:49:09-EST From: bbeeton Subject: Messages from DEK, part 4 (last) To: TeX-implementors@VAX01.AMS.COM Message-Id: <689352549.0.BNB@MATH.AMS.COM> Mail-System-Version: Date: 5 November 91 Message No: 035 To: TeX implementors and distributors From: Barbara Beeton Subject: Messages from DEK, part 4 Fourth and last installment of DEK's September comments. Also included in DEK's package were some general comments to Peter Breitenlohner, who is, with DEK's encouragement, updating PATGEN to accommodate the new features of TeX 3. This is still a work in progress; however, anyone else who has examined PATGEN with this extension in mind might want to get in touch with Peter directly. (Sorry, Peter, for not warning you ahead of time.) ######################################################################## TeX -- incompatibilities between \input and \openin This report is my own. When updating our user documentation for AMS-TeX, AMS-LaTeX, et al., I try to keep the files that will be distributed together in one directory, and run (La)TeX from another, to segregate the files that are created by the run from the originals. There is no problem with files based on Plain, but LaTeX first checks for the existence of some files with \openin and, if they are there, then applies \input . The problem is that (at least in the VMS and some PC implementations) \openin checks only the connected directory, not the path specified by TeXinputs: . Discussions with other users and implementors have uncovered the fact that some implementors have added the logical path to the \openin procedure, while others have not. (The DEC-20 implementation did check TeXinputs: for both \input and \openin, so I had rashly assumed that was what was supposed to happen.) I understand that the WEB code for the two procedures is different, but I believe it's not clear whether or why \openin should *not* check the same input path as \input , and that means the implementors are free to make their own interpretation. A clear statement of what the behavior should be would be very helpful. [ dek: I had some correspondence about this a few months ago, but I forgot what I said. The difference in code between \input and \openin is actually to allow reading files from a system area under \read without requiring a full path name, but not under \openin. However, lots of operating systems make it nicer to define environmental variables for sequences of places to try, and such implementations naturally make use of the more general paths on \openin as well as \read. Clearly LaTeX is important enough that the implementors should make LaTeX as easy to use as possible. I need the feature also with my use of Plain TeX: I have put ".." on my standard input path list, so that I can go to a subdirectory to make a DVI file and partial cross reference files that won't disturb anything on the parent directory. I recommend therefore that implementors use environmental variables for directory path lists (or a default one if the programmer hasn't set it up) whenever the operating system allows it. My favored conventions on implementation questions in general are expressed by the change files I have contributed to the distribution [under `local' directory] ... these are for Pascal, _not_ C, versions of TeX and MF but I do use them heavily. Incidentally I dislike several aspects of WEB-to-C versions on Stanford computers, especially the treatment of command lines -- they don't check .fmt files for garbage but I guess that hasn't been a problem. ] ************************************************************************ WEB system -- dealing with repeating code in .WEB files Date: Tue 26 Mar 91 20:09:38-EST From: bbeeton To: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk Subject: possible bugs, requesting verification [ this was in response to my saying that any large .web file is likely to have repeating blocks of code, and thus a line number is advisable when listing differences. where he says "web" he clearly means "tangle". ] Date: Sat, 23 Mar 1991 20:22 PST From: Don Hosek Subject: Re: Updates to TeX.WEB, MF.WEB, GFtoDVI, et al. Incidentally, the repeating code problem is particularly nasty when writing change files. WEB only checks to see if the first line matches rather than the whole of the text in the @x..@y block which caused me a great deal of grief when I wrote the CMS change file for MFT; there are a lot of repeating first lines of a block of text. -dh ------- Date: Wed, 27 Mar 91 18:33:18 GMT From: Chris Thompson Subject: Re: [possible bugs, requesting verification] ... As regards Don Hosek's complaint about Web (and it applies to both TANGLE and WEAVE, of course, which is presumably why he confusingly says "Web"): I agree, it's a right pain. I understand why it got like that, though: it means that the programs never have to buffer more than one line from each input file at a time. I am still paranoid about storage consumption as well, in an age where there is little sympathy for this! The worst cases are when one *removes* a change (maybe one had an ahead- of-base-source bug fix, for example) and suddenly later changes start failing to match (or even worse, succeed in matching) the wrong part of the file. One has to increase the context, often into the TeX parts of the modules, to ensure uniqueness. I would certainly suggest that you send Don Hosek's remarks to Don Knuth, but I fear he probably won't want to change anything in this area now. Chris Thompson ------- Date: Thu, 28 Mar 91 17:03:50 GMT From: Chris Thompson Subject: Re: [possible bugs, requesting verification] ... It is all documented: WEBMAN.DVI page 10, section 11 says: "Whenever the first ``old line'' of a change is found to match a line in the web_file, all other lines in that change must match too." There is no bug; it is just a rather painful spec to live with, as Don Hosek says. It is a bit painful, as well, that it just reflects the @y, and doesn't tell you *which* lines mismatched! Chris ------- [ dek: WEB was never intended to be the "last word"; I expect second generation systems to do all kinds of things with much greater generality. I stopped when I had something good enough to get on with what needed to be done. There is something painful about every system, but really I have lots more problems with all the other software I have to live with! ] ######################################################################## Date: Tue, 30 APR 91 21:31:17 BST Reply-to: Brian {Hamilton Kelly} From: TEX@rmcs.cranfield.ac.uk To: BNB <@nsfnet-relay.ac.uk:BNB@MATH.AMS.com> Subject: Possible bug in TeX V3.1 ??? Dear barbara, I'm loth to say this, because I know how rarely anything is genuinely a bug, but I'm a bit suspicious about TeX's unpacking and repacking of ligatures before and after hyphenation. I have a font that, like DEK's example in the New TeX and MF announcement, has a variant of "s" for the ends of words (it's actually an updating of my Greek fonts). So the ligature program reads as follows: % % Ligatures for sigma at end of "word" % boundarychar := 255; ligtable "s": 255 =:| "c", "." =:| "c", "," =:| "c", ":" =:| "c", ";" =:| "c", "!" =:| "c", "?" =:| "c", ")" =:| "c", "/" =:| "c", "]" =:| "c", "*" =:| "c"; % % Note that s is not ligatured with apostrophe, so that one can write things % like s''ena sp'iti ('' in this font produces an apostrophe, since ' % on its own is an acute accent.) % Now this works beautifully, most of the time. However, if TeX decides that it should attempt hyphenation, and if the word being hyphenated ends in punctuation, such as ".", then \S898 of TeX.web gives up on taking apart the ligatures when it meets the period, since it's a non-letter (has lc_code=0) --- so the word "xomol'ogysys." (where 'o is a ligature defined in the font, and for which "'" has a non-zero lccode) gets passed to the hyphenation procedure as the 12 characters "x o m o l ' o g y s y s" in hc[1:hn]. After hyphenation has been considered, the period is no longer hanging around for reconstitute to put back together. (Incidentally, when I read the code, I'd convinced myself that the final "s" wasn't going to be present in hc[hn] for hyphenate to consider, but the VAX-Pascal debugger shows that it _is_ there!) I've managed to effect a workaround, by setting the \lccodes for all the punctuation that enters into the ligature program for sigma; but then the hyphenation algorithm is given the _13_ characters "x o m o l ' o g y s y s .", which I'm sure it's unlikely to be completely happy with (although it does seem to find the same breaks); surely, it will no longer recognize any explicit end-of-word marks in the \patterns? [ dek: that is true but perhaps there areen't so many patterns in Greek. (Of course I am not happy with this workaround either) ] Perhaps, instead of setting \lccode`\.=`\., I should perhaps set it as \lccode`\.=256, so that it's non-zero, but doesn't pass the character {\it per se\/} into the hyphenation algorithm. Perhaps you could ask Don what he advises, or whether perhaps \S898 should _complete_ its dismantling of the ligature, and only afterwards exclude the non-letter characters, noting the whole sequence for reconstitute's benefit. Brian ------- Date: Thu, 02 May 91 00:49:54 BST From: Chris Thompson To: bbeeton Cc: Brian {Hamilton Kelly} Subject: Re: [[TEX@rmcs.cranfield.ac.uk: Possible bug in TeX V3.1 ???]] Barbara, There does indeed appear to be something murky going on. I am not at all familiar with the code for reconstituting new-style ligatures, so a full report will take a little while... Setting the \lccode's for punctuation to pretend that they are letters is a terrible way to have to work round the problem, and B{HK} is of course right that > it will no > longer recognize any explicit end-of-word marks in the \patterns On the other hand > I should perhaps set it as > \lccode`\.=256 certainly won't work: \lccode values are restricted to 0..255. I am not sure what he is trying to say here. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk ------- Date: Thu, 2 MAY 91 22:11:57 BST Reply-to: Brian {Hamilton Kelly} From: TEX@rmcs.cranfield.ac.uk To: BNB <@nsfnet-relay.ac.uk:BNB@MATH.AMS.com> Subject: Re: [[TEX@rmcs.cranfield.ac.uk: Possible bug in TeX V3.1 ???]] Chris, In message of Thu, 02 May 91 00:49:54 BST, Chris Thompson wrote: > There does indeed appear to be something murky going on. I am not at all > familiar with the code for reconstituting new-style ligatures, so a full > report will take a little while... Thanks! I thought I was going nuts at first! > Setting the \lccode's for punctuation to pretend that they are letters > is a terrible way to have to work round the problem, and B{HK} is of > course right that > > it will no > > longer recognize any explicit end-of-word marks in the \patterns > > On the other hand > > I should perhaps set it as > > \lccode`\.=256 > certainly won't work: \lccode values are restricted to 0..255. I am not > sure what he is trying to say here. Sorry, I hadn't tried this; in fact, only thought of it when composing the message. By analogy with \hyphenchar, I was hoping that I could set an \lccode to a non-character value, and thus ensure (perhaps?) that the hyphenation algorithm wouldn't consider the punctuation characters, since they'd be excluded in |hc|; but I see now that |lc_code| is a |equiv| and thus in a |quarter_word|, so cannot be set outside range 0..255 (as TeX tells me when I try!) One thought: Perhaps when unravelling ligature nodes in the pre-hyphenation phase, TeX should take cognizance of whether the ligature program was one that used =:| or |=:| (I'm not sure of |=:) and still stop at the [ dek: ^^ is this a smily face? ] punctuation character, corresponding to the "retained" character, but remember that it "belonged" and thus still be able to reconstitute it correctly afterwards. Best regards, Brian ------- Date: Fri, 03 May 91 17:17:13 BST From: Chris Thompson To: Barbara Beeton Cc: Brian {Hamilton Kelly} Subject: Re: [[TEX@rmcs.cranfield.ac.uk: Possible bug in TeX V3.1 ???]] Barbara, & Brian, I have been looking at the pre- and post- hyphenation code, and I have come to the conclusion that Brian's problem is probably a bug, rather than a feature. The horizontal list for either "...ogysys " or "...ogysys. " contains a ligature node with |lig_char| = "c" and component character list containing just "s"; the "." is a separate character node in the second case. The difference is that in the first case the ligature node's |sub_type| is 1 ("formed from a right boundary character") while in the second it is 0. If automatic hyphenation is invoked, section 898 reconstructs the original character list up to "s", and this is what is intended. The difference in the cases is that section 903 sets |bchar:=255| in the first case (|hb| is the ligature node described above) but not in the second case. This allows |reconstitute| to rebuild the ligature node, but only in the first case. The reason I think this is probably a bug is the asymmetry of treatment of the left-hand and right-hand edges of the word in section 903. There |ha| is examined in great detail in order to decide what to put into |hu[0]| and |init_lig|, in particular if the word is preceded by punctuation characters that alter the first letter of the word (e.g. by |=:> ligatures) then such effects will be recreated by by |reconstitute|. On the other hand, |bchar| is set only to |non_char| |font_bchar[hf]|; any following punctuation characters (at |q=link(hb)|) are never examined. Certainly I think this ought to be brought to Don's attention, if he has any to spare for TeX at the moment. I think it may actually be a matter of some urgency, in that otherwise people like Brian trying to use right-boundary effects in fonts may be forced into using inappropriate work-rounds; maybe even ones that would not survive a proper fix. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk ------- [ dek: Chris is absolutely right; I should have provided better right context to the reconstitution algorithm. [Why did I get into this?!] Draft changes are being put into version 3.14$\alpha$ In the new version the effect of \noboundary between a word and punctuation will be lost (for example ...ogysys\noboundary. _will_ now convert the s to a c ) but that minor problem is much worse than the present alternative. An explicit kern ...ogysys\noboundary\kern0pt. will preserve such noboundary status if necessary. The going rate for bugs in the 1989 code is $10.24, so Brian gets credit for this one! ] ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 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 035 ] ------- 5-Nov-1991 17:26:28-GMT,1154;000000000000 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PEB@DM0MPI11.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04164; Tue, 5 Nov 91 10:26:25 MST Message-Id: <9111051726.AA04164@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Tue, 5 Nov 91 12:03:30-EDT Received: from DM0MPI11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8963; Tue, 05 Nov 91 12:01:06 EST Received: from DM0MPI11 (PEB) by DM0MPI11 (Mailer R2.08) with BSMTP id 5246; Tue, 05 Nov 91 18:00:57 GMT Date: Tue, 05 Nov 91 17:56:54 GMT From: Peter Breitenlohner Organization: Max-Planck-Institut fuer Physik, Muenchen Subject: Re: last message from Bart Childs To: Tex-implementors@math.ams.com There is only one big problem with changing whole modules (apart from the fact that I personally prefer minimal changes): If you change a whole module, say module 11, then both module 10 and 11 are marked as changed by WEAVE. This is so because the change file entry starts before WEAVE detects the end of the previous module or rather the start of the current one. Peter 8-Nov-1991 22:40:20-GMT,3540;000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01577; Fri, 8 Nov 91 15:40:15 MST Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GCPKB1ROMO91VV49@HMCVAX.CLAREMONT.EDU>; Fri, 8 Nov 1991 14:38 PST Date: Fri, 8 Nov 1991 14:38 PST From: Don Hosek Subject: Re: TFM directories To: beebe@math.utah.edu, tex-implementors@math.ams.com Cc: driv-l@tamvm1.BITNET Message-Id: <01GCPKB1ROMO91VV49@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"beebe@math.utah.edu" X-Vms-Cc: TEX_IMPLEMENTORS,IN%"driv-l@tamvm1" -Date: Thu, 24 Oct 91 15:48:43 MDT -From: "Nelson H. F. Beebe" -Wayne G. Sullivan writes ->> ... ->> The reason in one case why TEXFONTS was not used for the TFM directory is ->> that widely distributed DVI drivers use TEXFONTS for FONTS. Though it ->> might have been an unwise original choice to use TEXFONTS to specify the ->> directory for TFMs, its use for another purpose in the DVI driver programs ->> is even more unfortunate. Has this been corrected? Is it safe now to use ->> TEXFONTS to specify the TFM directory (directories)? ->> ... -The reason is that at Stanford, Don Knuth chose to store the bitmaps -and metrics in the same directory, which is exactly how they end up -when you run METAFONT. With long file names, there was no problem in -having cmr10.tfm, cmr10.300gf, cmr10.329gf, ... all in the same place. -VAX VMS systems before version 4.0, PC DOS, and others with short file -name requirements led to implementors moving the magnification out of -the filename into the directory name, e.g. 300\cmr10.gf, 329\cmr10.gf, -..., and in {\em those} environments, it makes sense to put the .tfm -files in a separate directory too, since there is then no good reason -why they should live in the same file directory as a bitmap at a -ø =Ñÿparticular size. -I have seen TeX implementations (e.g. that of Personal TeX, Inc) that -use separate TEXFONTS and TEXTFMS search paths. -Few drivers ever use .tfm files, so they question hasn't come up for -them as often. -My 2.10 drivers did not read .tfm files, but those in the 3.0 -development do; they find them in the TEXFONTS search path. If there -is strong feeling in the implementors community that drivers that read -.tfm files should support a separate TEXTFMS path, I can easily do -that, since 3.0 sources have not yet been released to anyone, and only -about 3 or 4 lines of code need to be changed. I'd do it in such a -way that if lookup failed on TEXTFMS, I'd fall back to TEXFONTS anyway. -In my 3.0 drivers, .tfm files are only consulted when bitmap -representations cannot be found, so efficiency of file lookup is -definitely not an issue; it might be in a PostScript driver that -needed .afm files for use with printer-resident fonts. Raster and metric fonts should be searched for using independent search paths. The names of these paths should be configurable (ideally without recompilation of the driver). On most/all TeX distributions which I've come across, PKs and TFMs live in separate directories. The exact logical name that points to them can vary, however, depending on the implementation. e.g., VMS uses TEX_FONTS (sometimes TEX_FONT_METRICS and incorrectly, TEX$FONTS). on DOS I've seen TEXFONTS, TEXTFMS and TEXTFM. (btw, for VMS developers, the change files for TeX and MF provide one good way to configure these things for VMS. -dh 5-Nov-1991 17:08:10-GMT,2317;000000000001 Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04067; Tue, 5 Nov 91 10:08:04 MST Resent-Message-Id: <9111051708.AA04067@math.utah.edu> Return-Path: <@neuron.cs.tamu.edu:bart@cs.tamu.edu> Received: from neuron.cs.tamu.edu by MATH.AMS.COM via SMTP with TCP; Tue, 5 Nov 91 11:38:18-EDT Received: by neuron.cs.tamu.edu (AA11354); Tue, 5 Nov 91 10:33:47 CST Date: Tue, 5 Nov 91 10:33:47 CST From: bart@cs.tamu.edu (Bart Childs) Message-Id: <9111051633.AA11354@neuron.cs.tamu.edu> To: bnb@math.ams.com Subject: WEB commentary in message 35 Resent-Date: Tue 5 Nov 91 11:51:25-EST Resent-From: bbeeton Resent-To: tex-implementors@VAX01.AMS.COM The comments about tangle/web ... are right on but there is one missing point in the discussion. One of the basic concepts of Literate Programming is that documentation and code go together. It is a simple thought The entries in a change file should always be a whole module. Even if you are changing only one line out of a long module (like 11 in tex.web), you should include the whole module! If you are changing any code, you should also change the documentation. Incidentally, module 11 is the best module to violate this simple thought with because the documentation is normally a comment on the same line of code. Except for bibtex with its plethora of lines with only an at sign on them, I have had NO problems with any decent WEB (DEK's are really fine, locally written ones can have the problems) since I began putting the whole module in the change file. Further, it has encouraged us to always update the documentation which is a worthwhile event. (I also change bibtex by concatenation of `@ ' lines with the next immediately.) Surely the argument about the change files being wastefully large will not be raised, after all PostScript is common. If the size of the files is critical, the differences are usually quite small and can be stored in and the change filerebuilt as needed. A web-mode for gnu-emacs and some tools for working with webs are available for anonymous ftp on `csseq.cs.tamu.edu' which is 128.194.2.20. Anybody that would like to be on a mailing list for this information, please send me your address (preferably e-mail of course). Bart Childs -------