7-Mar-1997 13:27:55-GMT,1913;000000000001 Received: from axp14.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA27222 for ; Fri, 7 Mar 1997 06:27:54 -0700 (MST) Received: from pillar.elsevier.co.uk (GATE1.AMS.ORG) by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with ESMTP id <01IG7OTM0QOG0008H6@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 7 Mar 1997 07:40:56 EST Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA07573 for ; Fri, 07 Mar 1997 12:38:47 +0000 (GMT) Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP) ; Fri, 07 Mar 1997 12:40:55 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA26835 for ; Fri, 07 Mar 1997 12:40:47 +0000 (GMT) Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA27242; Fri, 07 Mar 1997 12:40:45 +0000 (GMT) Date: Fri, 07 Mar 1997 12:40:45 +0000 (GMT) From: Sebastian Rahtz Subject: pdftex To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199703071240.MAA27242@lochnagarn.elsevier.co.uk> TUG has set up a mailing list to discuss Han The Thanh's TeX variant which produces PDF instead of DVI output. If you want to join, send subscribe pdftex to majordomo@mail.tug.org I am the list moderator (cos i am interested, not because i am in any way involved in the project) pdftex is on CTAN in systems/tex2pdf, for those who want to dive into it in its current state. But Han The Thanh is not at all committed to the current state of the changes or the syntax of the new primitives, so anyone on this list looking at porting it should be careful :-} Sebastian 16-Mar-1997 12:58:59-GMT,6450;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id FAA11855 for ; Sun, 16 Mar 1997 05:58:56 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 16 Mar 1997 12:58:54 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGK97XUS9S001IM2@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 16 Mar 1997 07:34:42 EST Received: from kralle.zdv.Uni-Mainz.DE ([134.93.8.158]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 16 Mar 1997 12:34:30 +0000 (UT) Received: from frank.zdv.uni-mainz.de (Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.8.5/8.8.5) with UUCP id NAA31886; Sun, 16 Mar 1997 13:31:28 +0100 (MET) Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id NAA06900; Sun, 16 Mar 1997 13:23:22 +0100 Date: Sun, 16 Mar 1997 13:23:22 +0100 From: Frank Mittelbach Subject: Re: (La)TeX virus In-reply-to: <9703150154.AA10806@hemlock.pa.dec.com> To: lamport@pa.dec.com Cc: "Dr. Yvo Desmedt" , Keith.McMillan@ameritech.com, tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199703161223.NAA06900@frank.zdv.uni-mainz.de> References: <199703141743.LAA03559@blatz.cs.uwm.edu> <9703150154.AA10806@hemlock.pa.dec.com> X-Authentication-warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to frank.zdv.uni-mainz.de!latex3 using -f > Dear Mr McMilland and Professor Desmedt, > > But co-authors e-mail (La)TeX documents! > > I'm not too worried about co-authors inserting viruses in the versions > they send to one another. (Yes, I know that this is a way to spread > an an infection.) not having seen the original paper message i can only guess as to what you think is the security issue involving TeX (not LaTeX by the way---as LaTeX can't implement any higher level security with respect to what TeX offers or does not offer) so my assumption is that you are worried about the possibility of TeX opening write channels to any file on the system that allows being written to, e.g., to .profile on a unix system (or read channels to files like .netrc and then copying this information to some other file accessible to the intruder) this is certainly a possibility and TeX does not offer right now a way to identify such actions, however, although I agree it would be better if there is a way to determine which files are written to or prevent writing to files in other directories (using a settable switch) i don't consider this a very serious security problem. TeX respects permission bits and so files that are read-only will not be modified --- as it is advisable to keep .profile and similar files in read-only mode anyway and that takes care of this problem already. In comparison to standard software distribution these days (with a configure/make/install type of setup) where it is often nearly impossible to figure out the exact actions carried out easily, the danger when using TeX seems to me remote; and in fact i never heard that anybody was seriously getting into problems > >However, any changes would have to be made in TeX itself, and such a > >change would be up to Don Knuth. > > He replied and said he forwarded the letter to "people who should be > able to take appropriate actions", I presume you know who that is. > > No, I don't. Perhaps Frank does. those are the people who implement TeX for various platforms. In fact those people have discussed the above issues some time back and if i remember correctly the final recommendation was to just inform users that TeX can write such files > Alternately, you could have a security parameter that allows to write > to any, same directory, or same file. The last is more secure. i don't know what is meant by "same file". Most TeX macro package rely on the possibility to produce scratch files to write to and read from so that it is impossible to restrict a TeX run just to produce a single file. > That parameter would have to be set when TeX was made, or at least > when the Format file was made. Such parameters tend to gravitate > towards the value that causes the least inconvenience--namely, the one > that is least secure. People who are paranoid to create their own > more secure versions are probably not going to risk running random TeX > input anyway. So, I see no reason to add a parameter. I don't think that is true; it would be possible, for example, to implement TeX to have a runtime command-line switch that would for example display writing to OS files via \write channels. > NOTE: we plan to send this to CERT and to a conference. As you see, > we are not in a rush. How long would it take before a corrective > action can be taken? > > Not knowing who is to do the correcting, I have no idea. Perhaps other than the above i don't see that there will or should be any corrective action to be taken. Anyway, all this is up to the TeX implementors --- it has nothing to do with macro package implementation on top of TeX, ie talking to Leslie or me is addressing the wrong people. As Don Knuth is not changing anything in the base source of TeX any such addition would need to come from implementors on the various platforms (some of which are commerical some of which are freeware or shareware). that in turn means that it is very unlikely to get a single corrective action implemented. > Frank does. Anyway, it's not clear whether it is better to publicize > this weakness so people will be careful about accepting TeX sources > from strangers, or to keep it quiet to avoid inspiring knaves. well, i think i would need to see a source that is doing any harm and is not looking suspicious in the first place. Clearly if one accepts arbitrary TeX code from strangers then too bad---that is like getting shell scripts or executables and just executing them so i think it might be a good idea to tell people that TeX code can do harm (as most stuff can --- such as ps files ....) so that it might be wise to look over a file first and perhaps keep important files read-only or not execute unknown TeX stuff from stranger on an important account. regards frank cc tex-implementors 16-Mar-1997 15:35:08-GMT,5072;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id IAA14745 for ; Sun, 16 Mar 1997 08:35:07 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 16 Mar 1997 15:35:05 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #16534) id <01IGKCG9HDQO001L43@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 16 Mar 1997 10:23:38 EST Date: Sun, 16 Mar 1997 10:23:29 -0500 (EST) From: bbeeton Subject: potential virus spreadable by (la)tex To: TeX-implementors@MATH.AMS.ORG Cc: keith.mcmillan@ameritech.com, desmedt@cs.uwm.edu, bnb@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <858525809.195705.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: attached are verbatim copies of a letter to don knuth regarding a potential virus using (la)tex, and don's response. apologies for the delay in distributing this. frank mittelbach has already addressed this topic in a message to tex-implementors, on the basis presumably of a message forwarded from leslie lamport. on account of the nature of the letters, please refrain from placing this message into any public archive. thanks. -- bb -------------------- University of Wisconsin, Milwaukee College of Engineering and Applied Science Department of Electrical Engineering and Computer Science PO Box 784 Milwaukee, WI 53201 February 24, 1997 Dr. Donald Knuth Department of Computer Science Stanford University Margaret Jacks Hall, Bldg. 460 Stanford, CA 94305 Dear Dr. Knuth, As you may be aware, a virus has recently been discovered that inhabits macro files used by the Microsoft Word program. Unfortunately, we need to inform you that in the course of completing an MS degree at the University of Wisconsin-Milwaukee in May 1994, I, Keith McMillan, created just such a virus using LaTeX, relying mostly on the facilities of TeX, and GNU Emacs. This virus, while not damaging (it carries no payload) is virulent. This virus only existed in a controlled environment, and no copies exist in the wild. In brief, the virus inhabits LaTeX document files, inserting a small routine into the .emacs file to locate other files to infect. It reads the target file into the .aux file generated by LaTeX, adds itself (in the form of macros) into the file, and then copies the newly infected file back over the original file. We believe that while this virus never existed outside a controlled environment, just such a virus is within the reach of any reasonably fluent TeX user, and precautions should be taken to prevent the misuse of TeX in such a manner. We further believe that restricting TeX to the types of files it can open for writing, for instance restricting it to only opening files of the form FILE.*, where FILE is the top level (i.e. user) input being read, could make an attack such as the one Keith developed ineffective. (This was suggested by Yair Frankel.) Further, it may be enough in the short term to inform the TeX user of what files are being opened and closed on the standard output channel, instead of only logging it to the log file (which is typically not read, unless something goes wrong). We must admit we have a degree of trepidation regarding your reaction to the news. We can't help but feel as though we are misusing a facility you provided in good faith, and betraying a legendary figure in the Computer Science field. On the other hand, it is probably better that these problems are uncovered and documented in the research community, rather than in the wild. Keith would be happy to provide you with a copy of the thesis. Yours Sincerely, Keith McMillan Yvo Desmedt Keith.McMillan@Ameritech.COM desmedt@cs.uwm.edu 3413 N. Cramer Street Professor Milwaukee, WI 53211 cc: Leslie Lamport -------------------- Stanford University Stanford, California 94305-9045 Donald E. Knuth Professor Emeritus of The Art of Computer Programming Computer Science Department -- Gates 4B Telephone [415] 723-4367 March 4, 1997 Professor Yvo Desmedt Mr. Keith McMillan Department of Electrical Engineering and Computer Science University of Wisconsin, Milwaukee P O Box 784 Milwaukee, WI 53201 Dear Professer Desmedt and Mr. McMillan, Thanks for writing about the potential virus. We had alerted implementors to this possibility many years ago, and in particular I thought it was impossible to write ".emacs" from within TeX. But evidently people have not followed the guidelines we suggested. I am forwarding copies of your letter to the people who should be able to take appropriate precautions. Sincerely, Donald E. Knuth Professor DEK/pw bcc: Barbara Beeton Barbara, Please show a copy of their letter to everybody that you think should see it. 17-Mar-1997 1:31:15-GMT,2076;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id SAA26126 for ; Sun, 16 Mar 1997 18:31:10 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Mar 1997 01:31:08 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGKZVZOLV4001FHU@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 16 Mar 1997 20:18:32 EST Received: from Xenon.Stanford.EDU ([171.64.64.24]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 17 Mar 1997 01:18:21 +0000 (UT) Received: (from rokicki@localhost) by Xenon.Stanford.EDU (8.8.4/8.8.4) id RAA22901; Sun, 16 Mar 1997 17:20:39 -0800 (PST) Date: Sun, 16 Mar 1997 17:20:39 -0800 (PST) From: "Tomas G. Rokicki" Subject: Re: potential virus spreadable by (la)tex To: BNB@MATH.AMS.ORG, TeX-implementors@MATH.AMS.ORG Cc: bnb@MATH.AMS.ORG, desmedt@cs.uwm.edu, keith.mcmillan@ameritech.com Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199703170120.RAA22901@Xenon.Stanford.EDU> Since this was brought up in the context of TeX, I feel it only fair to warn that the same thing is very much more easily accomplished in dvips (through the use of specials) and/or .dvipsrc files. In addition, dvips has numerous places where automatic arrays are used with gets or some other equivalent procedure, allowing sendmail-style attacks from within dvi files. So I guess it is time for me to make dvips virus-proof, probably not a trivial undertaking. In the interim, I'd like to suggest that we not make use of any features of dvips disabled by -DSECURE (primarily, the execution of commands by backtick-specials). Also, any suggestions on precisely what the security holes are and recommendations on how they can be patched would be greatly appreciated. The world has become a very different place in the last ten years, and it is about time I caught up with modern reality . . . -tom 17-Mar-1997 13:41:10-GMT,2575;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id GAA10934 for ; Mon, 17 Mar 1997 06:41:07 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Mar 1997 13:41:06 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGLOHO0AAO001P98@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 17 Mar 1997 08:03:18 EST Received: from helios.edvz.univie.ac.at ([131.130.1.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 17 Mar 1997 13:02:15 +0000 (UT) Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 0945; Mon, 17 Mar 1997 13:56:18 +0100 (MEZ) Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 4523; Mon, 17 Mar 1997 13:56:17 +0100 Date: Mon, 17 Mar 1997 13:48:36 +0100 (MEZ) From: Peter Schmitt Subject: Re: potential virus spreadable by (la)tex In-reply-to: "17 Mar 1997 12:02:47 +0100 from" <"vieth"@thphy.uni-duesseldorf.de> To: Ulrik Vieth , TeX-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <01IGLOIFG84I001P98@AXP14.AMS.ORG> >This way writing to files like ".rhosts" or ".emacs" should be >prevented. The only remaining danger might come from a TeX virus that >first writes a suitable "texmf.cnf" file to the current directory and >than tricks the user into running TeX again with the new settings from >the local config file taking precedence over the global settings. >Anyway, this should still be safer than not having any checks at all. > >Ulrik Vieth. > Just for completeness: There are even simpler methods to cause (limited) damage: \openout1 \jobname \closeout1 will overwrite the inputfile (and does not appear in the .log file) Or you can write a batch file (maybe named tex.bat or latex.bat) which might be invoked accidently and deletes *.tex (this is for DOS). Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 17-Mar-1997 17:22:43-GMT,4384;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id KAA16217 for ; Mon, 17 Mar 1997 10:22:41 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Mar 1997 17:22:40 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGLWCN2MYO001JF4@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 17 Mar 1997 11:47:26 EST Received: from pppl.gov ([192.55.106.85]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 17 Mar 1997 16:47:15 +0000 (UT) Received: from carl.pppl.gov (karney@carl.pppl.gov [198.35.4.72]) by pppl.gov (8.8.5/8.8.5) with ESMTP id LAA03511; Mon, 17 Mar 1997 11:47:07 -0500 (EST) Received: (from karney@localhost) by carl.pppl.gov (8.8.5/8.8.5) id LAA27638; Mon, 17 Mar 1997 11:47:04 -0500 (EST) Date: Mon, 17 Mar 1997 11:47:04 -0500 (EST) From: Charles Karney Subject: Re: potential virus spreadable by (la)tex In-reply-to: <858525809.195705.BNB@MATH.AMS.ORG> (message from bbeeton on Sun, 16 Mar 1997 10:23:29 -0500 (EST)) To: BNB@MATH.AMS.ORG Cc: TeX-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: karney@princeton.edu Message-id: <199703171647.LAA27638@carl.pppl.gov> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII It is important to alert the TeX user community to some elementary precautions when running TeX. Following the practice with other security alerts, this should be done fairly soon (within a week?), once some useful advice can be given. I suggest something along the lines of: ================================================================ (1) TeX has the ability to write files with (pretty much) arbitrary names in (pretty much) arbitrary directories. On multi-user systems (Unix, VMS) this is subject to the standard system protections on files. On some systems and with some implementations of TeX, further restrictions are placed on the files that can be written (e.g., some implementations for Unix prevent TeX from writing to "dot" files, .cshrc, .rhosts, etc.) (2) For this reason, you should not run TeX on a file from an untrusted source, nor should you use TeX macros from an untrusted source. (3) Similarly, on multi-user systems, you should avoid running TeX with special privileges (i.e., root on Unix systems). (Creation of "format" files should be done as a regular user.) (4) If possible, use an implementation of TeX which restricts which files can be written and which reports which files are written to in the log file. ================================================================ Left unsaid is whether the macros at CTAN are safe. The core distributions for TeX and LaTeX can almost certainly safe. But what about the other umpteen thousand macro files? Some consideration also needs to be given to other related programs (dvips, etc.). I hope too that no-one is running TeX, by default, in a mode which allows the execution of arbritrary commands (via the -shell-escape mechanism in some Unix implementations). I have posted a patch (posted to the tex-k mailing list) for Berry's implementation of TeX which restricts writes to a directory at or below the current directory or TEXMFOUTPUT. I don't think that this impacts normal use of TeX and it provides a way to run TeX safely on untrusted files via TEMPDIR=/tmp/tex.$$ umask 077 mkdir $TEMPDIR cd $TEMPDIR tex $1 Another possibility is to forbid ANY directory specification on output files and to write to TEXMFOUTPUT, if it's defined, or to the current directory, otherwise. (This is a reversal of the normal rules for TEXMFOUTPUT, which is normally only tried after the current directory.) Then, to run TeX safely you could do TEMPDIR=/tmp/tex.$$ umask 077 mkdir $TEMPDIR env TEXMFOUTPUT=$TEMPDIR tex $1 This scheme is attractive, since it is unnecessary to change TEXINPUTS to find multiple input files. Restricting TeX to write only files of the form \jobname.* is a non-starter. This would break lots of things. -- 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 3438 17-Mar-1997 22:45:44-GMT,2228;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA24298 for ; Mon, 17 Mar 1997 15:45:42 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Mar 1997 22:45:40 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGM8ENS0MO001WIK@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 17 Mar 1997 17:32:39 EST Received: from mailrelay.tiac.net ([199.0.65.237]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 17 Mar 1997 22:32:29 +0000 (UT) Received: from yandy.tiac.net (p6.ts25.metro.MA.tiac.com [206.119.196.167]) by mailrelay.tiac.net (8.8.5/) with SMTP id RAA26217; Mon, 17 Mar 1997 17:32:30 -0500 (EST) Date: Mon, 17 Mar 1997 17:33:00 -0500 From: Y&Y Inc Subject: Re: potential virus spreadable by (la)tex X-Sender: yandy@pop.tiac.net To: BNB@MATH.AMS.ORG, TeX-implementors@MATH.AMS.ORG Cc: bnb@MATH.AMS.ORG, desmedt@cs.uwm.edu, keith.mcmillan@ameritech.com, rokicki@CS.Stanford.EDU Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <3.0.32.19970317173256.007dc660@pop.tiac.net> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Content-type: text/plain; charset="us-ascii" Hi: DVIWindo has hyper-text support, which can be used to jump to other places in a DVI document or other DVI documents, but also has other capabilites, including launching an application. This should be disabled when used as a web browser. The ability to launch other applications is prettey handy. D.P. Story has a whole calculus course set up that way with Mathematica examples linked to via hyper-text buttons - he even does a quiz via batch files called this way! But obviously this capability can be misused. These hyper-text links get translated by DVIPSONE to pdfmarks for Acrobat Disitller. Which then has the same potential problem, since it will launch an application when the button is pushed. as far as I know there isn't much in Acrobat to protect one from mischief there. Sigh. Another thing to waste time on! Regards, Berthold. 19-Mar-1997 20:43:51-GMT,5408;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id NAA24945 for ; Wed, 19 Mar 1997 13:43:46 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 19 Mar 1997 20:43:45 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGOW9F9OHC001XRO@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 19 Mar 1997 15:17:16 EST Received: from pppl.gov ([192.55.106.85]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 19 Mar 1997 20:17:02 +0000 (UT) Received: from carl.pppl.gov (karney@carl.pppl.gov [198.35.4.72]) by pppl.gov (8.8.5/8.8.5) with ESMTP id PAA03952; Wed, 19 Mar 1997 15:16:59 -0500 (EST) Received: (from karney@localhost) by carl.pppl.gov (8.8.5/8.8.5) id PAA13579; Wed, 19 Mar 1997 15:16:57 -0500 (EST) Date: Wed, 19 Mar 1997 15:16:57 -0500 (EST) From: Charles Karney Subject: Re: potential virus spreadable by (la)tex In-reply-to: <33303230.2DF6@teleport.com> (message from Arthur Ogawa on Wed, 19 Mar 1997 10:39:16 -0800) To: Ogawa@teleport.com Cc: BNB@MATH.AMS.ORG, TeX-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: karney@princeton.edu Message-id: <199703192016.PAA13579@carl.pppl.gov> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII > Date: Wed, 19 Mar 1997 10:39:16 -0800 > From: Arthur Ogawa > > Charles Karney wrote: > > > I have posted a patch (posted to the tex-k mailing list) for Berry's > > implementation of TeX which restricts writes to a directory at or below the > > current directory or TEXMFOUTPUT. > > I favor this scheme. Why not at least have the default compile-time > option for UNIX TeX cleave to this standard? > > OTOH, if someone wished to create a TeX executable that was dangerously > unrestricted, then they would be free to do so via re-compilation. Such > implementations should probably announce that they are "dangerous". With Karl Berry's implementation (texk 7.x), recompilation is not necessary. Running env openout_any=1 latex ... circumvents all the checks on output file names. This is right sort of solution, 99.9% of TeX users will use TeX in the safe default mode. The 0.1% of users who don't want the checks can do so easily and hopefully they tend to be more aware of potential security issues. > Note that the virus described by McMillan and Desmedt requires the > participation of both TeX and of Emacs; this seems to be a common > thread. I submit that in running TeX, mf, or even dvips alone it would > be pretty much impossible to cause much damage: you have to invoke a > powerful application like Emacs or a shell to cause damage (beyond > overwriting e.g. \jobname.tex). Well the more juicy file for a badly configured TeX's to write (or overwrite) is ~/.rhosts. And every cracker's favorite entry for this file is "+ +", allowing anyone on the Internet login access to the users account. A cracker is 80% of the way to gaining root access on many systems once he can log in as a regular user. [A fair fraction (> 50%) of CERT notices are about program defects that allow ordinary users to gain root access.] This then is a MAJOR security problem (but it's not a virus!). Of course, texk 7.x closes this hole by disallowing writing to dot files. (And some systems also restrict the use of rshd or monitor .rhosts for suspicious entries.) > My concrete proposal is for webc to by default prevent the app from > writing to a dot file or a file above "./". And for apps capable of > doing so to announce themselves as "potentially violent". Any thoughts? Another potentially dangerous non-dot file that a cracker might want to write to is ~/.ssh/authorized_keys This lists the public keys for people accessing the system via ssh which is a secure replacement for rsh. I don't think that texk 7.x can write to this file either because it tacks ".tex" onto file names which don't contain a ".". (The check for dot files is NOT triggered by the .ssh above, since since check is done only on file name and not on the directory name.) But to be safe, I would suggest the following: (1) no initial dot is allowed in the file name (2) no initial dot is allowed in any component of the path name (3) directory must be at or below ./ or $TEXMFOUTPUT. A couple of final thoughts for the perverse: (1) Running latex on a malicious TeX file could create article.cls or article.sty in the current directory. This would then be used the next time latex is run, since TEXINPUTS nearly always has the current directory first. Other than having TeX/LaTeX misbehave, I'm not sure what impact this would have. I suppose a hijacked letter.cls could insert an inappropriate greeting or closing in a letter which a user who carefully read his letter in an editor might miss. (2) The default Unix setup allows PK files to be created on the fly. Presumably this process could be subverted and a copy of cmr10.300pk inserted with various letters permuted. It's difficult to see how this would go unnoticed for very long. -- 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 3438 19-Mar-1997 21:27:29-GMT,2673;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id OAA25970 for ; Wed, 19 Mar 1997 14:27:28 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 19 Mar 1997 21:27:26 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGOYI3T0GG002714@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 19 Mar 1997 16:21:37 EST Received: from kim.teleport.com ([192.108.254.26]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 19 Mar 1997 21:21:22 +0000 (UT) Received: from 205.138.246.20 (ppp1024.inreach.com [205.138.245.24]) by kim.teleport.com (8.8.5/8.7.3) with SMTP id NAA27749; Wed, 19 Mar 1997 13:21:06 -0800 (PST) Date: Wed, 19 Mar 1997 13:22:49 -0800 From: Arthur Ogawa Subject: Re: potential virus spreadable by (la)tex To: karney@princeton.edu Cc: BNB@MATH.AMS.ORG, TeX-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: Ogawa@teleport.com Message-id: <3330585F.EB0@teleport.com> Organization: TeX Consultants MIME-version: 1.0 X-Mailer: Mozilla 3.0Gold (Macintosh; I; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199703192016.PAA13579@carl.pppl.gov> Charles Karney wrote: > > With Karl Berry's implementation (texk 7.x), recompilation is not > necessary. Running > > env openout_any=1 latex ... > > circumvents all the checks on output file names. This is right sort of > solution... Can we be assured that the switch to openout_any=1 is something a TeX document would never be able to accomplish? > But to be safe, I would suggest the following: > (1) no initial dot is allowed in the file name > (2) no initial dot is allowed in any component of the path name > (3) directory must be at or below ./ or $TEXMFOUTPUT. You have my vote. > A couple of final thoughts for the perverse: > (1) Running latex on a malicious TeX file could create article.cls... > (2) The default Unix setup allows PK files to be created on the fly. > Presumably this process could be subverted... How very creative! Basically, TeX must be able to read in files that it has written out in an earlier run, so there is little way I can see to prevent such schemes. Their effect is solely on files, albeit important, in "./", however. -- Arthur Ogawa/TeX Consultants voice: +1 209 561-4585 Fax: +1 209 561-4584 emailto://ogawa@teleport.com http://www.teleport.com/~ogawa ftp://ftp.teleport.com/users/ogawa PGP key: finger -l ogawa@teleport.com 19-Mar-1997 22:54:40-GMT,3740;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA28188 for ; Wed, 19 Mar 1997 15:54:38 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 19 Mar 1997 22:54:37 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGP0XPFF9C001T4K@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 19 Mar 1997 17:31:27 EST Received: from pppl.gov ([192.55.106.85]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 19 Mar 1997 22:31:09 +0000 (UT) Received: from carl.pppl.gov (karney@carl.pppl.gov [198.35.4.72]) by pppl.gov (8.8.5/8.8.5) with ESMTP id RAA13000; Wed, 19 Mar 1997 17:31:05 -0500 (EST) Received: (from karney@localhost) by carl.pppl.gov (8.8.5/8.8.5) id RAA17355; Wed, 19 Mar 1997 17:31:01 -0500 (EST) Date: Wed, 19 Mar 1997 17:31:01 -0500 (EST) From: Charles Karney Subject: Re: potential virus spreadable by (la)tex In-reply-to: <3330585F.EB0@teleport.com> (message from Arthur Ogawa on Wed, 19 Mar 1997 13:22:49 -0800) To: Ogawa@teleport.com Cc: BNB@MATH.AMS.ORG, TeX-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: karney@princeton.edu Message-id: <199703192231.RAA17355@carl.pppl.gov> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII > Date: Wed, 19 Mar 1997 13:22:49 -0800 > From: Arthur Ogawa > > Running > > env openout_any=1 latex ... > > circumvents all the checks on output file names. > Can we be assured that the switch to openout_any=1 is something a TeX > document would never be able to accomplish? The document can't set openout_any, unless tex/latex is invoked with latex -shell-escape (and even then it would be indirect, since an inferior process can't change a parent's environment). This flag allows the execution of arbritary commands and so you should be careful using this. Again 99.9% of TeX users won't know about this. And the 0.1% who use it should know they are playing with fire if they run latex like this on a file from an untrusted source. > > (1) Running latex on a malicious TeX file could create article.cls... > How very creative! Basically, TeX must be able to read in files that it > has written out in an earlier run, so there is little way I can see to > prevent such schemes. Their effect is solely on files, albeit important, > in "./", however. I suppose TEXINPUTS could have "." at the end (like the usual advice on the Unix PATH nowadays). However, users sometimes want their macro files to override the system ones. In this case, they could use something like TEXINPUTS=~/tex:/usr/local/share/texmf/tex//:. (Compare PATH=$HOME/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:. ) This would need to be changed in texmf.cnf. I won't be doing this, since (a) it will break things for some people and (b) it won't be completely effective because plenty of users on our systems are setting TEXINPUTS directly themselves. Incidentally, I am logging the names of the output files written by TeX. My guess is that no-one is writing output files to other than the current directory. If my guess is confirmed after a couple of weeks, then I'll modify the openoutok routine to allow only output files in "." or $TEXMFOUTPUT (and NOT in their subdirectories). This will make it somewhat easier for users to see if strange files have been written by TeX. -- 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 3438 24-Mar-1997 19:59:30-GMT,2878;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id MAA16787 for ; Mon, 24 Mar 1997 12:59:28 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Mar 1997 19:59:27 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IGVU4O4WVK000MNN@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 24 Mar 1997 14:31:40 EST Received: from pppl.gov ([192.55.106.85]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 24 Mar 1997 19:31:29 +0000 (UT) Received: from carl.pppl.gov (karney@carl.pppl.gov [198.35.4.72]) by pppl.gov (8.8.5/8.8.5) with ESMTP id OAA26703; Mon, 24 Mar 1997 14:31:26 -0500 (EST) Received: (from karney@localhost) by carl.pppl.gov (8.8.5/8.8.5) id OAA03089; Mon, 24 Mar 1997 14:31:24 -0500 (EST) Date: Mon, 24 Mar 1997 14:31:24 -0500 (EST) From: Charles Karney Subject: Re: potential virus spreadable by (la)tex In-reply-to: <858525809.195705.BNB@MATH.AMS.ORG> (message from bbeeton on Sun, 16 Mar 1997 10:23:29 -0500 (EST)) To: BNB@MATH.AMS.ORG Cc: TeX-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: karney@princeton.edu Message-id: <199703241931.OAA03089@carl.pppl.gov> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Here are two other ideas for restricting what file names TeX can write to. I don't think either is really worth pursuing, but perhaps others would like to comment (1) restrict the extension of the filenames. Thus allow latex only to write to *.aux, *.lot, *.loc, etc. files. kpathsea would allow you easily to specify separate lists of extensions of each program. This would hopefully limit the scope of any damage to the product of TeX itself. I view this as a rather intrusive change since either macro writers will have to conform their file names to a "standard" or else the user/system administrator will have to keep on updating the list of allowable extensions. (2) restrict the allowed characters in pathnames. With Unix any non-null character is allowed in pathname. Possibly the presence of characters special to the shell would break poorly written system scripts. A potential attack along these lines is to insert a newline into a filename thereby causing purge scripts like this one find /tmp -atime +10 -print | xargs rm -f to delete the wrong files (with the GNU utilities this should read 'find ... -print0 | xargs -0 rm -f'). If any restriction along these lines were implemented, it should allow accented characters. -- 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 3438 12-Jun-1997 15:27:37-GMT,1625;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA20951 for ; Thu, 12 Jun 1997 09:27:35 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Jun 1997 15:27:35 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IJZE5260CG0002TF@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 12 Jun 1997 11:02:47 EST Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 12 Jun 1997 15:02:28 +0000 (UT) Date: Thu, 12 Jun 1997 16:03:23 +0100 From: Philip Taylor (RHBNC) Subject: Tex the program, module 103: print_scaled. To: tex-implementors@MATH.AMS.ORG Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <970612160323.5a18@vms.rhbnc.ac.uk> According to my copy of Vol.~B, the 8th line of print_scaled reads: repeat if delta > unity then s <-- s + '100000 - (delta div 2); { } this reading is confirmed by "tex82.bug" as found at CTAN, where I find repeat if delta>unity then s:=s+@'100000-(delta div 2); {round the last digit} However, in TeX 3.14159, I find instead: repeat if delta>unity then s:=s+@'100000-50000; {round the last digit} Since delta is a variable, the expression (delta div 2) cannot possibly be flattened to 50000; could anyone explain how this difference has come about, and for what reason? Philip Taylor, RHBNC. 16-Jun-1997 15:45:09-GMT,1974;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA15598 for ; Mon, 16 Jun 1997 09:44:58 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 16 Jun 1997 15:44:57 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IK502G6ASW000KLB@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 16 Jun 1997 11:24:23 EST Received: from mailrelay.tiac.net ([199.0.65.237]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 16 Jun 1997 15:24:10 +0000 (UT) Received: from p2.ts7.bedfo.MA.tiac.com (p2.ts7.bedfo.MA.tiac.com [207.60.9.227]) by mailrelay.tiac.net (8.8.5/) with SMTP id LAA05520; Mon, 16 Jun 1997 11:21:46 -0400 (EDT) Date: Mon, 16 Jun 1997 11:24:20 -0400 From: support@YandY.com (Y&Y Inc) Subject: Re: Tex the program, module 103: print_scaled. X-Sender: yandy@pop.tiac.net (Unverified) To: tex-implementors@MATH.AMS.ORG Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199706161521.LAA05520@mailrelay.tiac.net> MIME-version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Content-type: text/plain; charset="us-ascii" Hi: re: `CM' font metrics Is there some good reason why the EC font metrics don't match the CM font metrics for the characters that are common to both font sets (except where intentional changes were made)? The EC advance widths etc. are consistently about 1/4000 th smaller than the corresponding CM advance widths. Seems like an unnecccesary inconsistency to me. For example, it makes for potential inaccuracies when switching between EC and `fake EC' obtained via VF from CM. The CM font advance widths themselves are on average 2 scaled points too large, but that is a miniscule discrepancy compared to the above. Regards, Berthold Horn Berthold K. P. Horn Concord, MA 01742 16-Jun-1997 19:12:19-GMT,2784;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA20961 for ; Mon, 16 Jun 1997 13:12:16 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 16 Jun 1997 19:12:15 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IK57BWSTXC000MA1@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 16 Jun 1997 14:52:49 EST Received: from elessar.ics.muni.cz ([147.251.4.10]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 16 Jun 1997 18:52:37 +0000 (UT) Received: from daeron (daeron.fi.muni.cz [147.251.48.91]) by elessar.ics.muni.cz (8.8.5/8.8.5) with SMTP id UAA22302; Mon, 16 Jun 1997 20:52:39 +0200 (MET DST) Received: by daeron id AA11491 (5.67b8/IDA-1.4.4); Mon, 16 Jun 1997 20:52:35 +0200 Date: Mon, 16 Jun 1997 20:52:35 +0200 (MET DST) From: Petr Sojka Subject: Re: Tex the program, module 103: print_scaled. In-reply-to: <970612160323.5a18@vms.rhbnc.ac.uk> To: P.Taylor@vms.rhbnc.ac.uk Cc: tex-implementors@MATH.AMS.ORG, thanh@informatics.muni.cz (Han The Thanh) Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199706161852.AA11491@daeron> Organization: Masaryk University, Brno, The Czech Republic, www.fi.muni.cz MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL25 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Postal-Address: Faculty of Informatics, Botanicka 68a, 60200 Brno Telephone: +420-5-41512352 (my room), +420-5-41512329 (secretary), Fax: +420-5-41212568, 41213219 "RHBNC wrote:" : According to my copy of Vol.~B, the 8th line of print_scaled reads: : : repeat if delta > unity then s <-- s + '100000 - (delta div 2); { } : : this reading is confirmed by "tex82.bug" as found at CTAN, where I find : : repeat if delta>unity then s:=s+@'100000-(delta div 2); {round the last digit} : : However, in TeX 3.14159, I find instead: : : repeat if delta>unity then s:=s+@'100000-50000; {round the last digit} : : Since delta is a variable, the expression (delta div 2) cannot possibly : be flattened to 50000; could anyone explain how this difference has come : about, and for what reason? The reason is optimization. Even as this leads to less readable code, DEK don't relies on clever compilers and optimizes by hand. It can be proven given the cycle invariant that the condition is fulfilled after exactly five iterations and thus delta=10*10*10*10*10*10 and delta div 2 = 100000 div 2 = 50000. This example showes that getting rid of these optimizations woudn't be trivial in future possible reimplementation of TeX. Petr : Philip Taylor, RHBNC. 17-Jun-1997 7:36:09-GMT,2158;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA12237 for ; Tue, 17 Jun 1997 01:36:06 -0600 (MDT) From: KNAPPEN@MZDMZA.ZDV.UNI-MAINZ.DE Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Jun 1997 07:36:01 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IK5X80Z2GW000P4O@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 17 Jun 1997 03:14:07 EST Received: from dzdmzc.zdv.Uni-Mainz.DE ([134.93.8.34]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 17 Jun 1997 07:13:57 +0000 (UT) Received: from MZDMZA.ZDV.UNI-MAINZ.DE by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #22141) id <01IK69MSYUCGH63WP9@MZDMZA.ZDV.UNI-MAINZ.DE>; Tue, 17 Jun 1997 09:15:10 +0100 Date: Tue, 17 Jun 1997 09:15:10 +0100 Subject: Re: Tex the program, module 103: print_scaled. To: support@YandY.com Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <01IK69MSYZ1UH63WP9@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: IN%"support@YandY.com" X-VMS-Cc: IN%"tex-implementors@MATH.AMS.ORG" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Berthold Horn wrote: >>>The EC advance widths etc. are consistently about 1/4000 th smaller than the corresponding CM advance widths. Seems like an unnecccesary inconsistency to me. For example, it makes for potential inaccuracies when switching between EC and `fake EC' obtained via VF from CM. Berthold, which fonts did you compare? Only one of them (e.g. cmr10 vs. ecrm1000) or a larger set considering several design sizes? As fas as I know, the macros governing the advance width are the same for the cm fonts and the ec fonts. A potential source of those small difference is the interpolation mechanism used by the ec fonts. It introduces small rounding errors which also affect the starting values given in the parameter files. I found this phenomenon being relevant while designing the ec slitex typewriter fonts. --J"org Knappen 17-Jun-1997 8:35:52-GMT,4080;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA13510 for ; Tue, 17 Jun 1997 02:35:50 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Jun 1997 08:35:49 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IK5ZEVVQMO000PED@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 17 Jun 1997 04:17:00 EST Received: from beach.frankfurt.netsurf.de ([194.64.181.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 17 Jun 1997 08:16:45 +0000 (UT) Received: from puma.npc.de (deck-75.frankfurt.netsurf.de [194.64.181.107]) by beach.frankfurt.netsurf.de (8.6.12/8.6.12) with ESMTP id KAA00686; Tue, 17 Jun 1997 10:14:47 +0200 Received: (from schrod@localhost) by puma.npc.de (8.6.12/8.6.12) id JAA12919; Tue, 17 Jun 1997 09:27:19 +0200 Received: (from schrod@localhost) by puma.npc.de (8.6.12/8.6.12) id JAA12917; Tue, 17 Jun 1997 09:27:18 +0200 Date: Tue, 17 Jun 1997 09:27:18 +0200 From: Joachim Schrod Subject: Re: Tex the program, module 103: print_scaled. In-reply-to: <199706161852.AA11491@daeron> To: Petr Sojka Cc: P.Taylor@vms.rhbnc.ac.uk, tex-implementors@MATH.AMS.ORG, thanh@informatics.muni.cz (Han The Thanh) Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199706170727.JAA12917@puma.npc.de> MIME-version: 1.0 (generated by tm-edit 7.95) Content-type: text/plain; charset=US-ASCII References: <970612160323.5a18@vms.rhbnc.ac.uk> <199706161852.AA11491@daeron> >>>>> "PS" == Petr Sojka writes: PS> "RHBNC wrote:" PS> : According to my copy of Vol.~B, the 8th line of print_scaled reads: PS> : PS> : repeat if delta > unity then s <-- s + '100000 - (delta div 2); { } PS> : PS> : this reading is confirmed by "tex82.bug" as found at CTAN, where I find PS> : PS> : repeat if delta>unity then s:=s+@'100000-(delta div 2); {round the last digit} PS> : PS> : However, in TeX 3.14159, I find instead: PS> : PS> : repeat if delta>unity then s:=s+@'100000-50000; {round the last digit} PS> : PS> : Since delta is a variable, the expression (delta div 2) cannot possibly PS> : be flattened to 50000; could anyone explain how this difference has come PS> : about, and for what reason? PS> The reason is optimization. Even as this leads to less readable PS> code, DEK don't relies on clever compilers and optimizes by hand. PS> It can be proven given the cycle invariant that PS> the condition is fulfilled after exactly five iterations PS> and thus delta=10*10*10*10*10*10 and delta div 2 = 100000 div 2 = 50000. PS> This example showes that getting rid of these optimizations PS> woudn't be trivial in future possible reimplementation of TeX. Why? Exactly this example, invariant removal, is handled by most good compilers automatically. It's a good point _for_ writing readable, maintainable code, where profis like Phil are not baffled but that is still fast. Honestly, I worry more about _human_ productivity than _machine_ productivity, the latter gets faster all the time, the former doesn't increase. Having seen what a good optimizing compiler does to a source code, and having read DEK's code (that _hinders_ optimization with all his global variables and parameter/result passing by side effects) I'd bet that a clean implementation in C with following optimization is _faster_ than his code compiled on a good Pascal compiler. Note that I didn't say that it's a sensible thing to recode TeX with exactly the same algorithms in C. I'd happily spend a few machine cycles (maybe even a few more ;-) for a more modern system, both in terms of functionality and implementation. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: jschrod@acm.org Net & Publication Consultance GmbH Tel.: +49-6074-861530 Roedermark, Germany Fax: +49-6074-861531 17-Jun-1997 17:24:33-GMT,2494;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA24372 for ; Tue, 17 Jun 1997 11:24:31 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Jun 1997 17:24:29 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01IK6HX6X9SW000SSU@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 17 Jun 1997 13:07:06 EST Received: from mailrelay.tiac.net ([199.0.65.237]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 17 Jun 1997 17:06:55 +0000 (UT) Received: from denali (p14.ts3.bedfo.MA.tiac.com [207.60.9.111]) by mailrelay.tiac.net (8.8.5/) with SMTP id NAA28932; Tue, 17 Jun 1997 13:07:17 -0400 (EDT) Date: Tue, 17 Jun 1997 13:06:57 -0400 From: Y&Y Inc Subject: Re: Tex the program, module 103: print_scaled. In-reply-to: <01IK69MSYZ1UH63WP9@MZDMZA.ZDV.UNI-MAINZ.DE> X-Sender: yandy@pop.tiac.net (Unverified) To: KNAPPEN@MZDMZA.ZDV.UNI-MAINZ.DE Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <3.0.1.32.19970617130657.009d4680@pop.tiac.net> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Content-type: text/plain; charset="us-ascii" Hi: At 09:15 AM 97/06/17 +0100, you wrote: >>>>The EC advance widths etc. are consistently about 1/4000 th smaller than >the corresponding CM advance widths. Seems like an unnecccesary >inconsistency to me. For example, it makes for potential inaccuracies >when switching between EC and `fake EC' obtained via VF from CM. >Berthold, which fonts did you compare? Only one of them (e.g. cmr10 vs. >ecrm1000) or a larger set considering several design sizes? >As fas as I know, the macros governing the advance width are the same for >the cm fonts and the ec fonts. A potential source of those small difference >is the interpolation mechanism used by the ec fonts. It introduces small >rounding errors which also affect the starting values given in the >parameter files. I found this phenomenon being relevant while designing the >ec slitex typewriter fonts. The only one I compared in detail is ecrm1000 versus cmr10. The reason I compared this one in detail is that I found the discrepancy in some other fonts that I was looking at like, ecbx1000 etc. All of the ones I was looking at were at 10pt design size. Regards, Berthold. 17-Jul-1997 11:03:22-GMT,2040;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id FAA08943 for ; Thu, 17 Jul 1997 05:03:21 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Jul 1997 11:03:16 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #16534) with SMTP id <01ILC11PD1Z40000UN@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 17 Jul 1997 06:36:49 EST Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.123]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 17 Jul 1997 10:36:40 +0000 (UT) Received: from macbeth.uni-duesseldorf.de (macbeth.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA23239; Thu, 17 Jul 1997 12:29:13 +0200 Received: by macbeth.uni-duesseldorf.de (SMI-8.6/SMI-SVR4) id MAA29417; Thu, 17 Jul 1997 12:29:02 +0200 Date: Thu, 17 Jul 1997 12:29:02 +0200 From: Ulrik Vieth Subject: TeX History Alert To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199707171029.MAA29417@macbeth.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit While I was once again reading the Errorlog of TeX I noticed that another important day in TeX's history almost went unnoticed. On July 15, 1982 (excactly 15 years and 2 days ago), Knuth began debugging TeX 82, presumably version -100.0. Time to celebrate! Cheers, Ulrik. P.S. Whoever picked the date for EuroTeX'98 (March 29--31, 1998) apparently also made a good choice. If you look into the Errorlog for March 29, 1978, you'll find that it says: 29 Mar 1978 [...] # After these corrections, the test routine worked\thinspace\dots\ I feel that \TeX\ is now pretty well debugged (except perhaps for error recovery)---it's time to celebrate! Time for a "20 years of TeX 78" party at EuroTeX'98 next year? 17-Jul-1997 18:56:12-GMT,2061;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA19555 for ; Thu, 17 Jul 1997 12:56:10 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 17 Jul 1997 18:56:05 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #16534) id <01ILCHRIBIDC00018I@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 17 Jul 1997 14:40:10 EST Date: Thu, 17 Jul 1997 14:40:01 -0400 (EDT) From: bbeeton Subject: re-sending -- TeX History Alert To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <869164801.118779.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: sorry if this is a duplicate, however, last night there seem to have been some system-wide gremlins at work, and i was blessed with a flock of failed addresses for usually reliable sites. so at the risk of annoying some of you, i am re-sending ulrik's message. -- bb -------------------- Date: Thu, 17 Jul 1997 12:29:02 +0200 From: Ulrik Vieth To: tex-implementors@MATH.AMS.ORG Subject: TeX History Alert While I was once again reading the Errorlog of TeX I noticed that another important day in TeX's history almost went unnoticed. On July 15, 1982 (excactly 15 years and 2 days ago), Knuth began debugging TeX 82, presumably version -100.0. Time to celebrate! Cheers, Ulrik. P.S. Whoever picked the date for EuroTeX'98 (March 29--31, 1998) apparently also made a good choice. If you look into the Errorlog for March 29, 1978, you'll find that it says: 29 Mar 1978 [...] # After these corrections, the test routine worked\thinspace\dots\ I feel that \TeX\ is now pretty well debugged (except perhaps for error recovery)---it's time to celebrate! Time for a "20 years of TeX 78" party at EuroTeX'98 next year? 3-Sep-1997 6:43:54-GMT,6463;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id AAA11711 for ; Wed, 3 Sep 1997 00:43:48 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 3 Sep 1997 06:43:47 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IN6TRY045S000GRA@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 3 Sep 1997 02:12:07 EST Received: from yarkon.eng.tau.ac.il ([132.66.48.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 03 Sep 1997 06:11:50 +0000 (UT) Date: Wed, 03 Sep 1997 09:11:10 +0300 (IDT) From: Michael Slavutin Subject: Roman Numerals In-reply-to: <199708091724.AA18859@eng.tau.ac.il> To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: slavutin@eng.tau.ac.il Message-id: MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="1921388315-362165037-873267070=:3852" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1921388315-362165037-873267070=:3852 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear TeX community! The current algorithm of converting the numbers into roman ones that is used in TeX and is described in TEX.WEB (\paragraph 69) gives the following results: for gives instead of 1990 mcmxc mxm 1995 mcmxcv mvm 1999 mcmxcix mim Really, I don't know what is right, but I want to propose another algorithm that gives the results on the right column of the above table. It is written in PASCAL and the program called ROMAN.PAS is attached. Sincerely yours, Michael Slavutin, slavutin@eng.tau.ac.il --1921388315-362165037-873267070=:3852 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="roman.pas" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: e1RIRSBGT0xMT1dJTkcgUFJPR1JBTSBDT01QVVRFUyBUSEUgUk9NQU4gTlVN RVJBTCBPRiBBIEdJVkVODQpQT1NJVElWRSBJTlRFR0VSfQ0KDQpQUk9HUkFN IFJPTUFOOw0KICB7RklSU1QgT0YgQUxMIElUIERFQ0xBUkVTIFRIRSBCQVNJ QyBTWU1CT0xTIE9GIFJPTUFOIENPVU5USU5HIEFTICJzeW1ib2wiDQogICBB UlJBWSBPRiBDSEFSQUNURVJTIEFORCBUSEVJUiBOVU1FUklDQUwgRVFVSVZB TEVOVFMgQVMgImNvbnN0YW50Ig0KICAgQVJSQVkgT0YgSU5URUdFUlN9DQog IENPTlNUDQogICAgY29uc3RhbnQgOiBBUlJBWVsxLi43XU9GIElOVEVHRVIg PSAoMSw1LDEwLDUwLDEwMCw1MDAsMTAwMCk7DQogICAgc3ltYm9sICAgOiBB UlJBWVsxLi43XU9GIENIQVIgPSAnaXZ4bGNkbSc7DQogIHtUSEUgVkFSSUFC TEVTIElOIFVTRSBBUkU6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg biBJUyBUSEUgSU5URUdFUiBOVU1CRVIgVE8gQkUgQ09OVkVSVEVEDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgayBJUyBUSEUgSU5ERVggSU5UTyBU SEUgUk9NQU4gQVJSQVlTDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg aiBJUyBBTk9USEVSIElOREVYIElOVE8gVEhFIFJPTUFOIEFSUkFZU30NCiAg VkFSIG46aW50ZWdlcjsNCiAgICAgIGs6aW50ZWdlcjsNCiAgICAgIGo6aW50 ZWdlcjsNCiAgTEFCRUwgMTAsIDIwOw0KQkVHSU4NCiAge1JFQUQgbiBBTkQg U1RBUlQgQlVJTERJTkcgVEhFIFJPTUFOIEVRVUlWQUxFTlQgRlJPTSBUSEUg QkVHSU5OSU5HDQogICAoMTAwMCl9DQogIFJlYWQobik7DQogIGs6PTc7DQog IHtXRSBVU0UgVEhFIEZBQ1QgVEhBVCBUSEUgUk9NQU4gQVJSQVkgSVMgQlVJ TEQgRlJPTSBUSEUgTlVNQkVSUyBUSEFUDQogICBBUkUgT0YgVEhFIEtJTkQg MTBeTCBBTkQgNSoxMF5MIFdIRVJFIEwgSVMgQSBOT04tTkVHQVRJVkUgSU5U RUdFUi4NCiAgIFRIRSBPREQgRU5UUklFUyBBUkUgT0YgVEhFIFRZUEUgMTBe TCwgVEhVUyBUSEVZIENBTiBCRSBSRVBFQVRFRCBJTg0KICAgVEhFIFJPTUFO IE5VTUVSQUx9DQogIDEwOldISUxFICgobj49Y29uc3RhbnRba10pIEFORCBP ZGQoaykpIERPDQogICAgICAgQkVHSU4NCiAgICAgICAgIFdyaXRlKHN5bWJv bFtrXSk7DQogICAgICAgICBuOj1uLWNvbnN0YW50W2tdOw0KICAgICAgIEVO RDsNCiAgICAge05FWFQgV0UgSEFWRSBUTyBDSEVDSyBJRiBuIElTIE5PVCBF WEhBVVNURUQgQUxSRUFEWSAoT1IgSUYgSVQgV0FTDQogICAgICBORUdBVElW RSBJTiBUSEUgRklSU1QgVElNRS4gSUYgSVQgSVMsIFRIRSBDT01QVVRBVElP TiBJUyBURVJNSU5BVEVEfQ0KICAgICBJRiBuPD0wDQogICAgICAgVEhFTiBH T1RPIDIwOw0KICAgICB7VEhFTiBXRSBDSEVDSyBJRiBUSEUgUkVNQUlOREVS IE9GIG4gRklUUyBJTlRPIE9ORSBPRiBUSEUgSU5URVJWQUxTDQogICAgICBP RiBUWVBFIChjb25zdGFudFtrXS1jb25zdGFudFtqXSkuLmNvbnN0YW50W2td IChGT1IgRVhBTVBMRSwgSUYNCiAgICAgIG49OTIxLCBUSEUgRklSQ1QgVEhJ TkcgVE8gRElTUExBWSBJUyAiY20iLiBBRlRFUiBFVkVSWSBTVUNDRVNGVUxM DQogICAgICBDSEVDSyBuIElTIFVQREFURUQgQU5EIFNPIElTIGsgQUNDT1JE SU5HIFRPIFRIRSBSRU1BSU5ERVIgT0Ygbn0NCiAgICAgRk9SIGo6PTEgVE8g ay0xIERPDQogICAgICAgQkVHSU4NCiAgICAgICAgIElGIChuPj0oY29uc3Rh bnRba10tY29uc3RhbnRbal0pKQ0KICAgICAgICAgICBUSEVOIElGIChqPD5r LTEpDQogICAgICAgICAgICAgICAgICB7VEhFIENBU0VTIFNVQ0ggQVMgbj05 MjAgQVJFIFRSRUFURUQgSEVSRSBTSU5DRSBUSElTIElTDQogICAgICAgICAg ICAgICAgICAgImNtLi4uIn0NCiAgICAgICAgICAgICAgICAgIFRIRU4gQkVH SU4NCiAgICAgICAgICAgICAgICAgICAgICAgICBXcml0ZShzeW1ib2xbal0p Ow0KICAgICAgICAgICAgICAgICAgICAgICAgIFdyaXRlKHN5bWJvbFtrXSk7 DQogICAgICAgICAgICAgICAgICAgICAgICAgbjo9bitjb25zdGFudFtqXS1j b25zdGFudFtrXTsNCiAgICAgICAgICAgICAgICAgICAgICAgICBrOj1qLTE7 DQogICAgICAgICAgICAgICAgICAgICAgICAgR09UTyAxMDsNCiAgICAgICAg ICAgICAgICAgICAgICAgRU5EDQogICAgICAgICAgICAgICAgICBFTFNFIElG IE9kZChrKQ0KICAgICAgICAgICAgICAgICAgICAgICAgIHtBTkQgVEhFIENB U0VTIFNVQ0ggQVMgbj01MjAgSEVSRSBTSU5DRSBUSElTIElTDQogICAgICAg ICAgICAgICAgICAgICAgICAgICJkLi4uIn0NCiAgICAgICAgICAgICAgICAg ICAgICAgICBUSEVOIEJFR0lODQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFdyaXRlKHN5bWJvbFtqXSk7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG46PW4tY29uc3RhbnRbal07DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGs6PWotMTsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgR09UTyAxMDsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEVORA0KICAgICAgICAgICAgICAgICAgICAgICAgIHtIT1dF VkVSIElGIG4gSVMgU09NRVRISU5HIExJS0UgNDgxLCBUSEUgU0NSSVBUDQog ICAgICAgICAgICAgICAgICAgICAgICAgICJzeW1ib2xbal0iInN5bWJvbFtr XSIgSVMgUEVSRkVDVExZIFJJR0hUIFNJTkNFDQogICAgICAgICAgICAgICAg ICAgICAgICAgIFRISVMgSVMgImNkLi4uIn0NCiAgICAgICAgICAgICAgICAg ICAgICAgICBFTFNFIEJFR0lODQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFdyaXRlKHN5bWJvbFtqXSk7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFdyaXRlKHN5bWJvbFtrXSk7DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG46PW4rY29uc3RhbnRbal0tY29uc3RhbnRb a107DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGs6PWotMTsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR09UTyAxMDsNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVORDsNCiAgICAgICBFTkQ7 DQogICAgICAgazo9ay0xOw0KICAgICAgIEdPVE8gMTA7DQogICAgICAgMjA6 V3JpdGVsbignJyk7DQpFTkQu --1921388315-362165037-873267070=:3852-- 3-Sep-1997 12:30:17-GMT,1940;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA17770 for ; Wed, 3 Sep 1997 06:30:09 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 3 Sep 1997 12:30:08 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IN769J3GSG000HNZ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 3 Sep 1997 08:08:59 EST Received: from heaton.cl.cam.ac.uk ([128.232.32.11]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 03 Sep 1997 12:08:49 +0000 (UT) Received: from ouse.cl.cam.ac.uk [128.232.33.87] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.70 #1) id 0x6EEg-00045S-00; Wed, 03 Sep 1997 13:08:38 +0100 Date: Wed, 03 Sep 1997 13:08:36 +0100 From: Robin Fairbairns Subject: Re: Roman Numerals In-reply-to: "Your message of Wed, 03 Sep 1997 09:11:10 +0300." To: slavutin@eng.tau.ac.il Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: > The current algorithm of converting the numbers into roman ones > that is used in TeX and is described in TEX.WEB (\paragraph 69) > gives the following results: > for gives instead of > 1990 mcmxc mxm > 1995 mcmxcv mvm > 1999 mcmxcix mim > Really, I don't know what is right, Knuth's original is what's most commonly used. > but I want to propose another algorithm > that gives the results on the right column of the above table. It is > written in > PASCAL and the program called ROMAN.PAS is attached. Since this would give such strange-looking results, I would prefer that it not be used (quite apart from its potential effect on compatibility). Robin Fairbairns Cambridge 3-Sep-1997 12:44:01-GMT,5654;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA18009 for ; Wed, 3 Sep 1997 06:43:53 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 3 Sep 1997 12:43:39 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IN76WE2374000HS2@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 3 Sep 1997 08:27:24 EST Received: from mail2.panix.com ([198.7.0.33]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 03 Sep 1997 12:27:15 +0000 (UT) Received: from [134.74.144.6] ([134.74.144.6]) by mail2.panix.com (8.8.5/8.7.1/PanixM1.0) with SMTP id IAA16365; Wed, 03 Sep 1997 08:26:42 -0400 (EDT) Date: Wed, 03 Sep 1997 08:26:16 -0400 From: Mike Vulis Subject: Re: Roman Numerals X-Sender: mv@panix.com To: slavutin@eng.tau.ac.il Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <2.2.32.19970903122616.008d15a8@panix.com> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 2.2 (32) Content-type: text/plain; charset="us-ascii" I believe that in Roman numerals, one can "subtract" a digit only from a digit of the next higher order. Thus, mxm is incorrect (subtracting 10 from 1000 is jumping 2 orders). Granted, your idea would lead to more compact and readable notation, but it would not be "Roman Numerals" any longer. At 09:11 AM 9/3/97 +0300, you wrote: > > Dear TeX community! > > The current algorithm of converting the numbers into roman ones > that is used in TeX and is described in TEX.WEB (\paragraph 69) > gives the following results: > for gives instead of > 1990 mcmxc mxm > 1995 mcmxcv mvm > 1999 mcmxcix mim > Really, I don't know what is right, but I want to propose another > algorithm > that gives the results on the right column of the above table. It is > written in > PASCAL and the program called ROMAN.PAS is attached. > > Sincerely yours, > Michael Slavutin, > slavutin@eng.tau.ac.il >Content-Type: TEXT/PLAIN; charset=US-ASCII; name="roman.pas" >Content-ID: >Content-Description: > >{THE FOLLOWING PROGRAM COMPUTES THE ROMAN NUMERAL OF A GIVEN >POSITIVE INTEGER} > >PROGRAM ROMAN; > {FIRST OF ALL IT DECLARES THE BASIC SYMBOLS OF ROMAN COUNTING AS "symbol" > ARRAY OF CHARACTERS AND THEIR NUMERICAL EQUIVALENTS AS "constant" > ARRAY OF INTEGERS} > CONST > constant : ARRAY[1..7]OF INTEGER = (1,5,10,50,100,500,1000); > symbol : ARRAY[1..7]OF CHAR = 'ivxlcdm'; > {THE VARIABLES IN USE ARE: > n IS THE INTEGER NUMBER TO BE CONVERTED > k IS THE INDEX INTO THE ROMAN ARRAYS > j IS ANOTHER INDEX INTO THE ROMAN ARRAYS} > VAR n:integer; > k:integer; > j:integer; > LABEL 10, 20; >BEGIN > {READ n AND START BUILDING THE ROMAN EQUIVALENT FROM THE BEGINNING > (1000)} > Read(n); > k:=7; > {WE USE THE FACT THAT THE ROMAN ARRAY IS BUILD FROM THE NUMBERS THAT > ARE OF THE KIND 10^L AND 5*10^L WHERE L IS A NON-NEGATIVE INTEGER. > THE ODD ENTRIES ARE OF THE TYPE 10^L, THUS THEY CAN BE REPEATED IN > THE ROMAN NUMERAL} > 10:WHILE ((n>=constant[k]) AND Odd(k)) DO > BEGIN > Write(symbol[k]); > n:=n-constant[k]; > END; > {NEXT WE HAVE TO CHECK IF n IS NOT EXHAUSTED ALREADY (OR IF IT WAS > NEGATIVE IN THE FIRST TIME. IF IT IS, THE COMPUTATION IS TERMINATED} > IF n<=0 > THEN GOTO 20; > {THEN WE CHECK IF THE REMAINDER OF n FITS INTO ONE OF THE INTERVALS > OF TYPE (constant[k]-constant[j])..constant[k] (FOR EXAMPLE, IF > n=921, THE FIRCT THING TO DISPLAY IS "cm". AFTER EVERY SUCCESFULL > CHECK n IS UPDATED AND SO IS k ACCORDING TO THE REMAINDER OF n} > FOR j:=1 TO k-1 DO > BEGIN > IF (n>=(constant[k]-constant[j])) > THEN IF (j<>k-1) > {THE CASES SUCH AS n=920 ARE TREATED HERE SINCE THIS IS > "cm..."} > THEN BEGIN > Write(symbol[j]); > Write(symbol[k]); > n:=n+constant[j]-constant[k]; > k:=j-1; > GOTO 10; > END > ELSE IF Odd(k) > {AND THE CASES SUCH AS n=520 HERE SINCE THIS IS > "d..."} > THEN BEGIN > Write(symbol[j]); > n:=n-constant[j]; > k:=j-1; > GOTO 10; > END > {HOWEVER IF n IS SOMETHING LIKE 481, THE SCRIPT > "symbol[j]""symbol[k]" IS PERFECTLY RIGHT SINCE > THIS IS "cd..."} > ELSE BEGIN > Write(symbol[j]); > Write(symbol[k]); > n:=n+constant[j]-constant[k]; > k:=j-1; > GOTO 10; > END; > END; > k:=k-1; > GOTO 10; > 20:Writeln(''); >EN ============= Michael Vulis ============= MicroPress, Inc. 68-30 Harrow Street, Forest Hills NY 11375 USA Email: support@micropress-inc.com, sales@micropress-inc.com WEB: http://www.micropress-inc.com TEL: 718 575 1816 FAX: 718 575 8038 ============= 4-Sep-1997 18:46:48-GMT,6488;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA26500 for ; Thu, 4 Sep 1997 12:46:42 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 4 Sep 1997 18:46:41 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IN8XPP0EW0000NBV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 4 Sep 1997 14:26:18 EST Received: from clavin.cs.tamu.edu ([128.194.130.106]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 04 Sep 1997 18:26:08 +0000 (UT) Received: from dilbert.cs.tamu.edu (205@dilbert [128.194.133.100]) by cs.tamu.edu (8.8.7/8.8.7) with ESMTP id NAA29016; Thu, 04 Sep 1997 13:24:42 -0500 (CDT) Received: (from bart@localhost) by dilbert.cs.tamu.edu (8.8.7/8.8.7) id NAA08533; Thu, 04 Sep 1997 13:23:49 -0500 (CDT) Date: Thu, 04 Sep 1997 13:23:49 -0500 (CDT) From: Bart Childs Subject: Re: Roman Numerals To: tex-implementors@MATH.AMS.ORG Cc: support@micropress-inc.com Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199709041823.NAA08533@dilbert.cs.tamu.edu> Don taught a special topics class at Stanford some years ago about the TeX system from a somewhat Software Engineering viewpoint. In one of the classes this topic was discussed at some length. As I remember the result was that Don was aware of several different possibilities and he chose the one that is reflected by the code. It is not totally unlike `center in the US' and `centre in the UK.' I am sure there are hundreds of better comparisons. I think the attitude of most for a possible change would be either no! or why? Regards, Bart Childs > From support@micropress-inc.com Wed Sep 3 07:38:08 1997 Date: Wed, 03 Sep 1997 08:26:16 -0400 From: Mike Vulis Subject: Re: Roman Numerals X-Sender: mv@panix.com To: slavutin@eng.tau.ac.il Cc: tex-implementors@math.ams.org MIME-version: 1.0 I believe that in Roman numerals, one can "subtract" a digit only from a digit of the next higher order. Thus, mxm is incorrect (subtracting 10 from 1000 is jumping 2 orders). Granted, your idea would lead to more compact and readable notation, but it would not be "Roman Numerals" any longer. At 09:11 AM 9/3/97 +0300, you wrote: > > Dear TeX community! > > The current algorithm of converting the numbers into roman ones > that is used in TeX and is described in TEX.WEB (\paragraph 69) > gives the following results: > for gives instead of > 1990 mcmxc mxm > 1995 mcmxcv mvm > 1999 mcmxcix mim > Really, I don't know what is right, but I want to propose another > algorithm > that gives the results on the right column of the above table. It is > written in > PASCAL and the program called ROMAN.PAS is attached. > > Sincerely yours, > Michael Slavutin, > slavutin@eng.tau.ac.il >Content-Type: TEXT/PLAIN; charset=US-ASCII; name="roman.pas" >Content-ID: >Content-Description: > >{THE FOLLOWING PROGRAM COMPUTES THE ROMAN NUMERAL OF A GIVEN >POSITIVE INTEGER} > >PROGRAM ROMAN; > {FIRST OF ALL IT DECLARES THE BASIC SYMBOLS OF ROMAN COUNTING AS "symbol" > ARRAY OF CHARACTERS AND THEIR NUMERICAL EQUIVALENTS AS "constant" > ARRAY OF INTEGERS} > CONST > constant : ARRAY[1..7]OF INTEGER = (1,5,10,50,100,500,1000); > symbol : ARRAY[1..7]OF CHAR = 'ivxlcdm'; > {THE VARIABLES IN USE ARE: > n IS THE INTEGER NUMBER TO BE CONVERTED > k IS THE INDEX INTO THE ROMAN ARRAYS > j IS ANOTHER INDEX INTO THE ROMAN ARRAYS} > VAR n:integer; > k:integer; > j:integer; > LABEL 10, 20; >BEGIN > {READ n AND START BUILDING THE ROMAN EQUIVALENT FROM THE BEGINNING > (1000)} > Read(n); > k:=7; > {WE USE THE FACT THAT THE ROMAN ARRAY IS BUILD FROM THE NUMBERS THAT > ARE OF THE KIND 10^L AND 5*10^L WHERE L IS A NON-NEGATIVE INTEGER. > THE ODD ENTRIES ARE OF THE TYPE 10^L, THUS THEY CAN BE REPEATED IN > THE ROMAN NUMERAL} > 10:WHILE ((n>=constant[k]) AND Odd(k)) DO > BEGIN > Write(symbol[k]); > n:=n-constant[k]; > END; > {NEXT WE HAVE TO CHECK IF n IS NOT EXHAUSTED ALREADY (OR IF IT WAS > NEGATIVE IN THE FIRST TIME. IF IT IS, THE COMPUTATION IS TERMINATED} > IF n<=0 > THEN GOTO 20; > {THEN WE CHECK IF THE REMAINDER OF n FITS INTO ONE OF THE INTERVALS > OF TYPE (constant[k]-constant[j])..constant[k] (FOR EXAMPLE, IF > n=921, THE FIRCT THING TO DISPLAY IS "cm". AFTER EVERY SUCCESFULL > CHECK n IS UPDATED AND SO IS k ACCORDING TO THE REMAINDER OF n} > FOR j:=1 TO k-1 DO > BEGIN > IF (n>=(constant[k]-constant[j])) > THEN IF (j<>k-1) > {THE CASES SUCH AS n=920 ARE TREATED HERE SINCE THIS IS > "cm..."} > THEN BEGIN > Write(symbol[j]); > Write(symbol[k]); > n:=n+constant[j]-constant[k]; > k:=j-1; > GOTO 10; > END > ELSE IF Odd(k) > {AND THE CASES SUCH AS n=520 HERE SINCE THIS IS > "d..."} > THEN BEGIN > Write(symbol[j]); > n:=n-constant[j]; > k:=j-1; > GOTO 10; > END > {HOWEVER IF n IS SOMETHING LIKE 481, THE SCRIPT > "symbol[j]""symbol[k]" IS PERFECTLY RIGHT SINCE > THIS IS "cd..."} > ELSE BEGIN > Write(symbol[j]); > Write(symbol[k]); > n:=n+constant[j]-constant[k]; > k:=j-1; > GOTO 10; > END; > END; > k:=k-1; > GOTO 10; > 20:Writeln(''); >EN ============= Michael Vulis ============= MicroPress, Inc. 68-30 Harrow Street, Forest Hills NY 11375 USA Email: support@micropress-inc.com, sales@micropress-inc.com WEB: http://www.micropress-inc.com TEL: 718 575 1816 FAX: 718 575 8038 ============= 12-Sep-1997 7:06:31-GMT,5918;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA28060 for ; Fri, 12 Sep 1997 01:06:29 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Sep 1997 07:06:27 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01INJFHBZIM80003L5@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 12 Sep 1997 02:42:56 EST Received: from newton.feld.cvut.cz ([147.32.244.10]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 12 Sep 1997 06:42:42 +0000 (UT) Received: from localhost (olsak@localhost) by newton.feld.cvut.cz (8.8.5/8.8.5) with SMTP id IAA06805 for ; Fri, 12 Sep 1997 08:41:20 +0200 Date: Fri, 12 Sep 1997 08:41:20 +0200 (MET DST) From: Petr Olsak Subject: The encTeX extension of TeX X-Sender: olsak@newton.feld.cvut.cz To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: newton.feld.cvut.cz: olsak owned process doing -bs Dear TeX implementors, I deduce from the name of this e-mail list that the implementors of TeX for various operating systems from TeX WEB source are subscribed to this e-mail address. I don't know who is subscribed here explicit but I suppose that there is the right address for my offer here. I have made a little extension of TeX. All changes are done via WEB tex.ch change file, thus they are system independent. The new primitives are introduced. They give the possibility to read and change the xord/xchr reencoding vectors in TeX input preprocessor and to set the "printability" of characters for text output to log, terminal and to \write files. The "printability" means that the character outputs by its xchr[internal] code and not by ^^notation. This problem is solved by TCP tables in emTeX, for example. This solution is system dependent, but my solution is system independent. The encoding tables for xchr/xord vectors are inputted via \input and via appropriate macros during iniTeX in my extension. The settings are stored in the format file. The access to xchr/xord vectors are unconditionally needed in TeX implementation in our country. The Czech language has its alphabet with accented letters which are encoded in eight different encoding "standards" in computers. Four of this encodings are used commonly on DOS and PCs. I think, the similar problems are in another languages too. There were some solution for Czech language so far: The emTeX is widely used in DOS systems. Thus the TCP tables are used here. The web2c TeX is used in UNIX like systems. The ISO8859-2 encoding is defined for our language on these systems. I managed so called "CS-fonts" in Czech TeX implementation (named CSTeX) with a special encodnig (different from T1). This encoding matches with ISO8859-2 on our alphabet. The web2c TeX on UNIX is used with these fonts, thus no reencoding is needed. But this solution is not so universal. Now, the popularity of web2c TeX is adavanced because the 32 bit Operating systems go to the commonly purchased PC's. The problem arises: These systems do not use the ISO8859-2 for our language. The creation of the new font encoding for TeX fonts is bad idea. The TeX fonts are implemented independently on the operating system and differencies between operating systems and TeX font encoding must be solved via xchr/xord. It was the primary Don Knuth's idea, when EBDIC or ASCII seven bit encoding were used and TeX CM fonts were in ASCII only. The TeX implementation, where only identity mapping on codes > 128 are possible, is not usable for our language. The Skarvada's patch for web2c does some reencoding, but the xord/xchr setting is dependent on an environment variable setting and is independent on the format file. I mean, that it is the fragile solution and I prefer, the xord/xchr reencoding is stored in format file. You can look into my package (named encTeX) which introduces three new primitives to xchr/xord/printability setting. This package includes the patch file simply applicable to tex.ch in web2c 7.0 TeX implementation. The changes are independent on web2c and they can be implemented into various others tex.ch files manually. The README.eng file includes the short introduction to the new primitives and my arguments, why the xord/xchr accessing is very important in the TeX program. The pacakge is accesible via anonymous ftp on ftp://math.feld.cvut.cz/pub/olsak/enctex/ The TRIP test reports only two differencies: 1. The banner is changed, 2. The number of multiletter control sequences are geater by three. If you take my work as interesting for your implementation of TeX, please, contact me. We can discuss the details about implementation, documentation, license and so on. The compromisses are possible. For instance, the encTeX extension will be accessible only if the command line option -enc is specified on iniTeX state and this option is stored in the format file. This feauture is not implemented in my package bacause the command line parser is system dependent. If you include the encTeX into your TeX implementation, you can add this feature. It will be very good news for hunderts Czech users of TeX (and for users from other countries may by too), if the xord/xchr accessing will be implemented into widely used web2c TeX, MikTeX and others packages. The second package seems very interesting for Microsoft 32 bit platforms, but without reencoding possibility it is not usable for these users. Petr Olsak Departament of Mathematics, FEL CVUT Prague, Czech Republics http://math.feld.cvut.cz/olsak 16-Sep-1997 2:15:17-GMT,1646;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id UAA07227 for ; Mon, 15 Sep 1997 20:15:15 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 16 Sep 1997 02:15:14 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01INOQL16AZK000PK1@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 15 Sep 1997 21:54:22 EST Received: from zothommog.evcom.net ([208.136.203.8]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 16 Sep 1997 01:54:13 +0000 (UT) Received: (from kinch@localhost) by zothommog.evcom.net (8.8.5/8.6.12) id VAA14698 for tex-implementors@math.ams.org; Mon, 15 Sep 1997 21:54:32 -0400 Date: Mon, 15 Sep 1997 21:54:31 -0400 (EDT) From: "Richard J. Kinch" Subject: Meaningless conditional in tex.web? To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199709160154.VAA14698@zothommog.evcom.net> Content-type: text The following conditional appears in tex.web, sections 174 and 176: if (font(p); Thu, 18 Sep 1997 09:43:36 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 18 Sep 1997 15:43:30 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01INSBFILJW000138H@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 18 Sep 1997 11:24:01 EST Received: from fsnif.neuroinformatik.ruhr-uni-bochum.de ([134.147.176.16]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 18 Sep 1997 15:23:50 +0000 (UT) Received: from maloche.neuroinformatik.ruhr-uni-bochum.de (dak@maloche.neuroinformatik.ruhr-uni-bochum.de [134.147.176.143]) by fsnif.neuroinformatik.ruhr-uni-bochum.de (8.8.7/8.8.7) with SMTP id RAA23200; Thu, 18 Sep 1997 17:23:48 +0200 (MET DST) Received: by maloche.neuroinformatik.ruhr-uni-bochum.de (SMI-8.6/SMI-SVR4) id RAA09518; Thu, 18 Sep 1997 17:23:43 +0200 Date: Thu, 18 Sep 1997 17:23:43 +0200 From: David Kastrup Subject: Re: Meaningless conditional in tex.web? In-reply-to: <199709160154.VAA14698@zothommog.evcom.net> (kinch@holonet.net) To: kinch@holonet.net Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199709181523.RAA09518@maloche.neuroinformatik.ruhr-uni-bochum.de> MIME-version: 1.0 (generated by tm-edit 7.93) Content-type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by fsnif.neuroinformatik.ruhr-uni-bochum.de id RAA23200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by csc-sun.math.utah.edu id JAA20155 Date: Mon, 15 Sep 1997 21:54:31 -0400 (EDT) From: "Richard J. Kinch" The following conditional appears in tex.web, sections 174 and 176: if (font(p) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA02087; Thu, 18 Sep 1997 09:54:06 -0600 (MDT) Date: Thu, 18 Sep 1997 09:54:06 -0600 (MDT) To: David Kastrup Cc: beebe@math.utah.edu, kinch@holonet.net, tex-implementors@MATH.AMS.ORG X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Meaningless conditional in tex.web? In-Reply-To: Your message of Thu, 18 Sep 1997 17:23:43 +0200 Message-ID: >> David Kastrup writes: >> The definition of quarterword is a system dependency (if I'm not >> mistaken), and could well be -128..127 on systems other than the >> canonical Pascal/H system for which tex.web is written. That is correct; see section 110, p. 47, of ``TeX: The Program'', where Don explicitly allowed for both signed and unsigned ranges, via the constants min_quarterword and max_quarterword. The former has 44 references in the index, and the latter, 11. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 University of Utah Internet e-mail: beebe@math.utah.edu Department of Mathematics, 105 JWB URL: http://www.math.utah.edu/~beebe 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090, USA ======================================================================== 18-Sep-1997 17:10:05-GMT,1760;000000000001 Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA22359 for ; Thu, 18 Sep 1997 11:10:00 -0600 (MDT) Received: from shell2.bayarea.net (shell2.bayarea.net [205.219.84.7]) by baygate.bayarea.net (8.8.5/8.8.5) with ESMTP id KAA12132; Thu, 18 Sep 1997 10:12:31 -0700 (PDT) Received: (from quixote@localhost) by shell2.bayarea.net (8.8.5/8.8.5) id KAA11138; Thu, 18 Sep 1997 10:10:55 -0700 (PDT) From: Quixote Digital Typography Message-Id: <199709181710.KAA11138@shell2.bayarea.net> Subject: Re: Meaningless conditional in tex.web? To: beebe@math.utah.edu (Nelson H. F. Beebe) Date: Thu, 18 Sep 1997 10:10:54 -0700 (PDT) Cc: tex-implementors@math.ams.org In-Reply-To: from "Nelson H. F. Beebe" at Sep 18, 97 09:54:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >> David Kastrup writes: > >> The definition of quarterword is a system dependency (if I'm not > >> mistaken), and could well be -128..127 on systems other than the > >> canonical Pascal/H system for which tex.web is written. > That is correct; see section 110, p. 47, of ``TeX: The Program'', > where Don explicitly allowed for both signed and unsigned > ranges, via the constants min_quarterword and max_quarterword. > The former has 44 references in the index, and the latter, 11. Yes, but the constant in question must fall within the quarterword rang and is one of the consistency checks that occurs elsewhere in tex.web I was unable to figure out why that test was there. -dh 18-Sep-1997 17:25:15-GMT,2212;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA22752 for ; Thu, 18 Sep 1997 11:25:14 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 18 Sep 1997 17:25:14 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01INSF4N2WI8000YKC@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 18 Sep 1997 13:09:49 EST Received: from baygate.bayarea.net ([204.71.212.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 18 Sep 1997 17:09:36 +0000 (UT) Received: from shell2.bayarea.net (shell2.bayarea.net [205.219.84.7]) by baygate.bayarea.net (8.8.5/8.8.5) with ESMTP id KAA12132; Thu, 18 Sep 1997 10:12:31 -0700 (PDT) Received: (from quixote@localhost) by shell2.bayarea.net (8.8.5/8.8.5) id KAA11138; Thu, 18 Sep 1997 10:10:55 -0700 (PDT) Date: Thu, 18 Sep 1997 10:10:54 -0700 (PDT) From: Quixote Digital Typography Subject: Re: Meaningless conditional in tex.web? In-reply-to: To: beebe@math.utah.edu (Nelson H. F. Beebe) Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199709181710.KAA11138@shell2.bayarea.net> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL24] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit > >> David Kastrup writes: > >> The definition of quarterword is a system dependency (if I'm not > >> mistaken), and could well be -128..127 on systems other than the > >> canonical Pascal/H system for which tex.web is written. > That is correct; see section 110, p. 47, of ``TeX: The Program'', > where Don explicitly allowed for both signed and unsigned > ranges, via the constants min_quarterword and max_quarterword. > The former has 44 references in the index, and the latter, 11. Yes, but the constant in question must fall within the quarterword rang and is one of the consistency checks that occurs elsewhere in tex.web I was unable to figure out why that test was there. -dh 19-Sep-1997 8:32:09-GMT,1786;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA10643 for ; Fri, 19 Sep 1997 02:32:07 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 19 Sep 1997 08:32:06 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01INTAK8JA4W000XNR@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 19 Sep 1997 04:09:34 EST Received: from hermes.ucd.ie ([137.43.1.49]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 19 Sep 1997 08:09:24 +0000 (UT) Received: from maths.ucd.ie by hermes.ucd.ie (PMDF V5.1-8 #16181) with SMTP id <0EGQ00G9IXBLQR@hermes.ucd.ie> for tex-implementors@MATH.AMS.ORG; Fri, 19 Sep 1997 09:09:21 +0100 (BST) Received: by maths.ucd.ie (16.8/0.0) id AA05344; Fri, 19 Sep 1997 09:03:15 +0100 Date: Fri, 19 Sep 1997 09:03:14 +0100 (BST) From: wgs@maths.ucd.ie (Wayne G. Sullivan) Subject: Re: Meaningless conditional in tex.web? To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <9709190803.AA05344@maths.ucd.ie> Mailer: Elm [revision: 70.30] The two procedures, short_display and print_font_and_char, in which the check "(font(p)font_max)" belong to TeX's diagnostic routines. If some fundamental error has arisen, e.g., a format file has become corrupted, then font(p) might be beyond the range in the equivalence table which corresponds to fonts. Note that the test "p>mem_end" in print_font_and_char should never be satisfied when TeX is running correctly. Incidently, font_max in texk7.0/web2c/tex.ch is 2000, and the checks for font(p); Sun, 21 Sep 1997 01:39:50 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 21 Sep 1997 07:39:49 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01INW0S83GI8001HF5@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 21 Sep 1997 03:02:08 EST Received: from shum.cc.huji.ac.il ([132.64.1.3]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 21 Sep 1997 07:01:54 +0000 (UT) Received: from localhost (rama@localhost) by shum.cc.huji.ac.il (8.8.6/8.6.10) with SMTP id JAA05333 for ; Sun, 21 Sep 1997 09:01:51 +0200 (GMT+0200) Date: Sun, 21 Sep 1997 09:01:51 +0200 (GMT+0200) From: rama porrat Subject: Right-to-left TeX and LaTeX. In-reply-to: <199709181523.RAA09518@maloche.neuroinformatik.ruhr-uni-bochum.de> To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: shum.cc.huji.ac.il: rama owned process doing -bs Dear TeX implementor! Please allow me once again to draw you attention to right-to-left tex's (tex--xet's) poor condition, and ask for your advice re latex. TeX for unix: We work with an edited version of tex.web, having an accompnying suitable change file. It has been prepared by Uri Feldman of Israel. It works ok, only can't be upgraded to the next tex's version. I understand that a beta version of teTeX, which includes etex (and hence, tex--xet) is available. This will, I hope, replace our non official version. TeX for PC: There exists Peter Breitenlohner's tex--xet, included in etex. It works well, but it is a 16 bit program. So even in DOS we have difficulties when the input tex file is not small enough. LaTeX for all systems: We don't have a hebrew.sty for latex2e - we still work with latex209. A long time ago I have started to write a hebrew.sty suitable for latex2e, but I have stopped when I realized that this means editing numerous *cls and *sty files, editing which will have to be redone twice a year. Also, I do not have the knowledge of latex which is required in order to do that thing well. However, again I realize it has to be done now for the sake of latex users which need documents in right-to-left typesetting, and I see that an official right-to-left latex will not be available in the near future. I assume that if I am going to do all that editing, I have to look for all occurences or ...right.../..left... and supply the ...left.../...right.... equivalence. Is that right? Will that be sufficient? Can you give me some guidance in this work? I have already created a hebrew.sty with Babel's parameters (it might have to be reedited, as Babel had probably changed since I have done it, about 2 years ago), but this is just the beginning. Thanks! Rama. rama@cc.huji.ac.il The Hebrew University of Jerusalem. 22-Sep-1997 13:01:03-GMT,2076;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA00365 for ; Mon, 22 Sep 1997 07:01:02 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 22 Sep 1997 13:01:01 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01INXQU91K6O001BSZ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 22 Sep 1997 08:38:58 EST Received: from pillar.elsevier.co.uk ([193.131.222.35]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 22 Sep 1997 12:38:47 +0000 (UT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id NAA00174 for ; Mon, 22 Sep 1997 13:38:10 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Mon, 22 Sep 1997 13:38:06 +0100 Date: Mon, 22 Sep 1997 13:24:22 +0100 From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Subject: Re: Right-to-left TeX and LaTeX. In-reply-to: To: rama@cc.huji.ac.il Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <9249-Mon22Sep1997132422+0100-s.rahtz@elsevier.co.uk> MIME-version: 1.0 X-Mailer: VM 6.33 under Emacs 19.34.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199709181523.RAA09518@maloche.neuroinformatik.ruhr-uni-bochum.de> I dont understand the comment about the `poor conditon' of tex--xet. Do you mean the lack of TeX implementations that include it? or that its internally inadequate? as for LaTeX, thats a matter to take up with the LaTeX people, not tex implementors, isn't it? obviously, i challenge the assumption that you have to update your .cls file twice a year - it simply isnt true! sebastian 24-Sep-1997 14:01:11-GMT,2899;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA29341 for ; Wed, 24 Sep 1997 03:02:01 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1997 09:02:00 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO0ALLET1S001U6R@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 24 Sep 1997 04:26:17 EST Received: from shum.cc.huji.ac.il ([132.64.1.3]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 24 Sep 1997 08:26:04 +0000 (UT) Received: from localhost (rama@localhost) by shum.cc.huji.ac.il (8.8.6/8.6.10) with SMTP id KAA24416; Wed, 24 Sep 1997 10:24:41 +0200 (GMT+0200) Date: Wed, 24 Sep 1997 10:24:41 +0200 (GMT+0200) From: rama porrat Subject: Re: Right-to-left TeX and LaTeX. In-reply-to: <9249-Mon22Sep1997132422+0100-s.rahtz@elsevier.co.uk> To: Sebastian Rahtz Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: rama porrat Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: shum.cc.huji.ac.il: rama owned process doing -bs > I dont understand the comment about the `poor conditon' of tex--xet. > Do you mean the lack of TeX implementations that include it? or that > its internally inadequate? I'm sorry I used the wrong words. The program's condition is ok, and certainly internally inadequate. It is the user's condition which is not ok. If he works with tex--xet on his pc, he cannot include Gnuplot's graphs, because there will probably not be enough memory for more then one or two graphs. (As I have mentioned in my previous mail, I hope e-tex for unix will replace the current frozen tex--xet version used.) If the user uses Hebrew latex with tex--xet, he cannot write an article without having to ask for correction of numerous small problems. And he cannot use latex2e. This, I think, means that a user is not ok. The user does not have a 100% reliable program if he wants to write a Hebrew latex document. > as for LaTeX, thats a matter to take up with the LaTeX people, not tex > implementors, isn't it? Yes. I thought all implementors, including the persons in the latex3 project, are subscribed to this list. > obviously, i challenge the assumption that you > have to update your .cls file twice a year - it simply isnt true! I guess you mean that not many changes are maded every half year. But nevertheless, if one wants to be careful, one has to go over all the files twice a year and see if things have changed somewhere. Otherwise, why is there a new version of latex2e twice a year? Bye -- Rama. 24-Sep-1997 14:01:20-GMT,2989;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA01999 for ; Wed, 24 Sep 1997 03:43:31 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1997 09:43:31 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO0C3QUV9S001ZXI@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 24 Sep 1997 05:09:05 EST Received: from pillar.elsevier.co.uk ([193.131.222.35]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 24 Sep 1997 09:08:56 +0000 (UT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA14986 for ; Wed, 24 Sep 1997 10:08:05 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Wed, 24 Sep 1997 10:08:06 +0100 Date: Wed, 24 Sep 1997 10:04:40 +0100 From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Subject: Re: Right-to-left TeX and LaTeX. In-reply-to: To: rama@cc.huji.ac.il Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <8157-Wed24Sep1997100440+0100-s.rahtz@elsevier.co.uk> MIME-version: 1.0 X-Mailer: VM 6.33 under Emacs 19.34.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <9249-Mon22Sep1997132422+0100-s.rahtz@elsevier.co.uk> rama porrat writes: > If he works with tex--xet on his pc, he cannot include Gnuplot's > graphs, because there will probably not be enough memory for more > then one or two graphs. good gracious, you are descending to a *very* specific level here. How ever do I know how you include gnuplot graphs??????? thats your problem..... > The user does not have a 100% reliable program if he wants > to write a Hebrew latex document. it sounds like you want to use eTeX, and build a LaTeX 209 format file until someone fixes hebrew.sty for 2e. > Yes. I thought all implementors, including the persons in the latex3 > project, are subscribed to this list. no, just people who implement TeX or are interested in the subject. perhaps the word `implement' is confusing - this list is simply those people who have the problem of compiling a running TeX from tex.web > But nevertheless, if one wants to be careful, one has to go over all > the files twice a year and see if things have changed somewhere. > Otherwise, why is there a new version of latex2e twice a year? if you choose to use undocumented LaTeX internals in your style file, yes, you will have to check it twice a year. Moral - dont use undocumented internals... The LaTeX people dont change the meaning of the `official' commands Sebastian 24-Sep-1997 17:03:25-GMT,4375;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA05721 for ; Wed, 24 Sep 1997 11:03:23 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1997 17:03:19 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO0KJNAEMO001ZD8@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 24 Sep 1997 09:11:02 EST Received: from fsnif.neuroinformatik.ruhr-uni-bochum.de ([134.147.176.16]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 24 Sep 1997 13:10:48 +0000 (UT) Received: from maloche.neuroinformatik.ruhr-uni-bochum.de (dak@maloche.neuroinformatik.ruhr-uni-bochum.de [134.147.176.143]) by fsnif.neuroinformatik.ruhr-uni-bochum.de (8.8.7/8.8.7) with SMTP id PAA26745; Wed, 24 Sep 1997 15:08:53 +0200 (MET DST) Received: by maloche.neuroinformatik.ruhr-uni-bochum.de (SMI-8.6/SMI-SVR4) id PAA03700; Wed, 24 Sep 1997 15:08:48 +0200 Date: Wed, 24 Sep 1997 15:08:48 +0200 From: David Kastrup Subject: Re: Right-to-left TeX and LaTeX. In-reply-to: (message from rama porrat on Wed, 24 Sep 1997 10:24:41 +0200 (GMT+0200)) To: rama@cc.huji.ac.il Cc: s.rahtz@elsevier.co.uk, tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199709241308.PAA03700@maloche.neuroinformatik.ruhr-uni-bochum.de> MIME-version: 1.0 (generated by tm-edit 7.93) Content-type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by fsnif.neuroinformatik.ruhr-uni-bochum.de id PAA26745 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by csc-sun.math.utah.edu id LAA05721 Date: Wed, 24 Sep 1997 10:24:41 +0200 (GMT+0200) From: rama porrat > I dont understand the comment about the `poor conditon' of tex--xet. > Do you mean the lack of TeX implementations that include it? or that > its internally inadequate? I'm sorry I used the wrong words. The program's condition is ok, and certainly internally inadequate. ^^^^^^^^^^ You sure that's what you wanted to write? It is the user's condition which is not ok. If he works with tex--xet on his pc, he cannot include Gnuplot's graphs, because there will probably not be enough memory for more then one or two graphs. (As I have mentioned in my previous mail, I hope e-tex for unix will replace the current frozen tex--xet version used.) I guess you misunderstand what TeX--XeT is: it is a set of changefiles used when compiling a version of TeX. This set includes absolutely no information about the internal sizes of the resulting binary. So it seems that you have a version of TeX using TeX--XeT which has been compiled with small internal sizes. That's not the problem of the TeX--XeT patches, but of the person who prepared your binaries. > as for LaTeX, thats a matter to take up with the LaTeX people, not tex > implementors, isn't it? Yes. I thought all implementors, including the persons in the latex3 project, are subscribed to this list. It might have helped checking the list's charter before posting to it. The TeX implementor list is only concerned with TeX binaries, mainly with their bugs. The LaTeX people have their own forums. > obviously, i challenge the assumption that you > have to update your .cls file twice a year - it simply isnt true! I guess you mean that not many changes are maded every half year. But nevertheless, if one wants to be careful, one has to go over all the files twice a year and see if things have changed somewhere. Otherwise, why is there a new version of latex2e twice a year? Internals change and bugs are removed. The interfaces should mostly remain. What you might be thinking of is doing changes immediately in the LaTeX classes, which is neither prudent nor allowed according to the licence. David Kastrup Phone: +49-234-700-5570 Email: dak@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209 Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany 24-Sep-1997 19:27:47-GMT,2707;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA09253 for ; Wed, 24 Sep 1997 13:27:45 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1997 19:27:40 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO0X78V2680020A5@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 24 Sep 1997 15:13:35 EST Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 24 Sep 1997 19:13:26 +0000 (UT) Date: Wed, 24 Sep 1997 20:13:25 +0100 From: Philip Taylor (RHBNC) Subject: TeX--XeT To: TEX-IMPLEMENTORS@MATH.AMS.ORG Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <970924201325.10a60@vms.rhbnc.ac.uk> >> I guess you misunderstand what TeX--XeT is: it is a set of >> changefiles used when compiling a version of TeX. This set includes >> absolutely no information about the internal sizes of the resulting >> binary. So it seems that you have a version of TeX using TeX--XeT >> which has been compiled with small internal sizes. That's not the >> problem of the TeX--XeT patches, but of the person who prepared your >> binaries. But in Rama's case, the two are the same: Peter Breitenlohner; Peter is both the implementor of TeX--XeT and of PubliC (e-)TeX. Note that there is nothing _wrong_ with Peter's implementation of either: PubliC (e-)TeX is quite intentionally a Small Program which will run on a Small PC... Sebastian advises me that the Web2C/Win32 system _does_ include e-TeX, and if Rama can get that to run on his system, it should be quite large enough to deal with his documents (we hope!). >> It might have helped checking the list's charter before posting to >> it. The TeX implementor list is only concerned with TeX binaries, >> mainly with their bugs. The LaTeX people have their own forums. It might help if TeX-Implementors were not so dismissive of real users as the three lines above suggest: OK, perhaps this is the wrong forum in which to raise LaTeX-specific issues, but if we (TeX-Implementors) dismiss LaTeX queries in such a cavalier fashion, we can hardly complain when Rama and other TeX users with genuine problems decide to migrate to non-TeX-based systems on which they get more helpful responses. ** Phil (who wants to see TeX continue into the 21st Century, and who would therefore like to encourage an ethos in which users such as Rama get help rather than flak...). 25-Sep-1997 6:50:15-GMT,1781;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id AAA23319 for ; Thu, 25 Sep 1997 00:50:13 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Sep 1997 06:50:12 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO1KO7PZG0001ZFR@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 25 Sep 1997 02:25:32 EST Received: from shum.cc.huji.ac.il ([132.64.1.3]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 25 Sep 1997 06:25:17 +0000 (UT) Received: from localhost (rama@localhost) by shum.cc.huji.ac.il (8.8.6/8.6.10) with SMTP id IAA29243; Thu, 25 Sep 1997 08:23:50 +0200 (GMT+0200) Date: Thu, 25 Sep 1997 08:23:50 +0200 (GMT+0200) From: rama porrat Subject: Sorry .... In-reply-to: <199709241308.PAA03700@maloche.neuroinformatik.ruhr-uni-bochum.de> To: David Kastrup Cc: s.rahtz@elsevier.co.uk, tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: shum.cc.huji.ac.il: rama owned process doing -bs Sorry! Of course I meant > I'm sorry I used the wrong words. The program's condition is ok, > and certainly internally MOST adequate. ~~~~~~~~ Thanks to David Kastrup for pointing this to me, and I really think the latex3 group is doing a great job. All I am saying is, it would be nice if latex could be officially made to typeset from right-to-left. Rama. 25-Sep-1997 7:12:35-GMT,2392;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA23714 for ; Thu, 25 Sep 1997 01:12:33 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Sep 1997 07:12:32 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO1LE8OYG0001L8U@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 25 Sep 1997 02:46:40 EST Received: from shum.cc.huji.ac.il ([132.64.1.3]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 25 Sep 1997 06:46:16 +0000 (UT) Received: from localhost (rama@localhost) by shum.cc.huji.ac.il (8.8.6/8.6.10) with SMTP id IAA29429; Thu, 25 Sep 1997 08:46:07 +0200 (GMT+0200) Date: Thu, 25 Sep 1997 08:46:07 +0200 (GMT+0200) From: rama porrat Subject: Re: Right-to-left TeX and LaTeX. In-reply-to: <199709241308.PAA03700@maloche.neuroinformatik.ruhr-uni-bochum.de> To: David Kastrup Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: rama porrat Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: shum.cc.huji.ac.il: rama owned process doing -bs > What you might be thinking of is doing changes immediately in > the LaTeX classes, which is neither prudent nor allowed according to > the licence. If this is so, there is no chance of us having a possibility of writing Hebrew latex articles. Take a small example: In article.cls you have \renewcommand\thesubsection {\thesection.\@arabic\c@subsection} In a right-to-left document, the order should be reversed; that is, something similar to \renewcommand\thesubsection {\@arabic\c@subsection.\thesection} This is because, as the direction of typesetting is not part of the code, ALL the line is simply outputted backwards, so numbers come out reversed. Another example from article.cls -- \newenvironment{quote} {\list{}{\rightmargin\leftmargin}% ..... This should become {\list{}{\leftmargin\rightmargin}% ..... How is this to be solved without changing article.cls? And the class files are FULL of those things. Rama. 25-Sep-1997 10:01:11-GMT,3292;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA26576 for ; Thu, 25 Sep 1997 04:01:09 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Sep 1997 10:01:08 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO1QYUA440001UZ8@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 25 Sep 1997 05:25:49 EST Received: from pillar.elsevier.co.uk ([193.131.222.35]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 25 Sep 1997 09:25:39 +0000 (UT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA21619 for ; Thu, 25 Sep 1997 10:24:58 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Thu, 25 Sep 1997 10:24:53 +0100 Date: Thu, 25 Sep 1997 09:40:00 +0100 From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Subject: Re: TeX--XeT In-reply-to: <970924201325.10a60@vms.rhbnc.ac.uk> To: P.Taylor@vms.rhbnc.ac.uk Cc: TEX-IMPLEMENTORS@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <3302-Thu25Sep1997094000+0100-s.rahtz@elsevier.co.uk> MIME-version: 1.0 X-Mailer: VM 6.33 under Emacs 19.34.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <970924201325.10a60@vms.rhbnc.ac.uk> Philip Taylor (RHBNC) writes: > Sebastian advises me that the Web2C/Win32 system _does_ include e-TeX, > and if Rama can get that to run on his system, it should be quite > large enough to deal with his documents (we hope!). users of web2c 7.0 can, of course, change memory allocation in the run-time texmf.cnf file, so Rama is going to have to work much harder to run out of memory > ** Phil (who wants to see TeX continue into the 21st Century, and who > would therefore like to encourage an ethos in which users such > as Rama get help rather than flak...). This is silly. If any query goes to any list, madness ensues. In this case, Rama was misled by the title `tex-implementors', I think, but usually the purpose of mailing lists is pretty clear, and its perfectly reasonable to expect people to stick to those purposes. Whether the words were harsh or not, I think in fact Rama got the required answers, and indeed the LaTeX issues raised about hebrew (and czech, privately) were passed to the LaTeX team. I fail to see, actually, the relationship between the longevity of TeX and the helpfulness or otherwise of tex-implementors list.... I would peraps suggest the longevity of TeX is determined by factors outside TeX. That is to say, it will survive until someone makes something better. Possibly that something better will come from inside the TeX world, but lets be honest, there are not many signs of it. I discount things like e-TeX, which are just tidying up the edges, and probably Omega too unless it has a fairly radical change of heart. We'll have to see what NTS produces, won't we? Lets hope something more than the stated aim of `reimplementing TeX in Lisp'.... Sebastian 25-Sep-1997 10:10:39-GMT,2634;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA26748 for ; Thu, 25 Sep 1997 04:10:38 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Sep 1997 10:10:37 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IO1R2KS0R40020II@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 25 Sep 1997 05:28:49 EST Received: from pillar.elsevier.co.uk ([193.131.222.35]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 25 Sep 1997 09:28:40 +0000 (UT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA21768 for ; Thu, 25 Sep 1997 10:27:59 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Thu, 25 Sep 1997 10:27:58 +0100 Date: Thu, 25 Sep 1997 09:57:42 +0100 From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Subject: Re: Right-to-left TeX and LaTeX. In-reply-to: To: rama@cc.huji.ac.il Cc: dak@neuroinformatik.ruhr-uni-bochum.de, tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <6711-Thu25Sep1997095742+0100-s.rahtz@elsevier.co.uk> MIME-version: 1.0 X-Mailer: VM 6.33 under Emacs 19.34.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199709241308.PAA03700@maloche.neuroinformatik.ruhr-uni-bochum.de> > In a right-to-left document, the order should be reversed; > that is, something similar to > \renewcommand\thesubsection {\@arabic\c@subsection.\thesection} I don't really see the issue. create a `hebart.cls' which loads article.cls, and then redefine what you need. > How is this to be solved without changing article.cls? > And the class files are FULL of those things. > write your own classes? or do you mean you want \documentclass{article} to produce proper results in Hebrew? how do you indicate you are going to use Hebrew? with a \usepackage{hebrew}? but i concede you have a point, it might be nicer if the standard classes exposed more hooks for people like you. But: Sebastian's Prediction: latex2e standard classes will not be changed for Hebrew. I think you should a) write some decent classes of your own b) lobby for LaTeX3 to give you more hooks sebastian 5-Jan-1998 18:00:46-GMT,1651;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA20583 for ; Mon, 5 Jan 1998 11:00:43 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 5 Jan 1998 18:00:42 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IS0NBZB3YO0007NP@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 5 Jan 1998 12:25:13 EST Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 05 Jan 1998 17:24:59 +0000 (UT) Date: Mon, 05 Jan 1998 17:24:58 +0000 (GMT) From: Philip Taylor (RHBNC) Subject: Initex: \begingroup \dump To: TEX-IMPLEMENTORS@MATH.AMS.ORG Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <980105172458.9c4f@vms.rhbnc.ac.uk> Dear Colleagues -- whilst doing some work on the e-TeX format source over Christmas, I noticed the following oddity: Initex \relax \begingroup \dump reports This is TeX, Version 3.14159 [PD VMS 3.6] (INITEX) 5 JAN 1998 17:20 *\relax \begingroup \dump (\end occurred inside a group at level 1) ! You can't dump inside a group. <*> \begingroup \dump `{...\dump}' is a no-no. No pages of output. Everything is fine except for the diagnostic (\end occurred inside a group at level 1); surely this should read (\dump occurred inside a group at level 1)? ** Phil. 5-Jan-1998 22:51:34-GMT,2101;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id PAA27833 for ; Mon, 5 Jan 1998 15:51:33 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 5 Jan 1998 22:51:32 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IS0Y7TYAAO000A03@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 5 Jan 1998 17:36:23 EST Received: from kralle.zdv.Uni-Mainz.DE ([134.93.8.158]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 05 Jan 1998 22:36:13 +0000 (UT) Received: (from Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.8.8/8.8.8) id XAA03903; Mon, 05 Jan 1998 23:36:11 +0100 (MET) Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id WAA23204; Mon, 05 Jan 1998 22:43:48 +0100 Date: Mon, 05 Jan 1998 22:43:48 +0100 From: Frank Mittelbach Subject: Re: Initex: \begingroup \dump In-reply-to: <980105172458.9c4f@vms.rhbnc.ac.uk> To: P.Taylor@vms.rhbnc.ac.uk Cc: TEX-IMPLEMENTORS@MATH.AMS.ORG, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199801052143.WAA23204@frank.zdv.uni-mainz.de> References: <980105172458.9c4f@vms.rhbnc.ac.uk> X-Authentication-warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to latex3 using -f Philip writes: > Dear Colleagues -- whilst doing some work on the e-TeX format source > over Christmas, I noticed the following oddity: you should not work on something like this over Xmas :-) > Everything is fine except for the diagnostic (\end occurred inside a group > at level 1); surely this should read (\dump occurred inside a group at > level 1)? i think i remember a comment about this by Don which showed that he is aware of that but is not going to fix it. can't remember where i've seen it. perhaps in a fix to \aftergroup\relax on top-level? (this is the one that got me my first check: back then you could never \dump after this) happy new year frank 6-Feb-1998 19:30:23-GMT,1485;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA04844 for ; Fri, 6 Feb 1998 12:30:21 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 6 Feb 1998 19:30:11 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IT9G4X4KJK000852@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 6 Feb 1998 14:04:33 EST Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 06 Feb 1998 19:04:07 +0000 (UT) Date: Fri, 06 Feb 1998 19:04:06 +0000 (GMT) From: Philip Taylor (RHBNC) Subject: National variants of TeX To: TEX-IMPLEMENTORS@MATH.AMS.ORG Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <980206190406.2b6a0@vms.rhbnc.ac.uk> [Forwarded from Marion Neubauer, on behalf of DANTE e.V.] >> Dear Phil, >> >> maybe the following has been said before, maybe it's foolish ... >> A member of DANTE ask some times ago whether it is possible to translate >> the error messages of TeX to different languages. >> >> His assumption was, that only tex.pool has to be translated and >> everything's fine. >> >> If the question has been discussed before, just throw away this message. What is the received wisdom on this? ** Phil. 6-Feb-1998 19:42:55-GMT,3706;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA05153 for ; Fri, 6 Feb 1998 12:42:53 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 6 Feb 1998 19:42:52 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IT9H2CKIC0000CAQ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 6 Feb 1998 14:31:19 EST Received: from smtp2.xs4all.nl ([194.109.6.52]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 06 Feb 1998 19:31:04 +0000 (UT) Received: from infovore (root@dne01-20.dial.xs4all.nl [194.109.35.21]) by smtp2.xs4all.nl (8.8.8/8.8.8) with ESMTP id UAA08984 for ; Fri, 06 Feb 1998 20:31:00 +0100 (CET) Received: by infovore id m0y0tUa-000cz8C (Debian Smail-3.2 1996-Jul-4 #2); Fri, 06 Feb 1998 20:31:16 +0100 (CET) Date: Fri, 06 Feb 1998 20:31:16 +0100 From: Olaf Weber Subject: Re: National variants of TeX In-reply-to: Philip Taylor's message of "Fri, 06 Feb 1998 19:04:06 +0000 (GMT)" To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <87pvl07cor.fsf@xs4all.nl> MIME-version: 1.0 (generated by tm-edit 7.105) X-Mailer: Gnus v5.4.66/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Lines: 52 References: <980206190406.2b6a0@vms.rhbnc.ac.uk> Philip Taylor writes: > [Forwarded from Marion Neubauer, on behalf of DANTE e.V.] >>> Dear Phil, >>> >>> maybe the following has been said before, maybe it's foolish ... >>> A member of DANTE ask some times ago whether it is possible to translate >>> the error messages of TeX to different languages. >>> >>> His assumption was, that only tex.pool has to be translated and >>> everything's fine. >>> >>> If the question has been discussed before, just throw away this message. > What is the received wisdom on this? > ** Phil. Translating the pool would do a 90% job: there are some messages in tex.web that do not use the string pool mechanism. A list follows below. For Web2C an additional difficulty would be to get messages used in the C part into the string pool as well -- I do not know the extent to which this would be a problem for other implementations. infovore:/home/olaf/web2c/src/texk/web2c$ grep "('.*')" tex.web else bad_pool('! I can''t read TEX.POOL.') begin if eof(pool_file) then bad_pool('! TEX.POOL has no check sum.'); bad_pool('! TEX.POOL line doesn''t begin with two digits.'); bad_pool('! You have to increase POOLSIZE.'); bad_pool('! TEX.POOL check sum doesn''t have nine digits.'); done: if a<>@$ then bad_pool('! TEX.POOL doesn''t match; TANGLE me again.'); if format_ident=0 then wterm_ln(' (no format preloaded)') wterm_ln('Sorry, I can''t find that format;',' will try PLAIN.'); wterm_ln('I can''t find the PLAIN format file!'); wterm_ln('(Fatal format file error; I''m stymied)'); undump_size(0)(pool_size)('string pool size')(pool_ptr); undump_size(0)(max_strings)('max strings')(str_ptr); undump_size(7)(font_mem_size)('font mem size')(fmem_ptr); undump_size(font_base)(font_max)('font max')(font_ptr); undump_size(0)(trie_size)('trie size')(j); @+init trie_max:=j;@+tini undump_size(0)(trie_op_size)('trie op size')(j); @+init trie_op_ptr:=j;@+tini begin wlog_ln(' '); wlog_ln('Here is how much of TeX''s memory',' you used:'); wlog(' ',str_ptr-init_str_ptr:1,' string'); if str_ptr<>init_str_ptr+1 then wlog('s'); if font_ptr<>font_base+1 then wlog('s'); wlog(' ',hyph_count:1,' hyphenation exception'); if hyph_count<>1 then wlog('s'); -- Olaf Weber 7-Feb-1998 15:32:58-GMT,2522;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA00847 for ; Sat, 7 Feb 1998 08:32:56 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 7 Feb 1998 15:32:51 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITAMF87PSG000BN8@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 7 Feb 1998 10:15:13 EST Received: from kralle.zdv.Uni-Mainz.DE ([134.93.8.158]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sat, 07 Feb 1998 15:15:01 +0000 (UT) Received: (from Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.8.8/8.8.8) id QAA19222 for tex-implementors@MATH.AMS.ORG; Sat, 07 Feb 1998 16:15:00 +0100 (MET) Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id LAA09892; Sat, 07 Feb 1998 11:21:25 +0100 Date: Sat, 07 Feb 1998 11:21:25 +0100 From: Frank Mittelbach Subject: Re: National variants of TeX In-reply-to: <87pvl07cor.fsf@xs4all.nl> To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199802071021.LAA09892@frank.zdv.uni-mainz.de> References: <980206190406.2b6a0@vms.rhbnc.ac.uk> <87pvl07cor.fsf@xs4all.nl> X-Authentication-warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to latex3 using -f Olaf Weber writes: > Philip Taylor writes: > > [Forwarded from Marion Neubauer, on behalf of DANTE e.V.] > > >>> Dear Phil, > >>> > >>> maybe the following has been said before, maybe it's foolish ... > >>> A member of DANTE ask some times ago whether it is possible to translate > >>> the error messages of TeX to different languages. > >>> > >>> His assumption was, that only tex.pool has to be translated and > >>> everything's fine. > >>> > >>> If the question has been discussed before, just throw away this message. > > > What is the received wisdom on this? > > ** Phil. > > Translating the pool would do a 90% job: there are some messages in > tex.web that do not use the string pool mechanism. A list follows > below. i don't think this figure is right; the problem is that many of the help messages are divided into little bits which are sometimes reused several times. For that reasons a translation even of just the standard messages (not those that are hardwired into the program) would be very difficult if not impossible to do in a sensible way. frank 8-Feb-1998 9:38:46-GMT,2393;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA23584 for ; Sun, 8 Feb 1998 02:38:43 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 8 Feb 1998 09:38:42 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITBOADKE6O000HP3@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 8 Feb 1998 04:19:42 EST Received: from smtp2.xs4all.nl ([194.109.6.52]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 08 Feb 1998 09:19:10 +0000 (UT) Received: from infovore (root@dtc01-02.dial.xs4all.nl [194.109.54.3]) by smtp2.xs4all.nl (8.8.8/8.8.8) with ESMTP id JAA19157 for ; Sun, 08 Feb 1998 09:42:40 +0100 (CET) Received: by infovore id m0y1EYO-000d0hC (Debian Smail-3.2 1996-Jul-4 #2); Sat, 07 Feb 1998 19:00:36 +0100 (CET) Date: Sat, 07 Feb 1998 19:00:33 +0100 From: Olaf Weber Subject: Re: National variants of TeX In-reply-to: Frank Mittelbach's message of "Sat, 07 Feb 1998 11:21:25 +0100" To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <87g1lvpa66.fsf@xs4all.nl> MIME-version: 1.0 (generated by tm-edit 7.105) X-Mailer: Gnus v5.4.66/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Lines: 24 References: <980206190406.2b6a0@vms.rhbnc.ac.uk> <87pvl07cor.fsf@xs4all.nl> <199802071021.LAA09892@frank.zdv.uni-mainz.de> Frank Mittelbach writes: > Olaf Weber writes: >> Translating the pool would do a 90% job: there are some messages in >> tex.web that do not use the string pool mechanism. A list follows >> below. > i don't think this figure is right; It's an off-the-cuff estimate. > the problem is that many of the help messages are divided into > little bits which are sometimes reused several times. For that > reasons a translation even of just the standard messages (not those > that are hardwired into the program) would be very difficult if not > impossible to do in a sensible way. In that case you'd have to rewrite the reporting routines to use "complete" messages which are translatable. It just goes to show that internationalization is hard to retrofit to an existing program. The NTS people had better sit up and take notice. -- Olaf Weber 9-Feb-1998 19:37:02-GMT,3251;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA09503 for ; Mon, 9 Feb 1998 12:36:56 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 9 Feb 1998 19:36:55 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITDMSLIV74000OU0@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 9 Feb 1998 13:58:28 EST Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 09 Feb 1998 18:58:16 +0000 (UT) Date: Mon, 09 Feb 1998 18:58:09 +0000 (GMT) From: Philip Taylor (RHBNC) Subject: DEK's ruling on the name and contents of "hyphen.tex" To: TEX-IMPLEMENTORS@MATH.AMS.ORG Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@MATH.AMS.ORG Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <980209185809.44181@vms.rhbnc.ac.uk> Dear Colleagues -- Some of you will be aware that there has been a debate concerning the validity or otherwise of creating a file called "hyphen.tex" which contains other than Knuth's canonical contents for that file. The problem was noticed when the "etex.src" wrapper file refused to process a file called "hyphen.tex" when that file contained (indirectly or otherwise) a reference to "ghyph31.tex", which in turn contained catcode changes as well as German patterns and exceptions. The problem was referred to Don for adjudication, and attached below is his response. Philip Taylor, RHBNC. -------- Date: Fri, 06 Feb 1998 15:07:30 -0500 (EST) From: bbeeton Subject: [Phyllis Winkler : hyphen.tex] To: P.Taylor@vms.rhbnc.ac.uk Cc: bnb@MATH.AMS.ORG Message-id: <886795650.881737.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: phil -- here's don's response. he agrees with you. i've left the pps, because it's the best warning i'm likely to get as to don's scheduled look at the problems pile. i will be getting in touch with peter b about a few things that are pending, and i think there's one thing i haven't sent him yet. in my thank you note to don, i mentioned that i'll be at eurotex from about mar 26-april 2, so he might please wait until the week after that so his request doesn't get caught in the deluge of mail waiting on my return. -- bb --------------- Date: Fri, 06 Feb 1998 11:53:12 -0800 (PST) From: Phyllis Winkler To: bnb@MATH.AMS.ORG Subject: hyphen.tex That file name is "sacred", and if anybody changes it they will cause severe upward/downward compatibility headaches. People can have a file localhyphen.tex or whatever they like, but they mustn't diddle with hyphen.tex (or plain.tex except to preload additional fonts). PS: [question about ams mathsci] PPS: Have a great vacation in the Caribbean! On your return, perhaps in April, I will be ready for a review of the TeX/MF sources (perhaps the last time ever, although I have also promised to look again in 2002 or 2003). Best regards, Don 9-Feb-1998 19:52:29-GMT,2035;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA09984 for ; Mon, 9 Feb 1998 12:52:27 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 9 Feb 1998 19:52:26 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITDNIHJQCW000LW6@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 9 Feb 1998 14:19:13 EST Received: from Kitten.mcs.com ([192.160.127.90]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 09 Feb 1998 19:19:03 +0000 (UT) Received: from alexander (quixote.pr.mcs.net [205.164.4.66]) by Kitten.mcs.com (8.8.7/8.8.2) with SMTP id NAA24728 for ; Mon, 09 Feb 1998 13:19:01 -0600 (CST) Date: Mon, 09 Feb 1998 13:17:55 -0600 From: Don Hosek Subject: Re: DEK's ruling on the name and contents of "hyphen.tex" In-reply-to: <980209185809.44181@vms.rhbnc.ac.uk> X-Sender: quixote@mail.bayarea.net To: TEX-IMPLEMENTORS@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <3.0.3.32.19980209131755.009482f0@mail.bayarea.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Content-type: text/plain; charset="us-ascii" Of course, this is what I'd been telling my clients to do since TeX 3.x came out. The correct way to handle additional hyphens is to create your formats with a command along the lines of: initex plain \input local \dump I'd go so far as to say that additional preloads should also go into local (although frankly, I don't see the point of doing additional preloads, especially with contemporary computer architectures). -dh --- Don Hosek dhosek@quixote.com Quixote Digital Typography 312-953-3679 fax: 312-803-0698 orders: 800-810-3311 For information about SERIF: THE MAGAZINE OF TYPE & TYPOGRAPHY, http://www.quixote.com/serif/ or mail serif-info@quixote.com 9-Feb-1998 21:57:38-GMT,2447;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id OAA13662 for ; Mon, 9 Feb 1998 14:57:35 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 9 Feb 1998 21:57:33 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITDRYD46KG000N53@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 9 Feb 1998 16:26:34 EST Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 09 Feb 1998 21:26:23 +0000 (UT) Received: from mail-out-4.tiac.net (mail-out-4.tiac.net [199.0.65.16]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id QAA17177; Mon, 09 Feb 1998 16:26:22 -0500 (EST envelope-from support@YandY.com) Received: from denali (p15.ts15.bedfo.MA.tiac.com [206.119.242.144]) by mail-out-4.tiac.net (8.8.7/8.8.7) with SMTP id VAA13793; Mon, 09 Feb 1998 21:26:20 +0000 (envelope-from support@YandY.com) Date: Mon, 09 Feb 1998 16:26:29 -0500 From: "Y&Y, Inc." Subject: Re: DEK's ruling on the name and contents of "hyphen.tex" In-reply-to: <3.0.3.32.19980209131755.009482f0@mail.bayarea.net> X-Sender: yandy@pop.tiac.net To: Don Hosek , TEX-IMPLEMENTORS@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <3.0.5.32.19980209162629.0097e250@pop.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset="us-ascii" References: <980209185809.44181@vms.rhbnc.ac.uk> At 01:17 PM 98/02/09 -0600, Don Hosek wrote: >Of course, this is what I'd been telling my clients to do since TeX 3.x came out. >The correct way to handle additional hyphens is to create your formats By additional hyphens do you mean (i) additional languages, (ii) additional hyphenation expceptions for English, or (iii) something else. >with a command along the lines of: >initex plain \input local \dump What if I don't want the hyphenation patterns in hyphen.tex at all? I suppose I could load another set of hyphenation patterns and waste the string space, but ... >I'd go so far as to say that additional preloads should also go into local >(although frankly, I don't see the point of doing additional preloads, >especially with contemporary computer architectures). Agreed. Berthold. 10-Feb-1998 0:00:10-GMT,1383;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id RAA16885 for ; Mon, 9 Feb 1998 17:00:09 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 10 Feb 1998 00:00:08 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITDWDF8NTS000MZO@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 9 Feb 1998 18:32:45 EST Received: from cs.umb.edu ([158.121.104.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 09 Feb 1998 23:32:16 +0000 (UT) Received: from hub.cs.umb.edu by cs.umb.edu with SMTP id AA14265 (5.65c/IDA-1.4.4 for TEX-IMPLEMENTORS@MATH.AMS.ORG); Mon, 09 Feb 1998 18:32:06 -0500 Received: (from kb@localhost) by hub.cs.umb.edu (8.8.0/8.8.0) id SAA02819; Mon, 09 Feb 1998 18:32:03 -0500 (EST) Date: Mon, 09 Feb 1998 18:32:03 -0500 (EST) From: "K. Berry" Subject: Re: DEK's ruling on the name and contents of "hyphen.tex" To: support@yandy.com Cc: dhosek@quixote.com, TEX-IMPLEMENTORS@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <199802092332.SAA02819@hub.cs.umb.edu> What if I don't want the hyphenation patterns in hyphen.tex at all? Then you copy plain.tex to berthold.tex and remove \input hyphen.tex. 10-Feb-1998 20:46:49-GMT,8837;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA17427 for ; Tue, 10 Feb 1998 13:46:45 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 10 Feb 1998 20:46:44 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #1) id <01ITF2OS5YZK000PJD@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 10 Feb 1998 15:19:14 EST Date: Tue, 10 Feb 1998 15:19:04 -0500 (EST) From: bbeeton Subject: Re: DEK's ruling on the name and contents of "hyphen.tex" To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: <887141944.755459.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: attached are three messages regarding the name and contents of "hyphen.tex": - a message from frank mittelbach explaining the reasons why a more flexible position, blessed by dek, would be valuable - dek's response - some additional comments from frank i would also like to announce that don has informed me that he will be requesting, probably sometime early in april, the accumulated bug reports that i have been collecting since his last review. if anyone knows of anything that should be asked and hasn't been, now's the time to get it in. (and those of you who act as the vetting brigade, this is fair warning that i'll be in touch with you soon too.) i will be away for two periods between now and april: feb 19-mar 3, and mar 37-apr 3; please be patient if you're trying to get in touch. -- bb -------------------- Date: Sat, 07 Feb 1998 12:26:32 +0100 From: Frank Mittelbach Subject: Re: A response from DEK concerning the name and contents of "hyphen.tex" I'm not surprised at Don's reaction to Phil's letter if it was passed on to him unchanged (i.e. without describing the discussion that went on before) as it basically asked: is it okay to modify plain.tex or hyphen.tex arbitrarily and still call the result plain TeX? of course that isn't. but the point was a different one. PEB, SPQR and me were saying that the currently existing situation is unfortunate as it doesn't allow ordinary users to benefit from using the official standard plain macros (not a special copy from one version which will get obsolete after a while) while nevertheless have the opportunity to use their local hyphenation patterns. this can be easily achieved by an official *fully upward compatible* modification of plain.tex by Don in the following (or similar) way: instead of \input hyphen have if exist hyphen.cfg then write message to terminal and log: Plain TeX with customised hyphenation patterns input hyphen.cfg else input hyphen.tex fi This way there is no issue of a clear standard version but at the same time all the other plain TeX users not writing in in US English would be served as well. As i said before this is not at all comparable to the situation where somebody changed the cm fonts and it would have no side effects other than one more string allocated to the string pool (because of the \ifeof test) since the test will happen during format generation and the resulting format would clearly identify itself as *special* if customised hyphenation patterns are used. I wonder why i care; after all to me it doesn't matter as i'm not a plain TeX user and also being capable of writing wrapper code as suggested by Phil to solve a problem like this. But there are many users out there who are not capable of doing this and many of them do live by now for a long time with the only solution they found (i.e. loading different hyphenation patterns into plain (i have seen such implementations back in 1985 already) by using hyphen.tex as an intermediate layer) and an trying to get and official dictum that all these are bad guys doesn't help them while in my opinion a small modification like the above would clearly help them and everybody. Now perhaps Phil isn't aware of such problems so much since he can reasonably live with hyphen.tex unchanged and also belongs to the dieing crowd of people who can write a chess program in TeX but in my opinion his (good) intentions are counterproductive to the use of plain TeX. i therefore find it unfortunate that the underlying issue was not brought to the attention of Don, but instead a very compressed version which did not do justice to the intentions and arguments brought forward by Sebastian, Peter, and me. As his letter had the ring of us suggesting to people that they should produce "plain TeX formats" that are not containing the plain macros and the AM.E patterns --- which is not correct in this interpretation --- I'm cc'ing this mail to Don's secretary; she may decide whether she will pass my comments on to Don. best frank -------------------- Date: Mon, 09 Feb 1998 12:56:34 -0800 (PST) Subject: quick note from Don Barbara, Please tell the implementors that, for all time, anybody who wants to run a program called "tex" automatically gets plain TeX with the English hyphenation patterns as they have always been. Nobody should substitute anything anytime for the file "hyphen.tex". I read Frank's message, and I understand what he wants, but I disagree with his solution. The correct solution is for implementors to supply a program called "eurotex" or whatever, which will look for local hyphenation patterns or use environment variables or whatever they want. It's easy to read in the current plain.tex after changing the definition of \input temporarily, so that it plain.tex won't actually input hyphen.tex. (A similar trick is used all the time with METAFONT.) As long as people who want the facility Frank wants use another name, they can have what they want. I insist, however, that the unadorned name "tex" forever means the one I have spent a bit of time developing, which I have essentially frozen except for really drastic bugs. That's all I have asked in return for my work. Over AND OUT! -- Don -------------------- Date: Tue, 10 Feb 1998 19:57:17 +0100 From: Frank Mittelbach To: bbeeton Subject: Re: A response from DEK concerning the name and contents of "hyphen.tex" [...] i still would like to give the following observation to Don (whether or not you pass it on). what he tries to achieve is not understood by the public and therefore the results are not according to his wishes (and he better believes me on that), take for example, Don Hosek who, having seen Don's (Knuth) reply to Phil's letter writes on TEX-IMPLEMENTORS: Of course, this is what I'd been telling my clients to do since TeX 3.x came out. The correct way to handle additional hyphens is to create your formats with a command along the lines of: initex plain \input local \dump he thinks he is following Don's wishes (and he is to the letter but not in spirit) since he implicitly is suggesting to fiddle with the format from the outside but still calls the result plain tex. and yes, i know that his example is not working but in spirit it is the same as renaming a .fmt file after generation back to plain.fmt now i fully agree with Don that an effective solution to the problem is that every TeX installation provides some "cfgplain.tex" (or whatever name) that loads plain.tex with a suitable trick as suggested by Don. only that for enforcing its official status, ie being really there with every TeX installation and accepted by the users it would be so much nicer and easier if that file would have the name D.Knuth on top and a remark stating that it is provided so that everybody can have a customised version. in summary i believe that Don's wishes would be better served if he would officially provide such a file as part of TeX or have it provided by somebody he trust in providing proper code (or as a change to plain but i see why he doesn't want that) --- he seems to think otherwise but i fear he will be wrong. if he keeps his opinion then yes the best approach is as outlined by him and should be undertaken by the TeX Implementors well, i will not write on that topic another single line since i believe (just like Don) that it is not worth my time worrying about it. > i intend to send don's message to tex-implementors, to follow up on the > first message from don that phil forwarded, but for it to make maximum > sense, your message with the expanded commentary should accompany it. > so i'm asking for permission to forward that also to tex-implementors. > > okay? go ahead, if you like you can add my above comments as well Over AND OUT :-) frank 12-Feb-1998 8:11:25-GMT,6664;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA09962 for ; Thu, 12 Feb 1998 01:11:23 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Feb 1998 08:11:18 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITH5W2ZCO00010EM@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 12 Feb 1998 02:38:04 EST Received: from newton.feld.cvut.cz ([147.32.244.10]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 12 Feb 1998 07:37:52 +0000 (UT) Received: from localhost (olsak@localhost) by math.feld.cvut.cz (8.8.5/8.8.5) with SMTP id IAA14011 for ; Thu, 12 Feb 1998 08:35:44 +0100 Date: Thu, 12 Feb 1998 08:35:44 +0100 (MET) From: Petr Olsak Subject: Re: DEK's ruling on the name and contents of "hyphen.tex" In-reply-to: <887141944.755459.BNB@MATH.AMS.ORG> To: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Frank Mittelbach wrote: > ... > this can be easily achieved by an official *fully upward compatible* > modification of plain.tex by Don in the following (or similar) way: > > instead of \input hyphen > > have > > if exist hyphen.cfg then > > write message to terminal and log: > Plain TeX with customised hyphenation patterns > > input hyphen.cfg > > else > > input hyphen.tex > > fi NO, NO, NO, NO! I hope, this feature will be never implemented into plain. This is very bad, if the plain format is depend on the presence of some file and is depend on contents of this file. > ... > only that for enforcing its official status, ie being really there > with every TeX installation and accepted by the users it would be so > much nicer and easier if that file would have the name D.Knuth on top > and a remark stating that it is provided so that everybody can have a > customised version. I mean, Frank sees this problem from LaTeX point of view. LaTeX is very different macro package than plain. LaTeX is user oriented, modular (using classes, styles, packages, *.cfg files), multilingual, defines user language for markup, aspires to general formatting tool, is permanently developed and new release introduced twice in year. On the other hand, plain has two important features never seen in LaTeX: 1. plain is frozen and is standard. All English documents will be formatted by plain in the same way independent on TeX installation and independent on the time. If I write "tex document", I presuppose, the result is only one on the whole World. The *.cfg files are in opposition to this feature. 2. plain is a good example of macro programming given from author of TeX. Plain-user reads this example as inspiration for his own macros and is not important, if plain is included in his work without changes or only some parts of ideas of plain macros are used. Plain-user is macro programmer and he is not an user in LaTeX point of view --- he is never finding the solution of his problem in prepared macro packages on CTAN but he make his own solution and he reads the TeXbook. The plain is not the general formatting tool but it is only the good starting point for very simple documents and (more important) it is an inspiration for advanced users. The general solution of using the plain macros in different languages and environments sugested from anybody is in opposition to this feature. I am happy that Don Knuth did not accept Frank's suggestions. ------- I have seen some hyphen.tex files different from standard Knuth's file distributed from babel or something else. I strongly and immediatelly deleted this file and changed by Knuth's original file in my distribution of TeX (called CSTeX). But some problems occur, if users want to implement CSTeX macros in different distribution where babel and bad hyphen.tex was included (the tetex for Linux, for example). I am happy that problem is discussed here and it will be solved by removing the bad hyphen.tex from all official distributions. ------- I can refer about my solution of using plain macros in Czech and Slovak languages. There is the csplain.ini file with the contents: \input csfonts % re-defines primitive \font, cs* instead cm* loaded \input plain % Knuth's format plain \restorefont % original meaning of primitive \font \input il2code % extra codes for czech/slovak letters in ISO-8859-2 \input hyphen.lan % czech/slovak hyphenation pattern (may be others too) \input plaina4 % \hsize and \vsize for A4 \everyjob=\expandafter{\the\everyjob \message{The format: csplain .} \message{The cs-fonts are preloaded and A4 size implicitly defined.}} \dump Users can generate the csplain format by: initex csplain.ini The "csplain.fmt" was generated in old version of web2c TeX implementations and in all others implementations but "csplain.ini.fmt" is generated in new version of web2c (I mean, this is a bug of web2c, but this is the subject of another discussion about sections 511--533, namelly 516 in tex.web). The csplain format is depend on actual version of plain (I suppose only bugs will be removed). Our special fonts (called CSfonts) are preloaded. It is possible to format the English plainTeX documents via csplain. The resulting text will be the same (CSfonts have the same glyphs on the first 128 slots) but formatting result will be no the same (the kernings are improved, the implicit page size is different...). The Czech users know about it and they can use the pure plain alongside csplain format if they want. The csplain+CSfonts is frozen and is standard for Czech/Slovak languages in the same manner, as the plain+CM fonts. I give guarantee of csplain+CSfonts stability for Czech and Slovak users in the same manner as Knuth guarants the TeX+MF+plain+CMfonts stability for users on the whole World (see feature 1). I have written the documentation of TeX+plain+csplain in my book "TeXbook naruby" (TeXbook inside out). The free pdf version of this book with thousands hyperlinks is available on http://math.feld.cvut.cz/olsak/tbn.html. Users can inspire from my examples of macros from this book but they cannot use this macros directly as general formatting tool (see feature 2). This book has a similar meaning for Czech and Slovak users as Knuth's TeXbook for all users. Petr Olsak 16-Feb-1998 18:42:03-GMT,2441;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA18644 for ; Mon, 16 Feb 1998 11:41:59 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 16 Feb 1998 18:41:58 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01ITN1MYXSZK001J0N@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 16 Feb 1998 07:40:53 EST Received: from afmp02.mppmu.mpg.de ([134.107.4.101]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 16 Feb 1998 12:40:40 +0000 (UT) Received: from pcl163a.mppmu.mpg.de by afmp02.mppmu.mpg.de (5.65v3.2/1.1.10.5/09Jan98-0252PM) id AA17855; Mon, 16 Feb 1998 13:40:35 +0100 Received: from localhost (peb@localhost) by pcl163a.mppmu.mpg.de (8.7/8.7) with SMTP id NAA02065; Mon, 16 Feb 1998 13:40:34 +0100 Date: Mon, 16 Feb 1998 13:40:34 +0100 (MET) From: Peter Breitenlohner Subject: Re: DEK's ruling on the name and contents of "hyphen.tex" In-reply-to: <887141944.755459.BNB@MATH.AMS.ORG> To: bbeeton Cc: tex-implementors@MATH.AMS.ORG Errors-to: tex-implementors-request@MATH.AMS.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: pcl163a.mppmu.mpg.de: peb owned process doing -bs On Tue, 10 Feb 1998, bbeeton wrote: > attached are three messages regarding the name and contents of > "hyphen.tex": > - a message from frank mittelbach explaining the reasons why > a more flexible position, blessed by dek, would be valuable > - dek's response > - some additional comments from frank There is a simple way to input plain.tex from a wrapper file WITHOUT reading hyphen.tex, and I have used that for ages (well years). It is, however, a hack and therefore some people don't like it. You proceed as follows: \catcode`\{=1 \catcode`\}=2 \catcode`#=6 \let\x=\input \def\input#1 {\let\input=\x \let\x=\undefined} \x plain % read plain.tex without hyphen.tex % input some patterns, etc % redefine format name, version \dump Absolutely no need to either modify/copy plain/hyphen Note that this leaves neither macro definitions nor hash table entries behind it, it does however depend on the (known) structure of plain.tex! Peter Breitenlohner 30-Mar-1998 11:04:20-GMT,1104;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA13280 for ; Mon, 30 Mar 1998 04:04:19 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 30 Mar 1998 11:04:14 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IV9KZKD1WW000ESF@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 30 Mar 1998 05:20:55 EST Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 30 Mar 1998 10:20:24 +0000 (UT) Date: Mon, 30 Mar 1998 11:20:23 +0100 From: Philip Taylor (RHBNC) Subject: Tracing cs-name creation as a part of *TeX To: TEX-IMPLEMENTORS@ams.org Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <980330112023.11358@vms.rhbnc.ac.uk> I think it's a splendid idea and would add functionality which I have often wanted/needed. ** Phil. 31-Mar-1998 14:38:44-GMT,2104;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA18989 for ; Tue, 31 Mar 1998 07:38:38 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 31 Mar 1998 14:38:33 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVB6KMZ2C0000MEZ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 31 Mar 1998 08:49:14 EST Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 31 Mar 1998 13:49:05 +0000 (UT) Received: from mail-out-3.tiac.net (mail-out-3.tiac.net [199.0.65.15]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id IAA28468; Tue, 31 Mar 1998 08:48:37 -0500 (EST envelope-from support@YandY.com) Received: from denali (p20.tc7.metro.MA.tiac.com [209.61.76.149]) by mail-out-3.tiac.net (8.8.7/8.8.7) with SMTP id IAA29924; Tue, 31 Mar 1998 08:49:16 -0500 (EST envelope-from support@YandY.com) Date: Tue, 31 Mar 1998 08:49:06 -0500 From: "Y&Y, Inc." Subject: dumping csnames X-Sender: yandy@pop.tiac.net (Unverified) To: tex-implementors@ams.org Cc: Frank.Mittelbach@uni-mainz.de Errors-to: tex-implementors-request@ams.org Message-id: <199803311349.IAA29924@mail-out-3.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" Frank wrote: > because when i ran this against the LaTeX format i found that a number > of command names, such as downbarcefill or @sharp etc etc appeared > several times (something which surprised me) ...and shouldn't happen if the hash table is working correctlly. The bug is in the code. It steps through the hash table *and* follows links in the table. This means that any key displaced because of collision will be listed twice. In plain TeX for example, |cos| |zeta| |widehat| etc etc are listed twice by the code shown. It can be fixed by removing the tracing along the chains. Regards, Berthold Horn 1-Apr-1998 11:16:08-GMT,2174;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA19707 for ; Wed, 1 Apr 1998 04:16:06 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 1 Apr 1998 11:16:06 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVCEGT9GTC000SQR@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 1 Apr 1998 05:46:01 EST Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 01 Apr 1998 10:45:51 +0000 (UT) Received: from mail-out-3.tiac.net (mail-out-3.tiac.net [199.0.65.15]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id FAA02147; Wed, 01 Apr 1998 05:45:22 -0500 (EST envelope-from support@YandY.com) Received: from denali (p28.tc3.metro.MA.tiac.com [209.61.75.157]) by mail-out-3.tiac.net (8.8.7/8.8.7) with SMTP id FAA13875; Wed, 01 Apr 1998 05:46:10 -0500 (EST envelope-from support@YandY.com) Date: Wed, 01 Apr 1998 05:45:54 -0500 From: "Y&Y, Inc." Subject: Re: dumping csnames In-reply-to: <199803311349.IAA29924@mail-out-3.tiac.net> X-Sender: yandy@pop.tiac.net To: tex-implementors@ams.org Cc: Frank.Mittelbach@uni-mainz.de Errors-to: tex-implementors-request@ams.org Message-id: <199804011046.FAA13875@mail-out-3.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" At 08:49 AM 98/03/31 -0500, Y&Y, Inc. wrote: >The bug is in the code. It steps through the hash table *and* >follows links in the table. This means that any key displaced >because of collision will be listed twice. In plain TeX >for example, |cos| |zeta| |widehat| etc etc are listed twice >by the code shown. It can be fixed by removing the tracing >along the chains. Having fixed that bug, I am left with a puzzle: the number of entries I find in the hash table is slightly larger than cs_count. For plain TeX I get CSNAMES (cs_count 923 hash_used 32421 hash_prime 27197 hash_size 32768 ) but then find 950 entries in the table... 1-Apr-1998 22:42:03-GMT,1514;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id PAA14202 for ; Wed, 1 Apr 1998 15:42:02 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 1 Apr 1998 22:42:01 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVD2MOQ3SG000V7J@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 1 Apr 1998 17:17:58 EST Received: from master.boston.deshaw.com ([149.77.131.1]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 01 Apr 1998 22:17:47 +0000 (UT) Received: from artichoke (artichoke.boston.deshaw.com [149.77.133.89]) by master.boston.deshaw.com (8.8.8/8.8.8/2.0.kim) with SMTP id RAA00760; Wed, 01 Apr 1998 17:17:41 -0500 (EST) Date: Wed, 01 Apr 1998 17:17:48 -0500 From: "Kamesh R. Aiyer" Subject: MS buying Tex To: kinch@holonet.net Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <3522BD0C.1979@acm.org> MIME-version: 1.0 X-Mailer: Mozilla 3.0 (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Wouldn't that be a mstex? In any case, I am not a tex implementor, so I was a bit surprised to receive your mail sent to "tex-implementors@ams.org". Technically you are spamming me and I don't llke it even if in this particular case, the story was amusing. Cheers, -- Kamesh PS. Take me off the list. 2-Apr-1998 17:22:11-GMT,1570;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id KAA03825 for ; Thu, 2 Apr 1998 10:22:08 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 2 Apr 1998 17:22:06 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVE5FMGONK0014XI@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 2 Apr 1998 11:49:31 EST Received: from mail.inreach.com ([209.142.0.3]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 02 Apr 1998 16:49:11 +0000 (UT) Received: from 209.142.4.192 (209-142-5-161.stk.inreach.net [209.142.5.161]) by mail.inreach.com (8.8.8/8.8.6/(InReach)) with SMTP id IAA02391; Thu, 02 Apr 1998 08:44:51 -0800 (PST) Date: Thu, 02 Apr 1998 10:26:24 -0800 From: Arthur Ogawa Subject: Re: Microsoft buying TeX? Knuth selling out? To: "Richard J. Kinch" Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Reply-to: ogawa@teleport.com Message-id: <3523C24E.259A@teleport.com> Organization: TeX Consultants MIME-version: 1.0 X-Mailer: Mozilla 3.0Gold (Macintosh; I; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199804012148.QAA22411@zothommog.evcom.net> Richard J. Kinch wrote: > Did anybody else see this news item today?... > MICROSOFT BUYS TEX, PLANS NEW PRODUCTS :-D :-D :-D (Note the date!) Thank you, Richard! 14-Apr-1998 17:00:27-GMT,3417;000000000001 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA15635; Tue, 14 Apr 1998 11:00:27 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id LAA04611; Tue, 14 Apr 1998 11:00:27 -0600 (MDT) Date: Tue, 14 Apr 1998 11:00:27 -0600 (MDT) To: tex-implementors@math.ams.org Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: [Otto Stolz : Re: non-latin hyphenation?] Message-ID: This message from the Unicode list describes an unusual hyphenation practice; it might possibly be of interest to writers of certain rather specialized macro packages: --------------- Received: from public.lists.apple.com (A17-254-0-151.apple.com [17.254.0.151]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA15021 for ; Tue, 14 Apr 1998 10:46:51 -0600 (MDT) Received: from unicode.org (unicode2.apple.com [17.254.3.212]) by public.lists.apple.com (8.8.8/8.8.8) with SMTP id JAA33334 ; Tue, 14 Apr 1998 09:46:13 -0700 Received: by unicode.org (NX5.67g/NX3.0S) id AA23242; Tue, 14 Apr 98 09:05:12 -0700 Message-Id: <9804141605.AA23242@unicode.org> Errors-To: uni-bounce@unicode.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Uml-Sequence: 5186 (1998-04-14 16:05:07 GMT) From: Otto Stolz Reply-To: unicode@unicode.org To: Unicode List Date: Tue, 14 Apr 1998 09:05:06 -0700 (PDT) Subject: Re: non-latin hyphenation? On 1998-4-6 10:02, Bob_Hallissy@sil.org has written: > What other conventions exist for denoting an unusual (e.g., > middle-of-word) line break? Up to the year 1941, the Fraktur variant of the Latin script (aka "black letter", or "Gothic type") was officially used to write German. In this script, hyphenation is indicated by a glyph resembling an equals-sign, but slightly slanted (i. e. rising). This glyph is used at the end of the line, as the hyphen is used in English (and modern German) typography. I remember that some books written in Fraktur have indicated hyphenation in a more elaborate way, when it occurred across a page-break. If memory serves me right (I haven't one of these books at hand, right now), the partial word from the next page was repeated in a smaller font, at the bottom of the page, right under the first part of the word. I will try to check this, later at home. Best wishes, Otto Stolz ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 14-Apr-1998 17:46:05-GMT,4107;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA17292 for ; Tue, 14 Apr 1998 11:46:04 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Apr 1998 17:46:03 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVUZF84L40000JE4@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 14 Apr 1998 13:00:55 EST Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 14 Apr 1998 17:00:31 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA15635; Tue, 14 Apr 1998 11:00:27 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id LAA04611; Tue, 14 Apr 1998 11:00:27 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Tue, 14 Apr 1998 11:00:27 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: [Otto Stolz : Re: non-latin hyphenation?] To: tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 This message from the Unicode list describes an unusual hyphenation practice; it might possibly be of interest to writers of certain rather specialized macro packages: --------------- Received: from public.lists.apple.com (A17-254-0-151.apple.com [17.254.0.151]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA15021 for ; Tue, 14 Apr 1998 10:46:51 -0600 (MDT) Received: from unicode.org (unicode2.apple.com [17.254.3.212]) by public.lists.apple.com (8.8.8/8.8.8) with SMTP id JAA33334 ; Tue, 14 Apr 1998 09:46:13 -0700 Received: by unicode.org (NX5.67g/NX3.0S) id AA23242; Tue, 14 Apr 98 09:05:12 -0700 Message-Id: <9804141605.AA23242@unicode.org> Errors-To: uni-bounce@unicode.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Uml-Sequence: 5186 (1998-04-14 16:05:07 GMT) From: Otto Stolz Reply-To: unicode@unicode.org To: Unicode List Date: Tue, 14 Apr 1998 09:05:06 -0700 (PDT) Subject: Re: non-latin hyphenation? On 1998-4-6 10:02, Bob_Hallissy@sil.org has written: > What other conventions exist for denoting an unusual (e.g., > middle-of-word) line break? Up to the year 1941, the Fraktur variant of the Latin script (aka "black letter", or "Gothic type") was officially used to write German. In this script, hyphenation is indicated by a glyph resembling an equals-sign, but slightly slanted (i. e. rising). This glyph is used at the end of the line, as the hyphen is used in English (and modern German) typography. I remember that some books written in Fraktur have indicated hyphenation in a more elaborate way, when it occurred across a page-break. If memory serves me right (I haven't one of these books at hand, right now), the partial word from the next page was repeated in a smaller font, at the bottom of the page, right under the first part of the word. I will try to check this, later at home. Best wishes, Otto Stolz ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 15-Apr-1998 7:35:00-GMT,3765;000000000001 Received: from mail.kcl.ac.uk (root@mail.kcl.ac.uk [137.73.66.6]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id BAA27960 for ; Wed, 15 Apr 1998 01:34:58 -0600 (MDT) Received: from lucifer (lucifer.cc.kcl.ac.uk [137.73.36.170]) by mail.kcl.ac.uk (8.8.8/8.8.8) with SMTP id IAA07766; Wed, 15 Apr 1998 08:26:49 +0100 (BST) From: malcolm clark Sender: zqca0137@kcl.ac.uk To: "Nelson H. F. Beebe" cc: beebe@math.utah.edu, tex-implementors@ams.org Subject: re: [Otto Stolz : Re: non-latin hyphenation?] In-Reply-To: Message-ID: Date: Wed, 15 Apr 1998 08:36:20 +0100 (GMT Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1 Build (3) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 14 Apr 1998 11:00:27 -0600 (MDT) "Nelson H. F. Beebe" wrote: > This message from the Unicode list describes an unusual hyphenation > practice; it might possibly be of interest to writers of certain > rather specialized macro packages: > > --------------- > > Received: from public.lists.apple.com (A17-254-0-151.apple.com [17.254.0.151]) > by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA15021 > for ; Tue, 14 Apr 1998 10:46:51 -0600 (MDT) > Received: from unicode.org (unicode2.apple.com [17.254.3.212]) > by public.lists.apple.com (8.8.8/8.8.8) with SMTP id JAA33334 > ; Tue, 14 Apr 1998 09:46:13 -0700 > Received: by unicode.org (NX5.67g/NX3.0S) > id AA23242; Tue, 14 Apr 98 09:05:12 -0700 > Message-Id: <9804141605.AA23242@unicode.org> > Errors-To: uni-bounce@unicode.org > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Uml-Sequence: 5186 (1998-04-14 16:05:07 GMT) > From: Otto Stolz > Reply-To: unicode@unicode.org > To: Unicode List > Date: Tue, 14 Apr 1998 09:05:06 -0700 (PDT) > Subject: Re: non-latin hyphenation? > > On 1998-4-6 10:02, Bob_Hallissy@sil.org has written: > > What other conventions exist for denoting an unusual (e.g., > > middle-of-word) line break? > > Up to the year 1941, the Fraktur variant of the Latin script (aka "black > letter", or "Gothic type") was officially used to write German. In this > script, hyphenation is indicated by a glyph resembling an equals-sign, > but slightly slanted (i. e. rising). This glyph is used at the end of the > line, as the hyphen is used in English (and modern German) typography. > > I remember that some books written in Fraktur have indicated hyphenation > in a more elaborate way, when it occurred across a page-break. If memory > serves me right (I haven't one of these books at hand, right now), the > partial word from the next page was repeated in a smaller font, at the > bottom of the page, right under the first part of the word. I will try to > check this, later at home. > something similar is true of some 17th century texts published in the uk (not the use of fraktur, thankfully; or the odd hyphen). playfair's 'illustrations of the huttonian theory of the earth' 1802, republished in facsimile, Dover, 1956, no isbn, does something like this, but refines it by printing the first word of a succeeding page at the bottom right of the previous page (recto & verso). whether or not hyphenated. malcolm clark tel: (+44) 0171 873 2652 computing centre fax: (+44) 0171 836 1799 king's college, london url: http://www.kcl.ac.uk/links/mc.html strand email: malcolm.clark@kcl.ac.uk london wc2r 2ls, uk m.clark@acm.org 15-Apr-1998 8:07:04-GMT,4271;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA03158 for ; Wed, 15 Apr 1998 02:06:59 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 15 Apr 1998 08:06:52 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVVTYG0A0G000TKY@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 15 Apr 1998 03:35:21 EST Received: from mail.kcl.ac.uk ([137.73.66.6]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 15 Apr 1998 07:35:09 +0000 (UT) Received: from lucifer (lucifer.cc.kcl.ac.uk [137.73.36.170]) by mail.kcl.ac.uk (8.8.8/8.8.8) with SMTP id IAA07766; Wed, 15 Apr 1998 08:26:49 +0100 (BST) Date: Wed, 15 Apr 1998 08:36:20 +0100 (GMT Daylight Time) From: malcolm clark Subject: re: [Otto Stolz : Re: non-latin hyphenation?] In-reply-to: Sender: zqca0137@kcl.ac.uk To: "Nelson H. F. Beebe" Cc: beebe@math.utah.edu, tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1 Build (3) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Priority: NORMAL X-Authentication: none On Tue, 14 Apr 1998 11:00:27 -0600 (MDT) "Nelson H. F. Beebe" wrote: > This message from the Unicode list describes an unusual hyphenation > practice; it might possibly be of interest to writers of certain > rather specialized macro packages: > > --------------- > > Received: from public.lists.apple.com (A17-254-0-151.apple.com [17.254.0.151]) > by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA15021 > for ; Tue, 14 Apr 1998 10:46:51 -0600 (MDT) > Received: from unicode.org (unicode2.apple.com [17.254.3.212]) > by public.lists.apple.com (8.8.8/8.8.8) with SMTP id JAA33334 > ; Tue, 14 Apr 1998 09:46:13 -0700 > Received: by unicode.org (NX5.67g/NX3.0S) > id AA23242; Tue, 14 Apr 98 09:05:12 -0700 > Message-Id: <9804141605.AA23242@unicode.org> > Errors-To: uni-bounce@unicode.org > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Uml-Sequence: 5186 (1998-04-14 16:05:07 GMT) > From: Otto Stolz > Reply-To: unicode@unicode.org > To: Unicode List > Date: Tue, 14 Apr 1998 09:05:06 -0700 (PDT) > Subject: Re: non-latin hyphenation? > > On 1998-4-6 10:02, Bob_Hallissy@sil.org has written: > > What other conventions exist for denoting an unusual (e.g., > > middle-of-word) line break? > > Up to the year 1941, the Fraktur variant of the Latin script (aka "black > letter", or "Gothic type") was officially used to write German. In this > script, hyphenation is indicated by a glyph resembling an equals-sign, > but slightly slanted (i. e. rising). This glyph is used at the end of the > line, as the hyphen is used in English (and modern German) typography. > > I remember that some books written in Fraktur have indicated hyphenation > in a more elaborate way, when it occurred across a page-break. If memory > serves me right (I haven't one of these books at hand, right now), the > partial word from the next page was repeated in a smaller font, at the > bottom of the page, right under the first part of the word. I will try to > check this, later at home. > something similar is true of some 17th century texts published in the uk (not the use of fraktur, thankfully; or the odd hyphen). playfair's 'illustrations of the huttonian theory of the earth' 1802, republished in facsimile, Dover, 1956, no isbn, does something like this, but refines it by printing the first word of a succeeding page at the bottom right of the previous page (recto & verso). whether or not hyphenated. malcolm clark tel: (+44) 0171 873 2652 computing centre fax: (+44) 0171 836 1799 king's college, london url: http://www.kcl.ac.uk/links/mc.html strand email: malcolm.clark@kcl.ac.uk london wc2r 2ls, uk m.clark@acm.org 16-Apr-1998 5:41:11-GMT,4874;000000000001 Received: from gsb-sucre.stanford.edu (GSB-Sucre.Stanford.EDU [36.67.0.17]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id XAA12409 for ; Wed, 15 Apr 1998 23:41:10 -0600 (MDT) Received: from localhost (localhost) by gsb-sucre.stanford.edu (8.8.5/8.7.1) with internal id WAA29736; Wed, 15 Apr 1998 22:41:10 -0700 (PDT) Date: Wed, 15 Apr 1998 22:41:10 -0700 (PDT) From: Mail Delivery Subsystem Subject: Warning: could not send message for past 4 hours Message-Id: <199804160541.WAA29736@gsb-sucre.stanford.edu> To: Auto-Submitted: auto-generated (warning-timeout) ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Wed, 15 Apr 1998 17:50:49 -0700 (PDT) from math.ams.org [130.44.210.14] ----- The following addresses had transient non-fatal errors ----- berg@gsb-yen.stanford.edu (expanded from: BERG@GSB-SUCRE.STANFORD.EDU) ----- Transcript of session follows ----- berg@gsb-yen.stanford.edu... Deferred: Connection timed out with gsb-yen.stanford.edu. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old ----- Original message follows ----- Return-Path: beebe@csc-sun.math.utah.edu Received: from math.ams.org (math.ams.org [130.44.210.14]) by gsb-sucre.stanford.edu (8.8.5/8.7.1) with SMTP id RAA29596 for ; Wed, 15 Apr 1998 17:50:49 -0700 (PDT) Received: from axp14.ams.org by math.ams.org via smtpd (for GSB-Sucre.Stanford.EDU [36.67.0.17]) with SMTP; 16 Apr 1998 00:50:07 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVWTE448A8000MSI@AXP14.AMS.ORG> for A.Eric@GSB-HOW.Stanford.edu; Wed, 15 Apr 1998 20:29:34 EST Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 16 Apr 1998 00:29:24 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA04516; Wed, 15 Apr 1998 18:29:23 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id SAA15475; Wed, 15 Apr 1998 18:29:23 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Wed, 15 Apr 1998 18:29:23 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: More on alternate word-breaking hyphenation practices To: tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 Here is a followup with more ways to indicate word breaking at line boundaries, condensed from a posting today on the Unicode list: >> ... >> From: timpart@perdix.demon.co.uk (Timothy Partridge) >> Reply-To: unicode@unicode.org >> To: Unicode List >> Date: Wed, 15 Apr 1998 16:17:21 -0700 (PDT) >> Subject: Re: non-latin hyphenation? >> >> ... >> >> Tibetian see page 6-59 of Unicode standard (three occurances of normal end of >> word indicator) >> >> Thai uses hyphen in same way as English (The Thai System of Writing, Mary R. >> Haas). >> >> Japanese no indication, but prohibits line breaks at certain places reducing >> ambiguity (Understanding Japanese Information Processing, Ken Lunde). >> >> Italian (I know it's a Latin script!) Underline last character on line >> instead of using hyphen (ECMA Standard 48 / ISO 6429). I have never seen >> this used, but I live in England. >> >> Arabic I have never seen anything resembling a hyphen in samples, but don't >> know any language using this script. I suspect that kashida (stretching of >> words using lengthened horizontal lines) is used to avoid anything as ugly >> as a break inside a word. >> >> Tim >> >> -- >> Tim Partridge. Any opinions expressed are mine only and not those of my >> employer >> >> ... ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 16-Apr-1998 7:52:03-GMT,5639;000000000001 Received: from pansy.csv.warwick.ac.uk (root@pansy.csv.warwick.ac.uk [137.205.192.19]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id BAA02791 for ; Thu, 16 Apr 1998 01:52:00 -0600 (MDT) Received: from localhost (localhost) by pansy.csv.warwick.ac.uk (8.8.7/8.8.8) with internal id GAO03441; Thu, 16 Apr 1998 08:51:58 +0100 (BST) Date: Thu, 16 Apr 1998 08:51:58 +0100 (BST) From: Mail Delivery Subsystem Message-Id: <199804160751.GAO03441@pansy.csv.warwick.ac.uk> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="GAO03441.892713118/pansy.csv.warwick.ac.uk" Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --GAO03441.892713118/pansy.csv.warwick.ac.uk ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 16 Apr 1998 01:44:22 +0100 (BST) from math.ams.org [130.44.210.14] ----- The following addresses had transient non-fatal errors ----- malcolm.clark@kcl.ac.uk (expanded from: ) ----- Transcript of session follows ----- malcolm.clark@kcl.ac.uk... Deferred: Connection refused by mail.kcl.ac.uk. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old --GAO03441.892713118/pansy.csv.warwick.ac.uk Content-Type: message/delivery-status Reporting-MTA: dns; pansy.csv.warwick.ac.uk Arrival-Date: Thu, 16 Apr 1998 01:44:22 +0100 (BST) Final-Recipient: RFC822; cudax@pansy.csv.warwick.ac.uk X-Actual-Recipient: RFC822; malcolm.clark@kcl.ac.uk Action: delayed Status: 4.4.1 Remote-MTA: DNS; mail.kcl.ac.uk Last-Attempt-Date: Thu, 16 Apr 1998 08:51:58 +0100 (BST) Will-Retry-Until: Tue, 21 Apr 1998 01:44:22 +0100 (BST) --GAO03441.892713118/pansy.csv.warwick.ac.uk Content-Type: message/rfc822 Return-Path: Received: from math.ams.org (math.ams.org [130.44.210.14]) by pansy.csv.warwick.ac.uk (8.8.7/8.8.8) with SMTP id BAA19489 for ; Thu, 16 Apr 1998 01:44:22 +0100 (BST) Received: from axp14.ams.org by math.ams.org via smtpd (for mail-relay-1.csv.warwick.ac.uk [137.205.128.7]) with SMTP; 16 Apr 1998 00:44:16 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVWTE448A8000MSI@AXP14.AMS.ORG> for cudax@csv.warwick.ac.uk; Wed, 15 Apr 1998 20:29:34 EST Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 16 Apr 1998 00:29:24 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA04516; Wed, 15 Apr 1998 18:29:23 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id SAA15475; Wed, 15 Apr 1998 18:29:23 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Wed, 15 Apr 1998 18:29:23 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: More on alternate word-breaking hyphenation practices To: tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 Here is a followup with more ways to indicate word breaking at line boundaries, condensed from a posting today on the Unicode list: >> ... >> From: timpart@perdix.demon.co.uk (Timothy Partridge) >> Reply-To: unicode@unicode.org >> To: Unicode List >> Date: Wed, 15 Apr 1998 16:17:21 -0700 (PDT) >> Subject: Re: non-latin hyphenation? >> >> ... >> >> Tibetian see page 6-59 of Unicode standard (three occurances of normal end of >> word indicator) >> >> Thai uses hyphen in same way as English (The Thai System of Writing, Mary R. >> Haas). >> >> Japanese no indication, but prohibits line breaks at certain places reducing >> ambiguity (Understanding Japanese Information Processing, Ken Lunde). >> >> Italian (I know it's a Latin script!) Underline last character on line >> instead of using hyphen (ECMA Standard 48 / ISO 6429). I have never seen >> this used, but I live in England. >> >> Arabic I have never seen anything resembling a hyphen in samples, but don't >> know any language using this script. I suspect that kashida (stretching of >> words using lengthened horizontal lines) is used to avoid anything as ugly >> as a break inside a word. >> >> Tim >> >> -- >> Tim Partridge. Any opinions expressed are mine only and not those of my >> employer >> >> ... ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- --GAO03441.892713118/pansy.csv.warwick.ac.uk-- 18-Apr-1998 0:00:55-GMT,2851;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id SAA06612 for ; Fri, 17 Apr 1998 18:00:54 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 18 Apr 1998 00:00:49 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVZKDK6KCW0008TQ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 17 Apr 1998 19:43:27 EST Received: from june.cs.washington.edu ([128.95.1.4]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 17 Apr 1998 23:43:15 +0000 (UT) Received: (mackay@localhost) by june.cs.washington.edu (8.8.7+CS/7.2ju) id QAA22428; Fri, 17 Apr 1998 16:43:12 -0700 Date: Fri, 17 Apr 1998 16:43:12 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: More on alternate word-breaking hyphenation practices To: beebe@math.utah.edu, tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199804172343.QAA22428@june.cs.washington.edu> Hyphenation is utterly impossible in Arabic script. The only thing even remotely like it is the occasional splitting of a word across the boundary between the first half (misra`) of an Arabic poetic line and the second---the two halves are always printed with a gap between them and on the same line unless the format is really impossible, like text in the margin of another book. Even in this instance, the symbol used to show that the word is broken is not a hyphen, but a floating independent-form mim. Keshide (the word is Persian, and the best Arabic equivalent would be tatwil) is grossly overused. Long final forms are the preferred way of filling a line. Keshide extensions are, if possible, made nearly imperceptible, like changes in interword spacing. The one place where keshide is normal, and that, significantly is normally in Persian Nestaliq style, rather than in Arabic Naskhi, is in the long drawing out of the sin in the word sana "year", so that the actual numbers can ride over the extended stroke. It looks great in Nestaliq, but rather crude in Naskhi. %=======================================================================% | N O T I C E | | Please note the address and telephone number below. | | There is no Northwest Computing Support Center any longer. | | | %=======================================================================% Email: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for 218 Denny Hall, Box 353110 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder) 20-Apr-1998 7:32:35-GMT,2017;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA13177 for ; Mon, 20 Apr 1998 01:32:33 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Apr 1998 07:32:29 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IW2SWK77DS000IAK@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 20 Apr 1998 03:20:13 EST Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 20 Apr 1998 07:20:01 +0000 (UT) Received: by eiche.informatik.uni-stuttgart.de; Mon, 20 Apr 1998 09:19:37 +0200 Date: Mon, 20 Apr 1998 09:19:36 +0200 (MET DST) From: Klaus Lagally Subject: Re: More on alternate word-breaking hyphenation practices In-reply-to: To: tex-implementors@ams.org (TeX implementors) Errors-to: tex-implementors-request@ams.org Message-id: <199804200719.JAA24793@eiche.informatik.uni-stuttgart.de> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL24] Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit scripsit Nelson H. F. Beebe: > > >> Arabic I have never seen anything resembling a hyphen in samples, but don't > >> know any language using this script. I suspect that kashida (stretching of > >> words using lengthened horizontal lines) is used to avoid anything as ugly > >> as a break inside a word. There is no word-breaking at all in Arabic. Persian has compound words and may break them at compound boundaries, without explicit indication. Klaus -- Prof. Dr. Klaus Lagally | lagally@informatik.uni-stuttgart.de Institut fuer Informatik | Tel. +49-711-7816392 | Zeige mir deine Uhr, Breitwiesenstrasse 20-22 | FAX +49-711-7816370 | und ich sage dir, 70565 Stuttgart, GERMANY | (changed) | wie spaet es ist. 21-Apr-1998 1:28:00-GMT,4640;000000000001 Received: from gsb-sucre.stanford.edu (GSB-Sucre.Stanford.EDU [36.67.0.17]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id TAA23480 for ; Mon, 20 Apr 1998 19:27:59 -0600 (MDT) Received: from localhost (localhost) by gsb-sucre.stanford.edu (8.8.5/8.7.1) with internal id SAA05229; Mon, 20 Apr 1998 18:27:57 -0700 (PDT) Date: Mon, 20 Apr 1998 18:27:57 -0700 (PDT) From: Mail Delivery Subsystem Subject: Returned mail: Cannot send message within 5 days Message-Id: <199804210127.SAA05229@gsb-sucre.stanford.edu> To: Auto-Submitted: auto-generated (failure) The original message was received at Wed, 15 Apr 1998 17:50:49 -0700 (PDT) from math.ams.org [130.44.210.14] ----- The following addresses had permanent fatal errors ----- berg@gsb-yen.stanford.edu (expanded from: BERG@GSB-SUCRE.STANFORD.EDU) ----- Transcript of session follows ----- berg@gsb-yen.stanford.edu... Deferred: Connection timed out with gsb-yen.stanford.edu. Message could not be delivered for 5 days Message will be deleted from queue ----- Original message follows ----- Return-Path: beebe@csc-sun.math.utah.edu Received: from math.ams.org (math.ams.org [130.44.210.14]) by gsb-sucre.stanford.edu (8.8.5/8.7.1) with SMTP id RAA29596 for ; Wed, 15 Apr 1998 17:50:49 -0700 (PDT) Received: from axp14.ams.org by math.ams.org via smtpd (for GSB-Sucre.Stanford.EDU [36.67.0.17]) with SMTP; 16 Apr 1998 00:50:07 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IVWTE448A8000MSI@AXP14.AMS.ORG> for A.Eric@GSB-HOW.Stanford.edu; Wed, 15 Apr 1998 20:29:34 EST Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 16 Apr 1998 00:29:24 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA04516; Wed, 15 Apr 1998 18:29:23 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id SAA15475; Wed, 15 Apr 1998 18:29:23 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Wed, 15 Apr 1998 18:29:23 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: More on alternate word-breaking hyphenation practices To: tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 Here is a followup with more ways to indicate word breaking at line boundaries, condensed from a posting today on the Unicode list: >> ... >> From: timpart@perdix.demon.co.uk (Timothy Partridge) >> Reply-To: unicode@unicode.org >> To: Unicode List >> Date: Wed, 15 Apr 1998 16:17:21 -0700 (PDT) >> Subject: Re: non-latin hyphenation? >> >> ... >> >> Tibetian see page 6-59 of Unicode standard (three occurances of normal end of >> word indicator) >> >> Thai uses hyphen in same way as English (The Thai System of Writing, Mary R. >> Haas). >> >> Japanese no indication, but prohibits line breaks at certain places reducing >> ambiguity (Understanding Japanese Information Processing, Ken Lunde). >> >> Italian (I know it's a Latin script!) Underline last character on line >> instead of using hyphen (ECMA Standard 48 / ISO 6429). I have never seen >> this used, but I live in England. >> >> Arabic I have never seen anything resembling a hyphen in samples, but don't >> know any language using this script. I suspect that kashida (stretching of >> words using lengthened horizontal lines) is used to avoid anything as ugly >> as a break inside a word. >> >> Tim >> >> -- >> Tim Partridge. Any opinions expressed are mine only and not those of my >> employer >> >> ... ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 24-Apr-1998 15:31:33-GMT,3925;000000000001 Received: from localhost (localhost) by csc-sun.math.utah.edu (8.8.5/8.8.5) with internal id JAA14447; Fri, 24 Apr 1998 09:31:32 -0600 (MDT) Date: Fri, 24 Apr 1998 09:31:32 -0600 (MDT) From: Mail Delivery Subsystem Message-Id: <199804241531.JAA14447@csc-sun.math.utah.edu> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="JAA14447.893431892/csc-sun.math.utah.edu" Subject: Returned mail: Host unknown (Name server: math.ams.com: host not found) Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --JAA14447.893431892/csc-sun.math.utah.edu The original message was received at Fri, 24 Apr 1998 09:31:31 -0600 (MDT) from beebe@plot79.math.utah.edu [155.101.20.21] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 550 ... Host unknown (Name server: math.ams.com: host not found) --JAA14447.893431892/csc-sun.math.utah.edu Content-Type: message/delivery-status Reporting-MTA: dns; csc-sun.math.utah.edu Received-From-MTA: DNS; plot79.math.utah.edu Arrival-Date: Fri, 24 Apr 1998 09:31:31 -0600 (MDT) Final-Recipient: RFC822; tex-implementors@math.ams.com Action: failed Status: 5.1.2 Remote-MTA: DNS; math.ams.com Last-Attempt-Date: Fri, 24 Apr 1998 09:31:32 -0600 (MDT) --JAA14447.893431892/csc-sun.math.utah.edu Content-Type: message/rfc822 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA14446; Fri, 24 Apr 1998 09:31:31 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA24192; Fri, 24 Apr 1998 09:31:32 -0600 (MDT) Date: Fri, 24 Apr 1998 09:31:32 -0600 (MDT) To: tex-implementors@math.ams.com Cc: beebe@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: New development: Precision Graphics Markup Language (PGML) Message-ID: This note draws your attention to an interesting new development: http://www.w3.org/TR/1998/NOTE-PGML It describes PGML (Precision Graphics Markup Language), an outgrowth of PostScript and PDF designed for use on the Web. The document is dated 10-Apr-1998, just two weeks ago today. Since the authors come from Adobe, IBM, Netscape, and Sun, and the document is published by the World Wide Web Consortium, I believe that it has some significance, and even though it is very new, will be relevant to the TeX and PDF communities. Postings about PGML have already appeared on the pdftex list (from Sebastian Rahtz) and on the pdf list (from David Brailsford), so I'm not duplicating this announcement on those lists. David's posting contained substantial useful commentary on PGML, so if any of you are not on the pdf list, and would like to see it, e-mail me privately, and I'll forward you a copy. ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- --JAA14447.893431892/csc-sun.math.utah.edu-- 2-Jun-1998 12:57:52-GMT,2281;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA13081 for ; Tue, 2 Jun 1998 06:57:51 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 2 Jun 1998 12:57:50 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IXR5513L6O001NE4@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 2 Jun 1998 07:58:09 EST Received: from hermes.ucd.ie ([137.43.1.49]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 02 Jun 1998 11:57:58 +0000 (UT) Received: from maths.ucd.ie by hermes.ucd.ie (PMDF V5.1-10 #29647) with SMTP id <0ETX00J8LAKIT2@hermes.ucd.ie> for tex-implementors@MATH.AMS.ORG; Tue, 02 Jun 1998 12:57:55 +0100 (BST) Received: by maths.ucd.ie (16.8/0.0) id AA04518; Tue, 02 Jun 1998 12:50:08 +0100 Date: Tue, 02 Jun 1998 12:50:07 +0100 (BST) From: wgs@maths.ucd.ie (Wayne G. Sullivan) Subject: bug in vptovf.web, version 1.4 To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <9806021150.AA04518@maths.ucd.ie> Mailer: Elm [revision: 70.30] This is to report a bug in vftovp.web, version 1.4, which can yield a defective vf file. The procedure vf_fix, when supplied the parameters (0,0), produces the four bytes 255,0,0,0. The correct four bytes are 0,0,0,0. The above mentioned bug has the consequence that many current vf files on CTAN are corrupt. The fonts in question are those containing the special character "compwordmark". This has been implemented by the use of a rule of zero width for the vf map. The resulting vf file has a rule with large negative width. In practice it is unlikely to cause any problem, but vftovp, version 1.2, reports Bad VF file: Oversize dimension has been reset to zero. There is also an anomaly with vftovp. Even though the above message appears, the vpl file produced by vftovp contains SETRULE with width parameter -16.0. If one uses this vpl file to regenerate the vf, one obtains the original vf, so that vftovp will again complain. Though no real problems are caused by this, the behavior is similar to that all too often seen with PC's. TeX deserves better. Wayne Sullivan 2-Jun-1998 14:06:35-GMT,3215;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA14478 for ; Tue, 2 Jun 1998 08:06:34 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 2 Jun 1998 14:06:34 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #1) with SMTP id <01IXR8C4KA28001KQY@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 2 Jun 1998 09:29:20 EST Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 02 Jun 1998 13:29:12 +0000 (UT) Received: from mail-out-1.tiac.net (mail-out-1.tiac.net [199.0.65.12]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id JAA05102; Tue, 02 Jun 1998 09:29:07 -0400 (EDT envelope-from support@YandY.com) Received: from denali (p24.tc1.bedfo.MA.tiac.com [209.61.104.25]) by mail-out-1.tiac.net (8.8.7/8.8.7) with SMTP id JAA13809; Tue, 02 Jun 1998 09:29:03 -0400 (EDT) Date: Tue, 02 Jun 1998 09:29:09 -0400 From: "Y&Y, Inc." Subject: Re: bug in vptovf.web, version 1.4 In-reply-to: <9806021150.AA04518@maths.ucd.ie> X-Sender: yandy@pop.tiac.net To: wgs@maths.ucd.ie (Wayne G. Sullivan), tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199806021329.JAA13809@mail-out-1.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Content-type: text/plain; charset="us-ascii" Hi: This long-standing bug shows up in output of DVICOPY and is a pain in the butt that we had to provide work arounds for. However, I was under the impression that this was somehow intentional, that the weird rule with semi-infinite negative width was some kind of obscure marker for DVI produced from VF. Regards, Berthold Horn At 12:50 PM 98/06/02 +0100, Wayne G. Sullivan wrote: >This is to report a bug in vftovp.web, version 1.4, >which can yield a defective vf file. > >The procedure vf_fix, when supplied the parameters (0,0), >produces the four bytes 255,0,0,0. The correct four bytes are 0,0,0,0. > > >The above mentioned bug has the consequence that many current vf files >on CTAN are corrupt. The fonts in question are those containing the >special character "compwordmark". This has been implemented by the use >of a rule of zero width for the vf map. The resulting vf file has a rule >with large negative width. In practice it is unlikely to cause any problem, >but vftovp, version 1.2, reports > Bad VF file: Oversize dimension has been reset to zero. > >There is also an anomaly with vftovp. Even though the above message appears, >the vpl file produced by vftovp contains SETRULE with width parameter -16.0. >If one uses this vpl file to regenerate the vf, one obtains the original vf, >so that vftovp will again complain. Though no real problems are caused by >this, the behavior is similar to that all too often seen with PC's. Could you explain what on earth this means? Do you mean the TeX systems you use on PC's always produce meaningless error messages :-) If you are going to start a platform flame war, at least be precise :0) >TeX deserves better. > >Wayne Sullivan 12-Jun-1998 1:57:06-GMT,2445;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id TAA11789 for ; Thu, 11 Jun 1998 19:57:04 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Jun 1998 01:57:03 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IY4IBT07CW0014YS@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 11 Jun 1998 21:35:44 EST Received: from zothommog.evcom.net ([208.136.203.8]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 12 Jun 1998 01:35:34 +0000 (UT) Received: (from kinch@localhost) by zothommog.evcom.net (8.8.8/8.8.8) id VAA18008 for tex-implementors@ams.org; Thu, 11 Jun 1998 21:35:25 -0400 Date: Thu, 11 Jun 1998 21:35:25 -0400 (EDT) From: "Richard J. Kinch" Subject: Re-parameterizing CM math for non-CM text To: tex-implementors@ams.org (TeX Implementors) Errors-to: tex-implementors-request@ams.org Message-id: <199806120135.VAA18008@zothommog.evcom.net> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit In preparation for TUG 98 in Torun, I'm researching the re-parameterization of the CM math fonts (chiefly cmsy10, cmex10, cmmi10) to match various characteristics of arbitrary text typefaces such as weight, x-height, aspect ratio, vertical vs horizontal stem weights, etc. This would use the meta-characteristics of CM math to make new math typefaces that are visually compatible with non-CM text. Although there are a few TUGboat articles mentioning the few non-CM math fonts that exist (for Times and Lucida), there are no direct references that I have found to the subject of *reparameterizing CM* for this purpose. One hears comments to the effect that "[ordinary, un-re-parameterized] CM math looks bad with Times" (and who could disagree with that) but that's more of a problem statement than a solution. Isn't CM math "meta" enough to match quite a range of typefaces? Isn't Knuth's meta-integral (for example) in CM pretty much the last word in what an integral sign can be? We don't really need a distinctively "Lithos" integral sign, do we? I'd welcome any comments or pointers on this subject. Richard J. Kinch Publisher, TrueTeX (R) brand typesetting software. See http://idt.net/~truetex 12-Jun-1998 2:30:46-GMT,2976;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id UAA12380 for ; Thu, 11 Jun 1998 20:30:45 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Jun 1998 02:30:41 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IY4JSJ7L4W000WJQ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 11 Jun 1998 22:18:13 EST Received: from Kitten.mcs.com ([192.160.127.90]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 12 Jun 1998 02:18:04 +0000 (UT) Received: from alexander (quixote.pr.mcs.net [205.164.4.66]) by Kitten.mcs.com (8.8.7/8.8.2) with SMTP id VAA02983; Thu, 11 Jun 1998 21:18:01 -0500 (CDT) Date: Thu, 11 Jun 1998 21:16:09 -0500 From: Don Hosek Subject: Re: Re-parameterizing CM math for non-CM text In-reply-to: <199806120135.VAA18008@zothommog.evcom.net> X-Sender: quixote@mail.bayarea.net To: "Richard J. Kinch" , tex-implementors@ams.org (TeX Implementors) Errors-to: tex-implementors-request@ams.org Message-id: <3.0.3.32.19980611211609.0096e9d0@mail.bayarea.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Content-type: text/plain; charset="us-ascii" At 09:35 PM 6/11/1998 -0400, Richard J. Kinch wrote: >Isn't CM math "meta" enough to match quite a range of typefaces? Isn't Knuth's >meta-integral (for example) in CM pretty much the last word in what an integral >sign can be? We don't really need a distinctively "Lithos" integral sign, do >we? >I'd welcome any comments or pointers on this subject. The one concrete (so to speak) example that I can think of is Donald Knuth's modifications to select cmex characters to match the Concrete Roman with Euler math. I believe his TUGboat article talks a bit about what he did & there's also the code. In some experiments that I did quite some time ago trying to adapt CM math to work with Century Schoolbook, the metaness does in fact go some distance, although there are some frustrating boundary conditions hidden here and there. The only one that springs immediately to mind comes from a MF course I taught back in 89 (yikes--that was NINE years ago), where we attempted to create cmultra (akin to Ultra Bodoni). Some mid-curve control points revealed that certain characters had limits to how far the thickness of strokes could be made before distortions came into play. I suspect that a generic math set can be made, but the glyph shape programs in cm may only be usable as a starting point rather than just being pulled out intact. -dh --- Don Hosek dhosek@quixote.com Quixote Digital Typography 312-953-3679 fax: 312-803-0698 orders: 800-810-3311 For information about SERIF: THE MAGAZINE OF TYPE & TYPOGRAPHY, http://www.quixote.com/serif/ or mail serif-info@quixote.com 12-Jun-1998 8:42:29-GMT,1504;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA22604 for ; Fri, 12 Jun 1998 02:42:28 -0600 (MDT) From: KNAPPEN@MZDMZA.ZDV.UNI-MAINZ.DE Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Jun 1998 08:42:28 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IY4WM64J9S000YDU@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 12 Jun 1998 04:24:59 EST Received: from dzdmzb.zdv.Uni-Mainz.DE ([134.93.8.33]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 12 Jun 1998 08:24:47 +0000 (UT) Received: from MZDMZA.ZDV.UNI-MAINZ.DE by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #22141) id <01IY594CL8UCC8YKQL@MZDMZA.ZDV.UNI-MAINZ.DE>; Fri, 12 Jun 1998 10:24:47 +0100 Date: Fri, 12 Jun 1998 10:24:47 +0100 Subject: Re: Re-parameterizing CM math for non-CM text To: kinch@holonet.net Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <01IY594CL9S6C8YKQL@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: IN%"kinch@holonet.net" X-VMS-Cc: IN%"tex-implementors@ams.org" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT You may want to look at Fukui Rei's tipa Fonts; he has provided timesish and helveticaish parameter sets for a cm style design. Probably some programmes of the symbols will need adjustments, too. --J"org Knappen 12-Jun-1998 10:29:21-GMT,3798;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA24291 for ; Fri, 12 Jun 1998 04:29:20 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Jun 1998 10:29:19 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IY504DIX740016HM@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 12 Jun 1998 06:05:09 EST Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 12 Jun 1998 10:04:58 +0000 (UT) Received: from attila.uni-duesseldorf.de (attila [134.99.64.144]) by xerxes.thphy.uni-duesseldorf.de (8.8.8/8.8.8) with SMTP id MAA04090; Fri, 12 Jun 1998 12:02:48 +0200 (MET DST) Received: by attila.uni-duesseldorf.de (SMI-8.6/SMI-SVR4) id MAA16970; Fri, 12 Jun 1998 12:02:47 +0200 Date: Fri, 12 Jun 1998 12:02:47 +0200 From: Ulrik Vieth Subject: Re: Re-parameterizing CM math for non-CM text In-reply-to: <199806120135.VAA18008@zothommog.evcom.net> (kinch@holonet.net) To: kinch@holonet.net Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199806121002.MAA16970@attila.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit > In preparation for TUG 98 in Torun, I'm researching the > re-parameterization of the CM math fonts (chiefly cmsy10, cmex10, > cmmi10) to match various characteristics of arbitrary text typefaces > such as weight, x-height, aspect ratio, vertical vs horizontal stem > weights, etc. This would use the meta-characteristics of CM math to > make new math typefaces that are visually compatible with non-CM > text. Doesn't Alan Hoenig's mathinst or matkit package (on CTAN) attempt to do something like making a Baskerville-ish set of math symbols? IIRC, he only generates a subset of the CM math fonts, leaving out the italic letters, which are taken form the relevant text fonts. > Isn't CM math "meta" enough to match quite a range of typefaces? > Isn't Knuth's meta-integral (for example) in CM pretty much the last > word in what an integral sign can be? We don't really need a > distinctively "Lithos" integral sign, do we? Depends on the context. Knuth definitely needed an Euler integral sign, which is quite different from the CM integral, but in many cases you might get away with a modification of the CM integral. In addition, you have to be aware that CM math symbols have much less metaness than most of the text characters. When I prepared the Concrete Math fonts (see CTAN:fonts/concmath), I simply took the paramters from Concrete text fonts and used them to generate math fonts, but in some cases they produced nasty surprises. While most of the CM are relatively robust, some of the CM-based AMS symbols aren't. The Concrete style \varkappa and the Hebrew glyphs form xccbm don't look Concrete at all due to deficiencies of the METAFONT coding. Similarly, the circles in \oplus, etc. which are very light in CM became much heavier in Concrete, just because they are based on some paramter originally intended for text glyphs rather than using a fraction of the rule thickness. > I'd welcome any comments or pointers on this subject. You might be interested in the work on new math font encodings, which apart from producing virtual fonts also involves a certain amount of METAFONT hackery of CM, Concrete and Euler Symbols. See the Math Font Group's homepage at http://www.tug.org/twg/mfg/ and our EuroTeX paper at http://www.thphy.uni-duesseldorf.de/~vieth/subjects/tex/articles/new-math.ps.gz Cheers, Ulrik Vieth. 12-Jun-1998 17:35:33-GMT,2353;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA02591 for ; Fri, 12 Jun 1998 11:35:32 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Jun 1998 17:35:31 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IY5F1MPIXC0017UC@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 12 Jun 1998 13:12:52 EST Received: from zothommog.evcom.net ([208.136.203.8]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 12 Jun 1998 17:12:39 +0000 (UT) Received: (from kinch@localhost) by zothommog.evcom.net (8.8.8/8.8.8) id NAA03424; Fri, 12 Jun 1998 13:12:33 -0400 Date: Fri, 12 Jun 1998 13:12:33 -0400 (EDT) From: "Richard J. Kinch" Subject: Re: Re-parameterizing CM math for non-CM text To: tex-implementors@ams.org (TeX Implementors) Errors-to: tex-implementors-request@ams.org Message-id: <199806121712.NAA03424@zothommog.evcom.net> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thanks to all who responded. Thanks especially to Ulrik Veith who alerted me to Alan Hoenig's mathkit and mathinst projects. These two items respectively reparameterize CM in the method I envisioned, and create TeX or LaTeX style apparatus to make the fonts usable. That's quite a piece of work. I am going to concentrate on three aspects not addressed by mathkit or mathinst : (1) conversion of the METAFONT shapes to Type 1 outlines via Metafog, which will make the end-user's application much simpler, (2) improving the meta-ness of the CM math characters (that is, upgrading the METAFONT code for the CM math characters) so as to make them fit a wider range of typefaces with more subtlety, and (3) automatic characterization of the target text typeface by geometric analysis, thus avoiding the need for manual measurements. These aspects all have to do with the kind of computational geometry and topology I have been dealing with over the recent years since the original Metafog, and would seem to be tractable given that background. Richard J. Kinch Publisher, TrueTeX (R) brand typesetting software. See http://idt.net/~truetex 16-Jul-1998 22:37:46-GMT,2173;000000000001 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id QAA05262; Thu, 16 Jul 1998 16:37:45 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id QAA22404; Thu, 16 Jul 1998 16:37:44 -0600 (MDT) Date: Thu, 16 Jul 1998 16:37:44 -0600 (MDT) To: tex-implementors@math.ams.org, LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Quotation character conventions, and TeX/LaTeX support thereof Message-ID: I have just read a new document ``Quotation Character Semantics'', available on the Web at http://www.unicode.org/unicode/uni2errata/QuoteErrata.html This document discusses quotation character conventions in several European languages, and a related document ``Apostrophe Semantics'' at http://www.unicode.org/unicode/uni2errata/Apostrophe.htm discusses issues that appear when more than one apostrophe-like character is available for use, as is the case in Unicode. I raise these issues on the tex-implementors and latex-l lists because I believe they are relevant for TeX markup of documents, and for the LaTeX-3 design. ----------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ----------------------------------------------------------------------------- 17-Jul-1998 3:11:28-GMT,5003;000000000001 Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id VAA10611 for ; Thu, 16 Jul 1998 21:11:27 -0600 (MDT) Received: from localhost (localhost) by proxy1.ba.best.com (8.9.0/8.9.0/best.in) with internal id UAB05403; Thu, 16 Jul 1998 20:11:26 -0700 (PDT) Date: Thu, 16 Jul 1998 20:11:26 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <199807170311.UAB05403@proxy1.ba.best.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="UAB05403.900645086/proxy1.ba.best.com" Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --UAB05403.900645086/proxy1.ba.best.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 16 Jul 1998 15:46:31 -0700 (PDT) from e-math.ams.org [130.44.194.100] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Operation timed out with sparky.randomnoise.com. Warning: message still undelivered after 4 hours Will keep trying until message is 1 week old --UAB05403.900645086/proxy1.ba.best.com Content-Type: message/delivery-status Reporting-MTA: dns; proxy1.ba.best.com Arrival-Date: Thu, 16 Jul 1998 15:46:31 -0700 (PDT) Final-Recipient: RFC822; drf@randomnoise.com Action: delayed Status: 4.4.1 Remote-MTA: DNS; sparky.randomnoise.com Last-Attempt-Date: Thu, 16 Jul 1998 20:11:26 -0700 (PDT) Will-Retry-Until: Thu, 23 Jul 1998 15:46:31 -0700 (PDT) --UAB05403.900645086/proxy1.ba.best.com Content-Type: message/rfc822 Return-Path: Received: from e-math.ams.org (e-math.ams.org [130.44.194.100]) by proxy1.ba.best.com (8.9.0/8.9.0/best.in) with SMTP id PAA13282 for ; Thu, 16 Jul 1998 15:46:31 -0700 (PDT) Received: by e-math.ams.org; id AA11632; Thu, 16 Jul 1998 18:45:14 -0400 Received: from axp14.ams.org by math.ams.org via smtpd (for e-math.ams.org [130.44.194.100]) with SMTP; 16 Jul 1998 22:45:14 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZH8BMTC4W0001Z9@AXP14.AMS.ORG> for drf@randomnoise.com; Thu, 16 Jul 1998 18:38:20 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 16 Jul 1998 22:37:54 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id QAA05262; Thu, 16 Jul 1998 16:37:45 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id QAA22404; Thu, 16 Jul 1998 16:37:44 -0600 (MDT) X-Url: http://www.math.utah.edu/~beebe Date: Thu, 16 Jul 1998 16:37:44 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Quotation character conventions, and TeX/LaTeX support thereof To: tex-implementors@ams.org, LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE Cc: beebe@math.utah.edu Errors-To: tex-implementors-request@ams.org Message-Id: X-Us-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-Fax: +1 801 585 1640, +1 801 581 4148 I have just read a new document ``Quotation Character Semantics'', available on the Web at http://www.unicode.org/unicode/uni2errata/QuoteErrata.html This document discusses quotation character conventions in several European languages, and a related document ``Apostrophe Semantics'' at http://www.unicode.org/unicode/uni2errata/Apostrophe.htm discusses issues that appear when more than one apostrophe-like character is available for use, as is the case in Unicode. I raise these issues on the tex-implementors and latex-l lists because I believe they are relevant for TeX markup of documents, and for the LaTeX-3 design. ----------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ----------------------------------------------------------------------------- --UAB05403.900645086/proxy1.ba.best.com-- 18-Jul-1998 15:12:31-GMT,1552;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA22469 for ; Sat, 18 Jul 1998 09:12:30 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 18 Jul 1998 15:12:30 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01IZJKNNC0QO000C95@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 18 Jul 1998 10:52:55 EDT Received: from sun06.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0EWA008IPPBYP2@sun06.ams.org> for tex-implementors@axp14.ams.org; Sat, 18 Jul 1998 10:52:46 -0400 (EDT) Date: Sat, 18 Jul 1998 10:52:46 -0400 (EDT) From: Barbara Beeton Subject: note from Don Knuth (fwd) To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII if anyone has any pending questions, now's the time to send them in. thanks much. -- bb ---------- Forwarded message ---------- Date: Thu, 16 Jul 1998 13:09:45 -0700 To: bnb@ams.org Subject: note from Don Knuth Dear Barbara, I'm approaching the end of my 700-page book on digital typography (only the index remains, hurray); so it is now time to ask you to dump on me all supposed errata that have been sufficiently vetted that I might need to take a look--- before the next time I do this, in the year 2003 or so! Sincerely, Don 20-Jul-1998 9:23:36-GMT,2139;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA04155 for ; Mon, 20 Jul 1998 03:23:34 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Jul 1998 09:23:33 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZM0RWB0BK000G0V@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 20 Jul 1998 04:56:18 EDT Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 20 Jul 1998 08:55:55 +0000 (UT) Received: from attila.uni-duesseldorf.de (attila [134.99.64.144]) by xerxes.thphy.uni-duesseldorf.de (8.8.8/8.8.8) with SMTP id KAA28078; Mon, 20 Jul 1998 10:55:21 +0200 (MET DST) Received: by attila.uni-duesseldorf.de (SMI-8.6/SMI-SVR4) id KAA28845; Mon, 20 Jul 1998 10:55:20 +0200 Date: Mon, 20 Jul 1998 10:55:20 +0200 From: Ulrik Vieth Subject: Re: note from Don Knuth (fwd) In-reply-to: (message from Barbara Beeton on Sat, 18 Jul 1998 10:52:46 -0400 (EDT)) To: bnb@ams.org Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199807200855.KAA28845@attila.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit > if anyone has any pending questions, now's the time to send them in. > thanks much. > -- bb This reminds me of one question that appeared recently on comp.text.tex: Why does cmr5 use a different encoding than other cmr fonts (triggered by setting ligs:=1 instead of ligs:=2). When the question first appeared, I suspected it was known bug that was considered too late to fix because it would change the metrics, but then I searched the archived messages and found that it was apparently never reported before. So it is really a known bug or an intentional feature? The effect is clearly visible in the font samples of Volume E. Cheers, Ulrik. 20-Jul-1998 13:09:17-GMT,3922;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA07759 for ; Mon, 20 Jul 1998 07:09:16 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Jul 1998 13:09:16 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01IZM8VZGCG0000F9J@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 20 Jul 1998 08:48:25 EDT Received: from sun06.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0EWE0055E8WCPQ@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 20 Jul 1998 08:48:12 -0400 (EDT) Date: Mon, 20 Jul 1998 08:48:12 -0400 (EDT) From: Barbara Beeton Subject: Re: ligatures in cmr5 (was note from Don Knuth (fwd)) In-reply-to: <199807200855.KAA28845@attila.uni-duesseldorf.de> To: Ulrik Vieth Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII ukrik asks why cmr5 uses a different encoding than other cmr fonts with respect to ligatures. i'm pretty sure it isn't a bug. i'm pretty sure it has to do with the relatively wider-than-high settings of the cmr5 parameters, with the result that the distance between the two stems of, say, the "fi" ligature are rather less than the normal interletter spacing between the separate letters "f i", with the result that the ligature will look out of place in a word similarly to the way that the separate letters "f i" look ungraceful in the same word with cmr10. okay. here's what some searching in my own archives has uncovered. this was in a collection of knuth's responses to questions raised in texhax. -------------------- Date: 09 Jul 88 2345 PDT From: Don Knuth To: BB@SAIL.Stanford.EDU Subject: sundry matters for a saturday This is going to be a rather long letter, as I've just spent more than 16 hours (during 2.5 days) reading more than 100 issues of TeXhax! I have mountains of other mail to read next, so I thought it would be best just to write you a note containing all the things that struck me as was doing this exercise, instead of trying to send lots of little messages to people whose email addresses are inscrutable to me. [...] -------- 88.21 and 87.89 I intentionally omitted ligatures from cmr5 because this font is so extended and letterspaced the results look better without. The f-ligatures are put in fots only when combinations like "fi" look wrong due to interference of bulbs (or, in sans-serif fonts, when the characters are too dark in conjunction), not because there's a `fi' character in our language! In 6-point type a ligature fi looks better than the two characters f and i; in 5-point type it doesn't. (See the `magnified five-point type' example on page A16 for two fi non-ligatures! I believe the first edition had ligatures in this example, and I decided to drop them after looking closer at it.) -------------------- so, it's a feature, not a bug. regarding don's letter to me, it probably would have made sense for me to forward it to texhax, but i can't find it, and i can't find any evidence that i sent the entire thing to tex-implementors either. (i could have sent out items one by one to the people who asked, in much the same way that i distribute don's responses to bug reports -- yes, before anyone asks, i am still delinquent in completing the distribution of the last set, now at least two years overdue, but i shall complete this before this year's tug meeting.) so i think i shall just post the entire message to tex-implementors as a sort of "ten years ago this month" goodie. it should keep you all out of mischief for a while, looking up the references. -- bb 20-Jul-1998 13:22:51-GMT,27368;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA08011 for ; Mon, 20 Jul 1998 07:22:49 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Jul 1998 13:22:49 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #30286) id <01IZM95EHVVK000EVD@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 20 Jul 1998 08:56:04 EDT Date: Mon, 20 Jul 1998 08:55:52 -0400 (EDT) From: bbeeton Subject: ten years ago this month To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <900939352.774438.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: here's a message from don knuth addressing a lot of little questions that arose either in tugboat or in texhax ten years ago. the same questions still seem to come up from time to time, so maybe this little dose of history will do some good. -- bb -------------------- Date: 09 Jul 88 2345 PDT From: Don Knuth To: BB@SAIL.Stanford.EDU Subject: sundry matters for a saturday This is going to be a rather long letter, as I've just spent more than 16 hours (during 2.5 days) reading more than 100 issues of TeXhax! I have mountains of other mail to read next, so I thought it would be best just to write you a note containing all the things that struck me as was doing this exercise, instead of trying to send lots of little messages to people whose email addresses are inscrutable to me. (I've never learned how to send mail properly to other networks, and the number of keystrokes seems to be getting longer each month; so I expect some software is available to help, but I don't have the inclination to learn it these days when mail is not the greatest joy in my life!) >From last July to this June I've been totally immersed in finishing Concrete Mathematics (a 640-page book, which you know about because it is the one dedicated to Euler in several senses). At last it is done and A-W tells me they expect bound copies before July 31 --- Hurray! I plan to write a short piece for TUGboat, explaining about the Concrete fonts and their relation to Euler fonts and the macros I used for Euler fonts. (But I've got some earlier deadlines to meet first... with summer visitors I'll do research on random graphs, and I'm presenting a "major" paper about the evolution of TeX at a conference in Germany at the end of September.) As you can see from Computers & Typesetting, my normal rate of output is approximately one printed page per calendar day (since those five volumes plus the new material in Volume 2 totalled about 3600 pages in ten years). Therefore the creation of a 640-page book in less than twelve months meant I was doing twice as much as normal. I was able to keep halfway sane only by not reading my mail, so Phyllis nicely sorted it into categories and let it accumulate in eight large boxes. So far I've read through the electronic mail and the newsy journals like the Notices (nice new format) and TUGboat and Focus and the Intelligencer. It was extremely encouraging to see the acceptance of TeX by mathematicians everywhere, judging by many different reports in the Notices. -------- I'll be using long dashes to give some structure to this letter, since I'm going to ramble on about lots of different things! First, I really like the cover design of TUGboat 9.1; thank you. -------- More about TUGboat 9.1, here's a copy of a note I just wrote Pierre, inspired by his article: >Bravo for your superb discussion of Turkish hyphenation! Well done TeXnically >and well written expositorially. > >I don't think there's any reason to shy away from using @ instead of \`, >as far as plain TeX is concerned. But the symmetry between \` and \' is >appealing. > >Now on to page 43, where you discuss Unix stuff: >The "strange path" errors at 118dpi can be patched without much trouble (like >the change to GREEKU on page 37 of the change list that's bound with TUGboat >9#1). Namely, the patched code will test to see if some point that should be >to the right of another is actually to the left because of the perverse >rounding of other points at low res. I don't have time to do this test any >more myself, but I made several dozen such changes just before releasing the >new CM in 86. I'm sure you don't have time either; but somebody does, let's >hope, and I'll pay $2.56 for a good bugfix! > >What I did was to say tracingall just before the offending statement >(first isolating the offending character on file test.mf, and using >"mode=whatever; mag=whatever; input ztest" after setting z.mf to cmtex10.mf >or whatever parameters were involved), then saying >"showvariable x,y;" and plotting the x,y coordinates on a piece of paper >so that it became obvious what had gone wrong. -------- Still more about TUBgoat I mean TUGboat 9.1: Hoenig's remark on page 46 is great, "the spelling checker works like lightening"!! Maybe it's an advantage to have FEWER words in a spelling checker dictionary... On page 57, Stephen misses a lot of the expandable primitives in his 2(b) --- he doesn't mention \jobname, \romannumeral, \input, \meaning, \noexpand, etc. or conditionals (the latter being the trickiest). Finally, on the ad for the Montr\'eal TUG meeting, it would have been better to use a logo font for METAFONT... -------- Re Dick Palais's final column in this year's Notices, page 396, in the last paragraph (middle column) there are many consecutive hyphenated lines! This has happened elsewhere too; it suggests increasing \doublehyphendemerits because TeX could probably find a better solution if told to be a little fussier. Also, in a later issue (page 507, right column, line 10), the interword spacing was allowed to get VERY tight. I think the spaceshrink needn't be quite that drastic. Sure the columns are narrow, but words need to be separated by more than .05em! -------- Funny thing in TUGboat 8.3 page 304 Her-rmann could join the list on page 266! -------- Do you have any more of my pieces saved up for future TUGboats, other than the exercises for TeX: The Program? By the way, Bart wanted to see that; I suppose it is timely; have I sent camera copy? -------- And now to TeXhax. I'll identify by year then issue number (e.g., "87.98" means V87 #98). Some of these remarks you may wish to forward to the people concerned, when and if you have time; I haven't time myself, except in one case noted below. -------- 87.98 Eschenberg People don't seem to know that they can say "\let\par=\cr \obeylines" instead of bothering to define \autocr. -------- 87.104 re KSTfonts: No, I had nothing to do with those fonts, they existed years before I began to work on TeX. -------- 88.17 Stephan v. B brings up the interesting problem of changing \parskip just AFTER a paragraph has begun. His analysis doesn't make sense to me (or perhaps I'm missing something): if the empty hbox in his example occurs just after a page break, the top line should still be fine; it wouldn't move up into the header position, it would move up to where the empty hbox is. (Unless the height of the first line is more than the baselineskip, of course.) But he should say \nobreak before \vskip-\baselineskip, otherwise there might be a page break and his previous page will be too short. With that patch, his solution seems to be OK, albeit "inelegant". The solution by Reid in 88.19 IS elegant. This would be a good topic for you to discuss in your annual Q&A session in the summer TUG meeting, if you're not already fully booked with examples: Many people are unaware that "\noindent\par" is essentially a no-op except for contributing \parskip glue. (It doesn't make a blank line.) Reid uses this fact by getting rid of the paragraph indentation box with \lastbox, thus making the horizontal list empty (as if the paragraph had begun with \noindent) so the paragraph is effectively flushed and you can start over. But Reid's solution isn't stated perfectly: (a) He shouldn't refer to the paragraph indentation as "glue", it's really a box (as he knows); (b) if the paragraph began with \noindent there's no indentation box present, but he apparently thinks there's a box of width zero --- in this case \lastbox is void but \wd0 will still come out 0pt so he's OK; (c) \endgraf would be safer than \par when this trick is combined with others. -------- 88.17 Jim Walker's elegant solution to Hosek's "Tom Jones puzzle" would likewise be a good note for TUGboat. -------- 88.21 and 87.89 I intentionally omitted ligatures from cmr5 because this font is so extended and letterspaced the results look better without. The f-ligatures are put in fots only when combinations like "fi" look wrong due to interference of bulbs (or, in sans-serif fonts, when the characters are too dark in conjunction), not because there's a `fi' character in our language! In 6-point type a ligature fi looks better than the two characters f and i; in 5-point type it doesn't. (See the `magnified five-point type' example on page A16 for two fi non-ligatures! I believe the first edition had ligatures in this example, and I decided to drop them after looking closer at it.) -------- 88.26 "making fonts for ln03" Charles LaBrec comments that there may be a bug in the program for lowercase e, because the barline is placed vertically at y1=good.y bar_height wrt tiny.nib, while the actual bar thickness is unrelated to tiny.nib. He's right, as far as I can tell; the bowl that comes down to this position is drawn with tiny.nib, but that's no reason for it to be at a good y coordinate. And later the actual bar thickness, .6[thin_join,vair], isn't necessarily an integer; again there's no reason to do the rounding. So I could have left off the "good.y" when defining y1. (The same holds for ae and oe.) However, I've decided not to change this, since it only affects the barline by one pixel at most (and the barline of e can well afford to move up in this font). There's no instability (no "pimple" possibility) in a straight barline. And I may have had some obscure reason that I've forgotten; so I don't want to take a chance on rocking the boat. Only serious flaws should be corrected from now on... But if anybody wants to drop the "good.y", they can do it (it's like hand-tuning the fonts). Any change that improves the perceived appearance of the fonts without changing the TFM files is OK by me. I do think LaBrec's extensive LN03 experiments would be of interest to a large community. He should be encouraged to submit a note to TUGboat about the write-white changes he came up with. -------- 88.28 Flynn asks about detecting the current font. Nobody seems to have responded with the correct answer, namely \expandafter\if\the\font\tentt \else \fi (\ifx also works here). -------- 88.30 Hankerson's "bad pos" experience (re IBM 3812) This is worrisome: Apparently my updates to the sources aren't getting through. Here's a person who seems to have installed MF very recently (his cm base file was preloaded on 19 Mar 88), but he gets an error that can only occur if he has an old file GREEKU.MF (not containing the correction to page E179 dated 13 Oct 86). Also, he's still running version 1.0 of MF. If he got his software from K&S, presumably they have uptodate CM sources. If he got it from Maria Code, can it be that she still hasn't got the updates from 1986 on her VMS tape? -------- 88.36 Stephan's question about column widths isn't answered here. If I didn't put the answer in Appendix D, I'm pretty sure I told somebody... It's fairly easy to do this with \lastbox and \unskip in alternation, because TeX always produces an alternating sequence of boxes and tabskip glue (even when columns have been spanned it puts out boxes for the spanned columns). However, TeX doesn't put empty boxes at the right of short rows; so you need to know how many columns there were. -------- 88.37 Double-column output is discussed here and many other places, and people keep asking about triple columns too. Somebody should write to TeXhax reminding the world about Craig Platt's nice little note in TUGboat some years ago. -------- 88.42 Yap (and 88.50 Sullivan) on fonts with different nonzero checksums. There was a bug in the circle and line fonts used with LaTeX, causing the TFM file to be different at different magnifications (e.g. with SliTeX they are magnified). I fixed that bug long ago (well, last July); so I hope the corrected sources are getting to the world. Leslie has been maintaining the standard *.tex and *.sty files for LaTeX, but I'm not sure if he or anybody else is keeping the LaTeX *.mf files current. Somebody in a more recent issue (I forget where) claims that the arrowheads in line10 etc are in the wrong position. I didn't spot any problems in my tests last year, so I'll be surprised if that is really so; indeed, I have proofmode sheets (dated 8 July 1987 I see!) that display perfect alignment between arrowheads and the lines used for vectors, at resolution 2602pixels/inch. The rumor about misplaced arrowheads is therefore false. (One or two characters did have the wrong height or something, as I recall, before I fixed that font, so the picture environment macro may have gotten a bit confused.) -------- 88.45 Hill on underlined text for lawyers. Solutions by Sullivan and Lau in 88.52; discussion by others indicating that a font of underlined characters is best. But nobody mentions getting underlines in the spaces between words. This can be done, if desired, with leaders instead of glue; the lines will break (and leaders removed between lines) as usual when a paragraph is made. But it's easiest to provide only frenchspacing; I don't have an easy way to account for the space factors. Here's a short test file I just tried: \def\usp{\leaders\hrule height-.2pt depth.6pt\hskip\fontdimen3\font plus\fontdimen4\font minus\fontdimen5\font} \obeyspaces \let =\usp \tracingall A B c. D e f. \showlists Interestingly (to me anyway), you get a normal space after the D, not a leader-with-rule space. I wonder if Jacques's sneaky trick by which he implemented the complex French convention of quotes within quotes would lead to a way to use leaders for underlining parts of paragraphs... -------- 88.45 Nonbreaking hyphens Here's a letter I just sent to jimc at math.ucla: >I just spent 16 hours reading the past 100 issues of TeXhax, and >when I finished I didn't recall seeing an answer to your query in V88#45. >Here's what I hope somebody told you in the meanwhile: > >Your definition of \q- didn't work because TeX doesn't put >"\penalty\exhyphenpenalty" into your text after an explicit hyphen, >it puts "\discretionary{}{}{}" there; TeX doesn't look at the >current value of \exhyphenpenalty until it breaks a paragraph into lines, >and every occurrence of \discretionary{}{}{} is then treated the same. > >Exercise 14.6 explains how to suppress all line breaks after explicit >hyphens; but you specifically want to have selective control, with >some hyphens permitting breaks and others not. > >One way to do what you wanted is > \def\q-{{\hyphenchar\font=0`-'}} >since TeX won't regard the - as an explicit hyphen if it doesn't match >the \hyphenchar of the current font. > >Another way, which is less subtle and less efficient but who cares really, is > \def\q-{\hbox{`-'}} >since you can always suppress line breaks by putting things in boxes. >(I mention this on line 11 of page 93.) ------ 88.48 longrightarrow Ian Moor says "\longrightarrow comes out with the left half of the stem one pixel lower than the right half... it seems to be a font bug... is there a fix?" Yes, the fix is to get CM fonts (I hope). I vaguely recall that these characters didn't line up, years ago, but the problem was fixed already in the later versions of AM fonts. Hence I think this person must have an extremely old AMSY10 or maybe the old original CMSY10. On the other hand, the new CM routines for minus and for rightarrow aren't identical. The minus sign is drawn with rule.nib; the rightarrow is drawn by filling a contour using crisp.nib, which is a null pen in cmsy. In both cases the thickness of the stroke is rule_thickness, which is an integer number of pixels; and the center of the horizontal stroke is math_axis, which is at a "good.y" raster position with respect to rule_thickness. Therefore MF should put the stroke at the same place in both cases (unless I am outfoxing myself again). If there's a nonsquare aspect ratio, I'm not sure what might happen, since that can get very tricky; but Moor speaks of a previewer, so I suppose he's talking square pixels. If anybody with square pixels finds that the minus sign isn't at precisely the same height as the right arrow, I'd sure like to know what mode_def can do that. (Well, I don't REALLY want to know, because I really want to finish Volume 4; but as a scientist I have a compulsion to track down the causes of supposedly impossible things....) -------- 88.52 Hosek comments that cmr17 looks `anemic' compared to 18pt Century. Maybe so, and I'm not wounded deeply by such criticism; but let me get my two cents' worth in anyway explaining what I had in mind! I didn't have much time to test the 17pt fonts (and I don't remember if I even was able to look at on the APS before going to print --- probably not, as I had to leave for Boston), but my goal was not to make a font especially for title pages but rather to make a font with approximately the same "color" (grayness) as the other point sizes. Also, the letters are tighter together than in a magnified font of smaller size. I think cmr17 came out reasonable from those criteria. But a font specifically for titles should usually be bolder. My understanding is that a font family (different point sizes of the same name) is supposed to have consistent color. I tried to make cmr5 look about as gray as cmr10 (although cmr5 scaled 2000 is bolder than cmr10). It may well be that the 18pt Century font Hosek was comparing was really a demibold, but not called that since the customer just wanted something for titles and the nomenclature wasn't terribly important in 1900. -------- 88.54 The dictionary problem with double columns. Yes your \xdef suggestion is a good way to capture \topmark; but another instructive way is to put it into a box. I see that Skinner mentions this in 88.57. -------- 88.55 Joachim doesn't dig "\finalhyphendemerits=0". He seems to think this prevents a line break somehow. What it really does is say that we don't mind if the second-last line ends with a hyphen. (That was a memorable bug in CML many years back, right?) -------- 88.58 MF via WEB2 problem Ouch, that's not pleasant to see --- probably symptomatic of what people are doing out in the field --- installing MF and trying it first on CM fonts instead of on the TRAP test! A lousy way to proceed. -------- 88.58 contains a great phrase: Elsewhere we've been called TeXies, TeXophiles, and TeXites; but TeXegetes is a clear winner! -------- 88.58 Peter Flynn asks for oldstyle numerals in the csc fonts. I'm not so sure; I think I looked at a bunch of Monotype font specimens before I did this one, and if they had oldstyle I probably would have followed. Isn't the oldstyle zero pretty hard to tell from the lowercase o? And his example with digits 822 is puzzling since 8 is the same in both styles (so is 6). I guess there's no compelling reason to change. But anyway he tried unsuccessfully to solve the problem by making digits active. Several other people had similar troubles in other TeXhax notes, I forget where. They forget that they have to make the character active when they're defining it AND when they're using it later... The "right" way is illustrated in my TUGboat article about Macros for Jill. For example, here's what he wanted to do: \font\tencsc=cmcsc10 \def\oszero{{\teni0}} \def\osone{{\teni1}} % 2,3,4,5,7,9 to be done similarly; 6 and 8 can stay {\catcode`0=\active \catcode`1=\active \gdef\sc{\tencsc \catcode`0\active \catcode`1\active \let0=\oszero \let1=\osone}} Here's my 10th test of {\sc small caps with 1001 variations}. \nopagenumbers\bye Of course this is a "fragile" construction, since you can't change catcodes inside a \centerline, say, as normally defined in plain TeX; a more complicated definition of \centerline (analogous to the way I did \footnote) would allow dynamic catcodes. Perhaps I should have done that...too late now! -------- 88.61 No hyphenation after a hyphen It's not quite right to say "the penalty plus skip allows a break"; rather "the penalty allows a break, and the skip restarts an attempt at hyphenation". But the \penalty0 isn't needed, since there's already a \penalty\exhyphenpenalty present [well, what's actually present is \discretionary{}{}{}, which amounts to the same]; and even with \slash, the \hskip would allow a break. [There's an \allowhyphens macro defined in Appendix D but not in plain TeX (see TeXbook index); perhaps I should have put it into PLAIN.] Anyway, in the example the person gave, I would have just inserted a discretionary hyphen after seeing an underfull or overfull box. (Same in the 2-inch-wide newspaper example somebody else sent in; one of the names in the second-last line could have been hyphenated. Such changes take less than 1% of the time of copy preparation, so I really don't believe everything should be fully automatic.) -------- In general it's clear that Malcolm is doing an incredible service as moderator of TeXhax, and we should make sure that he gets at least 1% of the thanks he deserves. I don't know his email address at Stanford, but I did send an effusive note of thanks to texhax-request.... -------- After reading all these TeXhax, I'm impressed by the TeXpertise demonstrated by so many people. But there were also some things I was hoping to find that weren't there. For example, I didn't see a single item from Mexico (and just one from Spain). Are our computer networks set up in such a way as to exclude our Southern neighbors? The people south of the border are quite creative and we can learn from each other if we have better communication, so I'm disappointed to see it lacking. Another thing I missed: Nobody is experimenting with new versions of the CM fonts; that's so much fun, why haven't they tried?? Everybody plays with and reports mode_defs (99 people independently tried to solve the write-white problem); but nobody is encouraged to make even trivial modifications like a slanted typewriter 9pt. Somebody asked for a new version of AMNARO, but didn't realize that a novice could come up with it very quickly. (My daughter designed five special versions of CM fonts for the title page of her high-school graduation programs --- in less than an hour, with no previous experience!) The old AMNARO was my hasty attempt to match the headline font in a newspaper clipping from 1910 or so, when Jill was trying to emulate it in a family history report, and I remember that I hacked it together for her in almost no time. The TESTFONT.TEX routines and the explanation of parameters at the beginning of Volume E aren't that inscrutable are they? Alas, I must have failed. Nowhere in all those TeXhax did I see any mention of such font experiments, except in 88.52 where Don Hosek points out somewhere I said that I've limited the "standard" fonts drastically (thousands of reasonable possibilities exist) but provided some as demonstrations of what can be done. Sigh, people don't even try to make the ones they know they need (LaTeX's cmcsc9 and cmcsc8); they merely try mag=.9 and mag=.8. I guess we don't have to worry about bad fonts proliferating; we've scared everybody from even experimenting in the easy-fun ways! -------- Still another thing I wish had been happening: DRF designed a beautiful "AMF" format (extending TFM) and an extended symbolic form (analogous to PL) to go with it, together with utilities analogous to TFtoPL and PLtoTF... as you know. This allows device drivers to substitute, for any character in a font, any combination of characters in any number of other fonts. It's a super design, and Arbortext implements it in DVIAPS and other drivers DRF wrote for them years ago. So why don't they publicize it? So many people are worried about how to use Postscript fonts and other printer-resident fonts, but the fonts don't have accents etc. This convention solves all that. I don't think Arbortext gains anything by keeping mum about it. Nor do they lose by publishing it as a standard method of font-mapping. They are way ahead, having an implementation, so they needn't prevent other driver/previewer writers from devising similar implementations (non trivial but possible).... Similarly, Adobe tells what Postscript does but they don't reveal their algorithms about how they implement it. Standards are a GOOD THING, and this is one important kind of standard that should not be kept under wraps any longer. Please discuss this with Dave Rogers. I learned about the format only when looking at DVIAPS.WEB (having lost the documentation for our APS operator). As you may recall I mailed you an excerpt when I found it; I should have suggested publication in TUGboat already then, but I was preoccupied with Concrete Math. -------- Finally, I just got a note from Edgar Fu\ss, who says he wrote you about a suspected problem with version 2.92. I've responded to him that the behavior he observed ("Transcript written on ?.") is exactly correct, not an error. When a user does something that's really crazy (read nasty), TeX has to keep going; but TeX needn't worry about giving optimum service in the presence of perversity! The string pool is in use when a file name is being scanned, and if the user wants to put the file name on two separate lines TeX just doesn't choose to remember the name of the log file. Thus, it's not a bug, it's a feature (better to do that than to expire or to go to great pains for little gain). I have, however, just made a small change to TeX and MF, suggested by Chris Thompson. When TeX is almost out of memory, this change will allow it to run slightly longer in certain cases (and TeX's actions before dying will be somewhat more logical). The new change doesn't fix a bug, so I needn't have made it; but the dynamic allocation routines are of general interest, so I do want them to reflect my true intentions. Chris noticed that they didn't behave "continuously", as they stood. Thus, the SAIL sources of TEX.WEB[tex,sys] and MF.WEB[mf,sys] and all the TRIP and TRAP test stuff on [tex,sys] has changed again today and should be UNDEKed by somebody and moved to SCORE. The version numbers haven't changed (it's still TeX 2.93 and MF 1.5), because I decided that this change is just an optimization not a correction. It comes just adjacent to the previous change so it's best considered part of the previous change. -------- So sorry to have rambled on and on like this; now I can go to sleep, in preparation for several hundred letters to read tomorrow! (The snail-mail kind.) (Mostly about math and CS.) 22-Jul-1998 14:17:23-GMT,3010;000000000011 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA12030 for ; Wed, 22 Jul 1998 08:17:21 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 22 Jul 1998 14:17:13 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP3WNJYZ4000Q4B@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 22 Jul 1998 09:58:37 EDT Received: from helios.edvz.univie.ac.at ([131.130.1.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 13:58:25 +0000 (UT) Received: from VM.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 2236; Wed, 22 Jul 1998 15:58:19 +0100 (MEZ) Received: from VM.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by VM.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 8948; Wed, 22 Jul 1998 15:58:19 +0100 Date: Wed, 22 Jul 1998 15:53:00 +0100 (MEZ) From: Peter Schmitt Subject: Re: note from Don Knuth (fwd) In-reply-to: Your message of Sat, 18 Jul 1998 10:52:46 -0400 (EDT) To: Barbara Beeton , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <01IZP3WOHTPU000Q4B@AXP14.AMS.ORG> On Sat, 18 Jul 1998 10:52:46 -0400 (EDT) you said: >if anyone has any pending questions, now's the time to send them in. > -- bb Recently I noticed an inconsistency in the handling of arithmetic overflow. While usually this generates an errormessage, one case is _not_ detected: \advance'ing a \count register (while doubling the same number triggers an error!) The following short file can be used to watch this: \newcount \n \newcount \c \newcount \C \newdimen \d \newdimen \D \newskip \s \newskip \S \def\report {\immediate\write0 {added up: \the\add . . . . doubled up: \the\double } \line {\strut\rlap{(added up)}\hfill \llap{$\the\add$}\qquad \rlap{$\the\double$}\hfill\llap{(doubled up)}} } \def\test #1#2 #3#4 {\n=1 \let \add #1 \add #2 \let \double #3 \double #4 \loop \advance \n by 1 \advance \add by \add \multiply \double by 2 \report \ifnum \n<33 \repeat } \test \c 1 \C 0 % no overflow warning! \test \c 0 \C 1 \test \d 1sp \D 0sp \test \d 0sp \D 1sp \test \s 1sp \S 0sp \test \s 0sp \S 1sp \end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 22-Jul-1998 15:01:43-GMT,1221;000000000001 Received: from vms.rhbnc.ac.uk (alpha1.rhbnc.ac.uk [134.219.201.113]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA12895 for ; Wed, 22 Jul 1998 09:01:40 -0600 (MDT) Date: Wed, 22 Jul 1998 16:01:35 +0100 From: Philip Taylor (RHBNC) Reply-To: P.Taylor@vms.rhbnc.ac.uk To: beebe@math.utah.edu CC: TEX-IMPLEMENTORS@AMS.ORG, CHAA006@vms.rhbnc.ac.uk Message-Id: <980722160135.1a77@vms.rhbnc.ac.uk> Subject: Re: note from Don Knuth (fwd) >> I happen to disagree strongly with him on this point: all >> arithmetic at the user level, such as \multiply and \advance, >> should go through single routines that do check for overflow. Hear hear. One of the strongest features which we were able to adduce when insisting on VAX/VMS architecture many years ago (in preference to the countless platforms on which Unix ran) was that the VAX detects integer overflow, something that very few other architectures did. I was intrigued to read in yesterday's Java bulletin that integer I/0 yields an ArithmeticException whilst real x/0.0 yields Double.POSITIVE_INFINITY. Since NTS is predicated on the use of Java, I think we can give some reassurances in this area. ** Phil. 22-Jul-1998 15:01:58-GMT,1898;000000000001 Received: from AWIUNI11.EDVZ.UniVie.AC.AT (helios.edvz.univie.ac.at [131.130.1.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA12904 for ; Wed, 22 Jul 1998 09:01:55 -0600 (MDT) Message-Id: <199807221501.JAA12904@csc-sun.math.utah.edu> Received: from VM.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 2253; Wed, 22 Jul 98 17:02:20 MEZ Received: from VM.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by VM.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 9179; Wed, 22 Jul 1998 17:02:20 +0100 Date: Wed, 22 Jul 98 16:57:16 MEZ From: Peter Schmitt Subject: Re: note from Don Knuth (fwd) To: "Nelson H.F. Beebe" , Peter Schmitt cc: tex-implementors@ams.org In-Reply-To: Message of Wed, 22 Jul 1998 08:46:05 -0600 (MDT) from >>> Recently I noticed an inconsistency in the handling of >>> arithmetic overflow. >... >I reported this to Don Knuth several years ago: his response was >that while TeX detects integer overflow in multiplication, it does >not do so in addition because there are too many places where >checks would be needed. He therefore declared this a `feature', >rather than a `bug'. > I see -- nevertheless, there is still an `inconsistency', since adding skips or glue triggers overflow ( so, if you want to be on the safe side, you can add \skips and convert them to an integer :-) Peter Schmitt Peter.Schmitt@univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 22-Jul-1998 15:02:41-GMT,2972;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA12910 for ; Wed, 22 Jul 1998 09:02:38 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 22 Jul 1998 15:02:38 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP5KS811C000PM7@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 22 Jul 1998 10:46:20 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 14:46:07 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA12546; Wed, 22 Jul 1998 08:46:06 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id IAA02824; Wed, 22 Jul 1998 08:46:05 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Wed, 22 Jul 1998 08:46:05 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Re: note from Don Knuth (fwd) In-reply-to: Your message of Wed, 22 Jul 1998 15:53:00 +0100 (MEZ) To: Peter Schmitt Cc: beebe@math.utah.edu, Barbara Beeton , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 >> Recently I noticed an inconsistency in the handling of >> arithmetic overflow. ... I reported this to Don Knuth several years ago: his response was that while TeX detects integer overflow in multiplication, it does not do so in addition because there are too many places where checks would be needed. He therefore declared this a `feature', rather than a `bug'. I happen to disagree strongly with him on this point: all arithmetic at the user level, such as \multiply and \advance, should go through single routines that do check for overflow. Let us hope that the new NTS project will address this issue in a redesign of TeX. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- 22-Jul-1998 15:18:26-GMT,1735;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA13278 for ; Wed, 22 Jul 1998 09:18:25 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 22 Jul 1998 15:18:21 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP654OOBK000PRB@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 22 Jul 1998 11:01:56 EDT Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 15:01:44 +0000 (UT) Date: Wed, 22 Jul 1998 16:01:35 +0100 From: Philip Taylor (RHBNC) Subject: Re: note from Don Knuth (fwd) To: beebe@math.utah.edu Cc: TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <980722160135.1a77@vms.rhbnc.ac.uk> >> I happen to disagree strongly with him on this point: all >> arithmetic at the user level, such as \multiply and \advance, >> should go through single routines that do check for overflow. Hear hear. One of the strongest features which we were able to adduce when insisting on VAX/VMS architecture many years ago (in preference to the countless platforms on which Unix ran) was that the VAX detects integer overflow, something that very few other architectures did. I was intrigued to read in yesterday's Java bulletin that integer I/0 yields an ArithmeticException whilst real x/0.0 yields Double.POSITIVE_INFINITY. Since NTS is predicated on the use of Java, I think we can give some reassurances in this area. ** Phil. 22-Jul-1998 15:19:05-GMT,2381;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA13301 for ; Wed, 22 Jul 1998 09:19:03 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 22 Jul 1998 15:19:03 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP65BVV1C000RCB@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 22 Jul 1998 11:02:13 EDT Received: from helios.edvz.univie.ac.at ([131.130.1.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 15:01:54 +0000 (UT) Received: from VM.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 2253; Wed, 22 Jul 1998 17:02:20 +0100 (MEZ) Received: from VM.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by VM.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 9179; Wed, 22 Jul 1998 17:02:20 +0100 Date: Wed, 22 Jul 1998 16:57:16 +0100 (MEZ) From: Peter Schmitt Subject: Re: note from Don Knuth (fwd) In-reply-to: "22 Jul 1998 08:46:05 -0600 from" <"beebe"@math.utah.edu> (MDT) To: "Nelson H.F. Beebe" , Peter Schmitt Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <01IZP65DV5K2000RCB@AXP14.AMS.ORG> >>> Recently I noticed an inconsistency in the handling of >>> arithmetic overflow. >... >I reported this to Don Knuth several years ago: his response was >that while TeX detects integer overflow in multiplication, it does >not do so in addition because there are too many places where >checks would be needed. He therefore declared this a `feature', >rather than a `bug'. > I see -- nevertheless, there is still an `inconsistency', since adding skips or glue triggers overflow ( so, if you want to be on the safe side, you can add \skips and convert them to an integer :-) Peter Schmitt Peter.Schmitt@univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 22-Jul-1998 15:38:43-GMT,6605;000000000001 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13772; Wed, 22 Jul 1998 09:38:43 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03033; Wed, 22 Jul 1998 09:38:42 -0600 (MDT) Date: Wed, 22 Jul 1998 09:38:42 -0600 (MDT) To: tex-implementors@ams.org, Barbara Beeton Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: ["Nelson H. F. Beebe" : Re: note from Don Knuth (fwd)] Message-ID: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13743; Wed, 22 Jul 1998 09:37:32 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03012; Wed, 22 Jul 1998 09:37:31 -0600 (MDT) Date: Wed, 22 Jul 1998 09:37:31 -0600 (MDT) To: P.Taylor@vms.rhbnc.ac.uk Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: note from Don Knuth (fwd) In-Reply-To: Your message of Wed, 22 Jul 1998 16:01:35 +0100 Message-ID: Phil Taylor writes on Wed, 22 Jul 1998 16:01:35 +0100... >> I was intrigued to read in yesterday's Java bulletin that integer >> 1/0 yields an ArithmeticException whilst real x/0.0 yields >> Double.POSITIVE_INFINITY. Since NTS is predicated on the use of >> Java, I think we can give some reassurances in this area. Yes, Java's arithmetic is firmly grounded in the 1982 IEEE 754 floating-point standard, on which virtually all new computer designs since the early 1980s have been based; the only significant exceptions are the DEC VAX (and the Convex clone of that arithmetic), the Cray 64-bit vector systems, and the IBM S-3x0 mainframes (and their clones from Gould and Fujitsu). It has always bothered me that many architectures do not even provide for detection of integer overflow, and of those that do, most compiler implementations for C, C++, and Fortran, at least, mask the overflow interrupt. Java's designers went in the correct direction: they adopted IEEE 754 as the standard for Java floating-point arithmetic. Unfortunately, they fell down with integer arithmetic: from the official virtual machine definition in @String{pub-AW = "Ad{\-d}i{\-s}on-Wes{\-l}ey"} @String{pub-AW:adr = "Reading, MA, USA"} @Book{Lindholm:1997:JVM, author = "Tim Lindholm and Frank Yellin", title = "The {Java} Virtual Machine Specification", publisher = pub-AW, address = pub-AW:adr, pages = "xvi + 475", month = jan, year = "1997", ISBN = "0-201-63452-X", LCCN = "QA76.73.J38L56 1997", bibdate = "Wed Jun 17 22:05:06 MDT 1998", bibsource = "http://www.amazon.com/exec/obidos/ISBN=020163452X/wholesaleproductA/; http://www.aw.com/; http://www.javaworld.com/javaworld/books/jw-books-alphabytitle.html", price = "US\$36.53", series = "The Java Series", URL = "http://www.aw.com/cp/javaseries.html; http://www.aw.com/cseng/titles/0-201-63452-X", acknowledgement = ack-nhfb, dimensions = "9.20in x 7.36in x 1.03in", keywords = "Internet (Computer network); Java (Computer program language); Java (computer program language); programming languages (electronic computers); systems; virtual computer; Virtual computer systems", lccnalt = "96-015897", } on p. 76, it says: >> ... >> The Java Virtual Machine does not indicate overflow or >> underflow during operations on integer data types. The only >> integer operations that can throw an exception are the integer >> divide instructions ({\em idiv} and {\em ldiv}) and the >> integer remainder instructions ({\em irem} and {\em lrem}), >> which throws an {\tt ArithmeticException} if the divisor is >> zero. >> ... Thus, NTS in Java will still have to handle addition, subtraction, and multiply by special code that checks for overflow. Later, it says: >> ... >> The Java Virtual Machine's floating-point operators produce no >> exceptions. An operation that overflows produces a signed >> infinity, an operation that underflows produces a signed zero, >> and an operation that has no mathematically definite result >> produces NaN. All numeric operations with NaN as an operand >> produce NaN as a result. >> ... Thus, NaNs and Infinities propagate to the final results, where they are likely to be noticed, which is what the IEEE 754 designers intended.] ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- 22-Jul-1998 15:53:29-GMT,4358;000000000001 Received: from fsnif.neuroinformatik.ruhr-uni-bochum.de (root@fsnif.neuroinformatik.ruhr-uni-bochum.de [134.147.176.16]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA14239 for ; Wed, 22 Jul 1998 09:53:27 -0600 (MDT) Received: from puett.neuroinformatik.ruhr-uni-bochum.de (dak@puett [134.147.176.147]) by fsnif.neuroinformatik.ruhr-uni-bochum.de (8.8.8/8.8.8) with SMTP id RAA23816; Wed, 22 Jul 1998 17:53:06 +0200 (MET DST) Received: by puett.neuroinformatik.ruhr-uni-bochum.de (SMI-8.6/SMI-SVR4) id RAA13667; Wed, 22 Jul 1998 17:53:04 +0200 Date: Wed, 22 Jul 1998 17:53:04 +0200 Message-Id: <199807221553.RAA13667@puett.neuroinformatik.ruhr-uni-bochum.de> From: David Kastrup To: P.Taylor@vms.rhbnc.ac.uk Cc: beebe@math.utah.edu, TEX-IMPLEMENTORS@ams.org In-reply-to: <980722160135.1a77@vms.rhbnc.ac.uk> (CHAA006@vms.rhbnc.ac.uk) Subject: Re: note from Don Knuth (fwd) References: <980722160135.1a77@vms.rhbnc.ac.uk> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 22 Jul 1998 16:01:35 +0100 From: Philip Taylor (RHBNC) >> I happen to disagree strongly with him on this point: all >> arithmetic at the user level, such as \multiply and \advance, >> should go through single routines that do check for overflow. Hear hear. One of the strongest features which we were able to adduce when insisting on VAX/VMS architecture many years ago (in preference to the countless platforms on which Unix ran) was that the VAX detects integer overflow, something that very few other architectures did. Actually, there are quite a few cases where you don't want integer overflow to give notice. For example, when doing digital filters, you often can guarantee by appropriate dimensioning that the *result* of the filtering will be in a certain number range, while intermediate results might exceed it. In that case the final results will turn out correct. This is because integer arithmetic ignoring overflow forms a commutative ring. If you do anything on overflow, you lose, for example, associativity on addition. Having a full-blown ring for integral arithmetic does also mean that the compiler can rearrange integral expressions much more aggressively (making use of associative and distributive laws that don't hold with overflow arithmetic) without any influence on the outcome. BTW, I even have code here where two sequences of length 3^k are convolved efficiently with one another using just 32-bit 2's complement arithmetic. All coefficients used during the operation are very disconcerting (comparable to the output of typical pseudo random number generators) and massive overflow occurs at almost every step, yet at the end all falls into place and everything ugly cancels out magically. Change a single bit anywhere, and you get complete garbage. That kind of arithmetic has no problems claiming (1/3)=2863311531, after all 3*2863311531 = 1 again (and 3*x*(1/3) = x for *any* value of x, too). As TeX, however, *does* complain about overflow on multiplication, you would have a hard time implementing this sort of digital filters with it, anyhow. Even worse: if you happen to work on a machine architecture which *does* mind arithmetic overflow, you could even get a TeX program to abort due to bad user input. While I am in opposition to enforcing overflow check on the hardware level except possibly for very special-purpose hardware intended only for very special applications, or in programming languages like C, I do think that the nature of TeX would make checking for overflow there a sensible thing to do, even for addition. I was intrigued to read in yesterday's Java bulletin that integer I/0 yields an ArithmeticException whilst real x/0.0 yields Double.POSITIVE_INFINITY. Since NTS is predicated on the use of Java, I think we can give some reassurances in this area. I don't mind division by zero raising an exception. There is not much useful you could do instead. David Kastrup Phone: +49-234-700-5570 Email: dak@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209 Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany 22-Jul-1998 16:00:02-GMT,7297;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id KAA14391 for ; Wed, 22 Jul 1998 10:00:01 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 22 Jul 1998 16:00:00 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP7F0OP1S000Q5Z@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 22 Jul 1998 11:38:55 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 15:38:44 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13772; Wed, 22 Jul 1998 09:38:43 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03033; Wed, 22 Jul 1998 09:38:42 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Wed, 22 Jul 1998 09:38:42 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: ["Nelson H. F. Beebe" : Re: note from Don Knuth (fwd)] To: tex-implementors@ams.org, Barbara Beeton Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13743; Wed, 22 Jul 1998 09:37:32 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03012; Wed, 22 Jul 1998 09:37:31 -0600 (MDT) Date: Wed, 22 Jul 1998 09:37:31 -0600 (MDT) To: P.Taylor@vms.rhbnc.ac.uk Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: note from Don Knuth (fwd) In-Reply-To: Your message of Wed, 22 Jul 1998 16:01:35 +0100 Message-ID: Phil Taylor writes on Wed, 22 Jul 1998 16:01:35 +0100... >> I was intrigued to read in yesterday's Java bulletin that integer >> 1/0 yields an ArithmeticException whilst real x/0.0 yields >> Double.POSITIVE_INFINITY. Since NTS is predicated on the use of >> Java, I think we can give some reassurances in this area. Yes, Java's arithmetic is firmly grounded in the 1982 IEEE 754 floating-point standard, on which virtually all new computer designs since the early 1980s have been based; the only significant exceptions are the DEC VAX (and the Convex clone of that arithmetic), the Cray 64-bit vector systems, and the IBM S-3x0 mainframes (and their clones from Gould and Fujitsu). It has always bothered me that many architectures do not even provide for detection of integer overflow, and of those that do, most compiler implementations for C, C++, and Fortran, at least, mask the overflow interrupt. Java's designers went in the correct direction: they adopted IEEE 754 as the standard for Java floating-point arithmetic. Unfortunately, they fell down with integer arithmetic: from the official virtual machine definition in @String{pub-AW = "Ad{\-d}i{\-s}on-Wes{\-l}ey"} @String{pub-AW:adr = "Reading, MA, USA"} @Book{Lindholm:1997:JVM, author = "Tim Lindholm and Frank Yellin", title = "The {Java} Virtual Machine Specification", publisher = pub-AW, address = pub-AW:adr, pages = "xvi + 475", month = jan, year = "1997", ISBN = "0-201-63452-X", LCCN = "QA76.73.J38L56 1997", bibdate = "Wed Jun 17 22:05:06 MDT 1998", bibsource = "http://www.amazon.com/exec/obidos/ISBN=020163452X/wholesaleproductA/; http://www.aw.com/; http://www.javaworld.com/javaworld/books/jw-books-alphabytitle.html", price = "US\$36.53", series = "The Java Series", URL = "http://www.aw.com/cp/javaseries.html; http://www.aw.com/cseng/titles/0-201-63452-X", acknowledgement = ack-nhfb, dimensions = "9.20in x 7.36in x 1.03in", keywords = "Internet (Computer network); Java (Computer program language); Java (computer program language); programming languages (electronic computers); systems; virtual computer; Virtual computer systems", lccnalt = "96-015897", } on p. 76, it says: >> ... >> The Java Virtual Machine does not indicate overflow or >> underflow during operations on integer data types. The only >> integer operations that can throw an exception are the integer >> divide instructions ({\em idiv} and {\em ldiv}) and the >> integer remainder instructions ({\em irem} and {\em lrem}), >> which throws an {\tt ArithmeticException} if the divisor is >> zero. >> ... Thus, NTS in Java will still have to handle addition, subtraction, and multiply by special code that checks for overflow. Later, it says: >> ... >> The Java Virtual Machine's floating-point operators produce no >> exceptions. An operation that overflows produces a signed >> infinity, an operation that underflows produces a signed zero, >> and an operation that has no mathematically definite result >> produces NaN. All numeric operations with NaN as an operand >> produce NaN as a result. >> ... Thus, NaNs and Infinities propagate to the final results, where they are likely to be noticed, which is what the IEEE 754 designers intended.] ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- 22-Jul-1998 16:23:42-GMT,5038;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id KAA14960 for ; Wed, 22 Jul 1998 10:23:41 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 22 Jul 1998 16:23:40 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP7XB1L9C000TFQ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 22 Jul 1998 11:53:39 EDT Received: from fsnif.neuroinformatik.ruhr-uni-bochum.de ([134.147.176.16]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 15:53:29 +0000 (UT) Received: from puett.neuroinformatik.ruhr-uni-bochum.de (dak@puett [134.147.176.147]) by fsnif.neuroinformatik.ruhr-uni-bochum.de (8.8.8/8.8.8) with SMTP id RAA23816; Wed, 22 Jul 1998 17:53:06 +0200 (MET DST) Received: by puett.neuroinformatik.ruhr-uni-bochum.de (SMI-8.6/SMI-SVR4) id RAA13667; Wed, 22 Jul 1998 17:53:04 +0200 Date: Wed, 22 Jul 1998 17:53:04 +0200 From: David Kastrup Subject: Re: note from Don Knuth (fwd) In-reply-to: <980722160135.1a77@vms.rhbnc.ac.uk> (CHAA006@vms.rhbnc.ac.uk) To: P.Taylor@vms.rhbnc.ac.uk Cc: beebe@math.utah.edu, TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199807221553.RAA13667@puett.neuroinformatik.ruhr-uni-bochum.de> MIME-version: 1.0 (generated by tm-edit 7.106) Content-type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by fsnif.neuroinformatik.ruhr-uni-bochum.de id RAA23816 References: <980722160135.1a77@vms.rhbnc.ac.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by csc-sun.math.utah.edu id KAA14960 Date: Wed, 22 Jul 1998 16:01:35 +0100 From: Philip Taylor (RHBNC) >> I happen to disagree strongly with him on this point: all >> arithmetic at the user level, such as \multiply and \advance, >> should go through single routines that do check for overflow. Hear hear. One of the strongest features which we were able to adduce when insisting on VAX/VMS architecture many years ago (in preference to the countless platforms on which Unix ran) was that the VAX detects integer overflow, something that very few other architectures did. Actually, there are quite a few cases where you don't want integer overflow to give notice. For example, when doing digital filters, you often can guarantee by appropriate dimensioning that the *result* of the filtering will be in a certain number range, while intermediate results might exceed it. In that case the final results will turn out correct. This is because integer arithmetic ignoring overflow forms a commutative ring. If you do anything on overflow, you lose, for example, associativity on addition. Having a full-blown ring for integral arithmetic does also mean that the compiler can rearrange integral expressions much more aggressively (making use of associative and distributive laws that don't hold with overflow arithmetic) without any influence on the outcome. BTW, I even have code here where two sequences of length 3^k are convolved efficiently with one another using just 32-bit 2's complement arithmetic. All coefficients used during the operation are very disconcerting (comparable to the output of typical pseudo random number generators) and massive overflow occurs at almost every step, yet at the end all falls into place and everything ugly cancels out magically. Change a single bit anywhere, and you get complete garbage. That kind of arithmetic has no problems claiming (1/3)=2863311531, after all 3*2863311531 = 1 again (and 3*x*(1/3) = x for *any* value of x, too). As TeX, however, *does* complain about overflow on multiplication, you would have a hard time implementing this sort of digital filters with it, anyhow. Even worse: if you happen to work on a machine architecture which *does* mind arithmetic overflow, you could even get a TeX program to abort due to bad user input. While I am in opposition to enforcing overflow check on the hardware level except possibly for very special-purpose hardware intended only for very special applications, or in programming languages like C, I do think that the nature of TeX would make checking for overflow there a sensible thing to do, even for addition. I was intrigued to read in yesterday's Java bulletin that integer I/0 yields an ArithmeticException whilst real x/0.0 yields Double.POSITIVE_INFINITY. Since NTS is predicated on the use of Java, I think we can give some reassurances in this area. I don't mind division by zero raising an exception. There is not much useful you could do instead. David Kastrup Phone: +49-234-700-5570 Email: dak@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209 Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany 22-Jul-1998 19:17:00-GMT,5108;000000000001 Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id NAA18537 for ; Wed, 22 Jul 1998 13:16:59 -0600 (MDT) Received: from localhost (localhost) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with internal id MAA23973; Wed, 22 Jul 1998 12:16:59 -0700 (PDT) Date: Wed, 22 Jul 1998 12:16:59 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <199807221916.MAA23973@proxy2.ba.best.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="MAA23973.901135019/proxy2.ba.best.com" Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --MAA23973.901135019/proxy2.ba.best.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Wed, 22 Jul 1998 07:53:37 -0700 (PDT) from e-math.ams.org [130.44.194.100] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Operation timed out with sparky.randomnoise.com. Warning: message still undelivered after 4 hours Will keep trying until message is 1 week old --MAA23973.901135019/proxy2.ba.best.com Content-Type: message/delivery-status Reporting-MTA: dns; proxy2.ba.best.com Arrival-Date: Wed, 22 Jul 1998 07:53:37 -0700 (PDT) Final-Recipient: RFC822; drf@randomnoise.com Action: delayed Status: 4.4.1 Remote-MTA: DNS; sparky.randomnoise.com Last-Attempt-Date: Wed, 22 Jul 1998 12:16:59 -0700 (PDT) Will-Retry-Until: Wed, 29 Jul 1998 07:53:37 -0700 (PDT) --MAA23973.901135019/proxy2.ba.best.com Content-Type: message/rfc822 Return-Path: Received: from e-math.ams.org (e-math.ams.org [130.44.194.100]) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with SMTP id HAA07301 for ; Wed, 22 Jul 1998 07:53:37 -0700 (PDT) Received: by e-math.ams.org; id AA14462; Wed, 22 Jul 1998 10:52:21 -0400 Received: from axp14.ams.org by math.ams.org via smtpd (for e-math.ams.org [130.44.194.100]) with SMTP; 22 Jul 1998 14:52:20 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP5KS811C000PM7@AXP14.AMS.ORG> for drf@randomnoise.com; Wed, 22 Jul 1998 10:46:24 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 14:46:07 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA12546; Wed, 22 Jul 1998 08:46:06 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id IAA02824; Wed, 22 Jul 1998 08:46:05 -0600 (MDT) X-Url: http://www.math.utah.edu/~beebe Date: Wed, 22 Jul 1998 08:46:05 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Re: note from Don Knuth (fwd) In-Reply-To: Your message of Wed, 22 Jul 1998 15:53:00 +0100 (MEZ) To: Peter Schmitt Cc: beebe@math.utah.edu, Barbara Beeton , tex-implementors@ams.org Errors-To: tex-implementors-request@ams.org Message-Id: X-Us-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-Fax: +1 801 585 1640, +1 801 581 4148 >> Recently I noticed an inconsistency in the handling of >> arithmetic overflow. ... I reported this to Don Knuth several years ago: his response was that while TeX detects integer overflow in multiplication, it does not do so in addition because there are too many places where checks would be needed. He therefore declared this a `feature', rather than a `bug'. I happen to disagree strongly with him on this point: all arithmetic at the user level, such as \multiply and \advance, should go through single routines that do check for overflow. Let us hope that the new NTS project will address this issue in a redesign of TeX. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- --MAA23973.901135019/proxy2.ba.best.com-- 22-Jul-1998 19:48:52-GMT,9433;000000000001 Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id NAA19168 for ; Wed, 22 Jul 1998 13:48:51 -0600 (MDT) Received: from localhost (localhost) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with internal id MAB06457; Wed, 22 Jul 1998 12:48:50 -0700 (PDT) Date: Wed, 22 Jul 1998 12:48:50 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <199807221948.MAB06457@proxy2.ba.best.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="MAB06457.901136930/proxy2.ba.best.com" Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --MAB06457.901136930/proxy2.ba.best.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Wed, 22 Jul 1998 08:46:55 -0700 (PDT) from e-math.ams.org [130.44.194.100] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Operation timed out with sparky.randomnoise.com. Warning: message still undelivered after 4 hours Will keep trying until message is 1 week old --MAB06457.901136930/proxy2.ba.best.com Content-Type: message/delivery-status Reporting-MTA: dns; proxy2.ba.best.com Arrival-Date: Wed, 22 Jul 1998 08:46:55 -0700 (PDT) Final-Recipient: RFC822; drf@randomnoise.com Action: delayed Status: 4.4.1 Remote-MTA: DNS; sparky.randomnoise.com Last-Attempt-Date: Wed, 22 Jul 1998 12:48:50 -0700 (PDT) Will-Retry-Until: Wed, 29 Jul 1998 08:46:55 -0700 (PDT) --MAB06457.901136930/proxy2.ba.best.com Content-Type: message/rfc822 Return-Path: Received: from e-math.ams.org (e-math.ams.org [130.44.194.100]) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with SMTP id IAA26974 for ; Wed, 22 Jul 1998 08:46:55 -0700 (PDT) Received: by e-math.ams.org; id AA19434; Wed, 22 Jul 1998 11:45:39 -0400 Received: from axp14.ams.org by math.ams.org via smtpd (for e-math.ams.org [130.44.194.100]) with SMTP; 22 Jul 1998 15:45:39 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP7F0OP1S000Q5Z@AXP14.AMS.ORG> for drf@randomnoise.com; Wed, 22 Jul 1998 11:38:59 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 15:38:44 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13772; Wed, 22 Jul 1998 09:38:43 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03033; Wed, 22 Jul 1998 09:38:42 -0600 (MDT) X-Url: http://www.math.utah.edu/~beebe Date: Wed, 22 Jul 1998 09:38:42 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: ["Nelson H. F. Beebe" : Re: note from Don Knuth (fwd)] To: tex-implementors@ams.org, Barbara Beeton Cc: beebe@math.utah.edu Errors-To: tex-implementors-request@ams.org Message-Id: X-Us-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-Fax: +1 801 585 1640, +1 801 581 4148 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13743; Wed, 22 Jul 1998 09:37:32 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03012; Wed, 22 Jul 1998 09:37:31 -0600 (MDT) Date: Wed, 22 Jul 1998 09:37:31 -0600 (MDT) To: P.Taylor@vms.rhbnc.ac.uk Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: note from Don Knuth (fwd) In-Reply-To: Your message of Wed, 22 Jul 1998 16:01:35 +0100 Message-ID: Phil Taylor writes on Wed, 22 Jul 1998 16:01:35 +0100... >> I was intrigued to read in yesterday's Java bulletin that integer >> 1/0 yields an ArithmeticException whilst real x/0.0 yields >> Double.POSITIVE_INFINITY. Since NTS is predicated on the use of >> Java, I think we can give some reassurances in this area. Yes, Java's arithmetic is firmly grounded in the 1982 IEEE 754 floating-point standard, on which virtually all new computer designs since the early 1980s have been based; the only significant exceptions are the DEC VAX (and the Convex clone of that arithmetic), the Cray 64-bit vector systems, and the IBM S-3x0 mainframes (and their clones from Gould and Fujitsu). It has always bothered me that many architectures do not even provide for detection of integer overflow, and of those that do, most compiler implementations for C, C++, and Fortran, at least, mask the overflow interrupt. Java's designers went in the correct direction: they adopted IEEE 754 as the standard for Java floating-point arithmetic. Unfortunately, they fell down with integer arithmetic: from the official virtual machine definition in @String{pub-AW = "Ad{\-d}i{\-s}on-Wes{\-l}ey"} @String{pub-AW:adr = "Reading, MA, USA"} @Book{Lindholm:1997:JVM, author = "Tim Lindholm and Frank Yellin", title = "The {Java} Virtual Machine Specification", publisher = pub-AW, address = pub-AW:adr, pages = "xvi + 475", month = jan, year = "1997", ISBN = "0-201-63452-X", LCCN = "QA76.73.J38L56 1997", bibdate = "Wed Jun 17 22:05:06 MDT 1998", bibsource = "http://www.amazon.com/exec/obidos/ISBN=020163452X/wholesaleproductA/; http://www.aw.com/; http://www.javaworld.com/javaworld/books/jw-books-alphabytitle.html", price = "US\$36.53", series = "The Java Series", URL = "http://www.aw.com/cp/javaseries.html; http://www.aw.com/cseng/titles/0-201-63452-X", acknowledgement = ack-nhfb, dimensions = "9.20in x 7.36in x 1.03in", keywords = "Internet (Computer network); Java (Computer program language); Java (computer program language); programming languages (electronic computers); systems; virtual computer; Virtual computer systems", lccnalt = "96-015897", } on p. 76, it says: >> ... >> The Java Virtual Machine does not indicate overflow or >> underflow during operations on integer data types. The only >> integer operations that can throw an exception are the integer >> divide instructions ({\em idiv} and {\em ldiv}) and the >> integer remainder instructions ({\em irem} and {\em lrem}), >> which throws an {\tt ArithmeticException} if the divisor is >> zero. >> ... Thus, NTS in Java will still have to handle addition, subtraction, and multiply by special code that checks for overflow. Later, it says: >> ... >> The Java Virtual Machine's floating-point operators produce no >> exceptions. An operation that overflows produces a signed >> infinity, an operation that underflows produces a signed zero, >> and an operation that has no mathematically definite result >> produces NaN. All numeric operations with NaN as an operand >> produce NaN as a result. >> ... Thus, NaNs and Infinities propagate to the final results, where they are likely to be noticed, which is what the IEEE 754 designers intended.] ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- --MAB06457.901136930/proxy2.ba.best.com-- 23-Jul-1998 22:52:14-GMT,4712;000000000001 Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id QAA23267 for ; Thu, 23 Jul 1998 16:52:13 -0600 (MDT) Received: from localhost (localhost) by proxy1.ba.best.com (8.9.0/8.9.0/best.in) with internal id PAA26537; Thu, 23 Jul 1998 15:52:12 -0700 (PDT) Date: Thu, 23 Jul 1998 15:52:12 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <199807232252.PAA26537@proxy1.ba.best.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="PAA26537.901234332/proxy1.ba.best.com" Subject: Returned mail: Cannot send message within 1 week Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --PAA26537.901234332/proxy1.ba.best.com The original message was received at Thu, 16 Jul 1998 15:46:31 -0700 (PDT) from e-math.ams.org [130.44.194.100] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Operation timed out with sparky.randomnoise.com. Message could not be delivered for 1 week Message will be deleted from queue --PAA26537.901234332/proxy1.ba.best.com Content-Type: message/delivery-status Reporting-MTA: dns; proxy1.ba.best.com Arrival-Date: Thu, 16 Jul 1998 15:46:31 -0700 (PDT) Final-Recipient: RFC822; drf@RANDOMNOISE.COM Action: failed Status: 4.4.7 Remote-MTA: DNS; sparky.randomnoise.com Last-Attempt-Date: Thu, 23 Jul 1998 15:52:12 -0700 (PDT) --PAA26537.901234332/proxy1.ba.best.com Content-Type: message/rfc822 Return-Path: Received: from e-math.ams.org (e-math.ams.org [130.44.194.100]) by proxy1.ba.best.com (8.9.0/8.9.0/best.in) with SMTP id PAA13282 for ; Thu, 16 Jul 1998 15:46:31 -0700 (PDT) Received: by e-math.ams.org; id AA11632; Thu, 16 Jul 1998 18:45:14 -0400 Received: from axp14.ams.org by math.ams.org via smtpd (for e-math.ams.org [130.44.194.100]) with SMTP; 16 Jul 1998 22:45:14 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZH8BMTC4W0001Z9@AXP14.AMS.ORG> for drf@randomnoise.com; Thu, 16 Jul 1998 18:38:20 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 16 Jul 1998 22:37:54 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id QAA05262; Thu, 16 Jul 1998 16:37:45 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id QAA22404; Thu, 16 Jul 1998 16:37:44 -0600 (MDT) X-Url: http://www.math.utah.edu/~beebe Date: Thu, 16 Jul 1998 16:37:44 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Quotation character conventions, and TeX/LaTeX support thereof To: tex-implementors@ams.org, LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE Cc: beebe@math.utah.edu Errors-To: tex-implementors-request@ams.org Message-Id: X-Us-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-Fax: +1 801 585 1640, +1 801 581 4148 I have just read a new document ``Quotation Character Semantics'', available on the Web at http://www.unicode.org/unicode/uni2errata/QuoteErrata.html This document discusses quotation character conventions in several European languages, and a related document ``Apostrophe Semantics'' at http://www.unicode.org/unicode/uni2errata/Apostrophe.htm discusses issues that appear when more than one apostrophe-like character is available for use, as is the case in Unicode. I raise these issues on the tex-implementors and latex-l lists because I believe they are relevant for TeX markup of documents, and for the LaTeX-3 design. ----------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ----------------------------------------------------------------------------- --PAA26537.901234332/proxy1.ba.best.com-- 24-Jul-1998 14:01:36-GMT,2473;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA09354 for ; Fri, 24 Jul 1998 08:01:35 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Jul 1998 14:01:30 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZRVXAAU2O0014FN@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 24 Jul 1998 09:42:27 EDT Received: from helios.edvz.univie.ac.at ([131.130.1.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 24 Jul 1998 13:42:15 +0000 (UT) Received: from VM.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 2839; Fri, 24 Jul 1998 15:42:40 +0100 (MEZ) Received: from VM.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by VM.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 4919; Fri, 24 Jul 1998 15:42:40 +0100 Date: Fri, 24 Jul 1998 15:34:25 +0100 (MEZ) From: Peter Schmitt Subject: Re: note from Don Knuth (fwd) In-reply-to: "22 Jul 1998 17:53:04 +0200 from" <"dak"@neuroinformatik.ruhr-uni-bochum.de> To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <01IZRVXAYQTU0014FN@AXP14.AMS.ORG> > >Actually, there are quite a few cases where you don't want integer >overflow to give notice. For example, when doing digital filters, you >often can guarantee by appropriate dimensioning that the *result* of >the filtering will be in a certain number range, while intermediate >results might exceed it. In that case the final results will turn out >correct. This is because integer arithmetic ignoring overflow forms a >commutative ring. If you do anything on overflow, you lose, for >example, associativity on addition. [] >David Kastrup Phone: +49-234-700-5570 > However, this is not true for overflow when adding TeX \count registers. If you start doubling by adding with 1 then you first get a negative number and then land in 0 while -- when starting with other numbers this need not be the case. Peter Schmitt Peter.Schmitt@univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien 24-Jul-1998 17:33:05-GMT,2634;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA13445 for ; Fri, 24 Jul 1998 11:33:04 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Jul 1998 17:33:03 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZS38TFYR40011HS@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 24 Jul 1998 13:11:45 EDT Received: from helios.edvz.univie.ac.at ([131.130.1.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 24 Jul 1998 17:11:35 +0000 (UT) Received: from VM.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 2887; Fri, 24 Jul 1998 19:12:00 +0100 (MEZ) Received: from VM.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by VM.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 5558; Fri, 24 Jul 1998 19:12:01 +0100 Date: Fri, 24 Jul 1998 18:58:36 +0100 (MEZ) From: Peter Schmitt Subject: \pagedepth [ Re: note from Don Knuth ] In-reply-to: Your message of Sat, 18 Jul 1998 10:52:46 -0400 (EDT) To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <01IZS38TYYJ60011HS@AXP14.AMS.ORG> >if anyone has any pending questions, now's the time to send them in. >thanks much. I now remember another thing that bothered me some time ago. ( I hope it is not folklore knowledge! ) The registers containing information on the current page are only marginally treated in the TeXbook. When some time ago I implemented \special-free changebars, I needed this information ( since part of this information gets lost when \box255 is put back on the current list ) and was surprised to find that \pagefilstretch and alike do not contain their information as glue (which could easily be added to a \skip) but as dimension in pt. ( But this is, probably, a feature. ) However, I found that \pagedepth always(?) is 0. I did not pursue this matter because I could get the information I needed from \dp255, but (maybe I misunderstand something) I would have expected \pagedepth = \dp255 at the beginning of the \output routine. Any comments? Peter Schmitt Peter.Schmitt@univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 24-Jul-1998 18:03:17-GMT,2411;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA14056 for ; Fri, 24 Jul 1998 12:03:13 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Jul 1998 18:03:13 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZS4B63CO00011N0@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 24 Jul 1998 13:41:58 EDT Received: from heaton.cl.cam.ac.uk ([128.232.32.11]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 24 Jul 1998 17:41:47 +0000 (UT) Received: from dorceus.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.1.34] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1) id 0yzlqV-0000m3-00; Fri, 24 Jul 1998 18:41:31 +0100 Date: Fri, 24 Jul 1998 18:41:29 +0100 From: Robin Fairbairns Subject: Re: note from Don Knuth (fwd) In-reply-to: "Your message of Fri, 24 Jul 1998 15:34:25 BST." <01IZRVXAYQTU0014FN@AXP14.AMS.ORG> To: Peter Schmitt Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: peter schmitt wrote, quoting david kastrup: > >Actually, there are quite a few cases where you don't want integer > >overflow to give notice. For example, when doing digital filters, you > >often can guarantee by appropriate dimensioning that the *result* of > >the filtering will be in a certain number range, while intermediate > >results might exceed it. In that case the final results will turn out > >correct. This is because integer arithmetic ignoring overflow forms a > >commutative ring. If you do anything on overflow, you lose, for > >example, associativity on addition. > > However, this is not true for overflow when adding TeX \count registers. > If you start doubling by adding with 1 then you first get a negative > number and then land in 0 while -- when starting with other numbers > this need not be the case. i'm with peter on this. it's a bit sad that it happens (and worse that it appears to be ok by don). the fact that tex's curious arithmetic might make implementation of digital filters in tex easier doesn't to *my* mind really make it a _good thing_. (or was david jibing at philip taylor for liking vaxen? hiss...) r 25-Jul-1998 4:23:30-GMT,2069;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id WAA24895 for ; Fri, 24 Jul 1998 22:23:27 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Jul 1998 04:23:21 UT Received: from sun06.pvd (SUN06.AMS.ORG) by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZSPYDHG40001ATN@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 25 Jul 1998 00:02:17 EDT Received: by sun06.pvd (SMI-8.6/SMI-SVR4) id AAA15981; Sat, 25 Jul 1998 00:02:02 -0400 Date: Sat, 25 Jul 1998 00:02:02 -0400 From: Michael John Downes Subject: Re: \pagedepth [ Re: note from Don Knuth ] In-reply-to: Peter Schmitt's message of Fri, 24 Jul 1998 18:58:36 +0100 (MEZ) To: Peter Schmitt Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: X-Mailer: Gnus v5.5/Emacs 20.2 Lines: 20 References: <01IZS38TYYJ60011HS@AXP14.AMS.ORG> Peter Schmitt writes: > However, I found that \pagedepth always(?) is 0. > I did not pursue this matter because I could get the information > I needed from \dp255, but (maybe I misunderstand something) > I would have expected \pagedepth = \dp255 > at the beginning of the \output routine. In the output routine, the values of \pagedepth and the other \pagexxx variables include the material in the "recent contributions" area (!) I, too, did not find this very useful when (two or three years ago) I wrote an output routine that reported in detail the contents of each page, including amount of space used for footnotes, figures, etc. In order to get accurate reports it was necessary to run two cycles of the output routine for each page with, on the second cycle, \unvbox255 \penalty-10000 (so that TeX goes into the output routine immediately without looking at the following material), and do a lot of tricky fiddling with \holdinginserts and such. Michael Downes 26-Jul-1998 16:51:28-GMT,5562;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id KAA26574 for ; Sun, 26 Jul 1998 10:51:27 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 26 Jul 1998 16:51:26 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01IZUUP2DD3K0015CO@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 26 Jul 1998 12:39:07 EDT Received: from sun06.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0EWP008M4NKXGJ@sun06.ams.org> for tex-implementors@axp14.ams.org; Sun, 26 Jul 1998 12:38:57 -0400 (EDT) Date: Sun, 26 Jul 1998 12:38:57 -0400 (EDT) From: Barbara Beeton Subject: Re: arithmetic overflow (was note from Don Knuth (fwd)) In-reply-to: <01IZP3W3WYIQ000GMQ@AXP14.AMS.ORG> To: Peter Schmitt Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII peter schmitt has reported: Recently I noticed an inconsistency in the handling of arithmetic overflow. While usually this generates an errormessage, one case is _not_ detected: \advance'ing a \count register (while doubling the same number triggers an error!) nelson beebe followed up with the comment that I reported this to Don Knuth several years ago: his response was that while TeX detects integer overflow in multiplication, it does not do so in addition because there are too many places where checks would be needed. He therefore declared this a `feature', rather than a `bug'. attached is the original report sent by nelson, with don's response. i don't find the current report sufficiently different that it should be forwarded to don anyway. in the spirit of "compromise", i invite peter, nelson, phil taylor, david kastrup, and robin fairbairns (the participants in the present discussion) together to write a brief and clear description of what happens, the implications of this feature, and incorporating don's response, to be published in the december issue of tugboat. -- bb -------------------- 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. ] 27-Jul-1998 15:18:46-GMT,3010;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA20603 for ; Mon, 27 Jul 1998 09:18:41 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 27 Jul 1998 15:18:33 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZW54SYVSG0016VQ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 27 Jul 1998 10:49:03 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 27 Jul 1998 14:48:47 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA17524; Mon, 27 Jul 1998 06:54:35 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id GAA03525; Mon, 27 Jul 1998 06:54:35 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Mon, 27 Jul 1998 06:54:35 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: A side note on integer arithmetic To: tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 Thanks for Barbara Beeton for digging up my original report to Don Knuth about integer overflow problems in TeX, and Don's response. Coincidentally, this morning's e-mail on another list carried a new item about the impact of integer overflow, joining the failure-of-Patriot-missiles-to-shoot-down-Iraqi-SCUDs-in-the-Gulf-War and the failure-of-the-Ariane-rocket The Aegis missile cruiser USS Yorktown was dead in the water for about two hours and 45 minutes: >> ... >> The Yorktown's Standard Monitoring Control System administrator >> entered zero into the data field for the Remote Data Base Manager >> program. That caused the database to overflow and crash all LAN >> consoles and miniature remote terminal units, the memo said. >> ... For further details, visit http://www.gcn.com/gcn/1998/July13/cov2.htm ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- 29-Jul-1998 15:14:49-GMT,4817;000000000001 Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA24347 for ; Wed, 29 Jul 1998 09:14:48 -0600 (MDT) Received: from localhost (localhost) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with internal id IAC08324; Wed, 29 Jul 1998 08:14:47 -0700 (PDT) Date: Wed, 29 Jul 1998 08:14:47 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <199807291514.IAC08324@proxy2.ba.best.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="IAC08324.901725287/proxy2.ba.best.com" Subject: Returned mail: Cannot send message within 1 week Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --IAC08324.901725287/proxy2.ba.best.com The original message was received at Wed, 22 Jul 1998 07:53:37 -0700 (PDT) from e-math.ams.org [130.44.194.100] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Operation timed out with sparky.randomnoise.com. Message could not be delivered for 1 week Message will be deleted from queue --IAC08324.901725287/proxy2.ba.best.com Content-Type: message/delivery-status Reporting-MTA: dns; proxy2.ba.best.com Arrival-Date: Wed, 22 Jul 1998 07:53:37 -0700 (PDT) Final-Recipient: RFC822; drf@RANDOMNOISE.COM Action: failed Status: 4.4.7 Remote-MTA: DNS; sparky.randomnoise.com Last-Attempt-Date: Wed, 29 Jul 1998 08:14:47 -0700 (PDT) --IAC08324.901725287/proxy2.ba.best.com Content-Type: message/rfc822 Return-Path: Received: from e-math.ams.org (e-math.ams.org [130.44.194.100]) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with SMTP id HAA07301 for ; Wed, 22 Jul 1998 07:53:37 -0700 (PDT) Received: by e-math.ams.org; id AA14462; Wed, 22 Jul 1998 10:52:21 -0400 Received: from axp14.ams.org by math.ams.org via smtpd (for e-math.ams.org [130.44.194.100]) with SMTP; 22 Jul 1998 14:52:20 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP5KS811C000PM7@AXP14.AMS.ORG> for drf@randomnoise.com; Wed, 22 Jul 1998 10:46:24 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 14:46:07 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA12546; Wed, 22 Jul 1998 08:46:06 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id IAA02824; Wed, 22 Jul 1998 08:46:05 -0600 (MDT) X-Url: http://www.math.utah.edu/~beebe Date: Wed, 22 Jul 1998 08:46:05 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Re: note from Don Knuth (fwd) In-Reply-To: Your message of Wed, 22 Jul 1998 15:53:00 +0100 (MEZ) To: Peter Schmitt Cc: beebe@math.utah.edu, Barbara Beeton , tex-implementors@ams.org Errors-To: tex-implementors-request@ams.org Message-Id: X-Us-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-Fax: +1 801 585 1640, +1 801 581 4148 >> Recently I noticed an inconsistency in the handling of >> arithmetic overflow. ... I reported this to Don Knuth several years ago: his response was that while TeX detects integer overflow in multiplication, it does not do so in addition because there are too many places where checks would be needed. He therefore declared this a `feature', rather than a `bug'. I happen to disagree strongly with him on this point: all arithmetic at the user level, such as \multiply and \advance, should go through single routines that do check for overflow. Let us hope that the new NTS project will address this issue in a redesign of TeX. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- --IAC08324.901725287/proxy2.ba.best.com-- 29-Jul-1998 15:50:29-GMT,9142;000000000001 Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA25312 for ; Wed, 29 Jul 1998 09:50:28 -0600 (MDT) Received: from localhost (localhost) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with internal id IAA21720; Wed, 29 Jul 1998 08:50:27 -0700 (PDT) Date: Wed, 29 Jul 1998 08:50:27 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <199807291550.IAA21720@proxy2.ba.best.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="IAA21720.901727427/proxy2.ba.best.com" Subject: Returned mail: Cannot send message within 1 week Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --IAA21720.901727427/proxy2.ba.best.com The original message was received at Wed, 22 Jul 1998 08:46:55 -0700 (PDT) from e-math.ams.org [130.44.194.100] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Operation timed out with sparky.randomnoise.com. Message could not be delivered for 1 week Message will be deleted from queue --IAA21720.901727427/proxy2.ba.best.com Content-Type: message/delivery-status Reporting-MTA: dns; proxy2.ba.best.com Arrival-Date: Wed, 22 Jul 1998 08:46:55 -0700 (PDT) Final-Recipient: RFC822; drf@randomnoise.com Action: failed Status: 4.4.7 Remote-MTA: DNS; sparky.randomnoise.com Last-Attempt-Date: Wed, 29 Jul 1998 08:50:27 -0700 (PDT) --IAA21720.901727427/proxy2.ba.best.com Content-Type: message/rfc822 Return-Path: Received: from e-math.ams.org (e-math.ams.org [130.44.194.100]) by proxy2.ba.best.com (8.9.0/8.9.0/best.in) with SMTP id IAA26974 for ; Wed, 22 Jul 1998 08:46:55 -0700 (PDT) Received: by e-math.ams.org; id AA19434; Wed, 22 Jul 1998 11:45:39 -0400 Received: from axp14.ams.org by math.ams.org via smtpd (for e-math.ams.org [130.44.194.100]) with SMTP; 22 Jul 1998 15:45:39 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZP7F0OP1S000Q5Z@AXP14.AMS.ORG> for drf@randomnoise.com; Wed, 22 Jul 1998 11:38:59 EDT Received: from csc-sun.math.utah.edu ([128.110.198.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 22 Jul 1998 15:38:44 +0000 (UT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13772; Wed, 22 Jul 1998 09:38:43 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03033; Wed, 22 Jul 1998 09:38:42 -0600 (MDT) X-Url: http://www.math.utah.edu/~beebe Date: Wed, 22 Jul 1998 09:38:42 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: ["Nelson H. F. Beebe" : Re: note from Don Knuth (fwd)] To: tex-implementors@ams.org, Barbara Beeton Cc: beebe@math.utah.edu Errors-To: tex-implementors-request@ams.org Message-Id: X-Us-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-Fax: +1 801 585 1640, +1 801 581 4148 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA13743; Wed, 22 Jul 1998 09:37:32 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id JAA03012; Wed, 22 Jul 1998 09:37:31 -0600 (MDT) Date: Wed, 22 Jul 1998 09:37:31 -0600 (MDT) To: P.Taylor@vms.rhbnc.ac.uk Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: note from Don Knuth (fwd) In-Reply-To: Your message of Wed, 22 Jul 1998 16:01:35 +0100 Message-ID: Phil Taylor writes on Wed, 22 Jul 1998 16:01:35 +0100... >> I was intrigued to read in yesterday's Java bulletin that integer >> 1/0 yields an ArithmeticException whilst real x/0.0 yields >> Double.POSITIVE_INFINITY. Since NTS is predicated on the use of >> Java, I think we can give some reassurances in this area. Yes, Java's arithmetic is firmly grounded in the 1982 IEEE 754 floating-point standard, on which virtually all new computer designs since the early 1980s have been based; the only significant exceptions are the DEC VAX (and the Convex clone of that arithmetic), the Cray 64-bit vector systems, and the IBM S-3x0 mainframes (and their clones from Gould and Fujitsu). It has always bothered me that many architectures do not even provide for detection of integer overflow, and of those that do, most compiler implementations for C, C++, and Fortran, at least, mask the overflow interrupt. Java's designers went in the correct direction: they adopted IEEE 754 as the standard for Java floating-point arithmetic. Unfortunately, they fell down with integer arithmetic: from the official virtual machine definition in @String{pub-AW = "Ad{\-d}i{\-s}on-Wes{\-l}ey"} @String{pub-AW:adr = "Reading, MA, USA"} @Book{Lindholm:1997:JVM, author = "Tim Lindholm and Frank Yellin", title = "The {Java} Virtual Machine Specification", publisher = pub-AW, address = pub-AW:adr, pages = "xvi + 475", month = jan, year = "1997", ISBN = "0-201-63452-X", LCCN = "QA76.73.J38L56 1997", bibdate = "Wed Jun 17 22:05:06 MDT 1998", bibsource = "http://www.amazon.com/exec/obidos/ISBN=020163452X/wholesaleproductA/; http://www.aw.com/; http://www.javaworld.com/javaworld/books/jw-books-alphabytitle.html", price = "US\$36.53", series = "The Java Series", URL = "http://www.aw.com/cp/javaseries.html; http://www.aw.com/cseng/titles/0-201-63452-X", acknowledgement = ack-nhfb, dimensions = "9.20in x 7.36in x 1.03in", keywords = "Internet (Computer network); Java (Computer program language); Java (computer program language); programming languages (electronic computers); systems; virtual computer; Virtual computer systems", lccnalt = "96-015897", } on p. 76, it says: >> ... >> The Java Virtual Machine does not indicate overflow or >> underflow during operations on integer data types. The only >> integer operations that can throw an exception are the integer >> divide instructions ({\em idiv} and {\em ldiv}) and the >> integer remainder instructions ({\em irem} and {\em lrem}), >> which throws an {\tt ArithmeticException} if the divisor is >> zero. >> ... Thus, NTS in Java will still have to handle addition, subtraction, and multiply by special code that checks for overflow. Later, it says: >> ... >> The Java Virtual Machine's floating-point operators produce no >> exceptions. An operation that overflows produces a signed >> infinity, an operation that underflows produces a signed zero, >> and an operation that has no mathematically definite result >> produces NaN. All numeric operations with NaN as an operand >> produce NaN as a result. >> ... Thus, NaNs and Infinities propagate to the final results, where they are likely to be noticed, which is what the IEEE 754 designers intended.] ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- --IAA21720.901727427/proxy2.ba.best.com-- 29-Jul-1998 18:03:47-GMT,2481;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA28536 for ; Wed, 29 Jul 1998 12:03:42 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 29 Jul 1998 18:03:30 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01IZZ3MREMTC0003T6@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 29 Jul 1998 13:38:32 EDT Received: from gate.rmcs.cranfield.ac.uk ([193.63.247.66]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 29 Jul 1998 17:38:22 +0000 (UT) Received: by gate.rmcs.cranfield.ac.uk; id AA15356; Wed, 29 Jul 1998 17:40:45 +0000 (GMT) Received: from gw.rmcs.cranfield.ac.uk(193.63.243.2) by gate.rmcs.cranfield.ac.uk via smap (3.2) id xma015351; Wed, 29 Jul 1998 17:40:27 +0000 (GMT) Date: Wed, 29 Jul 1998 18:37:46 +0100 (BST) From: Brian {Hamilton Kelly} Subject: Re: Quotation character conventions, and TeX/LaTeX support thereof To: tex-implementors@ams.org, LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE Cc: TEX@gw.rmcs.cranfield.ac.uk Errors-to: tex-implementors-request@ams.org Message-id: <980729183746.356b7@gw.rmcs.cranfield.ac.uk> In message of Thu, 16 Jul 1998 16:37:44 -0600 (MDT), "Nelson H. F. Beebe" wrote: > I have just read a new document ``Quotation Character Semantics'', > available on the Web at > > http://www.unicode.org/unicode/uni2errata/QuoteErrata.html > > This document discusses quotation character conventions in several > European languages, and a related document ``Apostrophe Semantics'' > at > > http://www.unicode.org/unicode/uni2errata/Apostrophe.htm When I first read this, I assumed that Nelson had made a transcription error: surely one URL wouldn't end in .html and the other in .htm? However, I should have known that he wouldn't make any error, let alone a silly little one like that. The URLs really DO have different "file types". Obviously consistency isn't a strong point with Unicode.org!! Sheesh! -- Brian {Hamilton Kelly} TeX@rmcs.cranfield.ac.uk Smail: Department of Informatics & Simulation, Cranfield University, Royal Military College of Science, Shrivenham, SWINDON SN6 8LA, U.K. Phone: Swindon (01793) 785252 (UK), +44-1793-785252 (International) 2-Aug-1998 13:28:03-GMT,5667;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA13336 for ; Sun, 2 Aug 1998 07:28:01 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 2 Aug 1998 13:28:00 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J04FL2E5XC000DO3@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 2 Aug 1998 09:14:43 EDT Received: from afmp02.mppmu.mpg.de ([134.107.4.101]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 02 Aug 1998 13:14:33 +0000 (UT) Received: from pcl163a.mppmu.mpg.de (pcl163a.mppmu.mpg.de [134.107.3.54]) by afmp02.mppmu.mpg.de (8.8.8/8.8.8) with ESMTP id PAA02703; Sun, 02 Aug 1998 15:14:36 +0200 (MET DST) Received: from localhost (peb@localhost) by pcl163a.mppmu.mpg.de (8.7/8.7) with SMTP id PAA03143; Sun, 02 Aug 1998 15:14:32 +0200 Date: Sun, 02 Aug 1998 15:14:32 +0200 (MET DST) From: Peter Breitenlohner Subject: Re: arithmetic overflow (was note from Don Knuth (fwd)) In-reply-to: To: Barbara Beeton Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Reply-to: Peter Breitenlohner Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: pcl163a.mppmu.mpg.de: peb owned process doing -bs On Sun, 26 Jul 1998, Barbara Beeton wrote: > in the spirit of "compromise", i invite peter, nelson, phil taylor, ^^^^^ > david kastrup, and robin fairbairns (the participants in the present > discussion) together to write a brief and clear description of what > happens, ... hi barbara i'm clearly not the above peter but anyway. 1. TeX (tex.web) declares the allowed range of numerical quantities to be less than 2^{31} for numbers and less than 2^{30}sp (=2^{14}pt) for dimensions. The program does various checks on overflow, but there are important areas without such. The `Compiler directives' (for a ficticious Pascal system) do, however, specify that arithmetic overflow should be caught by the run-time system. There is a big problem since many run-time systems don't provide for this, the only implementation i know of where this is realized is the one for VMS (based directly on Pascal, not on Web2c). There have been lots of arguments whether arithmetically wrong results (in extreme cases) or an aborted job are the lesser evil. 2. TeX's numerical quantities are used in essentially three different contexts described in the following. 2a. Whenever TeX expects a number or dimension, the program invokes the procedure `scan_int' or `scan_dimen' respectively. scan_int checks for overflow except when the number is obtained directly from an `internal integer' (possibly with a minus sign attached to it), e.g. on a 32-bit machine, \count0=-"7FFFFFFF \advance\count0 by -1 \showthe\count0 yields `-2147483648' (exceeding the above mentioned limit) \count0=-\count0 \showthe\count0 yields again `-2147483648' (this is wrong) scan_dimen always checks for the allowed range (this is necessary since the implementation gives a special meaning to certain dimensions of 16384.0pt or more). 2b. Arithmetic requested by the user The result of \multiply and \divide is always checked, the result of \advance is never checked for overflow (but the second operand for \advance is, of course, obtained and possibly checked via scan_int/scan_dimen) e.g. again 32-bits \count0="40000000 \multiply\count0 by2 \dimen0=8192pt \multiply\dimen0 by2 both produce the error message `Arithmetic overflow', whereas (see above for integers) \dimen0=8192pt \advance\dimen0 by\dimen0 \showthe\dimen0 yields `16384.0pt' (exceeding the above mentioned limit), and consequently \dimen1=\dimen0 \showthe\dimen1 produces the error message `Dimension too large' and yields the truncated result `16383.99998pt'. Continuing with \advance\dimen0 by8192pt \advance\dimen0 by8192pt \showthe\dimen0 yields `--32768.0pt' (note the double `-' sign!). Continuing further \advance\dimen0 by-1sp \showthe\dimen0 \advance\dimen0 by2sp \showthe\dimen0 yields `32767.99998pt' and `-32767.99998pt' (all wrong) 2c. Arithmetic done internally when accumulating box dimensions. The results are never checked. I assume this really is the place where Don's comment `too expensive' applies since there are literally many dozens of places where overflow checks ought to be inserted. Just a small demo \def\x{\hskip 8192pt} \setbox0=\hbox{\x\x}\showthe\wd0 yields the `illegal' result `16384.0pt, \setbox0=\hbox{\x\x\x\x}\showthe\wd0 yields again the `double negative' `--32768.0pt'. ============================================================ A final note: the curious result `--32768.0pt' is a consequence of the `print_scaled' procedure (here an excerpt from tex.web) @p procedure print_scaled(@!s:scaled); {prints scaled real, rounded to five digits} var delta:scaled; {amount of allowable inaccuracy} begin if s<0 then begin print_char("-"); negate(s); {print the sign, if negative} end; print_int(s div unity); {print the integer part} ..... First if s is negative a minus sign is printed and s is negated, but the negative of -2^{31} on 32-bit machines is again -2^{31}. This is then divided by 2^{16} and the result (-32768 entire points) is printed. The omitted remainder of the procedure deals with the fractional part and is of no interst here. peter 11-Aug-1998 8:39:09-GMT,2337;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA07402 for ; Tue, 11 Aug 1998 02:39:07 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 11 Aug 1998 08:39:06 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0GQ4AJC0G000GYV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 11 Aug 1998 04:25:18 EDT Received: from heaton.cl.cam.ac.uk ([128.232.32.11]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 11 Aug 1998 08:25:07 +0000 (UT) Received: from dorceus.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.1.34] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1) id 0z69jt-0008Nz-00; Tue, 11 Aug 1998 09:25:05 +0100 Date: Tue, 11 Aug 1998 09:25:01 +0100 From: Robin Fairbairns Subject: Re: note from Don Knuth (fwd) In-reply-to: "Your message of Mon, 10 Aug 1998 17:02:15 EDT." To: Barbara Beeton Cc: tex-implementors@ams.org, ctan@urz.uni-heidelberg.de Errors-to: tex-implementors-request@ams.org Message-id: > dek has just finished the 1998 cycle of updates to tex and friends. > the new versions should be appearing at labrea.stanford.edu later > today. ctan maintainers -- please *don't* post them yet. don would > like to make sure everything is solid first. we don't take explicit action to have these things appear -- they appear in ctan via mirroring. i have killed the mirroring here, but dante (i see) still has mirroring set up -- i haven't checked whether boston gets the files from dante (i would assume so). while they're at it (updating the files at labrea) it would be *really* nice if whoever it is would ***not*** compress the (relatively) tiny files. (no-one will admit to me that they're responsible for this behaviour: i suspect my mail there has gone into a black hole...) while it doesn't directly bother me one jot, it makes life noticeably difficult for some of ctan's users. the saving in disc space from compressing the files is probably the equivalent of about 10c worth of rotating metal... Robin Fairbairns For the CTAN team 11-Aug-1998 9:36:05-GMT,2751;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA08505 for ; Tue, 11 Aug 1998 03:36:03 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 11 Aug 1998 09:36:03 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0GS1O4N2O000H3Y@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 11 Aug 1998 05:20:36 EDT Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 11 Aug 1998 09:20:16 +0000 (UT) Received: from attila.uni-duesseldorf.de (attila [134.99.64.144]) by xerxes.thphy.uni-duesseldorf.de (8.8.8/8.8.8) with SMTP id LAA27194; Tue, 11 Aug 1998 11:20:05 +0200 (MET DST) Received: by attila.uni-duesseldorf.de (SMI-8.6/SMI-SVR4) id LAA20604; Tue, 11 Aug 1998 11:20:04 +0200 Date: Tue, 11 Aug 1998 11:20:04 +0200 From: Ulrik Vieth Subject: Re: note from Don Knuth (fwd) In-reply-to: (message from Robin Fairbairns on Tue, 11 Aug 1998 09:25:01 +0100) To: Robin.Fairbairns@cl.cam.ac.uk Cc: bnb@ams.org, tex-implementors@ams.org, ctan@urz.uni-heidelberg.de Errors-to: tex-implementors-request@ams.org Message-id: <199808110920.LAA20604@attila.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit Robin Fairbairns: >> dek has just finished the 1998 cycle of updates to tex and friends. >> the new versions should be appearing at labrea.stanford.edu later >> today. ctan maintainers -- please *don't* post them yet. don would >> like to make sure everything is solid first. > while they're at it (updating the files at labrea) it would be > *really* nice if whoever it is would ***not*** compress the > (relatively) tiny files. (no-one will admit to me that they're > responsible for this behaviour: i suspect my mail there has gone > into a black hole...) Last I heard, it was Tom Rokicki who has responsible for putting things on labrea, so try asking him about it. Anyway, to all implementors interested in preserving the file dates and times stamps regardless of how and when the files get installed on labrea and mirrored on CTAN, I recommend getting the original file tex98.tar.gz and using that as a basis for building a distribution. The original source file seems to be ftp://labrea.stanford.edu/pub/tex/tex98.tar.gz A mirror copy, which I've just installed, is available from ftp://ftp.tug.org/historic/knuth/tex98.tar.gz (You can also find an archival copy of tex95.tar.gz over there.) Cheers, Ulrik. 11-Aug-1998 10:41:41-GMT,1595;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA09973 for ; Tue, 11 Aug 1998 04:41:40 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 11 Aug 1998 10:41:39 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0GUJ5OTZK000H9G@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 11 Aug 1998 06:31:47 EDT Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 11 Aug 1998 10:31:38 +0000 (UT) Date: Tue, 11 Aug 1998 11:31:36 +0100 From: Philip Taylor (RHBNC) Subject: Re: note from Don Knuth (fwd) To: Robin.Fairbairns@cl.cam.ac.uk Cc: BNB@ams.org, TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <980811113136.4843@vms.rhbnc.ac.uk> >> while they're at it (updating the files at labrea) it would be >> *really* nice if whoever it is would ***not*** compress the >> (relatively) tiny files. (no-one will admit to me that they're >> responsible for this behaviour: i suspect my mail there has gone into >> a black hole...) >> >> while it doesn't directly bother me one jot, it makes life noticeably >> difficult for some of ctan's users. the saving in disc space from >> compressing the files is probably the equivalent of about 10c worth of >> rotating metal... Hear hear! Philip Taylor, RHBNC. 11-Aug-1998 10:51:34-GMT,2041;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA10271 for ; Tue, 11 Aug 1998 04:51:33 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 11 Aug 1998 10:51:32 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0GUP9RQ0W000HEX@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 11 Aug 1998 06:36:50 EDT Received: from picasso.imb-jena.de ([192.124.248.32]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 11 Aug 1998 10:36:39 +0000 (UT) Received: (from hsk@localhost) by picasso.imb-jena.de (980427.SGI.8.8.8/970903.SGI.AUTOCF/hsk) id MAA08738 for tex-implementors@ams.org; Tue, 11 Aug 1998 12:36:32 +0200 (MDT) Date: Tue, 11 Aug 1998 12:36:32 +0200 (MDT) From: hsk@imb-jena.de (Friedrich Haubensak) Subject: buglet in plain.tex 3.1415926 ? To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199808111036.MAA08738@picasso.imb-jena.de> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL25] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit hello, the following i've posted to comp.text.tex this morning. ulrik vieth (vieth@thphy.uni-duesseldorf.de) suggested that i send a copy to you. > there are new tex.web, mf.web, plain.tex, plain.mf etc. files on labrea. > though i haven't looked at all of them yet, there seems to be a typo in > one of them, plain.tex 3.1415926. line 663 reads > > \def\AA{\leavevmode\setbox0\hbox{!}\dimen@\ht1\advance\dimen@-1ex% > > imho this \ht1 should (still) be \ht0 (or \ht\z@). greetings, fritz haubensak -- Friedrich Haubensak hsk@imb-jena.de | Science is true! Institut fuer Molekulare Biotechnologie | Don't be mislead by facts. Beutenbergstrasse 11, Jena +---------------------------------- Post: PF 100 813, D-07708 Jena | Tel. +49-3641-65-6202 | Fax +49-3641-65-6210 11-Aug-1998 11:06:53-GMT,1897;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id FAA10604 for ; Tue, 11 Aug 1998 05:06:51 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 11 Aug 1998 11:06:51 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0GV81YY1C000HGN@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 11 Aug 1998 06:51:51 EDT Received: from pillar.elsevier.co.uk ([193.131.222.35]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 11 Aug 1998 10:51:42 +0000 (UT) Received: from snowdon.elsevier.co.uk [193.131.197.164]; by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP; sender "s.rahtz@elsevier.co.uk"; id LAA25965; hop 0; Tue, 11 Aug 1998 11:45:20 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Tue, 11 Aug 1998 11:51:30 +0100 Date: Tue, 11 Aug 1998 09:43:08 +0100 From: Sebastian Rahtz Subject: Re: note from Don Knuth (fwd) In-reply-to: To: bnb@ams.org Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <7317-Tue11Aug1998094308+0100-s.rahtz@elsevier.co.uk> MIME-version: 1.0 X-Mailer: emacs 19.34.6 (via feedmail 8-beta-20 Q); VM 6.33 under Emacs 19.34.6 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Barbara Beeton writes: ... > or directly to me. please put "tex 3.141592" in the subject -- i .... > + Changes to TeX: The Program > > A few corrections were made to the comments, but the version > remains 3.14159. lets just be clear that we are NOT moving to tex 3.141592 :-} sebastian 11-Aug-1998 11:30:28-GMT,2737;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id FAA11130 for ; Tue, 11 Aug 1998 05:30:27 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 11 Aug 1998 11:30:26 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0GW5H49J4000GRJ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 11 Aug 1998 07:18:06 EDT Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Tue, 11 Aug 1998 11:17:52 +0000 (UT) Received: from attila.uni-duesseldorf.de (attila [134.99.64.144]) by xerxes.thphy.uni-duesseldorf.de (8.8.8/8.8.8) with SMTP id NAA27524; Tue, 11 Aug 1998 13:17:42 +0200 (MET DST) Received: by attila.uni-duesseldorf.de (SMI-8.6/SMI-SVR4) id NAA21227; Tue, 11 Aug 1998 13:17:41 +0200 Date: Tue, 11 Aug 1998 13:17:41 +0200 From: Ulrik Vieth Subject: Re: buglet in plain.tex 3.1415926 ? In-reply-to: <199808111036.MAA08738@picasso.imb-jena.de> (hsk@imb-jena.de) To: hsk@imb-jena.de Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199808111117.NAA21227@attila.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit > hello, > the following i've posted to comp.text.tex this morning. ulrik vieth > (vieth@thphy.uni-duesseldorf.de) suggested that i send a copy to you. >> there are new tex.web, mf.web, plain.tex, plain.mf etc. files on labrea. >> though i haven't looked at all of them yet, there seems to be a typo in >> one of them, plain.tex 3.1415926. line 663 reads >> >> \def\AA{\leavevmode\setbox0\hbox{!}\dimen@\ht1\advance\dimen@-1ex% >> >> imho this \ht1 should (still) be \ht0 (or \ht\z@). As I have checked in the meantime, the latest errata.tex does say \ht0 as you suggested, so the \ht1 in plain.tex seems to be a typo. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \bugonpage A356, line 21 (8/6/98) \ninepoint\noindent |\def\AA{\leavevmode\setbox0=\hbox{!}\dimen@=\ht0 \advance\dimen@ by-1ex| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So was this the proof for "at least one mistake", DEK claims to have made? DEK> I hope a few people will be able to verify that the new stuff DEK> makes sense, before the files are too widely distributed. I tried DEK> to be careful and check everything carefully, but if I was only DEK> 99.9% accurate I made at least one mistake! I suppose the new DEK> sources shouldn't go into CTAN for another month or so. Cheers, Ulrik. 13-Aug-1998 2:42:01-GMT,1916;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id UAA07306 for ; Wed, 12 Aug 1998 20:42:00 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Aug 1998 02:41:56 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0J5UL8RK0000ULY@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 12 Aug 1998 22:17:56 EDT Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 13 Aug 1998 02:17:47 +0000 (UT) Received: from mail-out-3.tiac.net (mail-out-3.tiac.net [199.0.65.15]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id WAA18300 for ; Wed, 12 Aug 1998 22:17:46 -0400 (EDT envelope-from support@YandY.com) Received: from denali (p15.tc8.metro.MA.tiac.com [209.61.76.144]) by mail-out-3.tiac.net (8.8.7/8.8.7) with SMTP id WAA14797 for ; Wed, 12 Aug 1998 22:17:45 -0400 (EDT envelope-from support@YandY.com) Date: Wed, 12 Aug 1998 22:18:12 -0400 From: "Y&Y, Inc." Subject: tex 3.14159 and plain tex 3.1415926 X-Sender: yandy@pop.tiac.net To: tex-implementors@AXP14.AMS.ORG Errors-to: tex-implementors-request@AXP14.AMS.ORG Message-id: <199808130217.WAA14797@mail-out-3.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Content-type: text/plain; charset="us-ascii" Hi: Thanks for the information on the update. Is it really true that are no changes in TeX itself (other than changes in comments in tex.web)? Great, less work :-). Presumably then various `mis-features' reported were declared `features'? Like the truncation of long \special strings and the quite replacement of the tail of the string with \ETC.? Regards, Berthold. 15-Aug-1998 15:46:38-GMT,2339;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA00973 for ; Sat, 15 Aug 1998 09:46:36 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 15 Aug 1998 15:46:36 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0MQC91QYO000D6P@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 15 Aug 1998 11:36:28 EDT Received: from mail.inreach.com ([209.142.0.3]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sat, 15 Aug 1998 15:36:17 +0000 (UT) Received: from teleport.com (209-142-33-95.stk.inreach.net [209.142.33.95] (may be forged)) by mail.inreach.com (8.8.8/8.8.6/(InReach)) with ESMTP id IAA28592 for ; Sat, 15 Aug 1998 08:29:22 -0700 (PDT) Date: Sat, 15 Aug 1998 08:42:04 -0700 From: Arthur Ogawa Subject: Re: tex 3.14159 and plain tex 3.1415926 To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Reply-to: ogawa@teleport.com Message-id: <35D5AC48.38A048BE@teleport.com> Organization: TeX Consultants MIME-version: 1.0 X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199808130217.WAA14797@mail-out-3.tiac.net> Y&Y, Inc. wrote: > ...various `mis-features' reported were declared > `features'? Like the truncation of long \special strings and > the quite replacement of the tail of the string with \ETC.? ^^^^^ quiet That TeX would do such a thing mystifies me. The DVI file format allows for three \special syntax with sizes up to 2^^24 bytes. (Or perhaps more, this is from memory.) Under what circumstances does TeX truncate a \special? Oh, in the *TeX log*, you will see the \ETC, of course. I think this is not what Berthold had in mind, though. -- Arthur Ogawa/TeX Consultants voice: +1 209 561-4585 Fax: +1 209 561-4584 mailto:ogawa@teleport.com http://www.teleport.com/~ogawa ftp://ftp.teleport.com/users/ogawa PGP key: finger -l ogawa@teleport.com ________________________________ For the best in (La)TeX-nical typesetting and Web page production join the TeX Users Group (TUG) --- browse at http://www.tug.org 15-Aug-1998 17:34:50-GMT,4705;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA03670 for ; Sat, 15 Aug 1998 11:34:48 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 15 Aug 1998 17:34:48 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J0MU5N7Y5S000BZM@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 15 Aug 1998 13:25:38 EDT Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sat, 15 Aug 1998 17:25:29 +0000 (UT) Received: from mail-out-3.tiac.net (mail-out-3.tiac.net [199.0.65.15]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id NAA08204; Sat, 15 Aug 1998 13:25:28 -0400 (EDT envelope-from support@YandY.com) Received: from denali (p87.tc1.metro.MA.tiac.com [209.61.75.88]) by mail-out-3.tiac.net (8.8.7/8.8.7) with SMTP id NAA28866; Sat, 15 Aug 1998 13:25:26 -0400 (EDT envelope-from support@YandY.com) Date: Sat, 15 Aug 1998 13:25:54 -0400 From: "Y&Y, Inc." Subject: Re: tex 3.14159 and plain tex 3.1415926 In-reply-to: <35D5AC48.38A048BE@teleport.com> X-Sender: yandy@pop.tiac.net To: ogawa@teleport.com, tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <4.0.1.19980815125752.00f53100@pop.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Content-type: text/plain; charset="us-ascii" References: <199808130217.WAA14797@mail-out-3.tiac.net> Hi: At 08:42 AM 98/08/15 -0700, Arthur Ogawa wrote: >> ...various `mis-features' reported were declared >> `features'? Like the truncation of long \special strings and >> the quite replacement of the tail of the string with \ETC.? > ^^^^^ quiet >That TeX would do such a thing mystifies me. The DVI file format allows for >three \special syntax with sizes up to 2^^24 bytes. (Or perhaps more, this is >from memory.) It is not that the \special string is too long for the DVI file format, but that it is read into string memory at a point when there isn't enough space left for it. It is then chopped off, with its tail replaced with \ETC. --- no error message. >Under what circumstances does TeX truncate a \special? >Oh, in the *TeX log*, you will see the \ETC, of course. I think this is not >what Berthold had in mind, though. No, but the machinery that does that is exactly the same that chops off the tail of the \special. It results from \special output calling show_token_list, which is designed to be `robust' for dumping of debugging information, and to stop when it gets into trouble doing that. In a system with fixed allocations, this error will not be noticed normally, since if you are about to run out of string space, processing will stop soon anyway when you do run out and a truncated \special string is the least of your worries. In a system using dynamic allocation, this comes up, because it is not the end of the world when you run out string space, you just make more. But now you have a corrupt DVI file... This is one of several errors that will not be discovered easily in TeX systems with fixed allocations, but plague those with dynamic memory allocation. And something like the TRIP test is unable to help in finding these. Regards, Berthold. @ After all this preliminary shuffling, we come finally to the routines that actually send out the requested data. Let's do \.{\\special} first (it's easier). @= procedure special_out(@!p:pointer); var old_setting:0..max_selector; {holds print |selector|} @!k:pool_pointer; {index into |str_pool|} begin synch_h; synch_v;@/ old_setting:=selector; selector:=new_string; show_token_list(link(write_tokens(p)),null,pool_size-pool_ptr); selector:=old_setting; str_room(1); if cur_length<256 then begin dvi_out(xxx1); dvi_out(cur_length); end else begin dvi_out(xxx4); dvi_four(cur_length); end; for k:=str_start[str_ptr] to pool_ptr-1 do dvi_out(so(str_pool[k])); pool_ptr:=str_start[str_ptr]; {erase the string} end; @= procedure show_token_list(@!p,@!q:integer;@!l:integer); label exit; var m,@!c:integer; {pieces of a token} @!match_chr:ASCII_code; {character used in a `|match|'} @!n:ASCII_code; {the highest parameter number, as an ASCII digit} begin match_chr:="#"; n:="0"; tally:=0; while (p<>null) and (tally; @; p:=link(p); end; if p<>null then print_esc("ETC."); @.ETC@> exit: end; 26-Aug-1998 7:59:26-GMT,1596;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA29181 for ; Wed, 26 Aug 1998 01:59:21 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 26 Aug 1998 07:59:21 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J11MVRB5OW000YIO@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 26 Aug 1998 03:39:33 EDT Received: from perdita.zdv.Uni-Mainz.DE ([134.93.8.147]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Wed, 26 Aug 1998 07:39:21 +0000 (UT) Received: (from schoepf@localhost) by perdita.zdv.Uni-Mainz.de (8.8.8/8.8.8) id JAA00883; Wed, 26 Aug 1998 09:39:50 +0200 (MEST) Date: Wed, 26 Aug 1998 09:39:48 +0200 (MEST) From: Rainer Schoepf Subject: Bug in icmcsc10.mf fixed To: tex-implementors@ams.org, ctan-announce@urz.uni-heidelberg.de Cc: latex-team@goofy.zdv.Uni-Mainz.de Errors-to: tex-implementors-request@ams.org Message-id: <13795.48069.5882.796649@perdita.zdv.Uni-Mainz.de> Organization: Johannes Gutenberg-Universitaet Mainz MIME-version: 1.0 X-Mailer: VM 6.51 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Vladimir Volovich reported that the LaTeX font icmcsc10 (the invisible variant of cmcsc10) wasn't invisible. I have just corrected the file fonts/latex/mf/icmcsc10.mf on CTAN. Please update this file in all TeX distributions. Thank you Rainer Schoepf 19-Sep-1998 20:06:50-GMT,6326;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id OAA19431 for ; Sat, 19 Sep 1998 14:06:49 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 19 Sep 1998 20:06:44 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #30286) id <01J1ZVIR866O00060P@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 19 Sep 1998 15:54:03 EDT Date: Sat, 19 Sep 1998 15:53:54 -0400 (EDT) From: bbeeton Subject: possible problem with lcircle*.tfm file To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <906234834.431137.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: i am looking for a volunteer to help diagnose a problem that has turned up with the lcircle*.tfm fonts. here is the story. a probable metrics problem with lcircle10 was reported to blue sky research concerning bad positioning of a circle in the latex picture environment -- the circle crossed through the left edge of a square drawn around the circle. (the test file is attached.) since ams now holds the copyright on the type 1 outline fonts, the problem was passed on to us. we confirmed the reported effect. no tfm files are distributed with the cm-ps type 1 fonts; it is expected that the ctan tfm files will be used, although that is not documented in the ams distribution. exploring at ctan, we found the following files: 1994/06/05 | 9689 | fonts/latex/mf/circle.mf 1994/06/05 | 392 | fonts/latex/mf/lcircle10.mf 1994/06/05 | 392 | fonts/latex/mf/lcirclew10.mf 1991/03/07 | 820 | fonts/latex/tfm/lcircle10.tfm 1991/03/07 | 820 | fonts/latex/tfm/lcirclew10.tfm 1995/06/12 | 9688 | systems/knuth/local/lib/lcircle.mf 1995/06/12 | 126 | systems/knuth/local/lib/lcircle10.mf 1995/06/12 | 126 | systems/knuth/local/lib/lcirclew10.mf the discrepancies in dates and sizes led us to conclude that we had better check labrea as well: /tex/fonts -rw-rw-r-- 1 3732 lftp 820 Mar 10 1988 circle10.tfm -rw-rw-r-- 1 3732 lftp 820 Apr 3 1986 circlew10.tfm /tex/local/lib -rw-r--r-- 1 3732 lftp 9688 Aug 11 1989 lcircle.mf -rw-r--r-- 1 3732 lftp 126 Aug 11 1989 lcircle10.mf -rw-r--r-- 1 3732 lftp 126 Aug 11 1989 lcirclew10.mf whatever else one notices, it is clear that all the tfm files are dated earlier than any of the .mf files. however, we have converted them all to .pl form and compared -- the metrics are identical at labrea and ctan. but these are the metrics that gave the bad results with the test file. using two different versions of metafont (the web2c unix implementation >From tetex 0.4 on a digital alpha, and the mac implementation distributed with oztex), we generated new tfm and pl files for lcircle10. the two new versions are identical, but differ from the ctan/labrea versions. see below for sample extracts. using the new lcircle10.tfm we reran the test -- the problem went away. we conclude that the lcircle*.tfm files at ctan and labrea are probably wrong, and should be regenerated. this is what needs to be verified. when there is solid confirmation and agreement, i will get in touch with dek and request that labrea be updated, if that is appropriate. -------------------- some more details ... the names of the various files differ rather wildly. at labrea, the .tfm files are named simply "circle" -- no "l". however, all the .mf files do have "l", and further, except for the dates, they are the same as the ctan files in systems/knuth/local/lib/, which i understood to be mirrored from labrea, so this -- except for the dates -- is as expected. what should be the canonical names of these files? i remember some discussion a while back, but can't find any reference; it was apparently in some forum other than tex-implementors. the two sets of .mf files at ctan are rather more different. the sizes of the *10.mf files are more than double that of the knuth versions; this is because of the addition (by RmS -- rainer schoepf?) of a test for cmbase loaded -- it shouldn't be. however, the two versions should be functionally equivalent, provided the knuth versions are run with plain.base as they should be. the circle.mf/lcircle.mf files differ only by an extra blank line at the end of the version in fonts/latex/mf/. this file contains a correction signed by dek: % thickness#:=thickness/hppp; % and let thickness# round to right value % NO, I deleted this BAD line! --- DEK, 9 Jul 87 and that, i presume, is why these files are in the knuth area. but these file differences do not explain the differences in metrics. here are some examples from the pl files described above. Glyph metrics from the PL file generated from ftp://labrea.stanford.edu/tex/fonts/circle10.tfm (same results from the tfm at ctan): (CHARACTER O 1 (CHARWD R 0.4) (CHARHT R 0.224994) (CHARDP R 0.175008) ) (CHARACTER O 13 (CHARWD R 1.2) (CHARHT R 0.624994) (CHARDP R 0.575007) ) Corresponding glyph metrics from the PL file generated >From a TFM file generated by running OzMF 1.3 on the file ftp://ctan.tug.org/tex-archive/fonts/latex/mf/lcircle10.mf (same results using same source file and unix mf implementation): (CHARACTER O 1 (CHARWD R 0.4) (CHARHT R 0.219999) (CHARDP R 0.18) ) (CHARACTER O 13 (CHARWD R 1.2) (CHARHT R 0.62) (CHARDP R 0.58) ) -------------------- latex test file: \documentclass[11pt]{article} \begin{document} Please note the slight offset to the lower left of the circle with respect to the square. \begin{equation} \begin{picture}(40,40) \linethickness{0.38pt} \put(20,20){\oval(40,40)} \put( 0, 0){\line( 1, 0){40}} \put(40, 0){\line( 0, 1){40}} \put(40,40){\line(-1, 0){40}} \put( 0,40){\line( 0,-1){40}} \end{picture} \end{equation} \end{document} -------------------- will someone please volunteer to replicate these tests and report on the results? thanks. -- bb 19-Sep-1998 21:37:42-GMT,1820;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id PAA21369 for ; Sat, 19 Sep 1998 15:37:41 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 19 Sep 1998 21:37:41 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J1ZYERO9RK0005OI@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 19 Sep 1998 17:16:21 EDT Received: from zothommog.evcom.net ([208.136.203.8]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sat, 19 Sep 1998 21:16:11 +0000 (UT) Received: (from kinch@localhost) by zothommog.evcom.net (8.8.8/8.8.8) id RAA30458; Sat, 19 Sep 1998 17:16:04 -0400 Date: Sat, 19 Sep 1998 17:16:04 -0400 (EDT) From: "Richard J. Kinch" Subject: Re: possible problem with lcircle*.tfm file In-reply-to: <906234834.431137.BNB@MATH.AMS.ORG> To: BNB@ams.org (bbeeton) Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Reply-to: kinch@truetex.com Message-id: <199809192116.RAA30458@zothommog.evcom.net> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit > we conclude that the lcircle*.tfm files at ctan and labrea are probably > wrong, and should be regenerated. this is what needs to be verified. I agree with your diagnosis. TrueTeX ran the LaTeX test file correctly. We use an lcircle10.tfm that dates back to 1990, but which matches your newly regenerated versions, not the suspect ctan/labrea versions. I also ran the .mf sources throught TurboMETAFONT and confirmed this result. Richard J. Kinch Publisher, TrueTeX (R) brand typesetting software. See http://truetex.com 19-Sep-1998 23:56:58-GMT,3280;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id RAA23993 for ; Sat, 19 Sep 1998 17:56:56 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 19 Sep 1998 23:56:56 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J203IYD9GG0006RU@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 19 Sep 1998 19:43:16 EDT Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sat, 19 Sep 1998 23:43:07 +0000 (UT) Received: from mail-out-3.tiac.net (mail-out-3.tiac.net [199.0.65.15]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id TAA23012; Sat, 19 Sep 1998 19:43:07 -0400 (EDT envelope-from support@YandY.com) Received: from denali (p107.tc5.metro.MA.tiac.com [209.61.76.108]) by mail-out-3.tiac.net (8.8.7/8.8.7) with SMTP id TAA19504; Sat, 19 Sep 1998 19:43:06 -0400 (EDT envelope-from support@YandY.com) Date: Sat, 19 Sep 1998 19:42:32 -0400 From: "Y&Y, Inc." Subject: Re: possible problem with lcircle*.tfm file In-reply-to: <906234834.431137.BNB@MATH.AMS.ORG> X-Sender: yandy@pop.tiac.net To: bbeeton , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199809192343.TAA19504@mail-out-3.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Content-type: text/plain; charset="us-ascii" Hi: At 03:53 PM 98/09/19 -0400, bbeeton wrote: >a probable metrics problem with lcircle10 was reported to blue sky >research concerning bad positioning of a circle in the latex picture >environment -- the circle crossed through the left edge of a square >drawn around the circle. (the test file is attached.) I think it would help if you also sent the analysis in the email I sent alerting you to this problem. Basically the depths and heights for characters 0 - 39 are slighlty off in the TFM files for LCIRCLE10 and LCIRCLEW10 on CTAN. These are the same files as CIRCLE10 and CIRCLEW10 on LABREA. (The Textures metric files used by Markus van Almsick, who first noticed there was a problem, have a larger error, which made the effect more visible). I had trouble at first reproducing the problem since the TFM files that come with Y&Y TeX and the `extra LaTeX + SliTeX' fonts are correct. We made those many years ago when we made the Type 1 versions of the LINE and LCIRCLE fonts (the have a date of 1991-2-25), and discovered that the `official' TFMs didn't make sense. It's not an obvious thing to diagnose, since the depth and height of letters in these fonts are *not* matched by the character bounding boxes - as happens so often with `math' fonts, the TFM files lie. For example, the difference between height and depth is used to pin down the thickness of the stroke. And this is what is wrong in the CTAN TFMs. Note that if corrected TFMs for these two fonts are distributed then people should remake their format files, since these are amongst the fonts frozen into the format for LaTeX (that is, it doesn't help to simply put them where your TeX looks for TFM metric files!). Regards, Berthold. 20-Sep-1998 0:23:26-GMT,2629;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id SAA24526 for ; Sat, 19 Sep 1998 18:23:25 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Sep 1998 00:23:24 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J204JCE49S00062E@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 19 Sep 1998 20:11:50 EDT Received: from june.cs.washington.edu ([128.95.1.4]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 20 Sep 1998 00:11:41 +0000 (UT) Received: (mackay@localhost) by june.cs.washington.edu (8.8.7+CS/7.2ju) id RAA18290; Sat, 19 Sep 1998 17:11:40 -0700 Date: Sat, 19 Sep 1998 17:11:40 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: possible problem with lcircle*.tfm file To: BNB@ams.org, tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199809200011.RAA18290@june.cs.washington.edu> I can answer the question about the renaming to lcircle. Rick Furuta and I are responsible for that. All the other latex specific fonts began with the letter l, and in the days when we were using pretty crude heuristics to divide up font packages for the UnixTeX distribution, we found that it helped in many ways to be able to specify all LaTeX METAFONT sources as l*.whatever. I can't dredge up the specific arguments, and anyway the TDS has made them irrelevant, but there was a public airing of the name change, and all parties seemed to agree. I don't much like the look of the second lot of TFM glyph metrics. It looks to me as if a tacit rounding has been done. it is very rare for METAFONT to produce values as terse and rounded as that when curves are involved. The cir*.mf files are certainly older, unless there was a correction---and I don't remember one---but the lcir* files did not at the time Rick and I added the l undergo any changes whatsoever. lcircle*.mf and circle*.mf should be identical in all parameters, unless someone can remember an authorized change being made. If they are identical, then the difference in the two sets of glyph metrics indicate a drift in someone's METAFONT compilation. I'll do a compile of my copy of the lcir* files and see how it matches what you have. Pierre Email: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for 218 Denny Hall, Box 353110 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder) 20-Sep-1998 1:12:12-GMT,7804;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id TAA25360 for ; Sat, 19 Sep 1998 19:12:11 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Sep 1998 01:12:11 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2068SAX6O0007QU@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 19 Sep 1998 21:00:36 EDT Received: from sun06.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0EZK00MBN5GPTF@sun06.ams.org> for tex-implementors@axp14.ams.org; Sat, 19 Sep 1998 21:00:25 -0400 (EDT) Date: Sat, 19 Sep 1998 21:00:25 -0400 (EDT) From: Barbara Beeton Subject: Re: possible problem with lcircle*.tfm file In-reply-to: <199809192343.TAA19504@mail-out-3.tiac.net> To: "Y&Y, Inc." Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII berthold writes, in response to my message about the metrics anomaly in lcircle10, I think it would help if you also sent the analysis in the email I sent alerting you to this problem. thanks for the reminder about that message, berthold. i did need the nudge in order to be able to find it. it's attached. it does add some more details, but i think it doesn't change the situation, or what needs to be done about it at labrea and ctan. i have now received confirmation from several other people that they have performed the same test that i described, and gotten the same results; i am convinced that the .tfm files on ctan are erroneous, and need to be replaced by .tfm's newly generated by metafont. as far as i can tell from visual inspection of the output -- i have not examined the precise numbers -- the results are correct when using the new .tfm file. since it is my understanding that the ctan files are mirrored from labrea (although the difference in dates makes me wonder), *and* since the files at labrea are also wrong, they need to be replaced too. is there anything more that needs to be said about that to dek besides my message and the confirmation that what it says is true? specifically, do you still believe that this has uncovered a bug in metafont? i'm skeptical, as i explain below. circle.mf is essentially divided in two parts: - this comment: % a quarter-circle has width, height and depth set as explained on % page 389 of the TeXbook, not the real width, height, and depth - 40 characters -- circle quadrants -- for which heights and depths are present - this comment: % The full circles have height and depth 0pt because otherwise there % are too many heights and depths for the TFM files - 30 characters -- full circles with height = depth = 0 the absence of height and depth for the full circles is obviously intentional. there have been quite a few changes to metafont since the dates on the .tfm files at labrea (earlier than the dates on the ctan files); at least 5 of them (as listed in mf84.bug) are associated with errors in roundoff routines, and one of these (560) is an extensive correction to an earlier, even more extensive, correction (550). if i had to decide where the change was made that caused the different values in lcircle*.tfm, i'd say it was in one of these -- and i also believe that whatever problem was there before has probably been fixed, and that the values in the .tfm files generated by a current version of metafont are probably correct, unless some new error was introduced in the 1998 updates that don completed last month. (we didn't test with that version of metafont.) unless someone comes up with a demonstration that .tfm's generated by metafont 2.718 or higher are incorrect, on september 29 i will write to don and ask him please to regenerate (or have someone else regenerate) the .tfm files for lcircle* at labrea. i would also like to ask him to normalize the names of the circle fonts. at the same time i will submit a latexbug report containing the text of the message to don as well as the latex test file attached to my previous message, and the observation that a new latex.fmt file will be needed. when the new files are there, i will ask the ctan maintainers to install the new .tfm files, mirrored from labrea. i will include in that message the warning about a new latex.fmt file. it is the practice of the ctan maintainers to incorporate the important parts of the conveying message from the originator in messages to ctan-ann, and those messages are now automatically sent also to comp.text.tex. so, to summarize, here are the essential milestones: - notify dek about updating labrea - submit latexbug report - when labrea is updated, notify ctan management to update ctan - ctan-ann message forwarded to comp.text.tex i will be on holiday from september 24-28. i will plan on setting this scheme in motion as soon as i return. -- bb -------------------- Date: Fri, 18 Sep 1998 12:11:17 -0400 From: Berthold Horn To: Markus van Almsick Cc: Ben_Thoma@bluesky.com, tjk@ams.org, bnb@ams.org Subject: lcircle fonts and rule positioning in Textures with ATM Hi: re: incorrect TFM metrics for LaTeX circle font cause position error in picture env Well, the story is even more interesting. Remember I calculated an error of .26pt based on the difference between the Textures metrics and the CTAN metrivs, but then I saw a 0.3pt difference between the DVI file produced by Y&Y TeX and the DVI file produced by Textures? The difference is the result of the fact that the TFM files on CTAN are *also* wrong - less than those in Textures by about an order of magnitude, but still wrong. This means the CIRCLE10 and CIRCLEW10 TFMs on ftp.labrea.stanford (Knuth's home) are also wrong (since except for file name they are identical to LCIRCLE10 and LCIRCLEW10 on CTAN), so this (small) error has been there ever since the line and circle fonts were made. The errors occur in characters 0 -- 39 in both LCIRCLE10 and LCIRLEW10. So any circle constructed from quadrants will be misplaced slightly. Complete circles (open or filled) are not affected. I believe it may be a problem in the way the height and depth tables are constructed by MetaFont. As you know, TeX only has space in its tables for a small number of heights (16) , depths (16), and italic corrections (64). So when more than that number of distinct heights or depths is needed, it approximates. This doesn't quite explain it, since these fonts only need 10 different depths and 10 different heights, as far as I can tell. But it is possible that there is some error in the MetaFont code for these fonts, or in the algorithm used to allocate slots in the height and depth tables. In any case, the heights and depths in both the CTAN and the Textures metrics are wrong Error in depth and height of char 0-39 in LCIRCLE10: CTAN TFM: - 4.994 / 1000 em - Textures metrics: - 30.187/1000 em LCIRCLEW10: CTAN TFM: - 8.187 / 1000 em - Textures metrics: - 10.187/1000 em Fortunately the TFM files that come with Y&Y TeX are correct :-) I have a vague recollection that when we made these fonts in Type 1 format many years ago, we noticed this error in the TFMs and made our own TFMs to fix it... The error in DVI files based on CTAN metrics in the circletest.tex example is noticable at high magnification in DVIWindo, although not nearly as obvious as when using Textures metrics, which shows up even at normal magnification. Maybe someone can check the MetaFont code for LCIRCLE fonts... Regards, Berthold. 20-Sep-1998 2:14:49-GMT,3106;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id UAA26459 for ; Sat, 19 Sep 1998 20:14:48 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Sep 1998 02:14:47 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J208EM1UOW000816@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sat, 19 Sep 1998 22:02:32 EDT Received: from mail-out-0.tiac.net ([199.0.65.247]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 20 Sep 1998 02:02:24 +0000 (UT) Received: from mail-out-3.tiac.net (mail-out-3.tiac.net [199.0.65.15]) by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id WAA21130; Sat, 19 Sep 1998 22:02:23 -0400 (EDT envelope-from support@YandY.com) Received: from denali (p58.tc1.metro.MA.tiac.com [209.61.75.59]) by mail-out-3.tiac.net (8.8.7/8.8.7) with SMTP id WAA24507; Sat, 19 Sep 1998 22:02:21 -0400 (EDT envelope-from support@YandY.com) Date: Sat, 19 Sep 1998 22:02:16 -0400 From: "Y&Y, Inc." Subject: Re: possible problem with lcircle*.tfm file In-reply-to: <199809200011.RAA18290@june.cs.washington.edu> X-Sender: yandy@pop.tiac.net To: mackay@cs.washington.edu (Pierre MacKay), BNB@ams.org, tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199809200202.WAA24507@mail-out-3.tiac.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Content-type: text/plain; charset="us-ascii" At 05:11 PM 98/09/19 -0700, Pierre MacKay wrote: >I don't much like the look of the second lot of TFM glyph >metrics. It looks to me as if a tacit rounding has been done. >it is very rare for METAFONT to produce values as terse and >rounded as that when curves are involved. That is the problem with the CTAN versions: they have been `rounded' - although I cannot see why since only 10 different depths and 10 different heights are needed and TFM files have tables with space for 16 of each of those. The actual values should be nice round multiples of 20/1000 em and 40/1000 em (which are the stroke widths for LCIRCLE and LCIRCLEW respectively). Remember that these heights and depths are *not* the bounding boxes of the glyphs, but numbers needed for TeX to get proper positioning. >The cir*.mf files are certainly older, unless there was a >correction---and I don't remember one---but the lcir* files >did not at the time Rick and I added the l undergo any changes >whatsoever. lcircle*.mf and circle*.mf should be identical >in all parameters, unless someone can remember an authorized >change being made. If they are identical, then the difference >in the two sets of glyph metrics indicate a drift in someone's >METAFONT compilation. The LABREA metrics file for CIRCLE10 is identical to the CTAN metrics file for LCIRCLE10, right down to both having the FontID of CIRCLE10. Both are wrong. Ditto for CIRCLEW10 and LCIRCLEW10 (although the error is even smaller there). Regards, Berthold. 20-Sep-1998 8:50:15-GMT,1890;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA04296 for ; Sun, 20 Sep 1998 02:50:13 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 20 Sep 1998 08:50:12 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J20M60F5A8000927@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 20 Sep 1998 04:36:29 EDT Received: from kralle.zdv.Uni-Mainz.DE ([134.93.8.158]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 20 Sep 1998 08:36:19 +0000 (UT) Received: (from Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.8.8/8.8.8) id KAA25660; Sun, 20 Sep 1998 10:36:13 +0200 (MET DST) Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id KAA18047; Sun, 20 Sep 1998 10:23:48 +0200 Date: Sun, 20 Sep 1998 10:23:48 +0200 From: Frank Mittelbach Subject: Re: possible problem with lcircle*.tfm file In-reply-to: <199809200202.WAA24507@mail-out-3.tiac.net> To: "Y&Y, Inc." Cc: mackay@cs.washington.edu (Pierre MacKay), BNB@ams.org, tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199809200823.KAA18047@frank.zdv.uni-mainz.de> References: <199809200011.RAA18290@june.cs.washington.edu> <199809200202.WAA24507@mail-out-3.tiac.net> X-Authentication-warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to latex3 using -f i've tried the example with tex live 3 last night and there the outcome is correct as well. is it possible the the incorrect tfms have been produced using a preloaded cmbase? i remember that in the past this has been the usual problem with the circle fonts they cme out wrong if compiled with anything other than plain.base cheers frank 21-Sep-1998 8:37:09-GMT,1617;000000000001 Received: from math.ams.org ([130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA00468 for ; Mon, 21 Sep 1998 02:37:08 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 21 Sep 1998 08:36:27 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J21ZWI3B1C000CY2@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 21 Sep 1998 04:21:20 EDT Received: from regulus.informatik.uni-hannover.de ([130.75.26.7]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 21 Sep 1998 08:21:06 +0000 (UT) Received: (from te@localhost) by regulus.informatik.uni-hannover.de (8.9.1a/8.9.1) id KAA07375 for tex-implementors@ams.org; Mon, 21 Sep 1998 10:21:03 +0200 (MET DST) Date: Mon, 21 Sep 1998 10:21:03 +0200 (MET DST) From: Thomas Esser Subject: Re: possible problem with lcircle*.tfm file To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199809210821.KAA07375@regulus.informatik.uni-hannover.de> > will someone please volunteer to replicate these tests and report on > the results? Seems clear to me that the mf sources are correct and the tfm files on CTAN and labrea are wrong. The tfm files distributed with teTeX (both: 0.4 and 0.9 pretest) are correct. I think that I have regenerated all metrics after tex95 was released. I could reproduce the problem using the metric file from CTAN. I could not reproduce the wrong metrics (even with cmbase preloaded) myself. Thomas 21-Sep-1998 18:16:27-GMT,1968;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA13206 for ; Mon, 21 Sep 1998 12:16:25 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 21 Sep 1998 18:16:25 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J22K60NCE8000FAL@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 21 Sep 1998 14:00:49 EDT Received: from smtp3.xs4all.nl ([194.109.6.53]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Mon, 21 Sep 1998 18:00:39 +0000 (UT) Received: from infovore (root@infovore.xs4all.nl [194.109.13.254]) by smtp3.xs4all.nl (8.8.8/8.8.8) with ESMTP id UAA23533 for ; Mon, 21 Sep 1998 20:00:38 +0200 (CEST) Received: by infovore id m0zL9et-000ckwC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Mon, 21 Sep 1998 19:21:55 +0200 (NST) Date: Mon, 21 Sep 1998 19:21:52 +0200 From: Olaf Weber Subject: Re: possible problem with lcircle*.tfm file In-reply-to: Thomas Esser's message of "Mon, 21 Sep 1998 10:21:03 +0200 (MET DST)" To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <87u321pej3.fsf@infovore.xs4all.nl> MIME-version: 1.0 (generated by tm-edit 7.108) X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Content-type: text/plain; charset=US-ASCII Lines: 16 References: <199809210821.KAA07375@regulus.informatik.uni-hannover.de> Thomas Esser writes: >> will someone please volunteer to replicate these tests and report on >> the results? > Seems clear to me that the mf sources are correct and the tfm files on > CTAN and labrea are wrong. > The tfm files distributed with teTeX (both: 0.4 and 0.9 pretest) are > correct. I think that I have regenerated all metrics after tex95 was > released. The tfm files in texmflib-7.x are correct. -- Olaf Weber 24-Sep-1998 13:26:28-GMT,2425;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA16335 for ; Thu, 24 Sep 1998 07:26:17 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1998 13:26:16 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J26GM63LLS000YDO@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 24 Sep 1998 09:02:31 EDT Received: from regulus.informatik.uni-hannover.de ([130.75.26.7]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 24 Sep 1998 13:02:19 +0000 (UT) Received: (from te@localhost) by regulus.informatik.uni-hannover.de (8.9.1a/8.9.1) id PAA19474; Thu, 24 Sep 1998 15:01:29 +0200 (MET DST) Date: Thu, 24 Sep 1998 15:01:29 +0200 (MET DST) From: Thomas Esser Subject: Re: [TETEX 2167] Bad fonts with the latest 0.9 prerelease? To: lgh013@dma.isg.mot.com Cc: CTAN@urz.Uni-Heidelberg.de, latex-bugs@uni-mainz.de, teTeX discussion list , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199809241301.PAA19474@regulus.informatik.uni-hannover.de> [Gopal Harikumar :] > However, the compiled binaries seem to be imperfect. I get errors > while compiling latex files (which compiled flawlessly with an older > 0.9 prerelease). This is not a problem of the binaries, rather than a problem of one of the input files. > Here is an example: latex chokes on the following line in my file: > \font\TINY = icmcsc10 at 9pt The file icmcsc10.mf (e.g. as found on CTAN:fonts/latex/mf/icmcsc10.mf dated from 1998/08/26) seems to be unusable. Metafont seems to produce a bad TFM file when the new version of icmcsc10.mf is used. TeX complains with: Font \testfont=icmcsc10 not loadable: Bad metric (TFM) file. Can someone who does not use teTeX please confirm? I did a diff against the previous (working version) and found: - a comment: % RmS 1998/08/26: Corrected by exchanging the last two lines - and the last two (non-empty) lines wave been exchanged (Who is RmS?) I Cc'ed some CTAN adress, the tex-implementors and the latex-bugs list in the hope that someone on that list is responsible for fixing this problem (or forwarding to the right person). Thomas 24-Sep-1998 14:51:29-GMT,2335;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA18207 for ; Thu, 24 Sep 1998 08:51:27 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1998 14:51:26 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J26JDA69NK000Z1T@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 24 Sep 1998 10:21:38 EDT Received: from venus.open.ac.uk ([137.108.143.2]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 24 Sep 1998 14:21:26 +0000 (UT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Thu, 24 Sep 1998 15:13:12 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id PAA14286; Thu, 24 Sep 1998 15:12:24 +0100 (BST) Date: Thu, 24 Sep 1998 15:12:24 +0100 (BST) From: Chris Rowley Subject: Re: [TETEX 2167] Bad fonts with the latest 0.9 prerelease? In-reply-to: <199809241301.PAA19474@regulus.informatik.uni-hannover.de> To: Thomas Esser Cc: lgh013@dma.isg.mot.com, CTAN@urz.Uni-Heidelberg.de, latex-bugs@uni-mainz.de, teTeX discussion list , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13834.21122.651070.614619@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199809241301.PAA19474@regulus.informatik.uni-hannover.de> Thomas and CTAN people > > I did a diff against the previous (working version) and found: > - a comment: % RmS 1998/08/26: Corrected by exchanging the last two lines > - and the last two (non-empty) lines wave been exchanged > > (Who is RmS?) Rainer Schoepf, who is not around at present so someone else with ctan access needs to put in the fix right now. > > I Cc'ed some CTAN adress, the tex-implementors and the latex-bugs list in > the hope that someone on that list is responsible for fixing this problem > (or forwarding to the right person). We admit reposnsibility: many apologies to everyone! Chris Rowley --- On behalf of the LaTeX3 Project Team 24-Sep-1998 17:15:07-GMT,3335;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA22301 for ; Thu, 24 Sep 1998 11:15:05 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1998 17:15:05 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J26OR2Y9KW000XJY@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 24 Sep 1998 12:55:50 EDT Received: from ns.vsu.relarn.ru ([194.226.24.1]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 24 Sep 1998 16:55:20 +0000 (UT) Received: (from uucp@localhost) by cc.vsu.ru (8.9.1/8.9.1) with UUCP id UAA01470; Thu, 24 Sep 1998 20:52:06 +0400 Received: (from vvv@localhost) by vvv.vsu.ru (8.8.7/8.8.7) id UAA19646; Thu, 24 Sep 1998 20:51:56 +0400 Date: Thu, 24 Sep 1998 20:51:56 +0400 From: "=?koi8-r?b?98zBxMnNydIg98/Mz9fJ3g==?= (Vladimir Volovich)" Subject: Re: [TETEX 2167] Bad fonts with the latest 0.9 prerelease? In-reply-to: Chris Rowley's message of "Thu, 24 Sep 1998 16:15:54 +0200" To: Chris Rowley Cc: Thomas Esser , lgh013@dma.isg.mot.com, CTAN@urz.Uni-Heidelberg.de, latex-bugs@uni-mainz.de, teTeX discussion list , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: User-Agent: Gnus/5.070032 (Pterodactyl Gnus v0.32) Emacs/20.3 Lines: 46 References: <199809241301.PAA19474@regulus.informatik.uni-hannover.de> <13834.21122.651070.614619@fell.open.ac.uk> "CR" == Chris Rowley writes: >> I did a diff against the previous (working version) and found: - >> a comment: % RmS 1998/08/26: Corrected by exchanging the last two >> lines - and the last two (non-empty) lines wave been exchanged >> >> (Who is RmS?) CR> Rainer Schoepf, who is not around at present so someone else with CR> ctan access needs to put in the fix right now. As i posted the bug report for the icmcsc10 font (which was found by Olga Lapko), and suggested the fix (swap the last two lines in this font), which appeared to be incomplete fix, i'm somewhat also responsible for inconvenience made to people trying to use this modified font. I'm sorry. :-) Here is what i think should be done to correct this problem: 1) create a new file: icmc.mf, by copying cmc.mf from CM fonts and applying to it the following patch: --- csc.mf Mon Aug 10 03:00:00 1992 +++ icsc.mf Thu Sep 24 20:38:53 1998 @@ -49,7 +49,7 @@ o, apex_o: $.#:=lower.$.#; endfor fudge:=lower.fudge; font_setup; % now try again with |lower| settings -extra_endchar:=extra_endchar&"charcode:=charcode+code_offset"; +extra_endchar:="charcode:=charcode+code_offset;"&extra_endchar; code_offset:=ASCII"a" - ASCII"A"; input romanu; % majuscules (in lowercase positions) code_offset:=-3; 2) in the file icmcsc10.mf, change the last line: generate csc % switch to the driver file to the following: generate icsc % switch to the driver file This should produce a correct invisible icmcsc10 font (i checked the resulting TFM files for icmcsc10 and cmcsc10, and they differ only by family name, as intended). Best regards, -- Vladimir. 24-Sep-1998 17:47:46-GMT,2158;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA23211 for ; Thu, 24 Sep 1998 11:47:45 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Sep 1998 17:47:45 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J26Q6ZE0FK00155N@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 24 Sep 1998 13:37:47 EDT Received: from ns.vsu.relarn.ru ([194.226.24.1]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Thu, 24 Sep 1998 17:36:24 +0000 (UT) Received: (from uucp@localhost) by cc.vsu.ru (8.9.1/8.9.1) with UUCP id VAA01786; Thu, 24 Sep 1998 21:33:22 +0400 Received: (from vvv@localhost) by vvv.vsu.ru (8.8.7/8.8.7) id VAA20860; Thu, 24 Sep 1998 21:32:46 +0400 Date: Thu, 24 Sep 1998 21:32:45 +0400 From: "=?koi8-r?b?98zBxMnNydIg98/Mz9fJ3g==?= (Vladimir Volovich)" Subject: Re: [TETEX 2167] Bad fonts with the latest 0.9 prerelease? In-reply-to: Chris Rowley's message of "Thu, 24 Sep 1998 16:15:54 +0200" To: Chris Rowley Cc: Thomas Esser , lgh013@dma.isg.mot.com, CTAN@urz.Uni-Heidelberg.de, latex-bugs@uni-mainz.de, teTeX discussion list , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: User-Agent: Gnus/5.070032 (Pterodactyl Gnus v0.32) Emacs/20.3 Lines: 17 References: <199809241301.PAA19474@regulus.informatik.uni-hannover.de> <13834.21122.651070.614619@fell.open.ac.uk> "VV" == Vladimir Volovich writes: VV> Here is what i think should be done to correct this problem: Sorry for the followup to my message, but there seems to exist a more simple fix: the last two lines of icmcsc10.mf should read as follows: extra_endchar := "clearit;" & extra_endchar; generate csc % switch to the driver file (i.e. put "clearit;" before extra_endchar) and one does not need to create icmc.mf. Sorry again. Best regards, -- Vladimir. 25-Sep-1998 9:54:18-GMT,2008;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA14291 for ; Fri, 25 Sep 1998 03:54:16 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Sep 1998 09:54:12 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J27NMPZF5C0016X9@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 25 Sep 1998 05:34:35 EDT Received: from hermes.ucd.ie ([137.43.1.49]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 25 Sep 1998 09:34:22 +0000 (UT) Received: from maths.ucd.ie by hermes.ucd.ie (PMDF V5.1-10 #U3251) with SMTP id <0EZU00IQ62L0KG@hermes.ucd.ie> for tex-implementors@ams.org; Fri, 25 Sep 1998 10:34:13 +0100 (BST) Received: by maths.ucd.ie (16.8/0.0) id AA02967; Fri, 25 Sep 1998 10:34:15 +0100 Date: Fri, 25 Sep 1998 10:34:14 +0100 (BST) From: wgs@maths.ucd.ie (Wayne G. Sullivan) Subject: Bad fonts: icmcsc10.mf To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <9809250934.AA02967@maths.ucd.ie> Mailer: Elm [revision: 70.30] If one modifies icmcsc10.mf so that the final lines are as follows, lower.fudge:=1; % factor applied to weights of heavy characters %extra_endchar := "clearit" & extra_endchar ; extra_endchar := extra_endchar & "clearit"; generate csc % switch to the driver file then running MF generates a bad tfm file containing kerns for nonexistant characters (messages from tftopl), while if one moves the "%" so that the second extra_endchar line is commented out, while the first is operational, then a vaild tfm file is generated. Can anyone explain this behavior? Several other "icm" mf files have extra_endchar lines like the second, but yield valid tfm files. What is the difference for the case of cmcsc? Would it be better to have all these in the form of the first extra_endchar line? Wayne Sullivan 25-Sep-1998 12:07:12-GMT,1934;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA16580 for ; Fri, 25 Sep 1998 06:07:11 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Sep 1998 12:07:11 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J27SHZEZHS000YLY@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 25 Sep 1998 07:53:37 EDT Received: from hermes.ucd.ie ([137.43.1.49]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 25 Sep 1998 11:53:19 +0000 (UT) Received: from maths.ucd.ie by hermes.ucd.ie (PMDF V5.1-10 #U3251) with SMTP id <0EZU00OKL90OPB@hermes.ucd.ie> for tex-implementors@ams.org; Fri, 25 Sep 1998 12:53:13 +0100 (BST) Received: by maths.ucd.ie (16.8/0.0) id AA03112; Fri, 25 Sep 1998 12:53:16 +0100 Date: Fri, 25 Sep 1998 12:53:16 +0100 (BST) From: wgs@maths.ucd.ie (Wayne G. Sullivan) Subject: Bad fonts: icmcsc10.mf /explanation To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <9809251153.AA03112@maths.ucd.ie> Mailer: Elm [revision: 70.30] Klaus Lagally found the cause of the problem with extra_endchar in icmcsc8. One should have "clearit;" instead of "clearit". The reason icmcsc is special is that csc.mf also uses extra_endchar and fails to include ";". The concatenation joins "clearit" to "charcode:=charcode+code_offset" without separation. However, in all cases in which extra_endchar is concatenated, it would be good policy to include an appropriate separator, in most cases ";". I think it would be wise to modify all of the "i"-fonts, replacing "clearit" by "clearit;", rather than leaving bugs waiting to bite. The use of rgrep on the mf/source tree shows that the two above extra_endchar "bugs in waiting" appear in several other files. Wayne Sullivan 25-Sep-1998 12:37:59-GMT,1738;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA17152 for ; Fri, 25 Sep 1998 06:37:58 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Sep 1998 12:37:57 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J27THALH5S00122Z@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 25 Sep 1998 08:22:01 EDT Received: from heaton.cl.cam.ac.uk ([128.232.32.11]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Fri, 25 Sep 1998 12:21:47 +0000 (UT) Received: from dorceus.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.1.34] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1) id 0zMWsc-0003u8-00; Fri, 25 Sep 1998 13:21:46 +0100 Date: Fri, 25 Sep 1998 13:21:40 +0100 From: Robin Fairbairns Subject: Re: Bad fonts: icmcsc10.mf /explanation In-reply-to: "Your message of Fri, 25 Sep 1998 12:53:16 BST." <9809251153.AA03112@maths.ucd.ie> To: wgs@maths.ucd.ie (Wayne G. Sullivan) Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: thank you, wayne, for providing a solution. (i'd tried vladimir's proposed solution, which also included the semicolon ... and mistyped it without the semicolon.) i would claim that line 52 of csc.mf represents an actual bug in the cm fonts, on account of its lack of a semicolon. i'm happy to go through the fonts/latex/mf/i*.mf files on ctan to deal with the problem, and will do so tomorrow if no-one suggests otherwise (i _really_ ought to be working `properly' just now...) robin 27-Sep-1998 12:22:26-GMT,1879;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA15003 for ; Sun, 27 Sep 1998 06:22:24 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 27 Sep 1998 12:22:24 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J2ALLA7N6O001AT7@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 27 Sep 1998 08:08:28 EDT Received: from heaton.cl.cam.ac.uk ([128.232.32.11]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 27 Sep 1998 12:08:19 +0000 (UT) Received: from ouse.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.33.87] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1) id 0zNFaj-0000iF-00; Sun, 27 Sep 1998 13:06:17 +0100 Date: Sun, 27 Sep 1998 13:06:09 +0100 From: Robin Fairbairns Subject: Re: [TETEX 2167] Bad fonts with the latest 0.9 prerelease? In-reply-to: "Your message of Thu, 24 Sep 1998 21:32:45 +0400." To: "=?koi8-r?b?98zBxMnNydIg98/Mz9fJ3g==?= (Vladimir Volovich)" Cc: Multiple recipients of list CTAN , te@informatik.uni-hannover.de, Chris Rowley , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: i've replaced the relevant i*.mf files in ctan fonts/latex/mf with versions which have a semicolon at the end of the `clearit' string that gets added to extra_endchar this change seems to be unexceptional (i.e., doesn't cause anything to blow up, and in the one case where i've actually looked at the resulting bitmap it is indeed an invisible font ;-) but i have nevertheless preserved the originals just in case. robin 27-Sep-1998 22:12:12-GMT,3078;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id QAA25378 for ; Sun, 27 Sep 1998 16:12:09 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 27 Sep 1998 22:12:08 UT Received: from gate1.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with SMTP id <01J2B65TG6OW001GFV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 27 Sep 1998 17:57:09 EDT Received: from kralle.zdv.Uni-Mainz.DE ([134.93.8.158]) by gate1.ams.org via smtpd (for axp14.ams.org [130.44.1.14]) with SMTP; Sun, 27 Sep 1998 21:56:45 +0000 (UT) Received: (from Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.8.8/8.8.8) id XAA14993; Sun, 27 Sep 1998 23:56:39 +0200 (MET DST) Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id UAA11948; Sun, 27 Sep 1998 20:18:31 +0100 Date: Sun, 27 Sep 1998 20:18:31 +0100 From: Frank Mittelbach Subject: Re: [TETEX 2167] Bad fonts with the latest 0.9 prerelease? In-reply-to: To: Robin Fairbairns Cc: "=?koi8-r?b?98zBxMnNydIg98/Mz9fJ3g==?= (Vladimir Volovich)" , Multiple recipients of list CTAN , te@informatik.uni-hannover.de, Chris Rowley , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199809271918.UAA11948@frank.zdv.uni-mainz.de> References: X-Authentication-warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to latex3 using -f Robin Fairbairns writes: > i've replaced the relevant i*.mf files in ctan fonts/latex/mf with > versions which have a semicolon at the end of the `clearit' string > that gets added to extra_endchar > > this change seems to be unexceptional (i.e., doesn't cause anything to > blow up, and in the one case where i've actually looked at the > resulting bitmap it is indeed an invisible font ;-) but i have > nevertheless preserved the originals just in case. thanks Robin for fixing the copies on CTAN. once Rainer is back i guess he better looks into this as well to prevent that the errorous versions get regenerated from the LaTeX source distribution (not quite sure what the status of the i* fonts is in this regard). thanks also Robin, for *NOT* cc'ing the LaTeX bug database this time :-) for the record: any mail to latex-bugs@Uni-Mainz.de will generate a new bug report in our database unless the subject line refers to an existing pr number in the database (eg latex/2882: ... would be okay but without the "latex/:" assigned to the first pr we get thread after thread). i agree that this is perhaps not the cleverest behavior one could imagine, but it is what gnats (the system behind all that) does. so next time please remove such a cc if you notice it, it will save us a lot of duplicated bug reports. thanks frank 12-Oct-1998 17:39:09-GMT,1761;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA17143 for ; Mon, 12 Oct 1998 11:39:08 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 17:39:03 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VUQ8WYQ8000ING@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 13:16:24 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0Q008OE5AXBO@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 13:16:15 -0400 (EDT) Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Mon, 12 Oct 1998 17:16:14 +0000 (UT) Date: Mon, 12 Oct 1998 18:16:09 +0100 From: Philip Taylor (RHBNC) Subject: TeX & Y2K compliance To: TEX-IMPLEMENTORS@ams.org Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <981012181609.c1e@vms.rhbnc.ac.uk> I don't know whether we all naively believed that TeX was Y2K compliant, or whether this misapprehension was less widely held, but Chris Rowley had just demonstrated that it most certainly is not. I have repeated his tests using Web-PASCAL e-TeX, and get identical results. Philip Taylor, RHBNC. -------- [snip] PPS: I wrote all that so I thought I would send it anyway BUT, intuition suggests that it (well tex.web and the Web2c 6.1 implementation, at least) is not Y2K-compliant: print_int(year mod 100); producing: This is TeX, Version 3.14159 (C version 6.1) (format=latex 97.2.14) 12-Oct-1998 18:11:04-GMT,2634;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA18112 for ; Mon, 12 Oct 1998 12:11:01 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 18:11:01 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VW3U1ZKG000L4T@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 13:55:36 EDT Received: from zothommog.evcom.net by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0Q00A5N74E1V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 13:55:27 -0400 (EDT) Received: (from kinch@localhost) by zothommog.evcom.net (8.8.8/8.8.8) id NAA24979; Mon, 12 Oct 1998 13:55:15 -0400 Date: Mon, 12 Oct 1998 13:55:15 -0400 (EDT) From: "Richard J. Kinch" Subject: Re: TeX & Y2K compliance In-reply-to: <981012181609.c1e@vms.rhbnc.ac.uk> To: P.Taylor@vms.rhbnc.ac.uk Cc: TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: kinch@truetex.com Message-id: <199810121755.NAA24979@zothommog.evcom.net> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit > TeX ... not Y2K-compliant: [?] > print_int(year mod 100); This is compliant by many standards, unless one's standard is "mod 1000", so to speak, of which there are adherents, which over here seem mostly to be panicky politicians. Note that there is no "1900" embedded here. There is no technically compelling reason to choose mod 1000 vs mod 100; it is merely an arbitrary choice of degree of precision constrained by other considerations (typically political, not technical) than strictly right-vs-wrong. The non-compliance would seem to me to be in programs that might read and erroneously interpret the logfile date, not in the TeX logfile itself. The 2-digit year in the logfile is perfectly legitimate. (I, for one, will certainly continue to write bank checks in this manner.) Programs which interpret TeX logfile dates (which would seem to be a rare species) should be using something like the +/- 50-year technique. Since changing TeX to mod 1000 in this respect would still require a review of the date-reading code, there's no avoidance of that review to be had by enlarging the TeX precision. Let us, as the lordly college of TeX-implementors, foment rumors that TeX is non-compliant. Richard J. Kinch Publisher, TrueTeX (R) brand typesetting software. See http://truetex.com 12-Oct-1998 18:14:11-GMT,2565;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA18184 for ; Mon, 12 Oct 1998 12:14:09 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 18:14:09 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VW8IY7FK000IRV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 13:59:23 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0Q00A6Q7AM1V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 13:59:14 -0400 (EDT) Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Mon, 12 Oct 1998 17:59:11 +0000 (UT) Date: Mon, 12 Oct 1998 18:59:06 +0100 From: Philip Taylor (RHBNC) Subject: Re: TeX & Y2K compliance To: kinch@truetex.com Cc: TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <981012185906.167c@vms.rhbnc.ac.uk> >> This is compliant by many standards, unless one's standard is "mod 1000", so >> to speak, of which there are adherents, which over here seem mostly to be >> panicky politicians. Note that there is no "1900" embedded here. There is no >> technically compelling reason to choose mod 1000 vs mod 100; it is merely an >> arbitrary choice of degree of precision constrained by other considerations >> (typically political, not technical) than strictly right-vs-wrong. I agree, but then I wouldn't advocate mod 1000 either, since that would eventually fail the Y200K test. Not mod anything is the only possible solution, surely? >> The non-compliance would seem to me to be in programs that might read >> and erroneously interpret the logfile date, not in the TeX logfile itself. >> The 2-digit year in the logfile is perfectly legitimate. (I, for one, will >> certainly continue to write bank checks in this manner.) A practice I eschewed some years ago :-) >> Programs which interpret TeX logfile dates (which would seem to be a rare >> species) should be using something like the +/- 50-year technique. But this is a horrible HACK, precicated on nothing better than mere guesswork. >> Let us, as the lordly college of TeX-implementors, foment rumors that TeX is >> non-compliant. I shall have to look up "foment" in my O.E.D. before I can comment further. ** Phil. 12-Oct-1998 18:33:09-GMT,3820;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA18736 for ; Mon, 12 Oct 1998 12:33:08 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 18:33:07 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VWVFHFTS000LZR@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 14:17:51 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0Q00AAU85C1V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 14:17:42 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Mon, 12 Oct 1998 19:17:01 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA01758; Mon, 12 Oct 1998 19:16:54 +0100 (BST) Date: Mon, 12 Oct 1998 19:16:53 +0100 (BST) From: Chris Rowley Subject: Re: TeX & Y2K compliance In-reply-to: <981012185906.167c@vms.rhbnc.ac.uk> To: P.Taylor@vms.rhbnc.ac.uk Cc: kinch@truetex.com, TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Message-id: <13858.17520.194261.660814@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <981012185906.167c@vms.rhbnc.ac.uk> Phil wrote -- > >> This is compliant by many standards, unless one's standard is "mod 1000", so > >> to speak, of which there are adherents, which over here seem mostly to be > >> panicky politicians. Note that there is no "1900" embedded here. There is no > >> technically compelling reason to choose mod 1000 vs mod 100; it is merely an > >> arbitrary choice of degree of precision constrained by other considerations > >> (typically political, not technical) than strictly right-vs-wrong. > > I agree, but then I wouldn't advocate mod 1000 either, since that would > eventually fail the Y200K test. Not mod anything is the only possible > solution, surely? I agree with Phil; what possible reason is there not to simply remove any mod at all??? I did not send in the fix since I assumed it was obvious that this is wht should be done. On the other implication here: the "panicky politicians" are precisely the reason why I looked into this. I do not know about their influence outside the UK but here they have created a lot of work for a lot of my colleagues employed by the government, quangos and universities, etc who need bits of paper in files to state precisely that TeX (and every other application on a publicly funded computer system) does not do things like this (whether in a log file or anywhere). I suspect this is also true for that not-so-wwell-known "developing nation" the EU (look it up in your atlas:-). Such a document is difficult to produce whilst TeX so clearly does do this. > > >> The non-compliance would seem to me to be in programs that might read > >> and erroneously interpret the logfile date, not in the TeX logfile itself. > >> The 2-digit year in the logfile is perfectly legitimate. (I, for one, will > >> certainly continue to write bank checks in this manner.) > > A practice I eschewed some years ago :-) No way would I write something as pretentious and ugly as 00 anywhere:-). > > >> Programs which interpret TeX logfile dates (which would seem to be a rare > >> species) should be using something like the +/- 50-year technique. > > But this is a horrible HACK, precicated on nothing better than mere guesswork. Why should they do any such thing when it is trivial to fix it and (as Phil pointed out) it would make the code agree with the documentation in the web. chris 12-Oct-1998 18:44:10-GMT,1842;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA19048 for ; Mon, 12 Oct 1998 12:44:09 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 18:44:09 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VX35PQWW000M05@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 14:24:05 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0Q00ACF8FR1V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 14:23:55 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Mon, 12 Oct 1998 19:23:38 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA01774; Mon, 12 Oct 1998 19:23:32 +0100 (BST) Date: Mon, 12 Oct 1998 19:23:31 +0100 (BST) From: Chris Rowley Subject: Re: TeX & Y2K compliance In-reply-to: <199810121755.NAA24979@zothommog.evcom.net> To: kinch@truetex.com Cc: P.Taylor@vms.rhbnc.ac.uk, TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Message-id: <13858.18479.78575.461777@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <981012181609.c1e@vms.rhbnc.ac.uk> <199810121755.NAA24979@zothommog.evcom.net> If what Richard wrote is generally agreed by those who understand the US mood of the moment then there is clearly a very different feeling there to this side of the pond. Here the production by software of a two-digit date, wherever it appears, is seen as a problem to be invetigated and fixed. chris 12-Oct-1998 19:06:13-GMT,2197;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA19731 for ; Mon, 12 Oct 1998 13:06:12 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 19:06:12 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VXXFTSIO000LDA@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 14:48:30 EDT Received: from cheetah.it.wsu.edu by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0Q00AH39KJ1V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 14:48:20 -0400 (EDT) Received: from tigger (tigger.it.wsu.edu [134.121.11.6]) by cheetah.it.wsu.edu (8.8.7/8.8.7) with SMTP id LAA22445; Mon, 12 Oct 1998 11:48:12 -0700 (PDT) Received: by tigger (5.65v4.0/1.1.19.2/04Mar98-0829AM) id AA16279; Mon, 12 Oct 1998 11:48:11 -0700 Date: Mon, 12 Oct 1998 11:48:11 -0700 From: Dean Guenther Subject: Re: TeX & Y2K compliance To: kinch@truetex.com, C.A.Rowley@open.ac.uk Cc: P.Taylor@vms.rhbnc.ac.uk, TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Message-id: <199810121848.AA16279@tigger> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-MD5: DwUrQPNwp922gFPHZ9a9Hg== I agree with Chris and Phil. I've been putting time into Y2K compliance on this side of the pond too. To say that \TeX is "nearly" Y2K compliant would be unfortunate, even if it is in the log file. Put the 4 digit year in. -- Dean -> -> If what Richard wrote is generally agreed by those who understand the -> US mood of the moment then there is clearly a very different feeling -> there to this side of the pond. -> -> Here the production by software of a two-digit date, wherever it appears, -> is seen as a problem to be invetigated and fixed. -> -> -> chris -> Dean Guenther Internet: guenther@wsu.edu Washington State University AT&T: 509 335-0433 Pullman, WA. 99164-1222 fax: 509 335-0540 www & UNIX System Admin 12-Oct-1998 19:19:59-GMT,5667;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA20064 for ; Mon, 12 Oct 1998 13:19:58 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 19:19:58 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VYIPJNLS000M7T@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 15:04:53 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0Q00AL2ABM1V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 15:04:42 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Mon, 12 Oct 1998 20:04:20 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id UAA01818; Mon, 12 Oct 1998 20:04:14 +0100 (BST) Date: Mon, 12 Oct 1998 20:04:13 +0100 (BST) From: Chris Rowley Subject: Re: Y2K? In-reply-to: To: Barbara Beeton Cc: P.Taylor@vms.rhbnc.ac.uk, Robin.Fairbairns@cl.cam.ac.uk, E.H.M.FRAMBACH@eco.rug.nl, TEX-GROUPS@ifi.uio.no, CHAA006@vms.rhbnc.ac.uk, TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13858.18779.93116.221193@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199810121713.SAA01609@fell.open.ac.uk> Barbara Beeton wrote -- > it is for information only, and doesn't enter into any calculations, as > far as i can tell. But it is bad information. I agree that its is an isolated part of the program; that is why it can so easily be fixed and (as Phil pointed out) brought into agreement with the documentation. > > i hesitate to call it a bug -- it is clearly an intentional design > decision, judging from this comment in tex.web: But that is tue of all Y2K problems that I know about: they are clear design decisions that are now seen to be bad ones: anyone (and I mean anyone!!!) can make bad design decisions. > > The global variable |format_ident| is a string that is printed right > after the |banner| line when \TeX\ is ready to start. For \.{INITEX} this > string says simply `\.{(INITEX)}'; for other versions of \TeX\ it says, > for example, `\.{(preloaded format=plain 82.11.19)}', showing the year, > month, and day that the format file was created. We have |format_ident=0| > before \TeX's tables are loaded. > > i agree with your suggestion to post the question to tex-implementors, > and suggest that your doing so would save me considerable effort in > digging out any preceding messages. > however, i'm curious if you have > any suggestions about what should be done to make this y2k compliant. > should initex scream loudly and fail to dump a format if the operating > system provides only a 2-digit year, That may be a good idea but has nothing to do with fixing TeX's output (which is what I am suggesting). I have elsewhere suggested that the trip test should test that \the \year produces 4 tokens but that was before I discovered the separate problem which I am sure would be clear prima facie evidence of non-compliance in this part of the world. > or a year < 1776? Well, believe it or not, in the majority of countries in the world, and particularly in Phil's sceptred isle, that date is not so likely to be used in our compliance tests. One point on which I am unclear is whether anyone would still be claiming it is not a bug if \the \year typeset only two digits? The results of this are only for human reading, even more clearly than an entry in the preamble to the log file. > > i wouldn't get a polite reception unless i have a good statement of > exactly what the problem is (i.e., provide a credible example of what > could go wrong because of this 2-digit year, perhaps something like > automatically comparing two log files to see which is using the older > version of tex?) You seem to have constructed the example already. However, I would not base an argument on tsuch technicalities but more on a simple appeal to Don's humanitarian and social instincts (plus his well-known multi-cultural sensibilities). Making this trivial change will make life easier for lots of TeX supporters (in its many senses) in far-flung parst of the universe. > and offer (a) suggestion(s) for how to fix it, ... > i'd rather that this be provided by someone other than me. No problem; I think it is completely straightforward but the message was sent to the implementors list because probably some people there know that that this is a delusion of mine. > the dependence of this date on the operating system on which a format > was dumped. I agree that using better code here may make this output dependent on the OS (which it probably is not at present); if this is seen to be a problem then it should be moved to the "OS-dependent list". But if this is a problem then it would be very wise to change the trip test as mentioned above. Of course, since we shall all be using e-pdf-omega soon anyway (whose programmers are all so much easier to influence, eg with a couple of pints:-) this may all be unnecessary:-). chris PS: On a more personal note, the question I am most often asked, informally, nowadays about LaTeX is "is it Y2K compliant?" it has even become more popular than that one containing the words "when" and "LaTeX3". 12-Oct-1998 19:23:40-GMT,2468;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA20152 for ; Mon, 12 Oct 1998 13:23:38 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 19:23:38 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VYL8P6DC000M88@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 15:06:55 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0Q00ALPAF81V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 15:06:45 -0400 (EDT) Received: from smtp1.xs4all.nl ([194.109.6.51]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Mon, 12 Oct 1998 19:06:44 +0000 (UT) Received: from infovore (root@infovore.xs4all.nl [194.109.13.254]) by smtp1.xs4all.nl (8.8.8/8.8.8) with ESMTP id VAA10126 for ; Mon, 12 Oct 1998 21:06:43 +0200 (CEST) Received: by infovore id m0zSnOC-000cmqC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Mon, 12 Oct 1998 21:12:16 +0200 (NST) Date: Mon, 12 Oct 1998 21:12:10 +0200 From: Olaf Weber Subject: Re: TeX & Y2K compliance In-reply-to: Chris Rowley's message of "Mon, 12 Oct 1998 19:23:31 +0100 (BST)" To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <87ww65d27p.fsf@infovore.xs4all.nl> MIME-version: 1.0 (generated by tm-edit 7.108) X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Content-type: text/plain; charset=US-ASCII Lines: 19 References: <981012181609.c1e@vms.rhbnc.ac.uk> <199810121755.NAA24979@zothommog.evcom.net> <13858.18479.78575.461777@fell.open.ac.uk> Chris Rowley writes: > If what Richard wrote is generally agreed by those who understand the > US mood of the moment then there is clearly a very different feeling > there to this side of the pond. > Here the production by software of a two-digit date, wherever it appears, > is seen as a problem to be invetigated and fixed. Such an investigation might also lead to the conclusion that the application will not lose any functionality due to Y2K issues, in which case the two-digit year being printed is not exactly a problem. That having been said, I should also point out that this issue has been raised some time ago already, and web2c 7.2 prints all the digits of the year. -- Olaf Weber 12-Oct-1998 19:36:47-GMT,1994;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA20526 for ; Mon, 12 Oct 1998 13:36:46 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 19:36:45 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2VZ3BMF8W000MA8@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 15:21:29 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0Q00APCB2L1V@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 15:21:19 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Mon, 12 Oct 1998 20:20:43 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id UAA01891; Mon, 12 Oct 1998 20:20:36 +0100 (BST) Date: Mon, 12 Oct 1998 20:20:35 +0100 (BST) From: Chris Rowley Subject: Re: TeX & Y2K compliance In-reply-to: <87ww65d27p.fsf@infovore.xs4all.nl> To: Olaf Weber Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13858.21818.584038.312341@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <981012181609.c1e@vms.rhbnc.ac.uk> <199810121755.NAA24979@zothommog.evcom.net> <13858.18479.78575.461777@fell.open.ac.uk> <87ww65d27p.fsf@infovore.xs4all.nl> Olaf wrote -- > > That having been said, I should also point out that this issue has > been raised some time ago already, and web2c 7.2 prints all the digits > of the year. Yes indeed, it does. Apologies to everyone, I had intended to check that. I note that metafont has also been similarly fixed (well, changed:-). Does this imply that someone did check all Don's programs to see if similar things happen? chris 12-Oct-1998 21:30:07-GMT,4236;000000000001 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id PAA23453; Mon, 12 Oct 1998 15:30:06 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id PAA17182; Mon, 12 Oct 1998 15:30:05 -0600 (MDT) Date: Mon, 12 Oct 1998 15:30:05 -0600 (MDT) To: tex-implementors@ams.org Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: TeXware & Y2K compliance Message-ID: Chris Rowley writing on Mon, 12 Oct 1998 20:20:35 +0100 (BST) asks: >> Does this imply that someone did check all Don's programs to see if >> similar things happen? Of all the *.web files in my web2c-7.2 tree (28 of them), corresponding to the recent TeXlive3 CD-ROM, only three files (web2c/mp.web, mf/mf.web and tex/tex.web) have variables named `year' that are output in truncated two-digit form: mp.web: print_int(round_unscaled(internal[year]) mod 100); print_char("."); mf.web: print_int(round_unscaled(internal[year]) mod 100); print_char("."); tex.web: print_int(year mod 100); print_char("."); As Olaf Weber noted on this list earlier today, the corresponding change files (*.ch) alter these to print the full year. Of course, the real challenge in investigating Y2K compliance is going through source code line by line to see if data that happens to be year values is being manipulated, not just brute-force grepping source code for variables named year. For a real horror story of how insidiously ingrained in software truncated date handling can be, take at look at this new article which appeared in my mailbox last week: @String{j-COMPUTER = "Computer"} @Article{Eick:1998:RFV, author = "Stephen G. Eick", title = "Research Feature: {A} Visualization Tool for {Y2K}", journal = j-COMPUTER, volume = "31", number = "10", pages = "63--69", month = oct, year = "1998", CODEN = "CPTRB4", ISSN = "0018-9162", bibdate = "Tue Oct 6 18:50:08 MDT 1998", URL = "http://www.computer.org/computer/co1998/rx063abs.htm; http://dlib.computer.org/co/books/co1998/pdf/rx063.pdf", acknowledgement = ack-nhfb, } Fortunately, TeXware's primary use of year values is for logfile time stamping, so we need not be overly concerned that there are other truncated-year code fragments in the Web sources. Since \year is accessible to TeX packages, date truncation could also appear elsewhere in TeX distributions. I therefore checked all of the files in the TeXlive3 tex/tex/latex tree for references to \year, and turned up just one another year truncation, in: texmf/tex/latex/dinbrief/dinbrief.cls I have not checked other files outside the LaTeX tree. I also noticed that the leap year computation in the file texmf/tex/latex/misc/advdate.sty is not completely correct, since it doesn't check for the case of year multiples of 4000 (such years are not leap years); this bug won't strike for 2001 years yet, so most people would ignore it. Even the otherwise excellent GNU calendar.el package doesn't include that test, and the UNIX "cal 4000" command output shows a February 29. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- 12-Oct-1998 21:43:54-GMT,4967;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id PAA23897 for ; Mon, 12 Oct 1998 15:43:53 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 12 Oct 1998 21:43:53 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2W3L0ZFXS000MNG@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 12 Oct 1998 17:30:18 EDT Received: from csc-sun.math.utah.edu by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0Q00COZH279C@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 17:30:07 -0400 (EDT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id PAA23453; Mon, 12 Oct 1998 15:30:06 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id PAA17182; Mon, 12 Oct 1998 15:30:05 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Mon, 12 Oct 1998 15:30:05 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Re: TeXware & Y2K compliance To: tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 Chris Rowley writing on Mon, 12 Oct 1998 20:20:35 +0100 (BST) asks: >> Does this imply that someone did check all Don's programs to see if >> similar things happen? Of all the *.web files in my web2c-7.2 tree (28 of them), corresponding to the recent TeXlive3 CD-ROM, only three files (web2c/mp.web, mf/mf.web and tex/tex.web) have variables named `year' that are output in truncated two-digit form: mp.web: print_int(round_unscaled(internal[year]) mod 100); print_char("."); mf.web: print_int(round_unscaled(internal[year]) mod 100); print_char("."); tex.web: print_int(year mod 100); print_char("."); As Olaf Weber noted on this list earlier today, the corresponding change files (*.ch) alter these to print the full year. Of course, the real challenge in investigating Y2K compliance is going through source code line by line to see if data that happens to be year values is being manipulated, not just brute-force grepping source code for variables named year. For a real horror story of how insidiously ingrained in software truncated date handling can be, take at look at this new article which appeared in my mailbox last week: @String{j-COMPUTER = "Computer"} @Article{Eick:1998:RFV, author = "Stephen G. Eick", title = "Research Feature: {A} Visualization Tool for {Y2K}", journal = j-COMPUTER, volume = "31", number = "10", pages = "63--69", month = oct, year = "1998", CODEN = "CPTRB4", ISSN = "0018-9162", bibdate = "Tue Oct 6 18:50:08 MDT 1998", URL = "http://www.computer.org/computer/co1998/rx063abs.htm; http://dlib.computer.org/co/books/co1998/pdf/rx063.pdf", acknowledgement = ack-nhfb, } Fortunately, TeXware's primary use of year values is for logfile time stamping, so we need not be overly concerned that there are other truncated-year code fragments in the Web sources. Since \year is accessible to TeX packages, date truncation could also appear elsewhere in TeX distributions. I therefore checked all of the files in the TeXlive3 tex/tex/latex tree for references to \year, and turned up just one another year truncation, in: texmf/tex/latex/dinbrief/dinbrief.cls I have not checked other files outside the LaTeX tree. I also noticed that the leap year computation in the file texmf/tex/latex/misc/advdate.sty is not completely correct, since it doesn't check for the case of year multiples of 4000 (such years are not leap years); this bug won't strike for 2001 years yet, so most people would ignore it. Even the otherwise excellent GNU calendar.el package doesn't include that test, and the UNIX "cal 4000" command output shows a February 29. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- 13-Oct-1998 3:04:10-GMT,2372;000000000001 Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id VAA01171 for ; Mon, 12 Oct 1998 21:04:08 -0600 (MDT) Received: from vanity.cwi.nl (vanity.cwi.nl [192.16.196.144]) by hera.cwi.nl with ESMTP id FAA06413 for ; Tue, 13 Oct 1998 05:03:35 +0200 (MET DST) Received: by vanity.cwi.nl id FAA19559; Tue, 13 Oct 1998 05:03:34 +0200 (MET DST) Date: Tue, 13 Oct 1998 05:03:34 +0200 (MET DST) Message-Id: From: Ray Hirschfeld To: beebe@math.utah.edu In-reply-to: Subject: Re: TeXware & Y2K compliance > Date: Mon, 12 Oct 1998 15:30:05 -0600 (MDT) > From: "Nelson H. F. Beebe" > I also noticed that the leap year computation in the file > texmf/tex/latex/misc/advdate.sty is not completely correct, since it > doesn't check for the case of year multiples of 4000 (such years are > not leap years); this bug won't strike for 2001 years yet, so most > people would ignore it. Even the otherwise excellent GNU calendar.el > package doesn't include that test, and the UNIX "cal 4000" command > output shows a February 29. Although making years that are multiples of 4000 common years rather than leap years yields a closer long-term approximation to the true solar year, I don't think this rule is part of the Gregorian calendar (at least as promulgated by the papal bull of 1582, which I believe suggested that 3 out of 4 centenary years be common years rather than leap years). Is the multiple-of-4000 correction universally adopted? The Gregorian year is specified to be 365.2422 days long (which is very slightly longer than a true solar year), so the multiple-of-4000 correction doesn't go far enough, since it yields an approximation of 365.24225. This is an error of only one day in 20000 years, but in a direction more difficult to correct (requiring an anti-leap year). More accurate would be to make years that are multiples of 3200 common years unless they are multiples of 80000. (The correction needed is three days in 10000 years, and should be applied only to multiples of 400 in order to avoid interference with the higher order corrections). Do you know who decides these things? Is there an international standard? 13-Oct-1998 7:15:48-GMT,1463;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA06526 for ; Tue, 13 Oct 1998 01:15:46 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 07:15:46 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WNJS9SJK000O7P@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 03:01:58 EDT Received: from zothommog.evcom.net by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0R00LK07IZGF@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 03:01:48 -0400 (EDT) Received: (from kinch@localhost) by zothommog.evcom.net (8.8.8/8.8.8) id DAA11142 for tex-implementors@ams.org; Tue, 13 Oct 1998 03:01:37 -0400 Date: Tue, 13 Oct 1998 03:01:36 -0400 (EDT) From: "Richard J. Kinch" Subject: Re: TeX & Y2K compliance In-reply-to: <199810121755.NAA24979@zothommog.evcom.net> To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Reply-to: kinch@truetex.com Message-id: <199810130701.DAA11142@zothommog.evcom.net> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit > Let us, as the lordly college of TeX-implementors, foment rumors that TeX is > non-compliant. Yikes, I meant to say, "Let us NOT ...". Sorry. 13-Oct-1998 8:50:21-GMT,2354;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA08574 for ; Tue, 13 Oct 1998 02:50:19 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 08:50:15 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WQQT98AO000LDR@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 04:33:09 EDT Received: from heaton.cl.cam.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0R0014FBQWQ6@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 04:32:58 -0400 (EDT) Received: from dorceus.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.1.34] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1) id 0zSzrl-0003xe-00; Tue, 13 Oct 1998 09:31:37 +0100 Date: Tue, 13 Oct 1998 09:31:35 +0100 From: Robin Fairbairns Subject: Re: TeX & Y2K compliance In-reply-to: "Your message of Mon, 12 Oct 1998 21:12:10 +0200." <87ww65d27p.fsf@infovore.xs4all.nl> To: Olaf Weber Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: > Chris Rowley writes: > > > If what Richard wrote is generally agreed by those who understand the > > US mood of the moment then there is clearly a very different feeling > > there to this side of the pond. > > > Here the production by software of a two-digit date, wherever it appears, > > is seen as a problem to be invetigated and fixed. > > Such an investigation might also lead to the conclusion that the > application will not lose any functionality due to Y2K issues, in > which case the two-digit year being printed is not exactly a problem. > > That having been said, I should also point out that this issue has > been raised some time ago already, and web2c 7.2 prints all the digits > of the year. oh, good. i was doing other things last night and didn't think actually to *look* at one of my log files (or even to read tex: the program), but i was thinking `surely it's an implementation-dependent thing?' as i came to work... so that's another argument to dump versions that aren't currently in development (like emtex, gtex, etc.) -- i shall bear it in mind. r 13-Oct-1998 11:32:08-GMT,1391;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id FAA11360 for ; Tue, 13 Oct 1998 05:32:06 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 11:32:05 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WWAFHA40000KZV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 07:11:43 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0R001M5J38Q6@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 07:11:33 -0400 (EDT) Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Tue, 13 Oct 1998 11:11:33 +0000 (UT) Date: Tue, 13 Oct 1998 12:11:24 +0100 From: Philip Taylor (RHBNC) Subject: Re: TeX & Y2K compliance To: kinch@truetex.com Cc: TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <981013121124.167c@vms.rhbnc.ac.uk> >> > Let us, as the lordly college of TeX-implementors, foment rumors that TeX is >> > non-compliant. >> >> Yikes, I meant to say, "Let us NOT ...". Sorry. Too late, I already followed your advice :-) 13-Oct-1998 11:44:13-GMT,1807;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id FAA11604 for ; Tue, 13 Oct 1998 05:44:12 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 11:44:12 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WWSCCO6O0002V2@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 07:26:10 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0R001O0JR9Q6@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 07:26:00 -0400 (EDT) Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Tue, 13 Oct 1998 11:25:57 +0000 (UT) Date: Tue, 13 Oct 1998 12:25:57 +0100 From: Philip Taylor (RHBNC) Subject: Y2K, cont. To: TEX-IMPLEMENTORS@ams.org, OLAF@INFOVORE.XS4ALL.NL Cc: CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <981013122557.167c@vms.rhbnc.ac.uk> >> oh, good. i was doing other things last night and didn't think >> actually to *look* at one of my log files (or even to read tex: the >> program), but i was thinking `surely it's an implementation-dependent >> thing?' as i came to work... Most surely it's not; if Knuth writes "year mod 100", and an implementor junks the "mod 100" element, I would argue that the result cannot be called TeX. >> so that's another argument to dump versions that aren't currently in >> development (like emtex, gtex, etc.) -- i shall bear it in mind. Is this the left half (CTAN) or right half (private) of your brain speaking? ** Phil. 13-Oct-1998 11:57:55-GMT,2600;000000000011 Received: from taurus.cus.cam.ac.uk (cusexim@taurus.cus.cam.ac.uk [131.111.8.48]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA11841 for ; Tue, 13 Oct 1998 05:57:54 -0600 (MDT) Received: from cet1 by taurus.cus.cam.ac.uk with local (Exim 2.05 #4) id 0zT35G-0004td-00; Tue, 13 Oct 1998 12:57:46 +0100 Subject: Re: TeXware & Y2K compliance To: beebe@math.utah.edu (Nelson H. F. Beebe) Date: Tue, 13 Oct 1998 12:57:46 +0100 (BST) Cc: tex-implementors@ams.org In-Reply-To: from "Nelson H. F. Beebe" at Oct 12, 98 03:30:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson Nelson H. F. Beebe writes [...] > I also noticed that the leap year computation in the file > texmf/tex/latex/misc/advdate.sty is not completely correct, since it > doesn't check for the case of year multiples of 4000 (such years are > not leap years); this bug won't strike for 2001 years yet, so most > people would ignore it. Even the otherwise excellent GNU calendar.el > package doesn't include that test, and the UNIX "cal 4000" command > output shows a February 29. Please don't propagate this urban legend - there is no such 4000-year rule in the Gregorian calendar as designed historically or as currently given the force of law by any known legislature. To quote the Usenet "Calendar FAQ", regularly posted to several newsgroups, and also available at , | 2.2.2. Isn't there a 4000-year rule? | ------------------------------------ | | It has been suggested (by the astronomer John Herschel (1792-1871) | among others) that a better approximation to the length of the | tropical year would be 365 969/4000 days = 365.24225 days. This would | dictate 969 leap years every 4000 years, rather than the 970 leap | years mandated by the Gregorian calendar. This could be achieved by | dropping one leap year from the Gregorian calendar every 4000 years, | which would make years divisible by 4000 non-leap years. | | This rule has, however, not been officially adopted. I could go into the reasons why an added 4000-year rule is not be a good idea, but this isn't sci.math or sci.astro, so I will refrain... :-) Chris Thompson Cambridge University Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom. 13-Oct-1998 12:05:56-GMT,2205;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA12022 for ; Tue, 13 Oct 1998 06:05:55 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 12:05:55 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WXMI1CQ8000LWI@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 07:50:29 EDT Received: from pillar.elsevier.co.uk by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0R0052SKVUIK@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 07:50:19 -0400 (EDT) Received: from snowdon.elsevier.co.uk [193.131.197.164]; by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP; for ""; sender "s.rahtz@elsevier.co.uk"; id MAA00212; hop 0; Tue, 13 Oct 1998 12:42:47 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Tue, 13 Oct 1998 12:48:12 +0100 Date: Tue, 13 Oct 1998 12:42:53 +0100 ( `) From: Sebastian Rahtz Subject: Re: Y2K, cont. In-reply-to: <981013122557.167c@vms.rhbnc.ac.uk> To: P.Taylor@vms.rhbnc.ac.uk Cc: TEX-IMPLEMENTORS@ams.org, OLAF@INFOVORE.XS4ALL.NL Errors-to: tex-implementors-request@ams.org Message-id: <13859.15549.518000.475050@SRAHTZ> MIME-version: 1.0 X-Mailer: emacs 19.34.6 (via feedmail 9-beta-3 I); VM 6.61 under Emacs 19.34.6 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <981013122557.167c@vms.rhbnc.ac.uk> Philip Taylor (RHBNC) writes: > Most surely it's not; if Knuth writes "year mod 100", and an > implementor junks the "mod 100" element, I would argue > that the result cannot be called TeX. > Good, you argue away. Can you keep it private, though, within one or other half of your brain only? Why not write to Don Knuth and denounce the whole web2c-based TeX community as sinners and heretics and probably Molochian child-slayers of the worst order? A fellow-traveller in Cambridge, UK, has experience in drafting such letters. sebastian 13-Oct-1998 12:14:31-GMT,3081;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA12217 for ; Tue, 13 Oct 1998 06:14:30 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 12:14:29 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WXWOU6N4000P3I@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 07:58:42 EDT Received: from taurus.cus.cam.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0R0054ML8NIK@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 07:58:32 -0400 (EDT) Received: from cet1 by taurus.cus.cam.ac.uk with local (Exim 2.05 #4) id 0zT35G-0004td-00; Tue, 13 Oct 1998 12:57:46 +0100 Date: Tue, 13 Oct 1998 12:57:46 +0100 (BST) From: Chris Thompson Subject: Re: TeXware & Y2K compliance In-reply-to: To: beebe@math.utah.edu (Nelson H. F. Beebe) Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL24] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Nelson H. F. Beebe writes [...] > I also noticed that the leap year computation in the file > texmf/tex/latex/misc/advdate.sty is not completely correct, since it > doesn't check for the case of year multiples of 4000 (such years are > not leap years); this bug won't strike for 2001 years yet, so most > people would ignore it. Even the otherwise excellent GNU calendar.el > package doesn't include that test, and the UNIX "cal 4000" command > output shows a February 29. Please don't propagate this urban legend - there is no such 4000-year rule in the Gregorian calendar as designed historically or as currently given the force of law by any known legislature. To quote the Usenet "Calendar FAQ", regularly posted to several newsgroups, and also available at , | 2.2.2. Isn't there a 4000-year rule? | ------------------------------------ | | It has been suggested (by the astronomer John Herschel (1792-1871) | among others) that a better approximation to the length of the | tropical year would be 365 969/4000 days = 365.24225 days. This would | dictate 969 leap years every 4000 years, rather than the 970 leap | years mandated by the Gregorian calendar. This could be achieved by | dropping one leap year from the Gregorian calendar every 4000 years, | which would make years divisible by 4000 non-leap years. | | This rule has, however, not been officially adopted. I could go into the reasons why an added 4000-year rule is not be a good idea, but this isn't sci.math or sci.astro, so I will refrain... :-) Chris Thompson Cambridge University Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom. 13-Oct-1998 12:19:49-GMT,3050;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA12307 for ; Tue, 13 Oct 1998 06:19:47 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 12:19:47 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WY0F13YO000OBQ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 08:00:55 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0R0055DLD4IK@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 08:00:45 -0400 (EDT) Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Tue, 13 Oct 1998 12:00:41 +0000 (UT) Received: by eiche.informatik.uni-stuttgart.de; Tue, 13 Oct 1998 13:59:11 +0200 Date: Tue, 13 Oct 1998 13:59:11 +0200 (MET DST) From: Klaus Lagally Subject: Re: Y2K, cont. In-reply-to: <981013122557.167c@vms.rhbnc.ac.uk> from <"RHBNC"@Oct> To: P.Taylor@vms.rhbnc.ac.uk Cc: tex-implementors@ams.org (TeX implementors) Errors-to: tex-implementors-request@ams.org Message-id: <199810131159.NAA20865@eiche.informatik.uni-stuttgart.de> MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL24] Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit scripsit RHBNC: > > >> oh, good. i was doing other things last night and didn't think > >> actually to *look* at one of my log files (or even to read tex: the > >> program), but i was thinking `surely it's an implementation-dependent > >> thing?' as i came to work... > > Most surely it's not; if Knuth writes "year mod 100", and an > implementor junks the "mod 100" element, I would argue > that the result cannot be called TeX. Hello, I followed your discussion with some bewilderment, especially since I seem not to have got bnb's first message. As I see it, "Y2K compliance" does _not_ mean 4-digit dates in place of 2-digit dates (what happens after 9999?), but that the program in question will after 2000 still work according to its specification. Now what are the specifications in case of TeX? I looked up "\year" in the TeXbook, and it says in Chapter 24: "current year of our Lord", and the example in Appendix E gives 4 digits. Now I wonder what "Current year of our Lord" means before 1582, or even B.C.? Is there a year 0? If the specification is imprecise, what is the exact meaning of Y2K compliance in the case of TeX? And if the meaning of these LOG file entries is nowhere described, I feel they are in any case correct by definition, or even meaningless :-) Sincerely Klaus -- Prof. Dr. Klaus Lagally | lagally@informatik.uni-stuttgart.de Institut fuer Informatik | Tel. +49-711-7816392 | Zeige mir deine Uhr, Breitwiesenstrasse 20-22 | FAX +49-711-7816370 | und ich sage dir, 70565 Stuttgart, GERMANY | (changed) | wie spaet es ist. 13-Oct-1998 12:46:32-GMT,2583;000000000001 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA12863 for ; Tue, 13 Oct 1998 06:46:30 -0600 (MDT) Received: from maui (maui.ai.mit.edu [128.52.37.105]) by life.ai.mit.edu (8.9.1/AI2.7/ai.master.life:2.2) with SMTP id IAA15486; Tue, 13 Oct 1998 08:46:29 -0400 (EDT) Message-Id: <199810131246.IAA15486@life.ai.mit.edu> X-Sender: yandy@tiac.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 13 Oct 1998 08:46:44 -0400 To: "Nelson H. F. Beebe" , tex-implementors@ams.org From: "Y&Y, Inc." Subject: Re: TeXware & Y2K compliance Cc: beebe@math.utah.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 03:30 PM 10/12/98 -0600, Nelson H. F. Beebe wrote: >I also noticed that the leap year computation in the file >texmf/tex/latex/misc/advdate.sty is not completely correct, since it >doesn't check for the case of year multiples of 4000 (such years are >not leap years); this bug won't strike for 2001 years yet, so most >people would ignore it. Even the otherwise excellent GNU calendar.el >package doesn't include that test, and the UNIX "cal 4000" command >output shows a February 29. I believe this is incorrect. There is no such 4000 year rule. Even though it might make the year closer to the actual current average year, it just is not in the rules. Of course, people have quite a while to decide they might want to change the rules, but ... :-) While I think the Y2K `issue' is a giant rip-off by `consultants,' I am concerned a bit about Unix, DOS and Mac programs that use 32 bit words to represent seconds since some fixed epoch. Some of the C runtime libraries use a signed integer starting at 0 in Jan 1 1970, which means they will overflow in about 2038. On Mac some libraries use an unsigned quantity starting at 0 from 1904 Jan 1 which will overflow around 2040. And so on. Interestingly some libraries have implementations of `ctime' `asciitime' etc. that return NULL when given a negative time, which will typically create an invalid access when that string pointer is used. So the programs not only will produce bad output, but will crash (or maybe that is actually the preferred behaviour?) Of course those dates seem far away today, but so did 2000 when people wrote the code that is supposedly going to be an issue at the end of the millenium. So, is your TeX `Year 2038/2040' compliant? Regards, Berthold. 13-Oct-1998 13:03:11-GMT,3128;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA13247 for ; Tue, 13 Oct 1998 07:03:10 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 13:03:09 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2WZL781M8000PHC@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 08:46:42 EDT Received: from life.ai.mit.edu by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0R005PNNHJIK@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 08:46:32 -0400 (EDT) Received: from maui (maui.ai.mit.edu [128.52.37.105]) by life.ai.mit.edu (8.9.1/AI2.7/ai.master.life:2.2) with SMTP id IAA15486; Tue, 13 Oct 1998 08:46:29 -0400 (EDT) Date: Tue, 13 Oct 1998 08:46:44 -0400 From: "Y&Y, Inc." Subject: Re: TeXware & Y2K compliance In-reply-to: X-Sender: yandy@tiac.net To: "Nelson H. F. Beebe" , tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: <199810131246.IAA15486@life.ai.mit.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Content-type: text/plain; charset="us-ascii" At 03:30 PM 10/12/98 -0600, Nelson H. F. Beebe wrote: >I also noticed that the leap year computation in the file >texmf/tex/latex/misc/advdate.sty is not completely correct, since it >doesn't check for the case of year multiples of 4000 (such years are >not leap years); this bug won't strike for 2001 years yet, so most >people would ignore it. Even the otherwise excellent GNU calendar.el >package doesn't include that test, and the UNIX "cal 4000" command >output shows a February 29. I believe this is incorrect. There is no such 4000 year rule. Even though it might make the year closer to the actual current average year, it just is not in the rules. Of course, people have quite a while to decide they might want to change the rules, but ... :-) While I think the Y2K `issue' is a giant rip-off by `consultants,' I am concerned a bit about Unix, DOS and Mac programs that use 32 bit words to represent seconds since some fixed epoch. Some of the C runtime libraries use a signed integer starting at 0 in Jan 1 1970, which means they will overflow in about 2038. On Mac some libraries use an unsigned quantity starting at 0 from 1904 Jan 1 which will overflow around 2040. And so on. Interestingly some libraries have implementations of `ctime' `asciitime' etc. that return NULL when given a negative time, which will typically create an invalid access when that string pointer is used. So the programs not only will produce bad output, but will crash (or maybe that is actually the preferred behaviour?) Of course those dates seem far away today, but so did 2000 when people wrote the code that is supposedly going to be an issue at the end of the millenium. So, is your TeX `Year 2038/2040' compliant? Regards, Berthold. 13-Oct-1998 14:22:52-GMT,3199;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA14866 for ; Tue, 13 Oct 1998 08:22:51 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 14:22:51 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2X1X8SGCW000NIX@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 09:53:42 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0R0090WQL3HM@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 09:53:30 -0400 (EDT) Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Tue, 13 Oct 1998 13:53:27 +0000 (UT) Date: Tue, 13 Oct 1998 14:49:00 +0100 From: Philip Taylor (RHBNC) Subject: Re: Y2K, cont. To: Lagally@informatik.uni-stuttgart.de Cc: TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <981013144900.167c@vms.rhbnc.ac.uk> >> As I see it, "Y2K compliance" does _not_ mean 4-digit dates in place of >> 2-digit dates (what happens after 9999?), Absolutely: it means $n$-digit dates, where $n$ is necessary to unambiguously represent the year in question. >> but that the program in question >> will after 2000 still work according to its specification. I don't think I'd agree with this definition. I would expect the program in question to work w.e.f. 00:00:00 01-01-2000 exactly as it had worked previously MODULO not left-extending any year specified as a part or whole of a date. Thus a program which left-extends 2-digit years either by prefixing "19" OR by prefixing either "19" or "20" based on some arbitrary heuristic (such as the notional mid-point of the century) would, IMHO, not be Y2K compliant. >> I looked up "\year" in the TeXbook, and it says in Chapter 24: "current >> year of our Lord", and the example in Appendix E gives 4 digits. The example would seem sane, given that four digits are necessary and sufficient to represent both the year in which the TeXbook was written and the next several thousand years. >> Now I wonder what "Current year of our Lord" means before 1582, or even B.C.? Is it reasonable to expect Knuth to define how TeX might work if reverse time-travel eventually became possible? I think not. >> Is there a year 0? Even if there was, TeX did not exist at that time, and therefore its behaviour during that year is best left undefined. >> If the specification is imprecise, what is the exact >> meaning of Y2K compliance in the case of TeX? I would argue, a meaning similar to that which I described above. >> And if the meaning of these >> LOG file entries is nowhere described, I feel they are in any case correct >> by definition, or even meaningless :-) Doubtless philosophers would love to debate this point for millenia, but as a mere scientist I prefer to ascribe meaning even in the absence of a formal definition. >> Sincerely >> Klaus Sincerely Phil 13-Oct-1998 17:50:28-GMT,2357;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA20433 for ; Tue, 13 Oct 1998 11:50:27 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 13 Oct 1998 17:50:26 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2X9SO93B4000OQE@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 13 Oct 1998 13:39:05 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0S00EMP10S17@sun06.ams.org> for tex-implementors@axp14.ams.org; Tue, 13 Oct 1998 13:38:53 -0400 (EDT) Received: from smtp1.xs4all.nl ([194.109.6.51]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Tue, 13 Oct 1998 17:38:53 +0000 (UT) Received: from infovore (root@infovore.xs4all.nl [194.109.13.254]) by smtp1.xs4all.nl (8.8.8/8.8.8) with ESMTP id TAA26600; Tue, 13 Oct 1998 19:38:49 +0200 (CEST) Received: by infovore id m0zT8Tp-000cvhC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Tue, 13 Oct 1998 19:43:29 +0200 (NST) Date: Tue, 13 Oct 1998 19:43:27 +0200 From: Olaf Weber Subject: Re: Y2K, cont. In-reply-to: Philip Taylor's message of "Tue, 13 Oct 1998 12:25:57 +0100" To: TEX-IMPLEMENTORS@ams.org Cc: CHAA006@vms.rhbnc.ac.uk, P.Taylor@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Message-id: <87zpb0tl1c.fsf@infovore.xs4all.nl> MIME-version: 1.0 (generated by tm-edit 7.108) X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Content-type: text/plain; charset=US-ASCII Lines: 19 References: <981013122557.167c@vms.rhbnc.ac.uk> RHBNC writes: > Most surely it's not; if Knuth writes "year mod 100", and an > implementor junks the "mod 100" element, I would argue > that the result cannot be called TeX. For the record: the year is printed in sections 536, 617, and 1328. None of these are cross-referenced with /system dependencies/. In the first two cases, print_int is used, in the third the contentious 'mod 100' appears. The message printed is changed in some other ways as well, so you don't see (preloaded format=trip 95.3.8) but rather (format=trip 1998.5.31) because in the past someone felt the "preloaded" part was confusing. (I don't know when that change was made.) -- Olaf Weber 14-Oct-1998 4:30:28-GMT,5078;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id WAA05071 for ; Tue, 13 Oct 1998 22:30:27 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 04:30:27 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #30286) id <01J2XWKDUBRK000UFU@AXP14.AMS.ORG> for beebe@csc-sun.math.utah.edu; Wed, 14 Oct 1998 00:30:23 EDT Received: from AXP14.AMS.ORG (PMDF V5.1-8 #30286) id <01J2XWKAAXY8000UFL@AXP14.AMS.ORG>; Wed, 14 Oct 1998 00:30:23 -0400 (EDT) Date: Wed, 14 Oct 1998 00:30:23 -0400 (EDT) From: PMDF e-Mail Interconnect Subject: Delivery Notification: Delivery has been delayed To: beebe@math.utah.edu Message-id: <01J2XWKDDWAC000UFL@AXP14.AMS.ORG> MIME-version: 1.0 Content-type: MULTIPART/REPORT; BOUNDARY="Boundary_(ID_FwYgCTPm4DvToVB03l/Nag)" --Boundary_(ID_FwYgCTPm4DvToVB03l/Nag) Content-type: text/plain; CHARSET=US-ASCII This report relates to a message you sent with the following header fields: Message-id: Date: Mon, 12 Oct 1998 15:30:05 -0600 (MDT) From: "Nelson H. F. Beebe" To: tex-implementors@ams.org Subject: Re: TeXware & Y2K compliance Your message has been enqueued and undeliverable for 1 day to the following recipients: Recipient address: dak@neuroinformatik.ruhr-uni-bochum.de Reason: unable to deliver this message after 1 day Delivery attempt history for your mail: Tue, 13 Oct 1998 22:07:13 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. Tue, 13 Oct 1998 18:18:13 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. Tue, 13 Oct 1998 14:20:05 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. Tue, 13 Oct 1998 10:05:43 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. Tue, 13 Oct 1998 05:45:04 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. Tue, 13 Oct 1998 01:39:59 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. Mon, 12 Oct 1998 21:39:49 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. Mon, 12 Oct 1998 17:38:21 EDT Temporary error returned by SMTP partner. smtp; math.ams.org Sorry, unable to contact destination SMTP daemon. The mail system will continue to try to deliver your message for an additional 3 days. --Boundary_(ID_FwYgCTPm4DvToVB03l/Nag) Content-type: message/DELIVERY-STATUS Reporting-MTA: dns; AXP14.AMS.ORG Action: delayed Status: 4.0.0 (unable to deliver this message after 1 day) Final-recipient: rfc822;dak@neuroinformatik.ruhr-uni-bochum.de --Boundary_(ID_FwYgCTPm4DvToVB03l/Nag) Content-type: text/plain; CHARSET=US-ASCII Return-path: beebe@csc-sun.math.utah.edu Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #30286) id <01J2XWKAAXY8000UFL@AXP14.AMS.ORG>; Wed, 14 Oct 1998 00:30:22 EDT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2W3L0ZFXS000MNG@AXP14.AMS.ORG> for dak@neuroinformatik.ruhr-uni-bochum.de; Mon, 12 Oct 1998 17:30:19 EDT Received: from csc-sun.math.utah.edu by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0Q00COZH279C@sun06.ams.org> for tex-implementors@axp14.ams.org; Mon, 12 Oct 1998 17:30:07 -0400 (EDT) Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [155.101.20.21]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id PAA23453; Mon, 12 Oct 1998 15:30:06 -0600 (MDT) Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id PAA17182; Mon, 12 Oct 1998 15:30:05 -0600 (MDT) X-URL: http://www.math.utah.edu/~beebe Date: Mon, 12 Oct 1998 15:30:05 -0600 (MDT) From: "Nelson H. F. Beebe" Subject: Re: TeXware & Y2K compliance To: tex-implementors@ams.org Cc: beebe@math.utah.edu Errors-to: tex-implementors-request@ams.org Message-id: X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 Chris Rowley writing on Mon, 12 Oct 1998 20:20:35 +0100 (BST) asks: >> Does this imply that someone did check all Don's programs to see if >> similar things happen? Of all the *.web files in my web2c-7.2 tree (28 of them), corresponding to the recent TeXlive3 CD-ROM, only three files (web2c/mp.web, mf/mf.web and tex/tex.web) have variables named `year' that are output in truncated two-digit form: --Boundary_(ID_FwYgCTPm4DvToVB03l/Nag)-- 14-Oct-1998 12:43:43-GMT,4102;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA14551 for ; Wed, 14 Oct 1998 06:43:36 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 12:43:36 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YCOK28RK000VSS@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 08:12:02 EDT Received: from mail.omnilink.net by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0T00B9SGJROJ@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 08:11:52 -0400 (EDT) Received: from gazette.omnilink.net (gazette.omnilink.net [194.64.25.22]) by mail.omnilink.net (8.9.1a/8.9.1) with ESMTP id OAA28381 for ; Wed, 14 Oct 1998 14:11:50 +0200 (MET DST) Received: (from uucp@localhost) by gazette.omnilink.net (8.8.7/8.8.7) with UUCP id OAA01189 for TEX-IMPLEMENTORS@ams.org; Wed, 14 Oct 1998 14:11:49 +0200 (MEST envelope-from schrod@npc.de) Received: (from schrod@localhost) by npc.de (8.6.12/8.6.12) id EAA07034; Wed, 14 Oct 1998 04:13:47 +0200 Date: Wed, 14 Oct 1998 04:13:47 +0200 From: Joachim Schrod Subject: Re: TeX & Y2K compliance In-reply-to: <13858.18479.78575.461777@fell.open.ac.uk> To: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199810140213.EAA07034@npc.de> MIME-version: 1.0 (generated by tm-edit 7.95) Content-type: text/plain; charset=US-ASCII References: <981012181609.c1e@vms.rhbnc.ac.uk> <199810121755.NAA24979@zothommog.evcom.net> <13858.18479.78575.461777@fell.open.ac.uk> >>>>> "CR" == Chris Rowley writes: CR> If what Richard wrote is generally agreed by those who understand the CR> US mood of the moment then there is clearly a very different feeling CR> there to this side of the pond. Hmm, seems to be not ``this side of the pond'', but ``in UK''. CR> Here the production by software of a two-digit date, wherever it appears, CR> is seen as a problem to be invetigated and fixed. For the record, the situation in Germany: As long as an application doesn't _use_ a 2-digit year representation for further work, it is called Y2K compliant. I.e., TeX, the program, is considered Y2K compliant. If a whole TeX installation includes any utilities that reads log files (or the \year register, for that matter) and uses a 2-digit year representation without any adjustments to determine any time-relevant action to be done, then it's not compliant. In particular, as long as years are only printed, or read and reprinted, this doesn't concern the compliance of any system. Computations matter, not printouts. Cheers, Joachim PS: For those who don't know it: My company is involved in quite some Y2K compliance check projects currently, mostly at financial institutions (most well known are probably Dresdner Bank and European Central Bank). We earn most of our money with this stuff... :-) The statement above reflects the official policy of these institutions. I'd like to add that financial institutions are very concerned about the Y2K problem -- every project that concerns this problem (and the transition to Euro :-) is top priority at the moment. Perhaps I repeat myself, but: If we would care about 2-digit printing systems, we would panick and flee in the wilderness... You don't believe how many systems that are business-critical (i.e., responsible for multi-(American)-billions transactions) do so and will remain to do so. The problem at hand is processing of year representations, not printing. PPS: I agree, that one should ask Don to change the date printout -- but IMO it's not a matter of compliance, just a matter of putting out the information available to the system's user. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: jschrod@acm.org Net & Publication Consultance GmbH Tel.: +49-6074-861530 Roedermark, Germany Fax: +49-6074-861531 14-Oct-1998 14:22:16-GMT,3244;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA16458 for ; Wed, 14 Oct 1998 08:22:13 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 14:22:13 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YGBL5CKG000TGK@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 09:56:07 EDT Received: from AWIUNI11.EDVZ.UniVie.AC.AT (helios.edvz.univie.ac.at) by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00FGJLD67B@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 09:55:56 -0400 (EDT) Received: from VM.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 4369; Wed, 14 Oct 1998 15:56:15 +0100 (MEZ) Received: from VM.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by VM.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 0100; Wed, 14 Oct 1998 15:56:15 +0100 Date: Wed, 14 Oct 1998 15:32:42 +0100 (MEZ) From: Peter Schmitt Subject: Re: TeX & Y2K compliance In-reply-to: Your message of Wed, 14 Oct 1998 04:13:47 +0200 To: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <0F0T00FGMLD77B@sun06.ams.org> I am following this discussion with some amusement. It slightly reminds me of the agitated (and sometimes excited) treatment in the media. It has already been said: The only Y2K relevant point is the \year register, and this is able to hold much larger integers than four digit numbers. Of course, in order to obtain the correct \year, TeX depends on the operating system. On the other end: It is the responsibility of the user how he handles the \year -- if he prints or stores it in full or not. Whether one uses two-digit abbreviations is largely a matter of taste and style. Using, e.g., two digits for letters/appointments etc. will be no more confusing than it is now ( or has been 80 years ago :-) (I have already seen dates like 15.10.00 on mineral water bottles.) Though, of course something like 14 SEP 00 looks slightly strange ;-) I have looked at the .log files from rather ancient implementations and found the date fully spelled out -- _only_ the date of the format was abbreviated. But: how this date is given obviously is a matter of style just like the entire wording of the log messages! ( If one really does relevant computations with this date, he will still be safe for another 80 years because no log files have been written in 1900-1979. But who cares anyway? ) But, certainly, if some people would be happier with an unabridged date of the format -- and if this would improve the image of TeX in the public -- it would be nice to do it. Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 14-Oct-1998 14:27:27-GMT,2232;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA16556 for ; Wed, 14 Oct 1998 08:27:26 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 14:27:25 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YGP5B3DC000RYH@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 10:07:04 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00FT4LVF7B@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 10:06:53 -0400 (EDT) Received: from alpha1.rhbnc.ac.uk ([134.219.201.113]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Wed, 14 Oct 1998 14:06:52 +0000 (UT) Date: Wed, 14 Oct 1998 15:06:50 +0100 From: Philip Taylor (RHBNC) Subject: Re: TeX & Y2K compliance To: A8131DAL@helios.edvz.univie.ac.at Cc: TEX-IMPLEMENTORS@ams.org, CHAA006@vms.rhbnc.ac.uk Errors-to: tex-implementors-request@ams.org Reply-to: P.Taylor@vms.rhbnc.ac.uk Message-id: <981014150650.e89@vms.rhbnc.ac.uk> >> Whether one uses two-digit abbreviations is largely a matter of taste and >> style. Using, e.g., two digits for letters/appointments etc. >> will be no more confusing than it is now ( or has been 80 years ago :-) I'm sorry, I disagree. Assume the year is 2004, and my G.P. wishes to refer me to a consultant. If she writes "d.o.b. 4/3/02", then if "02" is interpreted as "2002" I will be referred to a paediatrician; but if it is interpreted as 1902, I will be referred to a geriatrician. And if either of these refer me to the path. lab. and uses the d.o.b. as communicated by my G.P., the path. lab. will use the norms relevant to a 2-y-o or a 102-y-o depending on the interpretation. Since the norms are likely to be very different, the probability of successful diagnosis could be very adversely affected. This, I argue, is why Y2K compliance is far more than $n$-digit registers; it is encumbent on us all to use full-length dates at all times, so that never again will there be this risk of confusion. ** Phil. 14-Oct-1998 16:22:36-GMT,3261;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id KAA19475 for ; Wed, 14 Oct 1998 10:22:35 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 16:22:34 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YKYVJS68000V8C@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 12:09:27 EDT Received: from gate1.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00JIGRJA9W@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 12:09:15 -0400 (EDT) Received: from helios.edvz.univie.ac.at ([131.130.1.2]) by gate1.ams.org via smtpd (for sun06.ams.org [130.44.1.6]) with SMTP; Wed, 14 Oct 1998 16:09:11 +0000 (UT) Received: from VM.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 4394; Wed, 14 Oct 1998 18:09:36 +0100 (MEZ) Received: from VM.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by VM.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 0349; Wed, 14 Oct 1998 18:09:36 +0100 Date: Wed, 14 Oct 1998 17:38:31 +0100 (MEZ) From: Peter Schmitt Subject: Re: TeX & Y2K compliance In-reply-to: "14 Oct 1998 15:06:50 +0100 from" <"CHAA006"@vms.rhbnc.ac.uk> To: P.Taylor@vms.rhbnc.ac.uk Cc: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <0F0T00JIHRJD9W@sun06.ams.org> >>> Whether one uses two-digit abbreviations is largely a matter of taste and >>> style. Using, e.g., two digits for letters/appointments etc. >>> will be no more confusing than it is now ( or has been 80 years ago :-) > >I'm sorry, I disagree. > You need not be sorry :-) -- but I think your argument is besides the point: I said: for letters/appointments, etc. _not_ for the year of birth! >Assume the year is 2004, and my G.P. wishes to refer me to a consultant. >If she writes "d.o.b. 4/3/02", then if "02" is interpreted as "2002" I will >be referred to a paediatrician; but if it is interpreted as 1902, I will be >referred to a geriatrician. > Usually, when you fill in forms you are entering your d.o.b. in full. (If the database later drops this important information it is careless of the maintainer!) - but you may have the habit to abbreviate the date of signature. >This, I argue, is why Y2K compliance is far more than $n$-digit registers; >it is encumbent on us all to use full-length dates at all times, so that >never again will there be this risk of confusion. > Moreover, this issue (d.o.b.) is not at all intrinsic to the use of of computers and the Y2K, but relates to 1900 (e.g.) as well, and therefore was present before. There still _are_ people born in 18xx! In any case: How is this related with the d.o.b. of format file? :-) Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria 14-Oct-1998 16:52:53-GMT,3561;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id KAA20257 for ; Wed, 14 Oct 1998 10:52:51 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 16:52:51 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YLVNC580000RFB@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 12:35:50 EDT Received: from heaton.cl.cam.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00K78SRDHR@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 12:35:40 -0400 (EDT) Received: from dorceus.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.1.34] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1) id 0zTTth-0000Ev-00; Wed, 14 Oct 1998 17:35:37 +0100 Date: Wed, 14 Oct 1998 17:35:34 +0100 From: Robin Fairbairns Subject: Re: TeX & Y2K compliance In-reply-to: "Your message of Wed, 14 Oct 1998 15:06:50 BST." <981014150650.e89@vms.rhbnc.ac.uk> To: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: phil taylor writes, quoting peter schmitt: > >> Whether one uses two-digit abbreviations is largely a matter of taste and > >> style. Using, e.g., two digits for letters/appointments etc. > >> will be no more confusing than it is now ( or has been 80 years ago :-) > > I'm sorry, I disagree. actually, i thought peter's contribution was rather sensible. i particularly liked his `parting shot' (that it should be changed to keep the witter-brigade off our backs), but i really honestly don't really care *all* that much about a date which i don't think one ever really *reads*... > Assume the year is 2004, and my G.P. wishes to refer me to a consultant. > If she writes "d.o.b. 4/3/02", then if "02" is interpreted as "2002" I will > be referred to a paediatrician; but if it is interpreted as 1902, I will be > referred to a geriatrician. And if either of these refer me to the path. > lab. and uses the d.o.b. as communicated by my G.P., the path. lab. will > use the norms relevant to a 2-y-o or a 102-y-o depending on the interpretation. > Since the norms are likely to be very different, the probability of successful > diagnosis could be very adversely affected. but we're not talking medical informatics here (even if we think of dick nickalls's tex-in-the-operating-theatre) because the *only* actual problem is this pointless truncation that don did of the date the format was made. confabulate that with the tex-correctness police and we're all set to have the witter-brigade down on us like a ton of bricks. > This, I argue, is why Y2K compliance is far more than $n$-digit registers; > it is encumbent on us all to use full-length dates at all times, so that > never again will there be this risk of confusion. but the confusion remains, because europeans and yanks have different ways of writing dates, regardless of whether they write 2- or 4-digit years -- is 11.10.98 november or october? and while that's not going to make a geriatric/paediatric distinction, it did cause a salesman at my previous employer to miss an important appointment ;-) by all means write the year out in full (whatever calendar you employ). but don't imagine it's a panacea, and don't imagine that correcting this particular instance in tex is going to change anything other than the incidence of incoming whinges... robin 14-Oct-1998 17:04:43-GMT,2431;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA20751 for ; Wed, 14 Oct 1998 11:04:42 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 17:04:41 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YMFHOX6O000XU8@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 12:51:05 EDT Received: from math.berkeley.edu by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0T00KF5TGRHR@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 12:50:53 -0400 (EDT) Received: from tashkent.berkeley.edu (vojta@tashkent.Berkeley.EDU [128.32.183.151]) by math.berkeley.edu (8.8.7/8.8.7) with ESMTP id JAA20269; Wed, 14 Oct 1998 09:50:51 -0700 (PDT) Received: (from vojta@localhost) by tashkent.berkeley.edu (8.8.7/8.8.7/Debian/GNU) id QAA01973; Wed, 14 Oct 1998 16:50:50 +0000 (GMT) Date: Wed, 14 Oct 1998 16:50:50 +0000 (GMT) From: vojta@math.berkeley.edu (Paul Vojta) Subject: Re: TeX & Y2K compliance To: P.Taylor@vms.rhbnc.ac.uk Cc: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199810141650.QAA01973@tashkent.berkeley.edu> > Date: Wed, 14 Oct 1998 15:06:50 +0100 > From: Philip Taylor (RHBNC) > Subject: Re: TeX & Y2K compliance > To: A8131DAL@helios.edvz.univie.ac.at > > Assume the year is 2004, and my G.P. wishes to refer me to a consultant. > If she writes "d.o.b. 4/3/02", then if "02" is interpreted as "2002" I will > be referred to a paediatrician; but if it is interpreted as 1902, I will be > referred to a geriatrician. And if either of these refer me to the path. > lab. and uses the d.o.b. as communicated by my G.P., the path. lab. will > use the norms relevant to a 2-y-o or a 102-y-o depending on the > interpretation. Since the norms are likely to be very different, the > probability of successful diagnosis could be very adversely affected. > > This, I argue, is why Y2K compliance is far more than $n$-digit registers; > it is encumbent on us all to use full-length dates at all times, so that > never again will there be this risk of confusion. Nice story, but that's not a Y2K issue at all. Suppose the year is 1998, and your G.P. writes "d.o.b. 4/3/96" ... --Paul Vojta, vojta@math.berkeley.edu 14-Oct-1998 17:38:06-GMT,2485;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA21613 for ; Wed, 14 Oct 1998 11:38:05 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 17:38:04 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YN8OFW8G000Y39@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 13:14:36 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00KPQUJZHR@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 13:14:25 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Wed, 14 Oct 1998 18:14:21 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id SAA03662; Wed, 14 Oct 1998 18:14:19 +0100 (BST) Date: Wed, 14 Oct 1998 18:14:18 +0100 (BST) From: Chris Rowley Subject: Re: TeX & Y2K compliance In-reply-to: <199810141650.QAA01973@tashkent.berkeley.edu> To: vojta@math.berkeley.edu (Paul Vojta) Cc: P.Taylor@vms.rhbnc.ac.uk, TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13860.55533.695143.594598@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199810141650.QAA01973@tashkent.berkeley.edu> Paul Vojta wrote -- > > Nice story, but that's not a Y2K issue at all. Suppose the year is 1998, > and your G.P. writes "d.o.b. 4/3/96" ... A witterer writes -- This has gotten totally off-topic but of course it is a Y2K issue in anything but the narrowest legal sense. Aliter, sane people ignore the 2 and the computer in "Y2K" when approriate and look at is as a data representation issue (in any system, computer or not). And whilst we are off-topic, people from cultures that support a mind-blowingly obscure method of writing dates in numerical form should not throw stones at cultures that care about the bureaucratic realiies and their effects on real people, rather than on the legal technicalities:-). And people who think that this is all a waste of time could save a very large amount of other people's person-hours by doing what web2c did and fixing (oops, changing) these three things so that suitable documents can be produced and filed away: it's that simple. chris 14-Oct-1998 18:25:39-GMT,1746;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA22859 for ; Wed, 14 Oct 1998 12:25:38 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 18:25:38 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YP03GDNK000YGV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 14:04:57 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00LPDWVXQF@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 14:04:46 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Wed, 14 Oct 1998 19:04:34 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA03693; Wed, 14 Oct 1998 19:04:33 +0100 (BST) Date: Wed, 14 Oct 1998 19:04:32 +0100 (BST) From: Chris Rowley Subject: Re: TeX & Y2K compliance In-reply-to: <0F0T00FGMLD77B@sun06.ams.org> To: Peter Schmitt Cc: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13860.59182.326278.491708@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <0F0T00FGMLD77B@sun06.ams.org> Peter Schmitt wrote -- > I am following this discussion with some amusement. "We're here to entertain youuuuu!" > It slightly reminds me of the agitated (and sometimes excited) > treatment in the media. That is not too surprising given the reason why I got into looking at it at all. chris 14-Oct-1998 18:31:42-GMT,3410;000000000001 Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA23044 for ; Wed, 14 Oct 1998 12:31:41 -0600 (MDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Wed, 14 Oct 1998 19:31:33 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA03711; Wed, 14 Oct 1998 19:31:31 +0100 (BST) From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Oct 1998 19:31:31 +0100 (BST) To: "Nelson H. F. Beebe" Cc: tex-implementors@ams.org Subject: Re: TeXware & Y2K compliance In-Reply-To: References: X-Mailer: VM 6.44 under Emacs 19.34.1 Message-ID: <13860.59356.978845.372339@fell.open.ac.uk> Nelson Beebe wrote -- > Of all the *.web files in my web2c-7.2 tree (28 of them), > corresponding to the recent TeXlive3 CD-ROM, only three files > (web2c/mp.web, mf/mf.web and tex/tex.web) have variables named `year' > that are output in truncated two-digit form: > > mp.web: > print_int(round_unscaled(internal[year]) mod 100); print_char("."); > > mf.web: > print_int(round_unscaled(internal[year]) mod 100); print_char("."); > > tex.web: > print_int(year mod 100); print_char("."); Thanks for checking. I assume that this agrees with what the web2c guys found. > > As Olaf Weber noted on this list earlier today, the corresponding > change files (*.ch) alter these to print the full year. But only for web2c. > > Of course, the real challenge in investigating Y2K compliance is going > through source code line by line to see if data that happens to be > year values is being manipulated, not just brute-force grepping source > code for variables named year. Absolutely true in general but I think that a number of people understand tex.web well enough to be confident that in this special case grepping for year does quickly lead to finding everything relevant. > > Since \year is accessible to TeX packages, date truncation could also > appear elsewhere in TeX distributions. I therefore checked all of the > files in the TeXlive3 tex/tex/latex tree for references to \year, and > turned up just one another year truncation, in: > > texmf/tex/latex/dinbrief/dinbrief.cls > We are certainly aware that any use of TeX as a programming language cannot be covered by any statement of compliance of TeX itself; and that LaTeX packages and classes are a large and important class of these. Thanks for checking them, especially since it was on my to-do list. I know that the code that is in dinbrief is also used in other places. > > I also noticed that the leap year computation in the file > texmf/tex/latex/misc/advdate.sty is not completely correct, since it > doesn't check for the case of year multiples of 4000 (such years are > not leap years); this bug won't strike for 2001 years yet, so most > people would ignore it. Even the otherwise excellent GNU calendar.el > package doesn't include that test, and the UNIX "cal 4000" command > output shows a February 29. Totally off-topic but I shall nevertheless add that some modern sources claim that the discrepancy that still needs fixing is approx 26sec/year. chris 14-Oct-1998 18:48:13-GMT,3936;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA23501 for ; Wed, 14 Oct 1998 12:48:12 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 18:48:07 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YPXLQC9C000YMS@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 14:31:57 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00NBXY4Y0S@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 14:31:47 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Wed, 14 Oct 1998 19:31:33 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA03711; Wed, 14 Oct 1998 19:31:31 +0100 (BST) Date: Wed, 14 Oct 1998 19:31:31 +0100 (BST) From: Chris Rowley Subject: Re: TeXware & Y2K compliance In-reply-to: To: "Nelson H. F. Beebe" Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13860.59356.978845.372339@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Nelson Beebe wrote -- > Of all the *.web files in my web2c-7.2 tree (28 of them), > corresponding to the recent TeXlive3 CD-ROM, only three files > (web2c/mp.web, mf/mf.web and tex/tex.web) have variables named `year' > that are output in truncated two-digit form: > > mp.web: > print_int(round_unscaled(internal[year]) mod 100); print_char("."); > > mf.web: > print_int(round_unscaled(internal[year]) mod 100); print_char("."); > > tex.web: > print_int(year mod 100); print_char("."); Thanks for checking. I assume that this agrees with what the web2c guys found. > > As Olaf Weber noted on this list earlier today, the corresponding > change files (*.ch) alter these to print the full year. But only for web2c. > > Of course, the real challenge in investigating Y2K compliance is going > through source code line by line to see if data that happens to be > year values is being manipulated, not just brute-force grepping source > code for variables named year. Absolutely true in general but I think that a number of people understand tex.web well enough to be confident that in this special case grepping for year does quickly lead to finding everything relevant. > > Since \year is accessible to TeX packages, date truncation could also > appear elsewhere in TeX distributions. I therefore checked all of the > files in the TeXlive3 tex/tex/latex tree for references to \year, and > turned up just one another year truncation, in: > > texmf/tex/latex/dinbrief/dinbrief.cls > We are certainly aware that any use of TeX as a programming language cannot be covered by any statement of compliance of TeX itself; and that LaTeX packages and classes are a large and important class of these. Thanks for checking them, especially since it was on my to-do list. I know that the code that is in dinbrief is also used in other places. > > I also noticed that the leap year computation in the file > texmf/tex/latex/misc/advdate.sty is not completely correct, since it > doesn't check for the case of year multiples of 4000 (such years are > not leap years); this bug won't strike for 2001 years yet, so most > people would ignore it. Even the otherwise excellent GNU calendar.el > package doesn't include that test, and the UNIX "cal 4000" command > output shows a February 29. Totally off-topic but I shall nevertheless add that some modern sources claim that the discrepancy that still needs fixing is approx 26sec/year. chris 14-Oct-1998 18:57:54-GMT,4846;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA23789 for ; Wed, 14 Oct 1998 12:57:52 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 18:57:52 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YQ9IDDM8000T5Q@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 14:40:47 EDT Received: from venus.open.ac.uk by sun06.ams.org (PMDF V5.1-10 #27147) with SMTP id <0F0T00NGGYJN0S@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 14:40:36 -0400 (EDT) Received: from fell.open.ac.uk by venus with SMTP Local (MMTA v2.2) with ESMTP; Wed, 14 Oct 1998 19:40:32 +0100 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA03726; Wed, 14 Oct 1998 19:40:31 +0100 (BST) Date: Wed, 14 Oct 1998 19:40:30 +0100 (BST) From: Chris Rowley Subject: Re: TeX & Y2K compliance In-reply-to: <199810140213.EAA07034@npc.de> To: Joachim Schrod Cc: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13860.56375.529765.658353@fell.open.ac.uk> MIME-version: 1.0 X-Mailer: VM 6.44 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <981012181609.c1e@vms.rhbnc.ac.uk> <199810121755.NAA24979@zothommog.evcom.net> <13858.18479.78575.461777@fell.open.ac.uk> <199810140213.EAA07034@npc.de> Joachim Schrod wrote -- > Hmm, seems to be not ``this side of the pond'', but ``in UK''. > > PS: For those who don't know it: My company is involved in quite some > Y2K compliance check projects currently, mostly at financial > institutions (most well known are probably Dresdner Bank and European > Central Bank). We earn most of our money with this stuff... :-) The > statement above reflects the official policy of these institutions. > I'd like to add that financial institutions are very concerned about > the Y2K problem -- every project that concerns this problem (and the > transition to Euro :-) is top priority at the moment. No, this seems to be a completely different divide. It is the difference between: -- large-scale commercial/financial/health/... organisations who have a real problem and have therefore, on the whole, made sensible assessments of the real problems and are not worried about things like TeX since, if they do happen to use it, they understand that it is incapable of doing anything dangerous (if used for its intended purposes:-); -- medium-to-large publicly-funded organisations (probably mostly research or education) who are under pressure to provide various bureaucracies (who largely have no idea what "Y2K compliant" means or what software systems are), both internal and external, with documentation that "proves" that every executable ever-used on their system in the last decade is "Y2K compliant"; for them, although usually the individuals who have been ordered to obtain these bits of paper know that for TeX it is a bizarre and useless occupation (a WOMAT since no brain is needed), the bureaucratic exercise is one they simply have to undertake. Thus the reason I started looking at the technical side of these things came from some people's desire to help these paper collectors by producing something that no one will ever look except to check that the file contains "bit of paper about TeX, Metafont, ...". It should be noted that in many cases these people are either employed themselves to do La/TeX support, or are close colleagues of those who do this support. Thus we wish to support them in this instance as a recompence for all the support they have (often very quietly) given the TeX community in the past and will do in the future. > > PPS: I agree, that one should ask Don to change the date printout -- > but IMO it's not a matter of compliance, just a matter of putting out > the information available to the system's user. Yes, I agree that legally and technically this has little to do with Y2K compliance (although my attorney may think differently if there is any money in it:-). Nevertheless there does seem to be a reasonably large body of technical opinion that it should be changed and it would seem reasonable to me that the place to change it is in the original web, rather than every system's change file making exactly the same change. I have seen no technical argument why it was there in the first place: my mind-reading (something you get a lot of experience of when you start disemboweling TeX, an increasingly popular hobby) suggests that it was to save two characters of memory space. The change is easy and obvious (see Web2c 7.2) so is there now any reason at all not to do it? chris 14-Oct-1998 20:24:17-GMT,2754;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id OAA26324 for ; Wed, 14 Oct 1998 14:24:06 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 20:24:05 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YT94H5DS000ZBZ@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 16:06:46 EDT Received: from zothommog.evcom.net by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0U0025M2IYBV@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 16:06:35 -0400 (EDT) Received: (from kinch@localhost) by zothommog.evcom.net (8.8.8/8.8.8) id QAA19594; Wed, 14 Oct 1998 16:06:28 -0400 Date: Wed, 14 Oct 1998 16:06:28 -0400 (EDT) From: "Richard J. Kinch" Subject: Re: TeX & Y2K compliance In-reply-to: <981014150650.e89@vms.rhbnc.ac.uk> To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Reply-to: kinch@truetex.com Message-id: <199810142006.QAA19594@zothommog.evcom.net> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit We Americans are now all jaded experts in casuistry and the expungement thereof, thanks to our esteemed president. These Y2K debates are likable, if that is the sort of thing you like. The rest of us just want to identify the problem kernel and solicit payment to fix it. In the end, some people will profit (Mr Clinton from Monica, at least). In order to concentrate efforts towards acquiring such profit, I would like to have an authoritative summary of where year-related issues reside in TeX, so users have some help in making up their own minds about "year compliance", and we implementors can say "check here and no further". I say "year" and not Y2K, because the issues are sometimes broader than Y2K, such as computing peoples' ages from dates of birth. Based on this tex-implementors thread (which I take as evidence of a lack of FAQ on this topic), I am proposing four general areas of year-related-issues: 1. TeX and METAFONT themselves cannot crash due to dates. 2. The format's year is printed with two digits in logfiles (unless patched as in web2c changefiles). 3. The value returned by \year can be two or four digits, and this is distinction is implementation-dependent. 4. Macro packages interpret the value returned by \year, and besides having to thus deal with (3), the macros themselves may naively manipulate dates. Is this list exhaustive? Richard J. Kinch Publisher, TrueTeX brand typesetting software. See http://truetex.com 14-Oct-1998 22:14:03-GMT,2127;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id QAA29324 for ; Wed, 14 Oct 1998 16:14:02 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Oct 1998 22:14:02 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2YWXGNHJK000UCV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Oct 1998 17:51:59 EDT Received: from math.berkeley.edu by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0U003FI7E5V9@sun06.ams.org> for tex-implementors@axp14.ams.org; Wed, 14 Oct 1998 17:51:42 -0400 (EDT) Received: from bosco.berkeley.edu (bosco.Berkeley.EDU [128.32.183.1]) by math.berkeley.edu (8.8.7/8.8.7) with ESMTP id OAA15163; Wed, 14 Oct 1998 14:51:40 -0700 (PDT) Received: (vojta@localhost) by bosco.berkeley.edu (8.8.5/8.6.4) id OAA23432; Wed, 14 Oct 1998 14:51:37 -0700 (PDT) Date: Wed, 14 Oct 1998 14:51:37 -0700 (PDT) From: vojta@math.berkeley.edu (Paul Vojta) Subject: Re: TeX & Y2K compliance To: C.A.Rowley@open.ac.uk, TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <199810142151.OAA23432@bosco.berkeley.edu> > Date: Wed, 14 Oct 1998 18:14:18 +0100 (BST) > From: Chris Rowley > To: vojta@math.berkeley.edu (Paul Vojta) > Cc: P.Taylor@vms.rhbnc.ac.uk, TEX-IMPLEMENTORS@ams.org > Subject: Re: TeX & Y2K compliance > > And people who think that this is all a waste of time could save a > very large amount of other people's person-hours by doing what web2c > did and fixing (oops, changing) these three things so that suitable > documents can be produced and filed away: it's that simple. Maybe it would be helpful if you could quote from some of the documents that you are supposed to sign and file away. As I see it, DEK uses year in several places, and chops off the first two digits only when it is printed to the log file. This suggests that he has already taken the Y2K issue into consideration. Over and out. --Paul Vojta, vojta@math.berkeley.edu 15-Oct-1998 8:01:01-GMT,1825;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA11590 for ; Thu, 15 Oct 1998 02:01:00 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 15 Oct 1998 08:00:59 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2ZHL7Q4EO000YB9@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 15 Oct 1998 03:43:43 EDT Received: from perdita.zdv.Uni-Mainz.de by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0U00FLJYSEXN@sun06.ams.org> for tex-implementors@axp14.ams.org; Thu, 15 Oct 1998 03:43:31 -0400 (EDT) Received: (from schoepf@localhost) by perdita.zdv.Uni-Mainz.de (8.8.8/8.8.8) id JAA04685; Thu, 15 Oct 1998 09:43:24 +0200 (MEST) Date: Thu, 15 Oct 1998 09:43:23 +0200 (MEST) From: Rainer Schoepf Subject: Re: TeX & Y2K compliance In-reply-to: <13860.55533.695143.594598@fell.open.ac.uk> To: TEX-IMPLEMENTORS@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13861.42907.245849.267560@perdita.zdv.Uni-Mainz.de> Organization: Johannes Gutenberg-Universitaet Mainz MIME-version: 1.0 X-Mailer: VM 6.51 under Emacs 19.34.1 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <199810141650.QAA01973@tashkent.berkeley.edu> <13860.55533.695143.594598@fell.open.ac.uk> Chris Rowley writes: > And people who think that this is all a waste of time could save a > very large amount of other people's person-hours by doing what web2c > did and fixing (oops, changing) these three things so that suitable > documents can be produced and filed away: it's that simple. Strong agreement. This discussion is a so-called partial WOMBAT. :-) Rainer Schöpf 15-Oct-1998 9:43:48-GMT,3046;000000000001 Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA13512 for ; Thu, 15 Oct 1998 03:43:47 -0600 (MDT) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 15 Oct 1998 09:43:42 UT Received: from sun06.ams.org by AXP14.AMS.ORG (PMDF V5.1-8 #30286) with ESMTP id <01J2ZLHVDFOG0012JC@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 15 Oct 1998 05:35:31 EDT Received: from ifi.informatik.uni-stuttgart.de by sun06.ams.org (PMDF V5.1-10 #27147) with ESMTP id <0F0V00IHH3YR1L@sun06.ams.org> for tex-implementors@axp14.ams.org; Thu, 15 Oct 1998 05:35:22 -0400 (EDT) Received: by isidor.informatik.uni-stuttgart.de; Thu, 15 Oct 1998 11:33:37 +0200 (MET DST) Date: Thu, 15 Oct 1998 11:33:30 +0200 (MET DST) From: Bernd Raichle Subject: Re: TeX & Y2K compliance In-reply-to: <199810142006.QAA19594@zothommog.evcom.net> To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <13861.49514.583339.716113@isidor> MIME-version: 1.0 X-Mailer: VM 6.51 under Emacs 19.34.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <981014150650.e89@vms.rhbnc.ac.uk> <199810142006.QAA19594@zothommog.evcom.net> On Wed, 14 October 1998 16:06:28 -0400, Richard J. Kinch writes: [...] > Based on this tex-implementors thread (which I take as evidence of a lack of > FAQ on this topic), I am proposing four general areas of year-related-issues: > > 1. TeX and METAFONT themselves cannot crash due to dates. Sic! > 2. The format's year is printed with two digits in logfiles (unless patched > as in web2c changefiles). The year is printed into the (text) log file _and_ it is ``printed'' into the format (string |format_ident|) and dvi files (``TeX output ..: