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 ..: