From 2500418497 at qq.com Sun May 2 15:13:42 2021 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Sun, 2 May 2021 21:13:42 +0800 Subject: [tex-k] C299: r not declared with the proper type Message-ID: During the 2021 tuneup, Knuth changed the Bernshtein macros on C299 so that the last four lines became primarydef t Bernshtein nn = begingroup save r; r = begingroup for n=nn downto 2: for k=1 upto n-1: u_[[[k]]]:=t[[[u_[[[k]]],u_[[[k+1]]] ]]]; endfor endfor u_[[[1]]] endgroup; numeric u_[[[]]]; r endgroup enddef; (The tokens [[[ and ]]] are primitive versions of [ and ]. --Hu) This introduced another bug: The temporary variable r is not declared with the proper type, so it is numeric. Then it is assigned the value of u_[[[1]]], which can be either numeric or pair as shown earlier in the code. METAFONT won't let you assign a pair to a numeric variable. You might want to fix this by saying "if pair u_[[[1]]]: pair r; fi" before the assignment, but the page is already full. And, as I said in January, it solves the "show" problem inadequately. Namely, "show .5[2a,2b,2c,2d]" now gives explicit results, but "show .5[3a,3b,3c,3d]" and "show 2[a,b,c,d]" fail. (Hence my TUGboat article.) Since it solves one problem inadequately and introduces another, maybe it's better to revert it and use the pre-2021-tuneup version? ---- By the way, .5[a,b] is a primary expression but .5[a,b,c] isn't. Thus in z1 .. controls t[z1,z2] and (t[z1,z2,z3]) .. t[z1,z2,z3,z4] the parentheses around t[z1,z2,z3] is necessary. There seems to be no way to make Bernstein work on the primary level, despite the "primarydef". From karl at freefriends.org Mon May 10 19:29:58 2021 From: karl at freefriends.org (Karl Berry) Date: Mon, 10 May 2021 11:29:58 -0600 Subject: [tex-k] inconsistent use of "eye", "mouth", "gullet" in The TeXbook In-Reply-To: Message-ID: <202105101729.14AHTw3I002458@freefriends.org> Hi Yajie, Date: Tue, 13 Apr 2021 17:10:41 +0800 Subject: [tex-k] inconsistent use of "eye", "mouth", "gullet" in The TeXbook I don't exactly see a clear inconsistency here. "eyes" convert characters from files into tokens, "mouth" expands the expandable tokens, "gullet" (on the way to the stomach) emphasizes the transition from expansion to execution in the stomach. All these phases blend into each other without sharp boundaries, as can be seen by the frequent use of "eyes and mouth", etc. And the whole thing is an inexact metaphor. So there isn't much use in striving for technically precise definitions. I guess this instance (and the analogous one in the mfbook) would be more consistent if "eyes" were also mentioned: > Page A267, lines -16 thru -13: > Chapter 7 has described the process by which input files are > converted to lists of tokens in TeX's "mouth," If you think there is some other change to make, let me know. I don't know which view the opening illustrations of Appendix I takes. It shows the parts of TeX's body labeled a, b, c, etc. It does not explain anything. But tex.web and mf.web take the former view in the explanation of get_next. get_next straddles all parts of the process. I don't think there is anything in tex/mf.web which says that the mouth is *not* expansion? Which view should I take if I were to write another article for TUGboat? "Gullet" is infrequently used, and I wouldn't bother using it in an article. I mostly see eyes/mouth/stomach (and occasionally bowels), used as I wrote above. What would be wrong with \def\%{\char`%}? The % would be treated as a comment character, because its category code is 14; thus, no % token or } token would get through to the gullet of TeX where numbers are treated. but I think the truth is that no % token or } token would get through to the _stomach_ of TeX where the definition is read. And numbers are not treated in the gullet anyway, according to the scan_int procedure in tex.web module 440. I don't think it is wrong as written. Although numbers are recognized, in the sense of scanning from input characters, in the eyes(/mouth), they are acted on by the stomach. In an assignment \catcode\`%=14, the "14" is being considered as its numeric value, not merely the lexical scan from the characters 1 and 4. As for stomach vs. gullet, there is no specific distinction between them as far as I can see, as I noted above. Here again is a case where Knuth is using an imprecise term to emphasize what's going on, the mixture of the different processes. (I want to explain that unlike TeX, METAFONT has two kinds of macros, one handled in the mouth/gullet and one handled in the stomach.) Sounds like a good topic. --thanks, karl. From doug at mathemaesthetics.com Tue May 11 18:12:35 2021 From: doug at mathemaesthetics.com (Doug McKenna) Date: Tue, 11 May 2021 10:12:35 -0600 (MDT) Subject: [tex-k] inconsistent use of "eye", "mouth", "gullet" in The TeXbook In-Reply-To: References: Message-ID: <45012871.88730679.1620749555646.JavaMail.zimbra@mathemaesthetics.com> Executing the TeX language has always reminded me of Pac-Man. There's a reason a commonly used LaTeX macro is named \gobble. I view expansion as regurgitation, the equivalent of ruminant cud-chewing. God knows where "flossing" fits in. :-) - Doug McKenna From 2500418497 at qq.com Thu May 20 12:03:45 2021 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Thu, 20 May 2021 18:03:45 +0800 Subject: [tex-k] A370: braces also inserted around \write token lists Message-ID: Appendix C of The TeXbook ends with an enumeration of character codes hardwired into TeX, and one of them is: (5) ... braces are inserted around an \output routine which is true. But TeX also inserts braces when expanding the token list of \write commands, although they are stripped later. This is confirmed by the fact that \catcode`(=1 \catcode`)=2 \catcode`#=6 \def\\#1(#1\iffalse(\fi)) \immediate\write16(hello\expandafter\\\string) prints "hello}" on your terminal, even if you're using INITEX! The idea is that TeX expands the token list of \write commands by enclosing them in {_1 ... }_2 and expands it in the same way after \edef, \message, etc. This seems like an implementation detail, since the braces will disappear anyway, but our devious program captured the }_2 by converting it into }_12 via \string and using an auxiliary macro \\ to put a )_2 after the }_12, so the right brace leaked and TeX didn't notice anything wrong. From 2500418497 at qq.com Thu May 20 12:48:44 2021 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Thu, 20 May 2021 18:48:44 +0800 Subject: [tex-k] A370: braces also inserted around \write token lists Message-ID: Sorry for my poor English. Somehow I thought "token list of \write commands" was plural because of the final "s"! The word "them" in enclosing them in {_1 ... }_2 obviously refers to the token list, not the whole command. From rdtennent at gmail.com Sun May 23 15:15:29 2021 From: rdtennent at gmail.com (Bob Tennent) Date: Sun, 23 May 2021 09:15:29 -0400 Subject: [tex-k] vertical line length issue Message-ID: <20210523131529.OlF4ZZZ3K%rdt@cs.queensu.ca> The attached dvi file, produced using musixtex, is problematic when processed by dvips at various resolutions: some of the vertical note stems are too long. On my system the problem arises with -D 300 but not with -D 600, but on other systems the situation is reversed. The problem does *not* arise using dvipdfm. Note that the beam itself is produced using tpic specials and so won't appear in, say, xdvi output. The musixtex-fonts package must be installed. Hiroaki Morimoto (the author of the musixvbm add-on that produces the vectorized beam) discovered this issue and may be able to provide more information. Bob Tennent -------------- next part -------------- A non-text attachment was scrubbed... Name: strangebeam.dvi Type: application/x-dvi Size: 968 bytes Desc: not available URL: From rdtennent at gmail.com Sun May 23 15:35:42 2021 From: rdtennent at gmail.com (Bob Tennent) Date: Sun, 23 May 2021 09:35:42 -0400 Subject: [tex-k] vertical line length issue In-Reply-To: <20210523131529.OlF4ZZZ3K%rdt@cs.queensu.ca> References: <20210523131529.OlF4ZZZ3K%rdt@cs.queensu.ca> Message-ID: <20210523133542.dlxNltE3N%rdt@cs.queensu.ca> >|The attached dvi file, produced using musixtex, is >|problematic when processed by dvips at various resolutions: >|some of the vertical note stems are too long. On my system >|the problem arises with -D 300 but not with -D 600, but on >|other systems the situation is reversed. The problem does >|*not* arise using dvipdfm. Note that the beam itself is >|produced using tpic specials and so won't appear in, say, >|xdvi output. The musixtex-fonts package must be installed. >| >|Hiroaki Morimoto (the author of the musixvbm add-on that >|produces the vectorized beam) discovered this issue and >|may be able to provide more information. It seems dvips -e0 solves this problem. Bob T. From karl at freefriends.org Mon May 24 00:16:02 2021 From: karl at freefriends.org (Karl Berry) Date: Sun, 23 May 2021 16:16:02 -0600 Subject: [tex-k] vertical line length issue In-Reply-To: <20210523131529.OlF4ZZZ3K%rdt@cs.queensu.ca> Message-ID: <202105232216.14NMG2xc002527@freefriends.org> some of the vertical note stems are too long. On my system the problem arises with -D 300 but not with -D 600, but on other systems the situation is reversed. Yikes. I would welcome a patch. Not likely I'll have a chance to look into the code myself for a while, but it's on the pile. Thanks for the report. -k From rdtennent at gmail.com Mon May 24 01:01:19 2021 From: rdtennent at gmail.com (Bob Tennent) Date: Sun, 23 May 2021 19:01:19 -0400 Subject: [tex-k] vertical line length issue In-Reply-To: <202105232216.14NMG2xc002527@freefriends.org> References: <20210523131529.OlF4ZZZ3K%rdt@cs.queensu.ca> <202105232216.14NMG2xc002527@freefriends.org> Message-ID: It seems to be a feature rather than a bug, apparently intended to align characters in words: Allowing individual characters to `drift' from their correctly rounded positions by a few pixels, while regaining the true position at the beginning of each new word, improves the spacing of letters in words We didn't remember that, for music, the -e0 option is recommended. Bob On Sun, May 23, 2021 at 6:16 PM Karl Berry wrote: > some of the vertical note stems are too long. On my system > the problem arises with -D 300 but not with -D 600, but on > other systems the situation is reversed. > > Yikes. > > I would welcome a patch. Not likely I'll have a chance to look into the > code myself for a while, but it's on the pile. Thanks for the report. -k > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2500418497 at qq.com Tue May 25 12:29:57 2021 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Tue, 25 May 2021 18:29:57 +0800 Subject: [tex-k] A210: nonfinal item should end in a semicolon, not period Message-ID: The TeXbook, page 210, exercise 20.13 says: which of the following are true? (a) `\if\a\b'; (b) `\ifcat\a\b'; (c) `\ifx\a\b'; (d) `\if\c'; (e) `\ifcat\c'; (f) `\ifx\ifx\ifx'. (g) `\if\ifx\a\b\c\else\if\a\b\c\fi\fi'. Why does the next-to-last item end in a period? In 2013 I'd think Knuth must have a reason because he was infallible (a common myth among programmers), but now I suspect this is an editorial oversight. --- By the way, the recent TUGboat article "Lapses in TeX" did't mention that TeX produces bad spacing when typesetting "{\sl The value of $l$ has ...}" but I don't know what the proper spacing should be. No italic correction after the $l$? Or there should be an italic correction after "of"? From karl at freefriends.org Tue May 25 23:47:25 2021 From: karl at freefriends.org (Karl Berry) Date: Tue, 25 May 2021 15:47:25 -0600 Subject: [tex-k] A210: nonfinal item should end in a semicolon, not period In-Reply-To: Message-ID: <202105252147.14PLlPvP021620@freefriends.org> but now I suspect this is an editorial oversight. I suspect so too. Will add to the list when I have a chance. --thanks, karl. From 2500418497 at qq.com Fri May 28 06:38:25 2021 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Fri, 28 May 2021 12:38:25 +0800 Subject: [tex-k] plain.mft: "nodisplay" -> "nodisplays" Message-ID: plain.mft misspells plain METAFONT's "nodisplays" as "nodisplay". It's also very incomplete. Here's what I think is missing: The token ... should be formatted like ... ==================================== ============================ bye end rotatedabout rotatedaround div mod define_good_x_pixels define_pixels define_good_y_pixels " define_whole_vertical_blacker_pixels " define_horizontal_corrected_pixels " cutdraw, cutoff filldraw pensquare, penrazor, penspeck pencircle proofrule, makelabel, makegrid screenrule mode_def mode_setup penlabels labels gfcorners screenchars And the tokens "range" and "thru" can be either in bold or roman font, but certainly not in italic. From karl at freefriends.org Sat May 29 23:27:08 2021 From: karl at freefriends.org (Karl Berry) Date: Sat, 29 May 2021 15:27:08 -0600 Subject: [tex-k] A210: nonfinal item should end in a semicolon, not period In-Reply-To: Message-ID: <202105292127.14TLR8Jx025386@freefriends.org> By the way, the recent TUGboat article "Lapses in TeX" did't mention that TeX produces bad spacing when typesetting "{\sl The value of $l$ has ...}" but I don't know what the proper spacing should be. No italic correction after the $l$? Or there should be an italic correction after "of"? The italic correction after f makes the spacing a little too large to my eyes, but that's probably better than no ic. I would probably insert a manual kern. I might also be tempted to use "value of l has", without math mode, because when the text font is slanted, a math italic l looks distracting to me, rather than helpful. All depends on context. TeX is just doing its job, typesetting the characters it's given. Humans still have to make some choices :). Barbara did mention lack of various kerns, which can be taken as a standin for "suboptimal spacing sometimes". Hard for me to picture what Knuth could have done about this particular case, though. --best, karl. From 2500418497 at qq.com Sun May 30 09:19:58 2021 From: 2500418497 at qq.com (=?gb18030?B?uvrRx73dIChIdSBZYWppZSk=?=) Date: Sun, 30 May 2021 15:19:58 +0800 Subject: [tex-k] mfman.mf, Figure 14e: points 2,2l,2r labeled twice Message-ID: mfman.mf, lines 1272 and 1274: labels.top(2r,2,2l, ... labels.bot(2r,2,2l, ... As a result, the top middle of Figure 14e has these points labeled twice: ________ ________ __-- | 2r | --__ __ | . | __ __--- | | 2r | | ---__ - | | 2 | | - | | . | | | | 2 | | | | 2l | | | | . | | | | 2l | | (Not sure if C139 is correct...) From rdtennent at gmail.com Sun May 30 15:51:32 2021 From: rdtennent at gmail.com (Bob Tennent) Date: Sun, 30 May 2021 09:51:32 -0400 Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines Message-ID: <20210530135132.DlXkIdvRH%rdtennent@gmail.com> The attached dvi was generated by musixtex. xdvi, dvips and yap produce the expected output but dvipdfm[x] generates incorrect output with overly long dashed lines. Bob T. -------------- next part -------------- A non-text attachment was scrubbed... Name: test.dvi Type: application/x-dvi Size: 772 bytes Desc: not available URL: From karl at freefriends.org Sun May 30 23:52:14 2021 From: karl at freefriends.org (Karl Berry) Date: Sun, 30 May 2021 15:52:14 -0600 Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines In-Reply-To: <20210530135132.DlXkIdvRH%rdtennent@gmail.com> Message-ID: <202105302152.14ULqE1I024060@freefriends.org> Hi Bob, Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines It's best to report dvipdfmx problems to its dedicated list, dvipdfmx at tug.org. Although since most of the dvi*fmx developers are on tex-k, I won't forward this one. (Sorry, no clue about the actual problem.) --best, karl. From karl at freefriends.org Sun May 30 23:52:10 2021 From: karl at freefriends.org (Karl Berry) Date: Sun, 30 May 2021 15:52:10 -0600 Subject: [tex-k] mfman.mf, Figure 14e: points 2,2l,2r labeled twice In-Reply-To: Message-ID: <202105302152.14ULqAUX024026@freefriends.org> mfman.mf, lines 1272 and 1274: labels.top(2r,2,2l, ... labels.bot(2r,2,2l, ... As a result, the top middle of Figure 14e has these points labeled twice: (Not sure if C139 is correct...) The printed page has only one occurrence of labels 2r,2,2l. I attach a scan in case your eyes see something different. So I guess the bug is that Don didn't update the distributed mfman.mf. Thanks. -k -------------- next part -------------- A non-text attachment was scrubbed... Name: 139.jpg Type: image/jpeg Size: 488207 bytes Desc: not available URL: From rdtennent at gmail.com Mon May 31 01:28:21 2021 From: rdtennent at gmail.com (Bob Tennent) Date: Sun, 30 May 2021 19:28:21 -0400 Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines Message-ID: <20210530232821.z01zlnarH%rdtennent@gmail.com> >| It's best to report dvipdfmx problems to its dedicated >| list, dvipdfmx at tug.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. Bob From shunsaku.hirata74 at gmail.com Mon May 31 16:41:23 2021 From: shunsaku.hirata74 at gmail.com (Shunsaku Hirata) Date: Mon, 31 May 2021 23:41:23 +0900 Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines In-Reply-To: <20210530135132.DlXkIdvRH%rdtennent@gmail.com> References: <20210530135132.DlXkIdvRH%rdtennent@gmail.com> Message-ID: Hi, The reason for this unexpected result seems to be the incorrect widths recorded in the font "musixspx" as reported by dvipdfmx (with the "-v" option). dvipdfmx:warning: Intolerable difference in glyph width: font=musixspx, char=23 dvipdfmx:warning: font: 901 vs. tfm: 300 dvipdfmx:warning: Intolerable difference in glyph width: font=musixspx, char=25 dvipdfmx:warning: font: 901 vs. tfm: 300 This is caused by inconsistency between Type1 font used for PDF output and TFM. Please fix the font. Thanks, Shunsaku Hirata 2021?5?30?(?) 22:51 Bob Tennent : > > The attached dvi was generated by musixtex. > > xdvi, dvips and yap produce the expected output but > dvipdfm[x] generates incorrect output with overly long > dashed lines. > > Bob T. From rdtennent at gmail.com Mon May 31 17:24:59 2021 From: rdtennent at gmail.com (Bob Tennent) Date: Mon, 31 May 2021 11:24:59 -0400 Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines Message-ID: <20210531152459.4ax1Djq7V%rdt@cs.queensu.ca> >|The reason for this unexpected result seems to be the >|incorrect widths recorded in the font "musixspx" as >|reported by dvipdfmx (with the "-v" option). >| >|dvipdfmx:warning: Intolerable difference in glyph width: font=musixspx, >|char=23 >|dvipdfmx:warning: font: 901 vs. tfm: 300 >|dvipdfmx:warning: Intolerable difference in glyph width: font=musixspx, >|char=25 >|dvipdfmx:warning: font: 901 vs. tfm: 300 >| >|This is caused by inconsistency between Type1 font used >|for PDF output and TFM. Please fix the font. Thank you for this. The type1 musixtex fonts were developed by Takanori Uchiyama in about 2003 and there have been no issues and no changes since then. On the other hand, the current issue with dvipdfmx seems to have started recently and did not arise with earler releases; has something changed in the way dvipdfmx deals with type1 fonts? I also note that no other dviware seems to have a similar issue. Best, Bob T. >|> The attached dvi was generated by musixtex. >|> >|> xdvi, dvips and yap produce the expected output but >|> dvipdfm[x] generates incorrect output with overly long >|> dashed lines. >|> >|> Bob T. From rdtennent at gmail.com Mon May 31 21:14:20 2021 From: rdtennent at gmail.com (Bob Tennent) Date: Mon, 31 May 2021 15:14:20 -0400 Subject: [tex-k] dvipdfm[x] problem with dashed horizontal lines In-Reply-To: References: <20210531152459.4ax1Djq7V%rdt@cs.queensu.ca> Message-ID: I've tried dvipdfmx -v on fontcharts of several of the musixtex fonts and virtually *every* glyph has "Intolerable difference in glyph width". There are some 80 musixtex fonts so "fixing" the fonts would involve adjusting the widths of some 20K glyphs. Do you have any other suggestions? Would a dvipdfmx option to revert to the "wrong" way of doing it be possible? Bob T. On Mon, May 31, 2021 at 12:12 PM Shunsaku Hirata < shunsaku.hirata74 at gmail.com> wrote: > > Thank you for this. The type1 musixtex fonts were developed > > by Takanori Uchiyama in about 2003 and there have been no > > issues and no changes since then. On the other hand, the > > current issue with dvipdfmx seems to have started recently > > and did not arise with earler releases; has something > > changed in the way dvipdfmx deals with type1 fonts? I also > > Yes, I recently made a change. > > Very old versions and recent versions should show the same > behavior. For many years dvipdfmx had been wrongly using > glyph widths taken from TFMs which can be different from the > actual widths recorded in Type1 fonts. > > > note that no other dviware seems to have a similar issue. > > Probably, this is due to the difference in the way how glyphs > are placed: dvipdfmx basically uses relative displacements > for placing glyphs in the output PDF while (probably) others > put each glyphs with absolute positions explicitly specified. > In the latter case inconsistent glyph widths don't affect the > rendered result. > > Thanks, > Shunsaku Hirata > -------------- next part -------------- An HTML attachment was scrubbed... URL: