11-Sep-2000 18:37:25-GMT,2740;000000000001 Return-Path: Received: from suncore.math.utah.edu (suncore0.math.utah.edu [128.110.198.5]) by csc-sun.math.utah.edu (8.9.3/8.9.3) with ESMTP id MAA07355; Mon, 11 Sep 2000 12:37:24 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3/8.9.3) id MAA22394; Mon, 11 Sep 2000 12:37:24 -0600 (MDT) Date: Mon, 11 Sep 2000 12:37:24 -0600 (MDT) From: "Nelson H. F. Beebe" To: tex-implementors@ams.org, texlive@tug.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: web2c 7.3.2 (TeX and Metafont) bounds violations Message-ID: There has been recent work on extended the gcc compiler to support bounded pointers: each OBJECT* pointer points to a 3-element structure containing the object's current address, and lower and upper bounds on the storage allocated for the object. You can read about it in http://gcc.gnu.org/projects/bp The reason for this post is to inform you that as part of the project, a number of open-source programs were built and tested with the extended gcc compiler, among them web2c 7.3.2, for which the above Web page notes >> ... >> Bounds violations exposed: >> >> * fixwrites: main read past the beginning of a string buffer when >> presented with an empty line. >> >> 100% of the test suite passes after fixing the bug listed above, >> and compiling with ``gcc ... -fno-strict-aliasing''. A >> strict-aliasing bug for i586 and i686 caused two assertion >> failures in kpathsea. >> ... Since TeXlive CDs are in production these past few months, it would be beneficial to incorporate fixes in new editions. I suspect that one or more commercial implementations of TeX also involve Web-to-C translations, so the fixes may be more widely applicable. ------------------------------------------------------------------------------- - 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 beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- 31-Oct-2000 16:02:56-GMT,1844;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id JAA14662 for ; Tue, 31 Oct 2000 09:02:55 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.9.3/8.9.3) with ESMTP id LAA01615 for ; Tue, 31 Oct 2000 11:02:53 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01JVZGKROSK0000G5J@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 31 Oct 2000 11:01:18 EST Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by ams.org (8.9.3/8.9.3) with ESMTP id LAA01278 for ; Tue, 31 Oct 2000 11:01:07 -0500 (EST) Received: from anxur.fi.muni.cz (11601@anxur.fi.muni.cz [147.251.48.3]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id RAA11628 for ; Tue, 31 Oct 2000 17:00:56 +0100 (MET) Received: (from thanh@localhost) by anxur.fi.muni.cz (8.8.5/8.8.5) id RAA17825 for tex-implementors@ams.org; Tue, 31 Oct 2000 17:00:50 +0100 (MET) Date: Tue, 31 Oct 2000 17:00:50 +0100 (MET) From: Han The Thanh Subject: discretionary To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <200010311600.RAA17825@anxur.fi.muni.cz> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Dear TeX implementors, can it happens that during line breaking, we get two consecutive discretionary nodes where the latter one has empty pre_break? I have the feeling that I encoutered such a case in the past but now cannot remember how it could happen. Or maybe I am wrong and it's impossible to get into such situation? Regards, Thanh 31-Oct-2000 18:53:22-GMT,3985;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id LAA20031 for ; Tue, 31 Oct 2000 11:53:20 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.9.3/8.9.3) with ESMTP id NAA13736 for ; Tue, 31 Oct 2000 13:53:18 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01JVZMJK5PXS000GZG@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Tue, 31 Oct 2000 13:52:09 EST Received: from aragorn.ics.muni.cz (relay.muni.cz [147.251.4.33]) by ams.org (8.9.3/8.9.3) with ESMTP id NAA13432 for ; Tue, 31 Oct 2000 13:51:57 -0500 (EST) Received: from anxur.fi.muni.cz (11601@anxur.fi.muni.cz [147.251.48.3]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id TAA03181 for ; Tue, 31 Oct 2000 19:51:56 +0100 (MET) Received: (from thanh@localhost) by anxur.fi.muni.cz (8.8.5/8.8.5) id TAA01615 for tex-implementors@ams.org; Tue, 31 Oct 2000 19:51:56 +0100 (MET) Date: Tue, 31 Oct 2000 19:51:55 +0100 (MET) From: Han The Thanh Subject: discretionary again To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <200010311851.TAA01615@anxur.fi.muni.cz> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL39 (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Dear TeX implementors, I encountered a case where it seems that using another font can give different result of discretionary nodes inserted by tex during line breaking. My test file looks as follows: ==================== cut here ========================== \font\fA=pgm1r8z at 8pt\fA \font\fB=pgm1ri8z at 8pt \let\tenrm=\relax \def\checkdisc{ \showhyphens{\italic{prijmout}} \setbox0=\hbox{\italic{prijmout}} \showbox0 } \nonstopmode \showboxbreadth=10 \hyphenation{pri-jmout} \def\italic #1{{#1}}\checkdisc \def\italic #1{{\fB#1}}\checkdisc \bye ==================== cut here ========================== This file was texed using plain tex with a small modification to displaying discretionary nodes (by short_display): ==================== cut here ========================== @x m. 175 disc_node: begin short_display(pre_break(p)); short_display(post_break(p));@/ @y disc_node: begin print("|"); short_display(pre_break(p)); print("|"); short_display(post_break(p));@/ print("|"); @z ==================== cut here ========================== and the log file looks as follows: ==================== cut here ========================== This is TeX, Version 3.14159 (Web2C 7.3.2.2) (format=tex 2000.10.31) 31 OCT 2000 19:11 **f (./f.tex Underfull \hbox (badness 10000) in paragraph at lines 15--15 [] \fA pri|-||jmout \hbox(5.232+1.84)x16383.99998, glue set 13345.86687 [] > \box0= \hbox(5.232+1.84)x26.63197 .\fA p .\fA r .\kern0.2 .\fA i .\fA j .\fA m .\fA o .\fA u .\fA t ! OK. \checkdisc ...box {\italic {prijmout}} \showbox 0 l.15 \def\italic #1{{#1}}\checkdisc Underfull \hbox (badness 10000) in paragraph at lines 16--16 [] \fB pr|i-||jmout \hbox(5.0+1.736)x16383.99998, glue set 13344.82112 [] > \box0= \hbox(5.0+1.736)x27.91197 .\fB p .\kern0.136 .\fB r .\kern0.2 .\fB i .\fB j .\fB m .\kern0.08 .\fB o .\fB u .etc. ! OK. \checkdisc ...box {\italic {prijmout}} \showbox 0 l.16 \def\italic #1{{\fB#1}}\checkdisc ) No pages of output. ==================== cut here ========================== When comparing the two following lines from the log file: [] \fA pri|-||jmout [] \fB pr|i-||jmout it looks like the content of the discretionary node in two cases are different. Does anyone please know why? Regards, Thanh 9-Mar-2001 6:02:51-GMT,1760;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id XAA14812 for ; Thu, 8 Mar 2001 23:02:50 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f2962lV19134 for ; Fri, 9 Mar 2001 01:02:47 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K0Z30UAH2O000JLI@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 9 Mar 2001 00:56:39 EST Received: from truetex.com (dsl-64-192-174-73.telocity.com [64.192.174.73]) by ams.org (8.11.2/8.11.2) with ESMTP id f295tkV18536 for ; Fri, 09 Mar 2001 00:55:47 -0500 (EST) Received: (from kinch@localhost) by truetex.com (8.8.7/8.8.7) id AAA03003; Fri, 09 Mar 2001 00:55:38 -0500 Date: Fri, 09 Mar 2001 00:54:36 -0500 (EST) From: Richard J Kinch Subject: Re: Old TUGboat volumes In-reply-to: <19350131201523.27343@fs.m17n.org> To: yannis@fluxus-virus.com (Yannis Haralambous) Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <200103090555.AAA03003@truetex.com> MIME-version: 1.0 X-Mailer: ELM [version 2.5 PL3] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Yannis, > I'm looking for old (< 1990) TUGboats, to complete my collection and > eventually to scan them for the archives. Can anyone help me? I'm > willing to buy them (for reasonable prices). I have from March 1986 and up. I also have a power cutter that can cut the bindings off for a scanner equipped with a sheet feeder. Richard J. Kinch Publisher, TrueTeX Typesetting Software http://www.truetex.com 9-Mar-2001 2:47:30-GMT,2696;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id TAA10454 for ; Thu, 8 Mar 2001 19:47:28 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f292lMV10849 for ; Thu, 8 Mar 2001 21:47:23 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K0YWBY5IXS000K2Y@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Thu, 8 Mar 2001 21:44:08 EST Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by ams.org (8.11.2/8.11.2) with ESMTP id f292hrV10248 for ; Thu, 08 Mar 2001 21:43:53 -0500 (EST) Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id LAA23007 for ; Fri, 09 Mar 2001 11:43:38 +0900 Received: from [192.47.44.62] (mac-french.m17n.org [192.47.44.62]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id LAA22093 for ; Fri, 09 Mar 2001 11:43:36 +0900 (JST) Date: Fri, 09 Mar 2001 11:43:39 +0900 From: Yannis Haralambous Subject: Old TUGboat volumes To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <19350131201523.27343@fs.m17n.org> MIME-version: 1.0 X-Mailer: CTM PowerMail 3.0.6 F Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit I'm looking for old (< 1990) TUGboats, to complete my collection and eventually to scan them for the archives. Can anyone help me? I'm willing to buy them (for reasonable prices). Thanks in advance Yannis +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@fluxus-virus.com | +--------------------------------------------------------------------+ | 187, rue Nationale fax : +33 (0)3.20.40.28.64 | | 59800 Lille, France tel. : +33 (0)6.07.98.16.26 | +--------------------------------------------------------------------+ | Visit the trilingual Atelier Fluxus Virus Web site: | | http://www.fluxus-virus.com | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 9-Mar-2001 6:14:04-GMT,3197;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id XAA15075 for ; Thu, 8 Mar 2001 23:14:02 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f296E0V19935 for ; Fri, 9 Mar 2001 01:14:00 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K0Z3J39BW0000NKG@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 9 Mar 2001 01:10:52 EST Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by ams.org (8.11.2/8.11.2) with ESMTP id f296ARV19412 for ; Fri, 09 Mar 2001 01:10:28 -0500 (EST) Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id PAA26222; Fri, 09 Mar 2001 15:10:26 +0900 Received: from [192.47.44.62] (mac-french.m17n.org [192.47.44.62]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id PAA23644; Fri, 09 Mar 2001 15:10:23 +0900 (JST) Date: Fri, 09 Mar 2001 15:10:26 +0900 From: Yannis Haralambous Subject: Re: Old TUGboat volumes In-reply-to: <200103090555.AAA03003@truetex.com> To: Richard J Kinch , tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <19350131234210.9805@fs.m17n.org> MIME-version: 1.0 X-Mailer: CTM PowerMail 3.0.6 F Content-type: text/plain; charset=ISO-8859-1 References: <200103090555.AAA03003@truetex.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunshine.math.utah.edu id XAA15075 >Yannis, > >> I'm looking for old (< 1990) TUGboats, to complete my collection and >> eventually to scan them for the archives. Can anyone help me? I'm >> willing to buy them (for reasonable prices). > >I have from March 1986 and up. Fine, but are you selling/giving them away? If yes, I'm interested. >I also have a power cutter that can cut the >bindings off for a scanner equipped with a sheet feeder. Good heaven, I would never do that to a TUGboat, especially an old one! My plan was scanning without destroying. Cheers Yannis +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@fluxus-virus.com | +--------------------------------------------------------------------+ | 187, rue Nationale fax : +33 (0)3.20.40.28.64 | | 59800 Lille, France tél. : +33 (0)6.07.98.16.26 | +--------------------------------------------------------------------+ | Visit the trilingual Atelier Fluxus Virus Web site: | | http://www.fluxus-virus.com | +--------------------------------------------------------------------+ ...pour distinguer l'extérieur d'un aquarium, mieux vaut n'être pas poisson ...the ball I threw while playing in the park has never reached the ground 9-Mar-2001 6:42:09-GMT,2289;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id XAA15711 for ; Thu, 8 Mar 2001 23:42:07 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f296g5V21685 for ; Fri, 9 Mar 2001 01:42:05 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K0Z4IOU4KG000MTV@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Fri, 9 Mar 2001 01:38:40 EST Received: from truetex.com (dsl-64-192-174-73.telocity.com [64.192.174.73]) by ams.org (8.11.2/8.11.2) with ESMTP id f296cPV21151 for ; Fri, 09 Mar 2001 01:38:26 -0500 (EST) Received: (from kinch@localhost) by truetex.com (8.8.7/8.8.7) id BAA03218; Fri, 09 Mar 2001 01:38:23 -0500 Date: Fri, 09 Mar 2001 01:38:23 -0500 (EST) From: Richard J Kinch Subject: Re: Old TUGboat volumes In-reply-to: <19350131234210.9805@fs.m17n.org> To: yannis@fluxus-virus.com (Yannis Haralambous) Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <200103090638.BAA03218@truetex.com> MIME-version: 1.0 X-Mailer: ELM [version 2.5 PL3] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Yannis, > Fine, but are you selling/giving them away? If yes, I'm interested. You are welcome to them for free if you're scanning for freely available editions. I'd prefer to have them electronically, anyway. > >I also have a power cutter that can cut the > >bindings off for a scanner equipped with a sheet feeder. > > Good heaven, I would never do that to a TUGboat, especially an old one! > My plan was scanning without destroying. I suppose that depends on your definition of "destroy". And are you that dedicated, that you're going to hand-scan all those old pages without a sheet feeder? You'll get a much better scan if the bindings aren't distorting and the inside edges and skewing the alignment while you're scanning. I would think the value of that to the world is more than the value of one more copy having an original binding. Kind of like carbon-dating the Shroud of Turin. Richard J. Kinch http://www.truetex.com 14-Mar-2001 11:19:00-GMT,5195;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id EAA24474 for ; Wed, 14 Mar 2001 04:18:59 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f2EBItV11202 for ; Wed, 14 Mar 2001 06:18:56 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K16DHY6ESG000ZT6@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Wed, 14 Mar 2001 06:11:40 EST Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by ams.org (8.11.2/8.11.2) with ESMTP id f2EBBSV10666 for ; Wed, 14 Mar 2001 06:11:28 -0500 (EST) Received: from jon.skorepa.cz (root@ts3-2.dialup.muni.cz [147.251.22.221]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id MAA06747; Wed, 14 Mar 2001 12:10:58 +0100 (MET) Received: (from ksk@localhost) by jon.skorepa.cz (8.9.3/8.9.3) id MAA29772; Wed, 14 Mar 2001 12:10:51 +0100 Date: Wed, 14 Mar 2001 12:10:50 +0100 From: Karel Skoupy Subject: \xleaders bug in TeX To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <20010314121050.A29537@jon.skorepa.cz> MIME-version: 1.0 X-Mailer: Mutt 1.0.1i Content-type: text/plain; charset=us-ascii Dear Colleagues, there is a report of a TeX bug which I already promised to Barbara Beeton. --ksk --------------------------------------------------------------------------- The \xleaders bug in TeX ======================== Description: ============ Under certain circumstances the result of \xleaders is not centered; the last box copy of \xleaders seems to be missing. In particular this happens when the width of \xleaders is exactly n times width of the box where n is in range 12..19 (and the width of the box is greater than 10sp). It can happen also in other cases where the overall width is not a product of the box width and a whole number (there is probably shorter English formulation). Example: ======== \setbox0=\hbox{X} % a box for \xleaders \dimen0=17\wd0 % exactly 17 times the width of the box \hbox{\vrule\cleaders\copy0\hskip\dimen0\vrule\quad(cleaders)} % cleaders \hbox{\vrule\xleaders\copy0\hskip\dimen0\vrule\quad(xleaders)} % xleaders Analysis: ========= In TeX: The Program, module 627, there are statements: lx:=(2*lr+lq+1) div (2*lq+2); {round|(lr/(lq+1))|} cur_h:=cur_h+((lr-(lq-1)*lx) div 2); where: rule_wd is the width of of \xleaders (the with which was specified plus 10sp to compensate for floating-point rounding) leader_wd is the width of the box lq is rule_wd div leader_wd; {the number of box copies} lr is rule_wd mod leader_wd; {the remaining space} cur_h is the starting horizontal position of leaders Let r be lr-(lq-1)*lx and let o be r div 2. lx is used as the spacing between copies of the box, r is the difference between the \xleaders width and the width actually used by the boxes and o (= (lr-(lq-1)*lx) div 2) is the offset of the first box. For leader_wd > 10 and rule_wd = 17 * leader_wd + 10 we have: lq = 17 lr = 10 lx = (2 * 10 + 17 + 1) div (2 * 17 + 2) = 38 div 36 = 1 r = 10 - (17 - 1) * 1 = -6 o = r div 2 = -3 So the space planned for \xleaders is 6sp wider than the specification after adding 10sp and the boxes start 3sp before the position of \xleaders which is not what we wanted. Furthermore the algorithm for outputting boxes in leaders does not count the number of box copies but checks the right edge (see module 626): while cur_h+leader_wd<=edge do @; where: edge is cur_h + rule_wd For 17th box we have: o + 17 * leader_wd + 16 + lx = -3 + 17 * leader_wd + 16 * 1 = -3 + rule_wd - 10 + 16 = rule_wd + 3 > rule_wd so the 17th box is not output. Even if the algorithm counted the number of box copies instead of checking the right edge the result would be still slightly incorrect because it would be 6sp wider than the specified width of \xleaders (plus 10sp for rounding errors) although 17 copies would easily fit for lx = 0. Discovering: ============ I found this bug during testing NTS (modular reimplementaion of TeX in Java) on the TeXbook. On the first page (69) of chapter 12 Glue there are illustrations of glues and boxes where \xleaders are used. The described behavior occurs in some case of the dotted illustration of glue. Because NTS was counting the number of box copies instead of checking the right edge the DVI outputs of TeX and NTS were different. Visually it is indistinguishable because the last dot which was missing would be hidden by a big dot denoting a box reference point anyway. I found it in October 2000, sorry for the delay. I would like to thank Bernd Raichle who made his own analysis as well and who first confirmed that it was really a bug. He also encouraged/pushed me to eventually write this report. You will probably hear more from him about this issue. Many thanks Bernd! Karel Skoupy skoupy@fi.muni.cz 19-Mar-2001 15:10:11-GMT,14685;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id IAA29584 for ; Mon, 19 Mar 2001 08:10:09 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f2JFA0V19471 for ; Mon, 19 Mar 2001 10:10:00 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K1DL5AHLZ4000B8Q@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 19 Mar 2001 10:06:10 EST Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by ams.org (8.11.2/8.11.2) with ESMTP id f2JF5pV18706 for ; Mon, 19 Mar 2001 10:05:52 -0500 (EST) Received: from isar.informatik.uni-stuttgart.de (isar [129.69.215.232]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id QAA17693; Mon, 19 Mar 2001 16:05:45 +0100 (MET) Received: (from raichle@localhost) by isar.informatik.uni-stuttgart.de (8.9.3/2.2) id QAA23955; Mon, 19 Mar 2001 16:05:48 +0100 (MET) Date: Mon, 19 Mar 2001 16:05:48 +0100 (MET) From: Bernd Raichle Subject: Re: \xleaders bug in TeX In-reply-to: <20010314121050.A29537@jon.skorepa.cz> To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <15030.8268.80962.856349@isar.informatik.uni-stuttgart.de> MIME-version: 1.0 X-Mailer: VM 6.75 under Emacs 20.7.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <20010314121050.A29537@jon.skorepa.cz> X-Authentication-warning: isar.informatik.uni-stuttgart.de: raichle set sender to raichle@Informatik.Uni-Stuttgart.DE using -f Dear TeX Implementors, Karel Skoupy asked me at the end of last year to look at some TeX code for which the dvi output of TeX and NTS differ. He wanted some comments if or if not the behaviour of NTS is O.K. and that it can still be called TeX. The result was that NTS is O.K. but TeX is not, i.e., TeX has a bug w.r.t. to \xleaders. For cases where there are _no_ rounding errors due to differences in the system dependent calculation of the glue setting or rounding errors when converting between dimensions, (1) the _last_ leader box is sometimes _missing_ making (2) the whole \xleaders appear expanded but _non_-centered within the given glue space. Even if the missing last leader box is not classified as a TeX bug, the non-centered output is one, either in the TeX.web code or in the documentation of \xleaders. Scanning through the TeX changes in the file ``tex82.bug'' I am sure that the bug exists since TeX version 1.0 because the space between leader boxes for \xleaders was introduced by change #255. The bug was not found because \xleaders is very rarely used and nobody who used it has cared about too much space at the right end of the leaders. Ok, here is the analysis I have written for Karel last year. Within the document there are some examples showing the \xleaders bug, the last one shows the bug for vertical mode. -------------------- CUT HERE -------------------- Subject: TeX.web bug in \xleaders resulting in a missing leader box The current and older versions of TeX.web (including TeX versions before 2.6!) have a bug in the routines dealing with leaders. Examples ======== Example 1. The bug is triggered by a simple example as the following Plain TeX input a\xleaders\hbox to 3pt{\hss .\hss}\hskip 45pt\relax b\bye Whereas one expects that there will be 15 dots---each leader box has a width of 3pt and is set in a glue of width 45pt---, only 14 dots are shown. Instead of the 15th dot there is unwanted white space between the 14th dot and the letter ``b''. As stated in the TeXbook the result of \xleaders are unaligned leaders where the leader boxes are replicated in such a way that they cover the glue width from beginning to the end in a _regular_ way. This is done by inserting white space between all leader boxes and before the first and after the last leader box. Thus even if only 14 leader boxes can be placed they have to be spread regularly within the space between ``a'' and ``b''. Regarding the possibility of machine-dependent rounding errors (cf. TeX.web, \S1374, ``We don't implement \.{\\write} inside of leaders. (The reason is that the number of times a leader box appears might be different in different implementations, due to machine-dependent rounding in the glue calculations.)''), in the shown example there are neither machine-dependent nor machine-independent rounding errors: - the glue has no stretch or shrink - the width of the glue and the leader box in pt is converted in sp without the need to round Therefore all comments in TeX.web and the TeXbook dealing with leaders w.r.t. machine-dependent rounding do not apply. In contrary all TeX implementations starting with version 2.6 (and with a small change also all starting with version 1.0) will show the white space instead of the missing 15th dot. Example 2. The following example shows a more complicated way involving machine-_in_dependent rounding to trap the bug: \dimen0=45pt \dimen2=1pt \divide\dimen2 6 % 1/6pt \count0=0 \loop \advance\dimen0 .50\dimen2 % some funny \advance\dimen0 -.25\dimen2 % redundant \advance\dimen0 -.25\dimen2 % calculations a\xleaders\hbox to 3pt{\hss.\hss}\hskip\dimen0 b \rlap{\qquad\the\dimen0}% \endgraf \advance\count0 1 \ifnum\count0<15 \repeat \bye As you can see the bug occurs in a non-monotonic way w.r.t. glue width. The last leader box is first missing, then appears when \dimen0 gets slightly larger, and then disappears again. Example 3. In TeXbook, Chapter 12, ``Glue'', this bug appears, too. On the first page of this chapter, four boxes with its dimensions, its alignment and the glue between them is shown. The glue is represented by a dotted line created by \xleaders. There is one dot missing in the \xleaders between the third and fourth box. This missing dot is not visible because of the big dot representing the reference point of each box. After redefining the box \bigdot (``manmac.tex'') to contain no dot you will see it. Analysis ======== Have a look at TeX.web sections 626. @ and 627. @ For vertical leaders the same analysis apply for the sections 635. @ and 636. @ because the code is almost the same (e.g. |cur_h| => |cur_h|, |leader_wd| => |leader_ht|, |rule_wd| => |rule_ht| etc.). The problem is that there are two almost independent calculations how many leader boxes are output: The first calculation is done in section 627 which sets |lq| to the number of times the leader box is replicated and |lx| giving the space inserted between the leader boxes to get expanded leaders. Depending on these calculations the placement of the first (and the last) box is done by adjusting the current position |cur_h|. The second "calculation" is done in section 626 where the termination condition determines how many leader boxes are set. This condition does not depend on |lq| nor does |edge|, one of its component, takes care of the necessary adjustment of the first and last leader box calculated in 627. Here is a more detailed analysis: The first calculation is done in section 627 (@), where |lq| is set to the number of times the leader box is replicated, |lx| is set to the portion of the remaining space to be put between the leader boxes, and to be inserted before the first and after the last leader box, theoretically. As Knuth states in TeX.web (concerning the integer division lx:=round(lr/(lq-1))): ``Slight inaccuracies in the division might accumulate; half of this rounding error is placed at each end of the leaders.'' Thus instead if inserting |lx| at the beginning and the end of the leaders, half of the remainder of |lr| minus ((lq-1)*lx) is inserted. This means that if (lr/(lq-1)) is between x+0.5 and x+1, |lx| is rounded to x+1 (x is an integer). The space inserted at the left and right end of the leaders is between 0.5*(lq-1) and 0*(lq-1). In which case occurs the rounding to the next larger integer? The expression |lx|:=(2*lr+lq+1)div(2*lq+2) is rounded to 1 if 2lr+lq+1 >= 2lq+2 2lr >= lq+1 lr >= 0.5*lq + 0.5 (1) and the inserted space at the beginning and end of the leaders ((lr-(lq-1)*lx) div 2) is negative if (for |lx|=1) (lr-(lq-1)*lx) div 2 <= -1 lr-(lq-1)*1 <= -2 lr <= -2 + lq-1 lr <= lq - 3 (2) 0.5*lq + 0.5 <= -2 + lq-1 (using (1)) lq >= 7 lq - 3 >= lr >= 0.5*lq+0.5 (3, using (1)+(2)) Thus for all quantities of leader boxes |lq| >= 7 it is possible that the inserted space is negative for some values of |lr|. These values can be computed using (3): lq = 7: 4 <= lr <= 4 => lr = 4 lq = 8: 4.5 <= lr <= 5 => lr = 5 lq = 9: 5 <= lr <= 6 => lr = 5 or 6 lq = 10: 5.5 <= lr <= 7 => lr = 6 or 7 ... lq = 20: 10.5 <= lr <= 17 => lr = 11...17 etc. And here is the ``real life'' test using TeX which shows that the last leader box is missing: \def\test#1 #2 {% \dimen0=3pt\dimen2=#1\dimen0 \advance\dimen2 by -10sp % compensate 10sp addition \advance\dimen2 by #2sp I\xleaders\hbox to 3pt{\hss .\hss}\hskip\dimen2\vrule\endgraf} \test 7 4 \test 8 5 \test 9 5 \test 9 6 \test 20 11 \test 20 17 \bye To get the reason for the missing last leader box we have to look at the place where the leader boxes are put into the dvi file. The second "calculation" is done in section 626 (@) where the leader boxes are set within the while loop: ... rule_wd:=rule_wd+10; {compensate for floating-point rounding} edge:=cur_h+rule_wd; lx:=0; @; while cur_h + leader_wd <= edge do begin ... output leader box to dvi... cur_h := cur_h + leader_wd + lx; end The while loop doesn't make use of |lq| containing the number of replicated leader boxes (the reason is that |lq| is only set for \cleaders and \xleaders, not for \leaders, but the code in 626 is shared for all types of leaders). Instead it uses its own termination condition by testing for the |egde| pointing to the end position of the glue. |egde| is set before the calculations of |lq|, |lx| etc. to |cur_h| + |rule_wd|. Now the bug occurs because |egde| is not adjusted by ((lr-(lq-1)*lx) div 2), atleast for all cases in which this expression is negative. If the space inserted after the last leader box is negative, the last leader box is not set because |cur_h| + |leader_wd| is larger than |edge|. This bug was introduced by the change of (cf. ``tex82.bug'') 255. Bug in \xleader computations (found by FY, August 18) [1983] in TeX version 1.0 (sic!) where |lx|, the space between leader boxes was introduced without changing the termination condition of the while loop in section 626. The change of 334. leaders too sensitive near exact multiples (M. F. Bridgland, 9 Nov 87) for TeX version 2.6 introducing a small displacement of 10sp for the leaders helps to uncover the bug. The comment in the code says that the 10sp were introduced to ``compensate for floating-point rounding'' (if the glue has stretch and shrink). Nonetheless for \xleaders it makes |lr| equals 10sp if |rule_wd| is a multiple of |leader_wd|. For the case that the glue width is a multiple of the width of the leader box, we know that |lr| equals 10sp and we can determine all cases where the last leader box is missing: lx is rounded to 1 and lr = 10 for all lq with 2 lr + lq + 1 >= 2 lq + 2 20 + lq + 1 >= 2 lq + 2 lq <= 19 The space inserted at the end is negative if 0.5 <= (lr/(lq-1)) < 1 0.5 <= 10/(lq-1) < 1 (lq>1) 10 < lq-1 <= 20 11 < lq <= 21 Thus the last leader box is missing for all cases where |rule_wd| equals |lq| times |leader_wd| and 11 < lq <= 19. The following TeX code loops through lq=1..30: \dimen0=3pt \count0=1 \loop I\xleaders\hbox to\dimen0{\hss.\hss}\hskip\count0\dimen0\vrule \rlap{\qquad\the\count0}\endgraf \advance\count0 1 \ifnum\count0<30 \repeat \bye Summary: As shown above the cases for which the last leader box is missing varies with the values of |lq|, |lr| and it is shown that for these cases |lr| is in the range of only a few scaled points (|lr| <= |lq| - 3). Nonetheless this small remaining space can occur quite often---either caused by the 10sp addition in TeX.web, by (machine-_in_dependent) rounding errors when doing dimension calculations, or by (machine-dependent) rounding errors when using glue with stretch or shrink. \leaders and \cleaders are not affected by the bug. They share almost the same code but the sometimes negative offset of ((lr-(lq-1)*lx) div 2) is only used for \xleaders. There is no such offset for aligned \leaders and |lq| is not set or used. For unaligned centered \cleaders the offset of (|lr| div 2) is always positive, thus it will be no problem to put |lq| leader boxes within the glue width. Bug fix proposal ================ The simplest bug fix is by adding |lq| for aligned leaders and using |lq| in the while loop for all types of leaders. Additional bug fix proposal =========================== We don't know the historical cause of the 10sp addition to compensate for floating-point rounding errors. In our opinion it will be better to _not_ widen |rule_wd| by 10sp in section 626. Instead the 10sp should be only added to the value of |rule_wd| when calculating |lq| (in section 627). For the rest of the calculations and the typesetting the original value of |rule_wd| should be used (assuming that |lq| is used in the while loop). \dimen0=12pt \count0=5 \hbox{% \loop \vtop{\hsize=20pt \centerline{\strut\the\count0}\hrule \xleaders\vbox to\dimen0{\hbox{\strut\TeX}\vfil}% \vskip\count0\dimen0 \hrule} % \advance\count0 1 \ifnum\count0<25 \repeat} \bye -------------------- CUT HERE -------------------- Best wishes, -bernd _____________________________________________________________________ Bernd Raichle "Le langage est source Autor des `german.sty' (aktuell: v2.5e) de malentendus" DE-TeX-FAQ: http://www.dante.de/faq/de-tex-faq/ (A. de Saint-Exupery) 19-Mar-2001 16:37:24-GMT,1497;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id JAA02426 for ; Mon, 19 Mar 2001 09:37:22 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f2JGbJV28819 for ; Mon, 19 Mar 2001 11:37:19 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K1DO92SQXS000BMP@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 19 Mar 2001 11:34:39 EST Received: from localhost (bnb@localhost) by ams.org (8.11.2/8.11.2) with ESMTP id f2JGYL428074; Mon, 19 Mar 2001 11:34:22 -0500 (EST) Date: Mon, 19 Mar 2001 11:34:21 -0500 (EST) From: Barbara Beeton Subject: Re: \xleaders bug in TeX In-reply-to: <15030.8268.80962.856349@isar.informatik.uni-stuttgart.de> To: Karel Skoupy , Bernd Raichle 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 thanks to karel and bernd for the clear description and analysis of areported bug in \xleaders. i have put this onto the queue to be sent to don the next time he requests the collected reports for action. according to his web pages, i am expecting that to happen early in 2002. -- bb 19-Mar-2001 17:11:24-GMT,2434;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id KAA03829 for ; Mon, 19 Mar 2001 10:11:22 -0700 (MST) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f2JHBJV02118 for ; Mon, 19 Mar 2001 12:11:20 -0500 (EST) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K1DPFBQHGW000BRL@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Mon, 19 Mar 2001 12:08:43 EST Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by ams.org (8.11.2/8.11.2) with ESMTP id f2JH8SV01534; Mon, 19 Mar 2001 12:08:29 -0500 (EST) Received: from server-1.pragma-ade.nl (s340-isdn1604.dial.xs4all.nl [194.109.186.68]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA08262; Mon, 19 Mar 2001 18:08:15 +0100 (CET) Received: from laptop-1 (laptop-1.pragma-ade.nl [200.1.1.25]) by server-1.pragma-ade.nl (8.9.3/8.9.3) with SMTP id RAA02280; Mon, 19 Mar 2001 17:51:27 +0100 Date: Mon, 19 Mar 2001 17:46:26 +0100 From: Hans Hagen Subject: Re: \xleaders bug in TeX In-reply-to: X-Sender: hagen@server-1 To: Barbara Beeton Cc: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <3.0.6.32.20010319174626.00974720@server-1> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Content-type: text/plain; charset="us-ascii" References: <15030.8268.80962.856349@isar.informatik.uni-stuttgart.de> At 11:34 AM 3/19/01 -0500, Barbara Beeton wrote: >thanks to karel and bernd for the clear description and analysis of >areported bug in \xleaders. > >i have put this onto the queue to be sent to don the next time he >requests the collected reports for action. according to his web >pages, i am expecting that to happen early in 2002. Then we may cross our fingers that don does not use \xleaders in typesetting taop -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- 8-Apr-2001 10:14:06-GMT,4861;000000000001 Return-Path: Received: from ams.org (sun06.ams.org [130.44.1.6]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id EAA14155 for ; Sun, 8 Apr 2001 04:14:04 -0600 (MDT) Received: from axp14.ams.org (axp14.ams.org [130.44.1.14]) by ams.org (8.11.2/8.11.2) with ESMTP id f38ADKv07347 for ; Sun, 8 Apr 2001 06:13:21 -0400 (EDT) Received: from ams.org (sun06.ams.org) by AXP14.AMS.ORG (PMDF V5.1-12 #D3824) with ESMTP id <01K25ANN7240000HNM@AXP14.AMS.ORG> for Beebe@Math.Utah.edu; Sun, 8 Apr 2001 06:07:41 EDT Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by ams.org (8.11.2/8.11.2) with ESMTP id f38A6sv06643 for ; Sun, 08 Apr 2001 06:06:54 -0400 (EDT) Received: from jon.skorepa.cz (root@ts3-2.dialup.muni.cz [147.251.22.221]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id MAA27282; Sun, 08 Apr 2001 12:07:20 +0200 (MET DST) Received: (from ksk@localhost) by jon.skorepa.cz (8.9.3/8.9.3) id MAA08125; Sun, 08 Apr 2001 12:07:25 +0200 Date: Sun, 08 Apr 2001 12:07:25 +0200 From: Karel Skoupy Subject: 3 bugs in tex.web (documentation part) To: tex-implementors@ams.org Errors-to: tex-implementors-request@ams.org Message-id: <20010408120725.C7787@jon.skorepa.cz> MIME-version: 1.0 X-Mailer: Mutt 1.0.1i Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Dear Colleagues, there is a report of some bugs/typos in tew.web (documentation part). ---------------------------------------------------------------- (1) Module 680, second last line: mark nodes, insert nodes, adjust nodes, ... claims that the types mentioned above cannot appear in a mlists. Mark nodes are created by modules 1097, 1101 and the procedure doesn't depend on current mode. Similarly insert and adjust nodes are created in module 1100 on the end of insert_group and this group is created in 1097, 1099 and is allowed for mmode. See also modules: 730, 761 that the mentioned types are dealt with in mlist_to_hlist. (I guess that the types were not allowed in the past and when that changed the documentation was not updated). ---------------------------------------------------------------- (2) Module 905, 6th line: between `fl' and `y', then m = 2, y = 2, and y1 will ... the statement "y = 2" is not correct. >From 3th line follows that y is not a number (index) but a string (vector) of characters. The last index of the y string is t and the statement should be "t = 2". (Probably a typo but confusing if you want to understand that paragraph). ---------------------------------------------------------------- (3) Module 911, line: qi(2),qi(6):begin cur_r:=rem_byte(q); { |=:. |=:> } there is a dot instead of a comma in the comment. (Simple typo). ---------------------------------------------------------------- The patch is appended on the end of this message. Barbara, I announced you 4 bugs but when checking the latest tex.web on CTAN I realized that one of them was already corrected. Best regards, --ksk ---------------------------------------------------------------- --- tex.web Thu Aug 10 07:01:14 2000 +++ tex.web.corrected Sun Apr 8 11:10:26 2001 @@ -13309,7 +13309,7 @@ allowed to appear in mlists together with the noads; \TeX\ tells the difference by means of the |type| field, since a noad's |type| is always greater than that of a node. An mlist does not contain character nodes, hlist nodes, vlist -nodes, math nodes, ligature nodes, mark nodes, insert nodes, adjust nodes, +nodes, math nodes, ligature nodes, or unset nodes; in particular, each mlist item appears in the variable-size part of |mem|, so the |type| field is always present. @@ -17697,7 +17697,7 @@ where $y_1\ldots y_t$ is some nonempty sequence of character, ligature, and kern nodes. We call $x_j\ldots x_m$ a ``cut prefix'' of $x_j\ldots x_n$. For example, if $x_1x_2x_3=\.{fly}$, and if the font contains `fl' as a -ligature and a kern between `fl' and `y', then $m=2$, $y=2$, and $y_1$ will +ligature and a kern between `fl' and `y', then $m=2$, $t=2$, and $y_1$ will be a ligature node for `fl' followed by an appropriate kern node~$y_2$. In the most common case, $x_j$~forms no ligature with $x_{j+1}$ and we simply have $m=j$, $y_1=x_j$. If $m}} ligature_present:=true; end; -qi(2),qi(6):begin cur_r:=rem_byte(q); {\.{\?=:}. \.{\?=:>}} +qi(2),qi(6):begin cur_r:=rem_byte(q); {\.{\?=:}, \.{\?=:>}} if lig_stack>null then character(lig_stack):=cur_r else begin lig_stack:=new_lig_item(cur_r); if j=n then bchar:=non_char