From karl at freefriends.org  Tue Jun  1 00:00:24 2021
From: karl at freefriends.org (Karl Berry)
Date: Mon, 31 May 2021 16:00:24 -0600
Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines
In-Reply-To: <20210530232821.z01zlnarH%rdtennent@gmail.com>
Message-ID: <202105312200.14VM0OPr024125@freefriends.org>

    Perhaps dvipdfmx.1 should be revised:

       For the version in TeX Live, all bugs and other reports
       should go to the dvipdfmx maintainers at tex-k (at) tug.org.

Indeed. Updated, committed ... --thanks, karl.

From rdtennent at gmail.com  Tue Jun  1 04:02:52 2021
From: rdtennent at gmail.com (Bob Tennent)
Date: Mon, 31 May 2021 22:02:52 -0400
Subject: [tex-k] [dvipdfmx] dvipdfm[x] problem with dashed horizontal
 lines
In-Reply-To: <20210531211420.uXIMDvayG%rdt@cs.queensu.ca>
References: <20210531211420.uXIMDvayG%rdt@cs.queensu.ca>
Message-ID: <20210601020252.jg1ihrAKC%rdt@cs.queensu.ca>

 >|I'm trying to force dvipdfmx to use bitmapped musixtex
 >|fonts (to avoid "Intolerable difference in glyph width"
 >|issues). I've disabled musix.map and the musixtex fonts
 >|do not appear in pdftex.map. Then dvipdfmx -v output
 >|includes
 >|
 >|  <musixspx at 19.93pt(TFM:musixspx)
 >|  pdf_font>> Simple font "musixspx" enc_id=<builtin,-1>
 >|  font_id=<musixspx,1>.
 >|
 >|yet the type1 versions are still appearing in the pdf.
 >|How do I force dvipdfmx to ignore the type1 fonts and use
 >|glyph widths from the tfm files (and presumably embed
 >|type3 bitmapped fonts)?

I've figured out how to do this: uninstall the system-wide
musixtex-fonts package, install a personal musixtex-fonts
package and *remove the type1 fonts*. Then dvipdfmx is
forced to use glyph widths from the tfm and the problematic
horizontal dashed lines are gone.

I've been told that it is "wrong" for dvipdfmx to use tfm
widths rather than pfb widths, and maybe that's true if the
pfbs are going to be used, but in my opinion it is a *bug*
to use pfbs that the user has explicitly chosen not to use.

Please fix this. 

Bob T.

From 2500418497 at qq.com  Tue Jun  1 05:26:10 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Tue, 1 Jun 2021 11:26:10 +0800
Subject: [tex-k] typo in LuaTeX reference manual
Message-ID: <tencent_A226497032D01AD95F8D53E7C62AAA4D2005@qq.com>

luatex-math.tex, line 1591:
    properties. Ther eis currently only one option:

"Ther eis" should be "There is".


From 2500418497 at qq.com  Tue Jun  1 15:32:17 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Tue, 1 Jun 2021 21:32:17 +0800
Subject: [tex-k] tangle.web: '.' -> `.'
Message-ID: <tencent_E4F5C9156B72FF17CE811BA9283F01EEA407@qq.com>

tangle.web, line 640 (section 31, the first Pascal comment):
    procedure error; {prints '\..' and location of error message}
should be
    procedure error; {prints `\..' and location of error message}

(Interestingly, the same typo has been fixed in weave.web.)




To karl: you might also want to change newbug.html, line 200
    <a href="/pipermail/tex-k/2021-May/03560.html"
to
    <a href="/pipermail/tex-k/2021-May/003560.html"


From shunsaku.hirata74 at gmail.com  Tue Jun  1 16:12:19 2021
From: shunsaku.hirata74 at gmail.com (Shunsaku Hirata)
Date: Tue, 1 Jun 2021 23:12:19 +0900
Subject: [tex-k] [dvipdfmx] dvipdfm[x] problem with dashed horizontal
	lines
In-Reply-To: <20210601020252.jg1ihrAKC%rdt@cs.queensu.ca>
References: <20210531211420.uXIMDvayG%rdt@cs.queensu.ca>
 <20210601020252.jg1ihrAKC%rdt@cs.queensu.ca>
Message-ID: <CAOyMh2pw7M9NoauhxFO0C_qgO=fV7zhbUzCmJdAVLj-5A6PG-A@mail.gmail.com>

Actually it is possible to have an option to recover the old
behavior (use TFM data for font dictionary's Width entry
which might be different from that of embedded font file),
however, by doing so it results in dvipdfmx to generate
PDF files which are not compliant to the PDF spec.

> I've been told that it is "wrong" for dvipdfmx to use tfm
> widths rather than pfb widths, and maybe that's true if the
> pfbs are going to be used, but in my opinion it is a *bug*
> to use pfbs that the user has explicitly chosen not to use.
>
> Please fix this.

Dvipdfmx does not provide a way to explicitly specify
which font format to use. But you may use a pk font by
explicitly specifying the file name including the extension.
For example,

    \special{pdf:mapline musixspx none musixspx.600pk}


Thanks,
Shunsaku Hirata

From rdtennent at gmail.com  Tue Jun  1 16:44:42 2021
From: rdtennent at gmail.com (Bob Tennent)
Date: Tue, 01 Jun 2021 10:44:42 -0400
Subject: [tex-k] [dvipdfmx] dvipdfm[x] problem with dashed horizontal
 lines
In-Reply-To: <CAOyMh2pw7M9NoauhxFO0C_qgO=fV7zhbUzCmJdAVLj-5A6PG-A@mail.gmail.com>
References: <20210531211420.uXIMDvayG%rdt@cs.queensu.ca>
 <20210601020252.jg1ihrAKC%rdt@cs.queensu.ca>
 <CAOyMh2pw7M9NoauhxFO0C_qgO=fV7zhbUzCmJdAVLj-5A6PG-A@mail.gmail.com>
Message-ID: <20210601144442.PsXRHEbEr%rdtennent@gmail.com>

 >|Actually it is possible to have an option to recover the
 >|old behavior (use TFM data for font dictionary's Width
 >|entry which might be different from that of embedded font
 >|file), however, by doing so it results in dvipdfmx to
 >|generate PDF files which are not compliant to the PDF
 >|spec.

Takanori Uchiyama, the developer of the type1 musixtex-fonts
has emerged and has regenerated the fonts to correct all the
inconsistent glyph widths. They're currently being tested.

 >|> I've been told that it is "wrong" for dvipdfmx to use
 >|> tfm widths rather than pfb widths, and maybe that's
 >|> true if the pfbs are going to be used, but in my
 >|> opinion it is a *bug* to use pfbs that the user has
 >|> explicitly chosen not to use.
 >|>
 >|> Please fix this.
 >|
 >|Dvipdfmx does not provide a way to explicitly specify
 >|which font format to use. But you may use a pk font
 >|by explicitly specifying the file name including the
 >|extension. For example,
 >|
 >|    \special{pdf:mapline musixspx none musixspx.600pk}

This approach would require some 79 specials! dvipdfmx
certainly uses the pk format if it can't find type1 files.
I wasn't asking for an option or a clumsy way to specify
the format. I was asking that dvipdfmx *automatically*
refrain from using type1 fonts that the user has explicitly
disabled.

Best,
Bob T.

From karl at freefriends.org  Wed Jun  2 00:56:18 2021
From: karl at freefriends.org (Karl Berry)
Date: Tue, 1 Jun 2021 16:56:18 -0600
Subject: [tex-k] typo in LuaTeX reference manual
In-Reply-To: <tencent_A226497032D01AD95F8D53E7C62AAA4D2005@qq.com>
Message-ID: <202106012256.151MuIDW010458@freefriends.org>

    Subject: [tex-k] typo in LuaTeX reference manual

Please report LuaTeX bugs to dev-luatex at ntg.nl. The LuaTeX maintainers
are not on tex-k. --thanks, karl.

From shunsaku.hirata74 at gmail.com  Wed Jun  2 01:33:16 2021
From: shunsaku.hirata74 at gmail.com (Shunsaku Hirata)
Date: Wed, 2 Jun 2021 08:33:16 +0900
Subject: [tex-k] [dvipdfmx] dvipdfm[x] problem with dashed horizontal
	lines
In-Reply-To: <20210601144442.PsXRHEbEr%rdtennent@gmail.com>
References: <20210601144442.PsXRHEbEr%rdtennent@gmail.com>
Message-ID: <5CA70585-282B-438F-8021-2F868045096C@gmail.com>


>> |Dvipdfmx does not provide a way to explicitly specify
>> |which font format to use. But you may use a pk font
>> |by explicitly specifying the file name including the
>> |extension. For example,
>> |
>> |    \special{pdf:mapline musixspx none musixspx.600pk}
> 
> This approach would require some 79 specials! dvipdfmx
> certainly uses the pk format if it can't find type1 files.
> I wasn't asking for an option or a clumsy way to specify
> the format.

This is just an example to see what will happen.
You can write the above mappings in map files too. This is usual way to specify the font.

Shunsaku Hirata



From shunsaku.hirata74 at gmail.com  Wed Jun  2 10:55:12 2021
From: shunsaku.hirata74 at gmail.com (Shunsaku Hirata)
Date: Wed, 2 Jun 2021 17:55:12 +0900
Subject: [tex-k] [dvipdfmx] dvipdfm[x] problem with dashed horizontal
	lines
In-Reply-To: <20210601020252.jg1ihrAKC%rdt@cs.queensu.ca>
References: <20210601020252.jg1ihrAKC%rdt@cs.queensu.ca>
Message-ID: <BD457209-A8D1-42E3-813D-32B3D46891E4@gmail.com>

I am not sure what you mean here though...

The absence of font mapping definition does not mean that dvipdfmx uses PK fonts, but rather, it means default settings (for the encoding and options) to be used for that font. 

This behavior is the same as the original dvipdfm (without "x") and can't be changed.


Shunsaku Hirata

> 2021/06/01 11:03?Bob Tennent <rdtennent at gmail.com>????:
> 
> ?
>> 
>> |I'm trying to force dvipdfmx to use bitmapped musixtex
>> |fonts (to avoid "Intolerable difference in glyph width"
>> |issues). I've disabled musix.map and the musixtex fonts
>> |do not appear in pdftex.map. Then dvipdfmx -v output
>> |includes
>> |
>> |  <musixspx at 19.93pt(TFM:musixspx)
>> |  pdf_font>> Simple font "musixspx" enc_id=<builtin,-1>
>> |  font_id=<musixspx,1>.
>> |
>> |yet the type1 versions are still appearing in the pdf.
>> |How do I force dvipdfmx to ignore the type1 fonts and use
>> |glyph widths from the tfm files (and presumably embed
>> |type3 bitmapped fonts)?
> 
> I've figured out how to do this: uninstall the system-wide
> musixtex-fonts package, install a personal musixtex-fonts
> package and *remove the type1 fonts*. Then dvipdfmx is
> forced to use glyph widths from the tfm and the problematic
> horizontal dashed lines are gone.
> 
> I've been told that it is "wrong" for dvipdfmx to use tfm
> widths rather than pfb widths, and maybe that's true if the
> pfbs are going to be used, but in my opinion it is a *bug*
> to use pfbs that the user has explicitly chosen not to use.
> 
> Please fix this. 
> 
> Bob T.


From 2500418497 at qq.com  Wed Jun  2 18:57:55 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Thu, 3 Jun 2021 00:57:55 +0800
Subject: [tex-k] bug in mf.web?
Message-ID: <tencent_774DFE679CC73710510E0217492F9342D608@qq.com>

I wonder if this is a bug in mf.web: module 37 says that "we access the
string pool only via" si and so, which convert between ASCII characters
(0..255) and their internal representations in the string pool (either
0..255 or -128..127). However, the function str_vs_str of module 46
fails to do so and fetches characters from the string pool directly, so
it compares not the ASCII codes but their internal representations.

This is harmless if the internal representation is also 0..255, or if
it is -128..127 by shifting the whole range by 128 (since the relative
order of characters will be preserved); but if it is -128..127 using
two's complement, the function may return wrong results.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mfbug.png
Type: application/octet-stream
Size: 194209 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20210603/1ff27446/attachment-0001.obj>

From don.hosek at gmail.com  Wed Jun  2 21:42:08 2021
From: don.hosek at gmail.com (Don Hosek)
Date: Wed, 2 Jun 2021 14:42:08 -0500
Subject: [tex-k] bug in mf.web?
In-Reply-To: <tencent_774DFE679CC73710510E0217492F9342D608@qq.com>
References: <tencent_774DFE679CC73710510E0217492F9342D608@qq.com>
Message-ID: <15C0895A-4AEA-4BDA-BD5B-54E4E129EA38@gmail.com>

I think you?re misinterpretting what Knuth says about packed_ASCII_code. He?s not allowing for negative values for ASCII codes in the comments, but rather working around the fact that for some Pascal compilers only allow for a signed 8-bit data type.

So ASCII_code must always be in the range 0..255. If the compiler doesn?t have an unsigned 8-bit data type, then the macros si and so must be defined to translate ASCII_code into a packed_ASCII_code. Simply copying an 8-bit unsigned value into an 8-bit signed field does not meet the requirements and would be a bug in the change file. There?s no real advantage to doing something different from 
  si(#) ? #-128
  si($) ? #+128
your code would run slower and require other changes as you?ve noted.

(and man, it?s been a long time since I dug into this level of Pascal code?I think the last Pascal program I wrote was ca 1991.)

> On 2 Jun 2021, at 11:57, ??? (Hu Yajie) <2500418497 at qq.com> wrote:
> 
> I wonder if this is a bug in mf.web: module 37 says that "we access the
> string pool only via" si and so, which convert between ASCII characters
> (0..255) and their internal representations in the string pool (either
> 0..255 or -128..127). However, the function str_vs_str of module 46
> fails to do so and fetches characters from the string pool directly, so
> it compares not the ASCII codes but their internal representations.
> 
> This is harmless if the internal representation is also 0..255, or if
> it is -128..127 by shifting the whole range by 128 (since the relative
> order of characters will be preserved); but if it is -128..127 using
> two's complement, the function may return wrong results.<mfbug.png>



From karl at freefriends.org  Thu Jun  3 23:31:13 2021
From: karl at freefriends.org (Karl Berry)
Date: Thu, 3 Jun 2021 15:31:13 -0600
Subject: [tex-k] tangle.web: '.' -> `.'
In-Reply-To: <tencent_E4F5C9156B72FF17CE811BA9283F01EEA407@qq.com>
Message-ID: <202106032131.153LVDUY010894@freefriends.org>

    tangle.web, line 640 (section 31, the first Pascal comment):
        procedure error; {prints '\..' and location of error message}
    should be
        procedure error; {prints `\..' and location of error message}

Yep, thanks. Maybe I even got the pipermail link right this time.

    (Interestingly, the same typo has been fixed in weave.web.)

Not the easiest thing to search for, but I didn't find any other
occurrences except in non-Knuth dvicopy.web.

    To karl: you might also want to change newbug.html, line 200
        <a href="/pipermail/tex-k/2021-May/03560.html"
    to
        <a href="/pipermail/tex-k/2021-May/003560.html"

Yep, thanks. -k

From karl at freefriends.org  Fri Jun  4 00:33:43 2021
From: karl at freefriends.org (Karl Berry)
Date: Thu, 3 Jun 2021 16:33:43 -0600
Subject: [tex-k] bug in mf.web?
In-Reply-To: <tencent_774DFE679CC73710510E0217492F9342D608@qq.com>
Message-ID: <202106032233.153MXhrf019029@freefriends.org>

    module 37 says that "we access the string pool only via" si and so,

That does seem like a bug in the text, at least, given the usage in
str_vs_str.

    but if it is -128..127 using two's complement, the function may
    return wrong results.

On the other hand, it seems possible that Knuth would change str_vs_str
to also use si() and so(). It would be up to him. Meanwhile, I think I
agree with Don H that it's up to the implementor to provide code that
does the right thing.

Anyway, I'll put it on the pile. --thanks, karl.

From 2500418497 at qq.com  Sat Jun  5 08:25:06 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Sat, 5 Jun 2021 14:25:06 +0800
Subject: [tex-k] E20, E35
Message-ID: <tencent_CBB3EA86310A51403B296A72DF3ADD3F8F05@qq.com>

Page E20, line 4
Change "Computers and Typesetting" to "Computers & Typesetting".

Page E20, line 12
Change the "in" in "250/36Pt# = 1in#" from roman to text italic?
for consistency with other sharped units.

Page E35, line 5
Change "cmmitt10" to "cmitt10" (cf. page 28).

Page E35, line 10
Change "cmsy12" to "cmbsy10" (cf. pages 32--34).


From 2500418497 at qq.com  Sat Jun  5 09:41:33 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Sat, 5 Jun 2021 15:41:33 +0800
Subject: [tex-k] E20, E35
Message-ID: <tencent_37C5BF8A33E8E62A4A51602F096C72D8DA05@qq.com>

Sorry, the two typos on E35
    cmmitt10 -> cmitt10
    cmsy12 -> cmbsy10
have already been fixed in a later printing.


From 2500418497 at qq.com  Mon Jun  7 14:04:22 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Mon, 7 Jun 2021 20:04:22 +0800
Subject: [tex-k] Volume E, index entry for cmbsy10
Message-ID: <tencent_53319321D605FE5A9C5C3753513302324908@qq.com>

I'm having trouble sending email to karl, so lemme try it here.

Volume E, index entry for cmbsy10 says "34--35", but E35 is a table
of standard font names plus two quotes and doesn't define cmbsy10.
(Have this been fixed in recent printings?)


From naveen at syrusdark.website  Mon Jun  7 20:45:19 2021
From: naveen at syrusdark.website (Naveen M K)
Date: Tue, 8 Jun 2021 00:15:19 +0530
Subject: [tex-k] Patch: Fix spaces in arguments of runscript.exe
Message-ID: <a851bf9b-b24a-4ac0-eeaa-6004e45fa80a@syrusdark.website>

Hi,

I am the maintainer of MSYS2-MINGW TexLive packages, I got a report[0], 
that command line arguments aren't passed correctly to underlying 
scripts. I have come up with a patch for fixing that. I have attached them.

Ciao,
Naveen M K


[0].. https://github.com/msys2/MINGW-packages/issues/8821
-------------- next part --------------
From b58d6e526ca16249dff680811e29ac6c646fa35e Mon Sep 17 00:00:00 2001
From: Naveen M K <naveen at syrusdark.website>
Date: Mon, 7 Jun 2021 23:42:01 +0530
Subject: [PATCH] runscript: always quote args

Signed-off-by: Naveen M K <naveen at syrusdark.website>
---
 .../texlive/w64_mingw_wrapper/runscript_dll.c | 34 ++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/texk/texlive/w64_mingw_wrapper/runscript_dll.c b/texk/texlive/w64_mingw_wrapper/runscript_dll.c
index 588c84b9..a4fd7acc 100644
--- a/texk/texlive/w64_mingw_wrapper/runscript_dll.c
+++ b/texk/texlive/w64_mingw_wrapper/runscript_dll.c
@@ -22,6 +22,38 @@ char subsys_mode[] = "CUI_MODE\n";
 char err_env_var[] = "RUNSCRIPT_ERROR_MESSAGE";
 char msg_buf[MAX_MSG];
 
+char *quote(char *data) {
+    int i, ln = strlen(data), nb;
+
+    /* We allocate twice as much space as needed to deal with worse-case
+       of having to escape everything. */
+    char *result = calloc(ln*2+3, sizeof(char));
+    char *presult = result;
+
+    *presult++ = '"';
+    for (nb=0, i=0; i < ln; i++)
+      {
+        if (data[i] == '\\')
+          nb += 1;
+        else if (data[i] == '"')
+          {
+            for (; nb > 0; nb--)
+              *presult++ = '\\';
+            *presult++ = '\\';
+          }
+        else
+          nb = 0;
+        *presult++ = data[i];
+      }
+
+    for (; nb > 0; nb--)        /* Deal w trailing slashes */
+      *presult++ = '\\';
+
+    *presult++ = '"';
+    *presult++ = 0;
+    return result;
+}
+
 
 __declspec(dllexport) int dllrunscript( int argc, char *argv[] ) 
 {
@@ -69,7 +101,7 @@ __declspec(dllexport) int dllrunscript( int argc, char *argv[] )
   lua_argv = (char **)malloc( (argc + 6) * sizeof(char *) );
   lua_argv[lua_argc=0] = texlua_name;
   lua_argv[++lua_argc] = fpath; // script to execute
-  for ( k = 1; k < argc; k++ ) lua_argv[++lua_argc] = argv[k]; // copy argument list
+  for ( k = 1; k < argc; k++ ) lua_argv[++lua_argc] = quote(argv[k]); // copy argument list
   lua_argv[++lua_argc] = subsys_mode; // sentinel argument
   lua_argv[++lua_argc] = argc ? argv[0] : own_path; // original argv[0]
   //lua_argv[++lua_argc] = argline; // unparsed arguments
-- 
2.31.1.windows.1


From naveen at syrusdark.website  Tue Jun  8 08:14:12 2021
From: naveen at syrusdark.website (Naveen M K)
Date: Tue, 8 Jun 2021 11:44:12 +0530
Subject: [tex-k] Patch: Fix spaces in arguments of runscript.exe
In-Reply-To: <a851bf9b-b24a-4ac0-eeaa-6004e45fa80a@syrusdark.website>
References: <a851bf9b-b24a-4ac0-eeaa-6004e45fa80a@syrusdark.website>
Message-ID: <15bb6053-ea9f-3e24-0ed7-127b9b193398@syrusdark.website>

Hi,

I have attached a slightly improved patch than the previous one.

Thanks.
Naveen

-------------- next part --------------
From 54107031fe8cdfb5d7ac0229016af95818b8adf0 Mon Sep 17 00:00:00 2001
From: Naveen M K <naveen at syrusdark.website>
Date: Mon, 7 Jun 2021 23:42:01 +0530
Subject: [PATCH] runscript: always quote args

Signed-off-by: Naveen M K <naveen at syrusdark.website>
---
 .../texlive/w64_mingw_wrapper/runscript_dll.c | 43 +++++++++++++++----
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/texk/texlive/w64_mingw_wrapper/runscript_dll.c b/texk/texlive/w64_mingw_wrapper/runscript_dll.c
index 588c84b9..395990a1 100644
--- a/texk/texlive/w64_mingw_wrapper/runscript_dll.c
+++ b/texk/texlive/w64_mingw_wrapper/runscript_dll.c
@@ -22,13 +22,44 @@ char subsys_mode[] = "CUI_MODE\n";
 char err_env_var[] = "RUNSCRIPT_ERROR_MESSAGE";
 char msg_buf[MAX_MSG];
 
+char *quote(char *data) {
+    int i, ln = strlen(data), nb;
+
+    /* We allocate twice as much space as needed to deal with worse-case
+       of having to escape everything. */
+    char *result = calloc(ln*2+3, sizeof(char));
+    char *presult = result;
+
+    *presult++ = '"';
+    for (nb=0, i=0; i < ln; i++)
+      {
+        if (data[i] == '\\')
+          nb += 1;
+        else if (data[i] == '"')
+          {
+            for (; nb > 0; nb--)
+              *presult++ = '\\';
+            *presult++ = '\\';
+          }
+        else
+          nb = 0;
+        *presult++ = data[i];
+      }
+
+    for (; nb > 0; nb--)        /* Deal w trailing slashes */
+      *presult++ = '\\';
+
+    *presult++ = '"';
+    *presult++ = 0;
+    return result;
+}
+
 
 __declspec(dllexport) int dllrunscript( int argc, char *argv[] ) 
 {
   static char own_path[MAX_PATH];
   static char fpath[MAX_PATH];
   char *fname, *argline, **lua_argv;
-  char *quoted_argline;
   int k, quoted, lua_argc;
   HMODULE module_handle = NULL;
 
@@ -56,24 +87,20 @@ __declspec(dllexport) int dllrunscript( int argc, char *argv[] )
   argline = GetCommandLine();
 
   if ( argline == NULL ) DIE("failed to retrieve command line string\n");
-  quoted_argline = malloc((1+strlen(argline)+1 + 1)*sizeof(char));
-  if ( quoted_argline == NULL ) DIE("failed to quote command line string\n");
   // skip over argv[0] (it can contain embedded double quotes if launched from cmd.exe!)
   for ( quoted = 0; (*argline) && ( !IS_WHITESPACE(*argline) || quoted ); argline++ )
     if ( *argline == '"' ) quoted = !quoted;
   while ( IS_WHITESPACE(*argline) ) argline++; // remove leading whitespace if any
-  // we need to quote our string , it seems.
-  snprintf(quoted_argline, (size_t)(1+strlen(argline)+1 + 1), "\"%s\"", argline); 
 
   // set up argument list for texlua script
   lua_argv = (char **)malloc( (argc + 6) * sizeof(char *) );
   lua_argv[lua_argc=0] = texlua_name;
   lua_argv[++lua_argc] = fpath; // script to execute
-  for ( k = 1; k < argc; k++ ) lua_argv[++lua_argc] = argv[k]; // copy argument list
+  for ( k = 1; k < argc; k++ ) lua_argv[++lua_argc] = quote(argv[k]); // copy argument list
   lua_argv[++lua_argc] = subsys_mode; // sentinel argument
   lua_argv[++lua_argc] = argc ? argv[0] : own_path; // original argv[0]
   //lua_argv[++lua_argc] = argline; // unparsed arguments
-  lua_argv[++lua_argc] = quoted_argline; // unparsed arguments
+  lua_argv[++lua_argc] = quote(argline); // unparsed arguments
   lua_argv[++lua_argc] = NULL;
 
   // call texlua interpreter
@@ -123,5 +150,3 @@ __declspec(dllexport) int dllwrunscript(
   return dllrunscript( 0, NULL );
 #endif
 }
-
-
-- 
2.31.1.windows.1


From 2500418497 at qq.com  Wed Jun  9 09:13:58 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Wed, 9 Jun 2021 15:13:58 +0800
Subject: [tex-k] E193, E543ff: programs aren't copied around verbatim
Message-ID: <tencent_A8C3FD9938156E00A3520554927027D9AD09@qq.com>

Page E193, line 7 says:

beginchar("0",9u#,fig_height#,0);
    ...  (a copy of the program for `0' in romand comes here)
penlabels(1,2,3,4); endchar;

But if you consult the official MF sources, you'll find in itald.mf

    x2r=hround(1.5u-.5curve);

where romand.mf says

    x2r=hround max(.7u,1.45u-.5curve);

So the skeleton of the italic "0" isn't quite the same as the roman "0",
despite what page E24, line 4 says.

Pages E543ff may have the same problem: compared with greekl.mf, the
skeletons of the Greek letters in tsetsl.mf have actually been optimized
for the extended-ASCII typewriter font.


From karl at freefriends.org  Fri Jun 11 18:48:16 2021
From: karl at freefriends.org (Karl Berry)
Date: Fri, 11 Jun 2021 10:48:16 -0600
Subject: [tex-k] E193, E543ff: programs aren't copied around verbatim
In-Reply-To: <tencent_A8C3FD9938156E00A3520554927027D9AD09@qq.com>
Message-ID: <202106111648.15BGmG8s032285@freefriends.org>

    Page E193, line 7 says:
    beginchar("0",9u#,fig_height#,0);
        ...  (a copy of the program for `0' in romand comes here)
    penlabels(1,2,3,4); endchar;
    But if you consult the official MF sources, you'll find in itald.mf
       x2r=hround(1.5u-.5curve);
    where romand.mf says
       x2r=hround max(.7u,1.45u-.5curve);

Indeed. Perhaps it was a bug fix that did not get propagated, instead of
an intentional difference. (I confess I did not try to look at the
geometric difference.)  Did you try to check the errata listings?

    Pages E543ff may have the same problem: compared with greekl.mf, the
    skeletons of the Greek letters in tsetsl.mf have actually been optimized
    for the extended-ASCII typewriter font.

Agreed there are plenty of differences. Again, some of them could be a
matter of sources getting out of sync rather than intentional
differences. Hard to say.

FWIW, I doubt Knuth will touch these MF programs even in the event of
another tuneup; seems more likely to add a few weasel words about the
programs being not exactly the same. Anyway, I'll add it to the pile
when I have a chance. --thanks, karl.


From 2500418497 at qq.com  Mon Jun 14 17:03:01 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Mon, 14 Jun 2021 23:03:01 +0800
Subject: [tex-k] gftype.web: "This pixel's upper" in index
Message-ID: <tencent_E7AC4FFCB939A56F54A23C0496932C27A909@qq.com>

If you "texdoc gftype" and go to page 28, you'll find

    This pixel's lower...: 43.
    This pixel's upper: 43.

even though both messages have been truncated.


From karl at freefriends.org  Mon Jun 14 23:21:01 2021
From: karl at freefriends.org (Karl Berry)
Date: Mon, 14 Jun 2021 15:21:01 -0600
Subject: [tex-k] gftype.web: "This pixel's upper" in index
In-Reply-To: <tencent_E7AC4FFCB939A56F54A23C0496932C27A909@qq.com>
Message-ID: <202106142121.15ELL1hY026389@freefriends.org>

        This pixel's upper: 43.

Thanks, added at https://tug.org/texmfbug/newbug.html#gftypeindexhu ... -k

From karl at freefriends.org  Mon Jun 14 23:21:02 2021
From: karl at freefriends.org (Karl Berry)
Date: Mon, 14 Jun 2021 15:21:02 -0600
Subject: [tex-k] A 215 line -15
In-Reply-To: <c49d00b4-b2bc-fd2b-8b1c-198931196a6f@mailbox.org>
Message-ID: <202106142121.15ELL2Sx026404@freefriends.org>

Hi Wolfgang - two months behind and counting, but anyway ...

    Date: Fri, 9 Apr 2021 15:53:33 +0200
    From: Wolfgang Helbig <helbig at mailbox.org>
    Subject: [tex-k] A 215 line -15

    Replace "alphabetic constant" by "character constant".
    The left quote works on all characters, not just alphabetic characters.
    
Yes, but the term "alphabetic constant" is otherwise used pervasively.

Also, it does not seem to me that "character constant" would be clearer
to readers, even though it is technically more correct. "Character
constant" is a term in programming languages, as you know, and it's just
misleading to think about TeX's ` feature like that.

    Date: Sat, 10 Apr 2021 16:42:43 +0200
    From: Wolfgang Helbig <helbig at mailbox.org>
    Subject: Re: [tex-k] A 215 line -15

    on B113 it says ``nonalphabetic character, like `\/''', so 'character' 
    and 'alphabetic character' seem to differ.

Knuth wrote "nonalphabetic character" once, in the implementation, to
emphasize what was going on in the program at that point. I don't see
that as a strong argument to change a dozen cases of "alphabetic
constant" throughout A and B. Especially since he never (as far as I
could grep) says "nonalphabetic constant". --best, karl.

From dmitry.zhelezniakov at gmail.com  Wed Jun 16 15:27:14 2021
From: dmitry.zhelezniakov at gmail.com (Dmitry Zheleznyakov)
Date: Wed, 16 Jun 2021 16:27:14 +0300
Subject: [tex-k] bibtexu crash
Message-ID: <CAG2fB4kpLJFbqx4kkoXE54qir+zdA179xGrg2EerBXeY1uw0=A@mail.gmail.com>

Hello!

Could you please check the crash in bibtexu.
This is BibTeXu: a UTF-8 Big BibTeX version 0.99d
Implementation:  C for Unix
Release version: 3.71 (04 mar 2019) (TeX Live 2021)
Compiled with:   ICU version 68.2

Please check the attachment with test files and log.
Previously. I used the version from the Debian repository, but it did work
with many items.
I installed the latest version, but it does not work at all.

Thank you in advance for the support.


-- 
Sincerely yours,
Dmitry Zhelezniakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-k/attachments/20210616/cb610568/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.7z
Type: application/x-7z-compressed
Size: 1890 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20210616/cb610568/attachment.bin>

From P.Taylor at Hellenic-Institute.Uk  Wed Jun 16 18:34:37 2021
From: P.Taylor at Hellenic-Institute.Uk (Philip Taylor)
Date: Wed, 16 Jun 2021 17:34:37 +0100
Subject: [tex-k] bibtexu crash
In-Reply-To: <CAG2fB4kpLJFbqx4kkoXE54qir+zdA179xGrg2EerBXeY1uw0=A@mail.gmail.com>
References: <CAG2fB4kpLJFbqx4kkoXE54qir+zdA179xGrg2EerBXeY1uw0=A@mail.gmail.com>
Message-ID: <b19e8c8a-757d-07af-0964-e70abbd9b6b0@Hellenic-Institute.Uk>

I have zero experience of BibTeXu, and almost zero experience of BibTeX 
in general, so I tried the following :

> D:\TeX\Projects>bibtexu test.bib

I was told :

> I couldn't open file name `test.bib.aux'
> (That was a fatal error)
>
> D:\TeX\Projects>

Was this to be expected, and if so, how /should/ I have launched BibTeXu 
in order for it to (a) succeed, or (b) demonstrate your problem ?
/--
Philip Taylor
/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-k/attachments/20210616/ae83caf1/attachment.html>

From karl at freefriends.org  Fri Jun 18 00:58:40 2021
From: karl at freefriends.org (Karl Berry)
Date: Thu, 17 Jun 2021 16:58:40 -0600
Subject: [tex-k] bibtexu crash
In-Reply-To: <CAG2fB4kpLJFbqx4kkoXE54qir+zdA179xGrg2EerBXeY1uw0=A@mail.gmail.com>
Message-ID: <202106172258.15HMweJf026683@freefriends.org>

Hi Dmitry,

    Release version: 3.71 (04 mar 2019) (TeX Live 2021)
    Compiled with:   ICU version 68.2

Yes, I get the same failure with tl21 bibtexu and ICU. Apparently
something in ICU has new requirements or backward incompatibilities.

Hironobu, maybe you'd be willing to look into this? You've been just
about the only person to touch bibtexu at all in years. I'd greatly
appreciate it. I'll attach Dmitry's test file and the generated .aux .

Thanks,
Karl

$ pdflatex test.tex
$ bibtexu test
..
Database file #1: test.bib
terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error -1
Aborted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.tex
Type: application/octet-stream
Size: 200 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20210617/db059991/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.aux
Type: application/octet-stream
Size: 179 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20210617/db059991/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.bib
Type: application/octet-stream
Size: 215 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20210617/db059991/attachment-0002.obj>

From kakuto at w32tex.org  Fri Jun 18 01:12:31 2021
From: kakuto at w32tex.org (Akira Kakuto)
Date: Fri, 18 Jun 2021 08:12:31 +0900
Subject: [tex-k] bibtexu crash
In-Reply-To: <202106172258.15HMweJf026683@freefriends.org>
References: <202106172258.15HMweJf026683@freefriends.org>
Message-ID: <505c7726-7dc5-28e8-3ba6-2af468e8b619@w32tex.org>

Hi Karl,

On 2021/06/18 7:58, Karl Berry wrote:
> Hi Dmitry,
> 
>      Release version: 3.71 (04 mar 2019) (TeX Live 2021)
>      Compiled with:   ICU version 68.2
> 
> Yes, I get the same failure with tl21 bibtexu and ICU. Apparently
> something in ICU has new requirements or backward incompatibilities.
> 
> Hironobu, maybe you'd be willing to look into this? You've been just
> about the only person to touch bibtexu at all in years. I'd greatly
> appreciate it. I'll attach Dmitry's test file and the generated .aux .
> 
> Thanks,
> Karl
> 
> $ pdflatex test.tex
> $ bibtexu test
> ..
> Database file #1: test.bib
> terminate called after throwing an instance of 'std::system_error'
>    what():  Unknown error -1
> Aborted
>

On Windows, test.aux is the same, but I don't get the failure:

bibtexu test
The top-level auxiliary file: test.aux
The style file: acm.bst
Database file #1: test.bib

Best,
Akira

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pdf
Type: application/pdf
Size: 43565 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20210618/d4371955/attachment-0001.pdf>

From h.y.acetaminophen at gmail.com  Fri Jun 18 08:39:18 2021
From: h.y.acetaminophen at gmail.com (Hironobu Yamashita)
Date: Fri, 18 Jun 2021 15:39:18 +0900
Subject: [tex-k] bibtexu crash
In-Reply-To: <202106172258.15HMweJf026683@freefriends.org>
References: <CAG2fB4kpLJFbqx4kkoXE54qir+zdA179xGrg2EerBXeY1uw0=A@mail.gmail.com>
 <202106172258.15HMweJf026683@freefriends.org>
Message-ID: <CAJCZBmTa+VD7JJ7f2p774LbVhQA3TN-18a-_yueCpeShv1xhQQ@mail.gmail.com>

Hi Karl,

> Yes, I get the same failure with tl21 bibtexu and ICU. Apparently
> something in ICU has new requirements or backward incompatibilities.

How unfortunate ...
When I tested in 2019, I found that bibtexu worked on some platform and
doesn't on others. I guess making it ok everywhere would require much work,
and I don't have enough knowledge about icu.

Hironobu

From diez.ulrich at web.de  Fri Jun 18 23:54:22 2021
From: diez.ulrich at web.de (Ulrich Diez)
Date: Fri, 18 Jun 2021 23:54:22 +0200
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
Message-ID: <trinity-e8a5bc66-456c-4b3e-b6ad-c5d33739bf01-1624053262180@3c-app-webde-bap15>

Bug report for the 2029 TeX tune-up

Subject: Error-message is expected but the text of the error-message is incorrect

Submitted by: Ulrich Diez  (diez.ulrich at web.de)


.tex-input-file FileA.tex contains:

   Line 1
   Line 2
   Line 3


.tex-input-file test.tex contains:

   \endinput\edef\foobar{\input FileA.tex }%
   \bye


I am aware of the circumstance that with \input "inside" \edef
you expect an error-message in any case. That is not what this
bug-report is about.

Be aware that in test.tex  \endinput is _before_ \edef !

Chapter 20: Definitions (also called macros) of the TeXbook says
about \endinput:

| - \endinput. The expansion is null. The next time TeX gets to the end
|   of an \input line, it will stop reading from the file containing that line.


Compiling test.tex  via  tex test.tex  yields the following console-output:


   This is TeX, Version 3.14159265 (TeX Live 2020) (preloaded format=tex)
   (./test.tex (./FileA.tex)
   Runaway definition?
   ->Line 1
   ! File ended while scanning definition of \foobar.
   <inserted text>
                   }
   l.1 \endinput\edef\foobar{\input FileA.tex
                                              }%
   ?
   ! Too many }'s.
   l.1 \endinput\edef\foobar{\input FileA.tex }
                                               %
   ?
    )
   No pages of output.
   Transcript written on test.log.



Do you see the statement

   ->Line 1
   ! File ended while scanning definition of \foobar.

?

That statement is not correct in this subtle case.

In this subtle case the reason for the runaway-definition
is not that TeX encountered the _end_ of a file.

In this subtle case the reason for the runaway-definition
is that reading from fileA.tex was ceased due to the
pending \endinput after reading and processing the
first line of fileA.tex.


In this subtle case a correct statement would be something
like:

   ->Line 1
   ! Due to pending \endinput reading from file was ceased
   ! after reading its first line while scanning definition
   ! of \foobar.


Rectifying this would probably be nice for people who play
with TeX-engines where eTeX-extensions with things like
\everyeof{\noexpand}\edef\foobar{\scantokens{..}}
are possible and who seem to struggle with misleading
statements coming from error-messages.

See, e.g.,

https://groups.google.com/g/comp.text.tex/c/tdE_mQrMoiE/m/7l9MWXl7AwAJ


Sincerely

Ulrich Diez



From ud.usenetcorrespondence at web.de  Sat Jun 19 13:45:58 2021
From: ud.usenetcorrespondence at web.de (ud.usenetcorrespondence at web.de)
Date: Sat, 19 Jun 2021 13:45:58 +0200
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
Message-ID: <trinity-cca15b0d-859d-4f16-88e6-734ac9135984-1624103158735@3c-app-webde-bap54>

Bug report for the 2029 TeX tune-up

Subject: Error-message is expected but the text of the error-message is incorrect

Submitted by: Ulrich Diez (diez.ulrich at web.de / ud.usenetcorrespondence at web.de)


.tex-input-file FileA.tex contains:

   Line 1
   Line 2
   Line 3


.tex-input-file test.tex contains:

   \endinput\edef\foobar{\input FileA.tex }%
   \bye


I am aware of the circumstance that with \input "inside" \edef
you expect an error-message in any case. That is not what this
bug-report is about.

Be aware that in test.tex \endinput is _before_ \edef !

Chapter 20: Definitions (also called macros) of the TeXbook says
about \endinput:

| - \endinput. The expansion is null. The next time TeX gets to the end
| of an \input line, it will stop reading from the file containing that line.


Compiling test.tex via tex test.tex yields the following console-output:


   This is TeX, Version 3.14159265 (TeX Live 2020) (preloaded format=tex)
   (./test.tex (./FileA.tex)
   Runaway definition?
   ->Line 1
   ! File ended while scanning definition of \foobar.
   <inserted text>
   }
   l.1 \endinput\edef\foobar{\input FileA.tex
   }%
   ?
   ! Too many }'s.
   l.1 \endinput\edef\foobar{\input FileA.tex }
   %
   ?
   )
   No pages of output.
   Transcript written on test.log.



Do you see the statement

   ->Line 1
   ! File ended while scanning definition of \foobar.

?

That statement is not correct in this subtle case.

In this subtle case the reason for the runaway-definition
is not that TeX encountered the _end_ of a file.

In this subtle case the reason for the runaway-definition
is that reading from fileA.tex was ceased due to the
pending \endinput after reading and processing the
first line of fileA.tex.


In this subtle case a correct statement would be something
like:

   ->Line 1
   ! Due to pending \endinput reading from file was ceased
   ! after reading its first line while scanning definition
   ! of \foobar.


Shorter and less informative:

   ->Line 1
   ! Processing the file ended while scanning definition of \foobar.

This doesn't say anything about the reason (reaching the end/
pending \endinput and end of file's first line) for ending the
processing of the file.

Rectifying this would probably be nice for people who play
with TeX-engines where eTeX-extensions with things like
\everyeof{\noexpand}\edef\foobar{\scantokens{..}}
are possible and who seem to struggle with misleading
statements coming from error-messages.

See, e.g.,

https://groups.google.com/g/comp.text.tex/c/tdE_mQrMoiE/m/7l9MWXl7AwAJ


Sincerely

Ulrich Diez

From karl at freefriends.org  Sun Jun 20 00:48:47 2021
From: karl at freefriends.org (Karl Berry)
Date: Sat, 19 Jun 2021 16:48:47 -0600
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
In-Reply-To: <trinity-cca15b0d-859d-4f16-88e6-734ac9135984-1624103158735@3c-app-webde-bap54>
Message-ID: <202106192248.15JMmlFm011002@freefriends.org>

Hi Ulrich,

       \endinput\edef\foobar{\input FileA.tex }%
       ...
       ! File ended while scanning definition of \foobar.

Well, reading of a file did in fact end (because of the \endinput).  As
you know, that is how \endinput works, as you and Donald A and others
discussed at length in the prior tex.sx post
https://tex.stackexchange.com/questions/554770.

TeX's hardwired error messages can't consider every conceivable
situation.  So I don't see an actual error here.

At any rate, as Knuth has said, any complex system can be improved
forever (in this case, with more ever-more-precise error messages).
He will not look at such asymptotic improvements.

Therefore I attempted to write this up at
  https://tug.org/texmfbug/nobug.html#endinput

Best,
Karl

From 2500418497 at qq.com  Tue Jun 22 08:16:30 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Tue, 22 Jun 2021 14:16:30 +0800
Subject: [tex-k] indexes to volumes B&D
Message-ID: <tencent_D249FC937AD642FE089C46372A51DD02C808@qq.com>

--------------------Volume B, index--------------------------

Extra \right.
    Delete the period. (Most error-message entries omit the period.)

--------------------Volume D, index--------------------------

Missing `#'
    Here the "#" stands for argument to WEB macro and is not part of
    METAFONT output. Other entries do not use # this way, so the entry
    should be merged with the actual outputs (Missing `,' & Missing `:').

[There are other problems in both indexes but I don't have time to find
them all. For example, the use of ellipses is somewhat inconsistent.]


From ud.usenetcorrespondence at web.de  Wed Jun 23 18:19:49 2021
From: ud.usenetcorrespondence at web.de (ud.usenetcorrespondence at web.de)
Date: Wed, 23 Jun 2021 18:19:49 +0200
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
In-Reply-To: <202106192248.15JMmlFm011002@freefriends.org>
References: <trinity-cca15b0d-859d-4f16-88e6-734ac9135984-1624103158735@3c-app-webde-bap54>
 <202106192248.15JMmlFm011002@freefriends.org>
Message-ID: <trinity-a0830a5e-e995-4b08-88b6-aa9f2cb43771-1624465189476@3c-app-webde-bs51>

Karl Berry wrote:

> Hi Ulrich,
>
> \endinput\edef\foobar{\input FileA.tex }%
> ...
> ! File ended while scanning definition of \foobar.
>
> Well, reading of a file did in fact end (because of the \endinput). As
> you know, that is how \endinput works, as you and Donald A and others
> discussed at length in the prior tex.sx post
> https://tex.stackexchange.com/questions/554770.
>
> TeX's hardwired error messages can't consider every conceivable
> situation. So I don't see an actual error here.

The phrase "File ended" implies that the end of the file in
question was reached which is not the case in the scenario
pointed out by me.

That's why I suggested:

! Processing the file ended while scanning definition of \foobar.

This phrase does not imply a reason for ending the processing
of the file and therefore might be less misleading in situations
like the scenario pointed out by me and might cover more
situations correctly.

Ulrich

From karl at freefriends.org  Wed Jun 23 22:30:52 2021
From: karl at freefriends.org (Karl Berry)
Date: Wed, 23 Jun 2021 14:30:52 -0600
Subject: [tex-k] indexes to volumes B&D
In-Reply-To: <tencent_D249FC937AD642FE089C46372A51DD02C808@qq.com>
Message-ID: <202106232030.15NKUqoO000711@freefriends.org>

    [B] Extra \right.
    [D] Missing `#'

Thanks, added to newbug.html. Good catches.

    the use of ellipses is somewhat inconsistent.

I doubt Knuth would be especially interested in perfect consistency in
that regard, anyway. --best, karl.

From karl at freefriends.org  Wed Jun 23 23:16:20 2021
From: karl at freefriends.org (Karl Berry)
Date: Wed, 23 Jun 2021 15:16:20 -0600
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
In-Reply-To: <trinity-a0830a5e-e995-4b08-88b6-aa9f2cb43771-1624465189476@3c-app-webde-bs51>
Message-ID: <202106232116.15NLGKT4006298@freefriends.org>

    ! Processing the file ended while scanning definition of \foobar.

I understand your suggestion. However, Knuth has consistently taken the
position that when people do tricky things (like putting expandable
material on the line after \endinput), they cannot expect perfect error
messages (or, necessarily, any). There is no chance that he would
complicate the code merely to issue a variant error message here. -k

From igor.liferenko at gmail.com  Fri Jun 25 03:24:09 2021
From: igor.liferenko at gmail.com (Igor Liferenko)
Date: Fri, 25 Jun 2021 08:24:09 +0700
Subject: [tex-k] Incorrect formatting of formula in mf.web
Message-ID: <CAJyx3621T0SmU0g_SwB3R1SWxtwy142ie8tOjQSOU9f3ukWGrg@mail.gmail.com>

Hi all,

In recent corrections of mf.web, the redundant `(' character was removed:

    -we could simply compute |(@t$(2^{29}$@>*p+q)div (2*q)|.
    +we could simply compute |@t$(2^{29}$@>*p+q)div (2*q)|.

But instead the `(' must be removed from inside $...$.
Not only the present correction breaks formatting, but it also
has overlapping groups (`$...$' and `(...)').

I discovered this when I tried to update my web2w implementation of
metafont to latest mf.web

Regards,
Igor

From igor.liferenko at gmail.com  Fri Jun 25 05:27:28 2021
From: igor.liferenko at gmail.com (Igor Liferenko)
Date: Fri, 25 Jun 2021 10:27:28 +0700
Subject: [tex-k] 'Floating point exception' in TeX
Message-ID: <CAJyx362mc_WE6Qxvp0M2UN7D7hAOPPXZyRpe0SY10Ro1CrXhuw@mail.gmail.com>

Hi all,

Run metafont on default io.mf like this:

    **\mode=localfont; input io

then type 'end', then run tex on this file:

    \font\x=./io scaled 16000 \x O \bye

We get 'Floating point exception'.
If 16000 is changed to 15999, everything
is OK.

If we use "at 2048pt" instead of "scaled ...",
then TeX warns us with this message:

    ! Improper `at' size (2048.0pt), replaced by 10pt.

Maybe for consistency it is worth to check the
"scaled" value also?

Regards,
Igor

From karl at freefriends.org  Fri Jun 25 23:47:11 2021
From: karl at freefriends.org (Karl Berry)
Date: Fri, 25 Jun 2021 15:47:11 -0600
Subject: [tex-k] 'Floating point exception' in TeX
In-Reply-To: <CAJyx362mc_WE6Qxvp0M2UN7D7hAOPPXZyRpe0SY10Ro1CrXhuw@mail.gmail.com>
Message-ID: <202106252147.15PLlB2Z029960@freefriends.org>

    Maybe for consistency it is worth to check the
    "scaled" value also?

Knuth isn't interested in pathological overflow conditions, but it
couldn't hurt for implementations to check for this one, seems to me.
If your or anyone wants to make a patch for web2c, I can put it in, else
I will look into it when I have a chance (not soon). --thanks, karl.

From karl at freefriends.org  Fri Jun 25 23:47:12 2021
From: karl at freefriends.org (Karl Berry)
Date: Fri, 25 Jun 2021 15:47:12 -0600
Subject: [tex-k] Incorrect formatting of formula in mf.web
In-Reply-To: <CAJyx3621T0SmU0g_SwB3R1SWxtwy142ie8tOjQSOU9f3ukWGrg@mail.gmail.com>
Message-ID: <202106252147.15PLlCAQ029968@freefriends.org>

        -we could simply compute |(@t$(2^{29}$@>*p+q)div (2*q)|.
        +we could simply compute |@t$(2^{29}$@>*p+q)div (2*q)|.

    But instead the `(' must be removed from inside $...$.

Indeed. Thanks. I'll add it to newbug.html soon. -k

From ud.usenetcorrespondence at web.de  Sat Jun 26 13:58:48 2021
From: ud.usenetcorrespondence at web.de (Ulrich  D i e z)
Date: Sat, 26 Jun 2021 13:58:48 +0200
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
	expected but the text of the error-message is incorrect
References: <202106232116.15NLGKT4006298@freefriends.org>
Message-ID: <001c01d76a82$aadcaa80$6902a8c0@speedport.ip>

----- Original Message -----
From: "Karl Berry" <karl at freefriends.org>
To: <ud.usenetcorrespondence at web.de>
Cc: <tex-k at tug.org>
Sent: Wednesday, June 23, 2021 11:16 PM
Subject: Re: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is expected but the text of the error-message is incorrect


>     ! Processing the file ended while scanning definition of \foobar.
>
> I understand your suggestion. However, Knuth has consistently taken the
> position that when people do tricky things (like putting expandable
> material on the line after \endinput), they cannot expect perfect error
> messages (or, necessarily, any). There is no chance that he would
> complicate the code merely to issue a variant error message here. -k

Does adding the two words  "Processing the" to error-message-phrase
in question really complicate things?

The error-message-text

    ! Processing the file ended while scanning definition of \foobar.

is more general than the error-message text

    ! File ended while scanning definition of \foobar.

and could be raised both in situations where the end of the
file in question is reached and in situations where the reason for
ending the processing of the file is a different one, e.g.,  a
pending \endinput, which in my humble opinion is not that tricky
as soon as one has realized what is written in the TeXbook.

I suppose adjusting the phrase in the documentation, i.e., in the
TeXbook and in "TeX the program" might be more work than
adjusting it for the program itself. :->


Whether Knuth might be inclined to rectify things is not of interest
to me.

What is of interest to me is the circumstance of incorrectly classifying
behavior as "not a bug" instead of classifying it, e.g., as "something
not worth to rectify":

This way yo you are quietly passing the buck to me.

Fact is:

In the scenario I showed, the program delivers a clearly false
statement in the form of an error message:

The claim to have reached an end of file when this is not the
case is a false statement supplied by the program.

If the fact that a program delivers a false statement, although
a less sharp but non-false statement is easily possible, is not
one of the things that can be subsumed under the general term
"bug", then I humbly request a Knuth definition for this term.



Whether anyone fixes it or instead categorizes it as a
"bug for some reason not worth rectifying" (which would
probably not imply a claim that is ojectively false)  , I don't
care.
The people here are doing volunteer work for free.
I have no right to expect anyone to do anything.

But I'm tired of being subtly played for a sucker:

By any reasonable understanding of the term "bug", it is
a bug. So I don't need to be tricked into the position of the
one who sees something wrong.

I consider the way A214 at
<https://tug.org/texmfbug/nobug.html#endinput> presents
things to be unserious:

First, it is not about the behavior of \endinput, but at most
about error messages related to it.  The headline should
emphasize the latter, not the former.

Secondly, these error messages are indeed "counter intuitive"
in the scenario I have shown. For the sake of honesty, this
"counter intuitive" could be narrowed down to "false" in this
case.


Ulrich



From helbig at mailbox.org  Sat Jun 26 16:50:19 2021
From: helbig at mailbox.org (Wolfgang Helbig)
Date: Sat, 26 Jun 2021 16:50:19 +0200
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
In-Reply-To: <trinity-cca15b0d-859d-4f16-88e6-734ac9135984-1624103158735@3c-app-webde-bap54>
References: <trinity-cca15b0d-859d-4f16-88e6-734ac9135984-1624103158735@3c-app-webde-bap54>
Message-ID: <c1439d92-0e09-5a09-8f36-191b90a618af@mailbox.org>

Hello Ulrich,

thank you for pointing out to this one:
> Shorter and less informative:
>
>     ->Line 1
>     ! Processing the file ended while scanning definition of \foobar.
This message is correct but not too complicated. For people like me the 
best choice. I'll change the error message in the next release of TeX-FPC.

Greetings

-- 
Wolfgang Helbig
Stauferstr. 22
71334 Waiblingen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: helbig.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20210626/2a2b4ae5/attachment.vcf>

From 2500418497 at qq.com  Mon Jun 28 02:21:22 2021
From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=)
Date: Mon, 28 Jun 2021 08:21:22 +0800
Subject: [tex-k] errata.tex, B21 entry: "->" should be ".."
Message-ID: <tencent_9CE6320A55E02D897592C8FAC83F8033F905@qq.com>

errata.tex, B21 entry
    ['41 -> '46, '60 -> '71, '136, '141 -> '146, '160 -> '171]
should say ".." instead of "->".

(There are lots of other typos in the errata files but I won't be catching
them anymore.)


From ud.usenetcorrespondence at web.de  Mon Jun 28 15:20:50 2021
From: ud.usenetcorrespondence at web.de (ud.usenetcorrespondence at web.de)
Date: Mon, 28 Jun 2021 15:20:50 +0200
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
In-Reply-To: <202106232116.15NLGKT4006298@freefriends.org>
References: <trinity-a0830a5e-e995-4b08-88b6-aa9f2cb43771-1624465189476@3c-app-webde-bs51>
 <202106232116.15NLGKT4006298@freefriends.org>
Message-ID: <trinity-5bbd31f0-4468-4abd-a058-4225307b0f78-1624886450731@3c-app-webde-bap45>

An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-k/attachments/20210628/af088a90/attachment.html>

From igor.liferenko at gmail.com  Tue Jun 29 03:35:44 2021
From: igor.liferenko at gmail.com (Igor Liferenko)
Date: Tue, 29 Jun 2021 08:35:44 +0700
Subject: [tex-k] Bad space in TeXbook
Message-ID: <CAJyx363+XevY46rWh8ASn6iw3GrSbp3Y7aEnGAqTjvDg7USc7A@mail.gmail.com>

Hi all,

Either on page 374 there is extra space:

    `|\t=\expandafter{\the\t|~|*}|' in the example on the previous page

Or on page 373 there is a missing space:

    \loop \ifnum\m>0 \t=\expandafter{\the\t*}\advance\m-1 \repeat

(see latest texbook.tex)

Is this a bug or a non-bug?

Regards,
Igor

From karl at freefriends.org  Tue Jun 29 23:22:39 2021
From: karl at freefriends.org (Karl Berry)
Date: Tue, 29 Jun 2021 15:22:39 -0600
Subject: [tex-k] Bad space in TeXbook
In-Reply-To: <CAJyx363+XevY46rWh8ASn6iw3GrSbp3Y7aEnGAqTjvDg7USc7A@mail.gmail.com>
Message-ID: <202106292122.15TLMdRe025664@freefriends.org>

    Either on page 374 there is extra space:
        `|\t=\expandafter{\the\t|~|*}|' in the example on the previous page

    Or on page 373 there is a missing space:
        \loop \ifnum\m>0 \t=\expandafter{\the\t*}\advance\m-1 \repeat

    (see latest texbook.tex)

Bizarrely, in the actual printed book I have (34th printing), there is a
space in both places. I see the change (removal of the space on the
\loop line) taking place in the 2014 texbook.tex, compared to 2008.

Anyway, it will be interesting to see how it looks in the upcoming
"Jubilee" printings. (I have no information about when they will be
available, just BTW.) Meanwhile, it is at least a texbook.tex bug, seems
to me. --thanks, karl.

From karl at freefriends.org  Wed Jun 30 01:01:14 2021
From: karl at freefriends.org (Karl Berry)
Date: Tue, 29 Jun 2021 17:01:14 -0600
Subject: [tex-k] Bug report for the 2029 TeX tune-up - Error-message is
 expected but the text of the error-message is incorrect
In-Reply-To: <trinity-5bbd31f0-4468-4abd-a058-4225307b0f78-1624886450731@3c-app-webde-bap45>
Message-ID: <202106292301.15TN1EBQ005657@freefriends.org>

I agree that the original message is inaccurate in many circumstances. It
does not even take any expansion trickery. If the input file consists of:
  \endinput
  foo
then "File ended" is just as wrong. (Don A pointed this out to me
off-list. He thought of "Input ended ..." or "File input ended ...",
in addition to your "Processing of file ended ...".)

Nevertheless, I do not want to change the message in web2c. First, there
are plenty of books, articles, posts, over the past decades that discuss
error messages. Changing the text now at this late date seems like a
cause of unnecessary confusion to me, outweighing the benefit from the
tiny increment of added correctness. (I imagine people wondering, "Why
is the message different? Is there some other case that emits the
original message?" Etc. At least I would, if I came across it in the
wild.)

Second, it sets a precedent. It's not unusual for Knuth's error messages
to be imprecise/imperfect/wrong/missing completely/whatever. I don't
feel it's desirable to go down the path of refining error reporting down
to the last syllable in non-Knuthian TeX.

As for nobug.html, the purpose of that page is to list bug reports which
are (typically) valid, but which Knuth has nevertheless declined to do
anything about (either specifically or as a general rule). "Not a bug
for Knuth." I did not intend to deem your bug report as invalid in some
absolute sense.

Certainly, "report 1" and "report 2" are completely different. I moved
the report 1 link to after "effects". --karl