From igor.liferenko at gmail.com Sun Apr 5 15:25:30 2020 From: igor.liferenko at gmail.com (Igor Liferenko) Date: Sun, 5 Apr 2020 20:25:30 +0700 Subject: [tex-k] dvips error: shell command execution in \special fails for metapost labels Message-ID: Hi, The following commands result to a failure (see attachments): mpost test tex test dvips -R0 test ps2pdf test.ps But if we change psfile="`cat test.1" into psfile="test.1" OR if we do not use label(btex hello etex, origin); then all is OK. -Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: test.mp Type: application/octet-stream Size: 86 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tex Type: application/x-tex Size: 76 bytes Desc: not available URL: From zlogene at gentoo.org Sun Apr 5 21:53:49 2020 From: zlogene at gentoo.org (Mikle Kolyada) Date: Sun, 5 Apr 2020 22:53:49 +0300 Subject: [tex-k] poppler-0.87 compatibility problem Message-ID: <34b3aa2c-9012-adc3-5532-8b3495f5a14d@gentoo.org> Hello, in Gentoo we have received a bug referenced at [1]. Would be nice to have the fix included before texlive-2020. Thanks in advance! [1] - https://bugs.gentoo.org/716344 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From norbert at preining.info Sun Apr 5 21:59:55 2020 From: norbert at preining.info (Norbert Preining) Date: Mon, 6 Apr 2020 04:59:55 +0900 Subject: [tex-k] poppler-0.87 compatibility problem In-Reply-To: <34b3aa2c-9012-adc3-5532-8b3495f5a14d@gentoo.org> References: <34b3aa2c-9012-adc3-5532-8b3495f5a14d@gentoo.org> Message-ID: <20200405195955.GC95479@burischnitzel.preining.info> Hi Mikle, On Sun, 05 Apr 2020, Mikle Kolyada wrote: > Hello, in Gentoo we have received a bug referenced at [1]. > Would be nice to have the fix included before texlive-2020. Sorry, that will not work out, the sources of TL are frozen since long, and we are testing already the ISO images. We will see whether this can be fixed after release in the sources, but that leaves gentoo (and all other dists) with the need to patch the sources. Now, if poppler would be come adult at some point and stop breaking everything in practically each release, that would be the best ... Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From kakuto at w32tex.org Mon Apr 6 00:11:37 2020 From: kakuto at w32tex.org (Akira Kakuto) Date: Mon, 6 Apr 2020 07:11:37 +0900 Subject: [tex-k] poppler-0.87 compatibility problem In-Reply-To: <20200405195955.GC95479@burischnitzel.preining.info> References: <34b3aa2c-9012-adc3-5532-8b3495f5a14d@gentoo.org> <20200405195955.GC95479@burischnitzel.preining.info> Message-ID: <77C115DA9C584EF89E2260EB32E9AC26@CJ3001517A> > On Sun, 05 Apr 2020, Mikle Kolyada wrote: >> Hello, in Gentoo we have received a bug referenced at [1]. >> Would be nice to have the fix included before texlive-2020. > > Sorry, that will not work out, the sources of TL are frozen since long, > and we are testing already the ISO images. In the sources in TeX Live 2020, system poppler 0.87.0 is already supported: cp pdftosrc-poppler0.83.0.cc pdftosrc.cc cp pdftoepdf-poppler0.86.0.cc pdftoepdf.cc before compilation. Best, Akira From zlogene at gentoo.org Mon Apr 6 09:00:06 2020 From: zlogene at gentoo.org (Mikle Kolyada) Date: Mon, 6 Apr 2020 10:00:06 +0300 Subject: [tex-k] poppler-0.87 compatibility problem In-Reply-To: <77C115DA9C584EF89E2260EB32E9AC26@CJ3001517A> References: <34b3aa2c-9012-adc3-5532-8b3495f5a14d@gentoo.org> <20200405195955.GC95479@burischnitzel.preining.info> <77C115DA9C584EF89E2260EB32E9AC26@CJ3001517A> Message-ID: On 06.04.2020 01:11, Akira Kakuto wrote: >> On Sun, 05 Apr 2020, Mikle Kolyada wrote: >>> Hello, in Gentoo we have received a bug referenced at [1]. >>> Would be nice to have the fix included before texlive-2020. >> >> Sorry, that will not work out, the sources of TL are frozen since long, >> and we are testing already the ISO images. > > In the sources in TeX Live 2020, system poppler 0.87.0 is > already supported: > > cp pdftosrc-poppler0.83.0.cc pdftosrc.cc > cp pdftoepdf-poppler0.86.0.cc pdftoepdf.cc > > before compilation. > > Best, > Akira > Hello Akira, This was indeed false alarm. The patch I made for poppler-0.86 also applies to poppler-0.87 Thank you and Norbert for quick response! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From igor.liferenko at gmail.com Mon Apr 6 10:30:42 2020 From: igor.liferenko at gmail.com (Igor Liferenko) Date: Mon, 6 Apr 2020 15:30:42 +0700 Subject: [tex-k] Issue with formatting of comment in TeXbook In-Reply-To: <202003272243.02RMhigk017943@freefriends.org> References: <202003272243.02RMhigk017943@freefriends.org> Message-ID: Hi Karl, > I think Knuth is just saving a line in the output. This page has lots of empty space in the bottom so it is not the reason, IMHO. The code looks much better with the following change to tex.web: @x {now pull out all the stops: try for the system \.{plain} file} @y @/@t\4@>{now pull out all the stops: try for the system \.{plain} file} @z Igor From igor.liferenko at gmail.com Mon Apr 6 15:02:43 2020 From: igor.liferenko at gmail.com (Igor Liferenko) Date: Mon, 6 Apr 2020 20:02:43 +0700 Subject: [tex-k] dvips error: psfile name is ignored if it begins with non-ascii character Message-ID: Hi, Run the following commands (see attachment): tex -ini -enc x.ini tex -fmt x x dvips x The output is dvips: Could not find figure file .1; continuing. If we put an ascii character after `psfile=', like `./', then output is dvips: Could not find figure file ./?.1; continuing. Is this a feature or a bug? Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: x.ini Type: application/octet-stream Size: 90 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: x.tex Type: application/x-tex Size: 33 bytes Desc: not available URL: From kakuto at w32tex.org Mon Apr 6 16:48:29 2020 From: kakuto at w32tex.org (Akira Kakuto) Date: Mon, 6 Apr 2020 23:48:29 +0900 Subject: [tex-k] dvips error: psfile name is ignored if it begins withnon-ascii character In-Reply-To: References: Message-ID: <750AB87B2FB84BB5B199630B7BAAD7B3@CJ3001517A> Dear Igor, Thanks for the report. I find that \special{psfile=non-ascii-name} becomes allowed by --- dospecial.c.orig Fri Apr 05 07:03:56 2019 +++ dospecial.c Mon Apr 06 23:25:34 2020 @@ -286,7 +286,7 @@ /* str : starting point for scan */ /* tno : table entry number of keyword, or -1 if keyword not found */ { - register char *s; + unsigned char *s; register int i; register char t; I'll apply the above patch after the release of TL2020. Best, Akira From 2500418497 at qq.com Mon Apr 13 18:51:10 2020 From: 2500418497 at qq.com (=?ISO-8859-1?B?ZGluZQ==?=) Date: Tue, 14 Apr 2020 00:51:10 +0800 Subject: [tex-k] ambiguous paragraph in The METAFONTbook Message-ID: The third paragraph on page 167 of The METAFONTbook is potentially ambiguous. It first speaks of "the longest syntactically correct From karl at freefriends.org Tue Apr 14 00:58:27 2020 From: karl at freefriends.org (Karl Berry) Date: Mon, 13 Apr 2020 16:58:27 -0600 Subject: [tex-k] ambiguous paragraph in The METAFONTbook In-Reply-To: Message-ID: <202004132258.03DMwRRX031466@freefriends.org> no reason not to apply the same treatment to " of " Thanks for the report. Sounds plausible. --best, karl. From doug at mathemaesthetics.com Tue Apr 21 00:55:28 2020 From: doug at mathemaesthetics.com (Doug McKenna) Date: Mon, 20 Apr 2020 16:55:28 -0600 (MDT) Subject: [tex-k] Minor issues in TANGLE and WEAVE Message-ID: <805482297.59255444.1587423328287.JavaMail.zimbra@mathemaesthetics.com> Two things I've found spending too much time with the source code for tangle.web and weave.web. ========== 1. In tangle.web (version 4.5), in section 72 of the woven PDF or on or around lines 1313--1314 of the WEB file, it is stated that the WEB command @= initiates a "verbatim" Pascal string. It then says with respect to @=, "It is also used for the end of the string." But later on, in section 169 or on or about line 3052 in the WEB file, the terminating delimiter being looked for is @>, not @=. Furthermore, weave.web in section 107, also looks for @> as the terminator for the @= verbatim string command. All of which makes sense, because @> is the terminating delimiter for a bunch of similar WEB commands. The CWEB manual says that @= is just another "control text" and all such control texts are terminated by @>. So I'd say the sentence on line 1314 in tangle.web is incorrect. ========== 2. In weave.web (version 4.4), a numeric macro @d in_like=15 {\&{in}} is defined in section 42 (on or about line 820), allegedly to represent the Pascal "in" keyword. But a few lines below, the numeric macro @d char_like=24 {\&{and}, \&{or}, \&{not}, \&{in}} is defined, and the comment for it says that it will be used also for the Pascal "in" keyword (and indeed later on it is). The macro identifier "in_like" is actually never used anywhere else in the program. So I'd say the definition of "in_like" should be removed, with appropriate renumbering of the remaining numeric macros. Or keep the same numbers, with a comment explaining the gap at 15. Or am I missing something? Doug McKenna From 2500418497 at qq.com Tue Apr 21 11:48:04 2020 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Tue, 21 Apr 2020 17:48:04 +0800 Subject: [tex-k] extra left parenthesis in "METAFONT: The Program" Message-ID: Section 107 of "METAFONT: The Program" contains the pseudo-Pascal fragment "((2^29*p+q) div (2*q)" which has an extra left parenthesis. Is this a typo or a wabi-sabi? (Sorry if it's already been reported.) From karl at freefriends.org Wed Apr 22 00:15:57 2020 From: karl at freefriends.org (Karl Berry) Date: Tue, 21 Apr 2020 16:15:57 -0600 Subject: [tex-k] extra left parenthesis in "METAFONT: The Program" In-Reply-To: Message-ID: <202004212215.03LMFvp6007875@freefriends.org> Hi again Hu, Section 107 of "METAFONT: The Program" contains the pseudo-Pascal fragment "((2^29*p+q) div (2*q)" which has an extra left parenthesis. Is this a typo or a wabi-sabi? It's a bug, but it was already fixed in 2002 (errata.tex, line 977), and the current printing of volume D doesn't contain it. (Sorry if it's already been reported.) Please check the errata files if you can. I know they are not the easiest thing to search through, but they're what we've got ... https://ctan.org/pkg/knuth-errata In any case, thanks for the report. --best, karl. From karl at freefriends.org Wed Apr 22 00:40:19 2020 From: karl at freefriends.org (Karl Berry) Date: Tue, 21 Apr 2020 16:40:19 -0600 Subject: [tex-k] Minor issues in TANGLE and WEAVE In-Reply-To: <805482297.59255444.1587423328287.JavaMail.zimbra@mathemaesthetics.com> Message-ID: <202004212240.03LMeJjS008777@freefriends.org> Hi Doug, on or around lines 1313--1314 of the WEB file, it is stated that the WEB command @= initiates a "verbatim" Pascal string. It then says with respect to @=, "It is also used for the end of the string." I believe the "It" in "It is also used for the end of the string." is referring to the `verbatim' symbolic name (what this is a list of), rather than the @= code that terminates the verbatim string in the input .web file. Looking at the module starting at line 3036 @ @= it ends with a comment end {another |verbatim| byte will be stored, since |a=verbatim|} I can't say I see offhand how "another" |verbatim| byte gets stored, but I get the sense that the verbatim code byte is marking the end of the string (in the representation) as well as the beginning, as the original comment can be interpreted as saying. Maybe the app_repl call is inserting the (end-)verbatim? Not sure. Or maybe I'm totally off. Anyway, if this is the intent, the text could be clarified to say "The |verbatim| code is also used" instead of "It". Wdyt? [weave.web] @d in_like=15 {\&{in}} I concur that in_like is not used anywhere in weave.web that I can see either, and should be removed. Will check with others ... --thanks, karl. From shreevatsa.public at gmail.com Wed Apr 22 01:57:14 2020 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Tue, 21 Apr 2020 16:57:14 -0700 Subject: [tex-k] extra left parenthesis in "METAFONT: The Program" In-Reply-To: <202004212215.03LMFvp6007875@freefriends.org> References: <202004212215.03LMFvp6007875@freefriends.org> Message-ID: On Tue, 21 Apr 2020 at 15:16, Karl Berry wrote: > Hi again Hu, > > Section 107 of "METAFONT: The Program" contains the pseudo-Pascal > fragment "((2^29*p+q) div (2*q)" which has an extra left > parenthesis. Is this a typo or a wabi-sabi? > > It's a bug, but it was already fixed in 2002 (errata.tex, line 977), > and the current printing of volume D doesn't contain it. > > (Sorry if it's already been reported.) > > Please check the errata files if you can. I know they are not the > easiest thing to search through, but they're what we've got ... > https://ctan.org/pkg/knuth-errata > > In any case, thanks for the report. --best, karl. > For what it's worth -- Knuth's webpage at https://cs.stanford.edu/~knuth/abcde.html links to a PDF of errata since 2001, in which this one is mentioned: https://cs.stanford.edu/~knuth/abcde-errata.pdf#page=13 (see under "page D42"). But the PDF file shown by `texdoc mf` (for me /usr/local/texlive/2020/texmf-dist/doc/generic/knuth/mf/mf.pdf) and mf.web still seem to contain the typo -- probably should be fixed there as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at mathemaesthetics.com Wed Apr 22 03:43:16 2020 From: doug at mathemaesthetics.com (Doug McKenna) Date: Tue, 21 Apr 2020 19:43:16 -0600 (MDT) Subject: [tex-k] Minor issues in TANGLE and WEAVE In-Reply-To: <202004212240.03LMeJjS008777@freefriends.org> References: <202004212240.03LMeJjS008777@freefriends.org> Message-ID: <93454735.59905910.1587519796743.JavaMail.zimbra@mathemaesthetics.com> Karl - The single best interpretation of "It is also used for the end of the string." is that "It" (whatever "it" is) is referring to a delimiter, in particular the string's terminating delimiter, of which there has to be one for the @= construction, where @= is the initiating delimiter for something in need of termination. Every neuron in my coding brain is saying that the original quoting mechanism was, @= foobar @=, but that a decision was later made to conform the syntax to that of other control texts, all of which are delimited at their ends with @>. So I'm guessing the comment wasn't updated, as regularly happens in every programmer's code (even the best!). In any case, whatever "it" is, "it" is ambiguous. Glad to hear of agreement with the "in_like" thing. Oh, and I found a typo in weave.web that's easy to fix: search for "find to find" and change it to "try to find". On or about line 2456. Doug McKenna ----- Original Message ----- From: "Karl Berry" To: "doug" Cc: "tex-k" Sent: Tuesday, April 21, 2020 4:40:19 PM Subject: Re: [tex-k] Minor issues in TANGLE and WEAVE Hi Doug, on or around lines 1313--1314 of the WEB file, it is stated that the WEB command @= initiates a "verbatim" Pascal string. It then says with respect to @=, "It is also used for the end of the string." I believe the "It" in "It is also used for the end of the string." is referring to the `verbatim' symbolic name (what this is a list of), rather than the @= code that terminates the verbatim string in the input .web file. Looking at the module starting at line 3036 @ @= it ends with a comment end {another |verbatim| byte will be stored, since |a=verbatim|} I can't say I see offhand how "another" |verbatim| byte gets stored, but I get the sense that the verbatim code byte is marking the end of the string (in the representation) as well as the beginning, as the original comment can be interpreted as saying. Maybe the app_repl call is inserting the (end-)verbatim? Not sure. Or maybe I'm totally off. Anyway, if this is the intent, the text could be clarified to say "The |verbatim| code is also used" instead of "It". Wdyt? [weave.web] @d in_like=15 {\&{in}} I concur that in_like is not used anywhere in weave.web that I can see either, and should be removed. Will check with others ... --thanks, karl. From 2500418497 at qq.com Wed Apr 22 11:45:06 2020 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Wed, 22 Apr 2020 17:45:06 +0800 Subject: [tex-k] duplicated words in "METAFONT: The Program" Message-ID: The latest version of mf.web contains some duplicate words, namely `the the $\log n$ factor' in line 7076 (section 323) and `to to vertex~|r|' in lines 11420--11421 (section 534). Again I'm not sure if this has been reported, but Knuth's errata files don't help, since they're last updated January 2014. Is there a list of bugs reported since 2014? (I did skim through the tex-k archive, and no posts after 2014 seem to mention the typos, but potential finders may have sent reports somewhere else like privately to karl.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Thu Apr 23 00:46:28 2020 From: karl at freefriends.org (Karl Berry) Date: Wed, 22 Apr 2020 16:46:28 -0600 Subject: [tex-k] duplicated words in "METAFONT: The Program" In-Reply-To: Message-ID: <202004222246.03MMkSIk001624@freefriends.org> The latest version of mf.web contains some duplicate words, Thanks. but Knuth's errata files don't help, since they're last updated January 2014. Not in this case, but many bugs are found when looking at older files or books, which is when the errata files might have them. Is there a list of bugs reported since 2014? No. (I did skim through the tex-k archive, and no posts after 2014 seem to mention the typos, Thank you for your efforts. More cannot be asked :). (Also thanks for the report you sent to me separately.) --karl From karl at freefriends.org Thu Apr 23 00:46:38 2020 From: karl at freefriends.org (Karl Berry) Date: Wed, 22 Apr 2020 16:46:38 -0600 Subject: [tex-k] extra left parenthesis in "METAFONT: The Program" In-Reply-To: Message-ID: <202004222246.03MMkcdq001709@freefriends.org> But the PDF file shown by `texdoc mf` (for me /usr/local/texlive/2020/texmf-dist/doc/generic/knuth/mf/mf.pdf) and mf.web still seem to contain the typo Wow, that is scary. I will report. Thanks. -k From 2500418497 at qq.com Thu Apr 30 05:51:15 2020 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Thu, 30 Apr 2020 11:51:15 +0800 Subject: [tex-k] Fw:spacing-related typo in "The METAFONTbook" Message-ID: Reposting it here. ------------------ Original ------------------ From: "??? (Hu Yajie)"<2500418497 at qq.com>; Date: Wed, Apr 22, 2020 08:18 PM To: "Karl&nbsp;Berry" From 2500418497 at qq.com Thu Apr 30 06:30:40 2020 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Thu, 30 Apr 2020 12:30:40 +0800 Subject: [tex-k] Additional duplicated words in Knuthware Message-ID: dvitype.web, lines 2268-9 @ Note that the last steps of the above code save the locations of the the |post| byte and the final |bop|.  We had better declare these global pltotf.web, line 431; vptovf.web, line 478 a blank space of width $r$ between the current character character and $c$; -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2500418497 at qq.com Thu Apr 30 08:47:39 2020 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Thu, 30 Apr 2020 14:47:39 +0800 Subject: [tex-k] one more duplicated word in webman.tex Message-ID: Lines 1593--4 of webman.tex duplicate the word "that". Sorry for failing to catch this. (If you have Linux, you may want to grep knuth-dist for more typos of this kind, something I'm unable to do on my Windows machine.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From salexander19 at gwmail.gwu.edu Thu Apr 30 15:26:24 2020 From: salexander19 at gwmail.gwu.edu (Spencer Alexander) Date: Thu, 30 Apr 2020 15:26:24 +0200 Subject: [tex-k] cwebman bugs Message-ID: Hello, (1) Even if I say ./wmerge common.w comm-man.ch common.out cweave common.out pdftex common.tex page 28 prints at the end instead of at the beginning. (I attach the .pdf for reference. `make fullmanual? does the same using cweave instead of wmerge.) It also happens for the ctangle- and cweave appendices, and it happens regardless of whether the .pdf is written directly or via dvi. (2) cwebmac.tex points to ftp.cs.stanford.edu/pub/ctwill but that folder doesn?t exist. (Could you tell me where it lives now? I know of Andreas Scherer?s copy.) Cheers, Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: common.pdf Type: application/pdf Size: 331774 bytes Desc: not available URL: From andreas_tex at freenet.de Thu Apr 30 20:02:29 2020 From: andreas_tex at freenet.de (Andreas Scherer) Date: Thu, 30 Apr 2020 20:02:29 +0200 Subject: [tex-k] cwebman bugs Message-ID: <687d694c-be69-6c31-2a85-ef8570331c21@freenet.de> Dear Spencer, (1) According to "point 9" on page 25 of 'cwebman.pdf', "Data for the table of contents is written to a file that is read **after** the indexes have been \TEX/ed", so this is fully intended. You can (and have to) put the toc-pages up front manually. (2) ftp.cs.stanford.edu/pub/ctwill does exist: drwxr-xr-x 2 ftp users 2048 May 10 2000 ctwill but there seems to be a configuration glitch on the FTP server at Stanford that prohibits access to this subdirectory (both via your web browser and via a simple ftp prompt). I never bothered to contact DEK or the LaBrea admins about this. (A while ago, a similar problem temporarily existed for CWEB itself, but that was fixed.) I can only promise that https://github.com/ascherer/ctwill does in fact hold the pristine contents of CTWILL version 3.61 of 2000. However, I invested quite some time and effort to upgrade CTWILL to the current CWEB 3.64b via https://github.com/ascherer/ctwill/tree/local and more recently https://github.com/ascherer/cwebbin -- the former *.diffs files were reprocessed into genuine change files that smoothly upgrade CTWILL to current CWEB and integrate it into TeX Live (2019 and up). Feel free to test this modernized CTWILL and report problems with it to this list (or my Github project(s)). Cheers, Andreas