From tug-news at tug.org Sat Nov 1 23:15:22 2025 From: tug-news at tug.org (TeX Users Group) Date: Sat, 1 Nov 2025 16:15:22 -0600 Subject: Nov25 news: James Mosley, TUGboat, LaTeX, conferences, CTAN Message-ID: <202511012215.5A1MFME3043303@freefriends.org> Hello TeX users, First, James Mosley, an esteemed type scholar of the past half-century, passed away in August; the upcoming TUGboat will have a memoriam. For this newsletter, we wanted to publicize that his lecture series on the history of letterforms is now available publicly: https://www.youtube.com/playlist?list=PLh8Q6TpPxtgxSG6DEuOrH9iKx9bh6Pr7G TUGboat 46:3, the last regular issue for 2025, is at the printer and will mail soon. The deadline for the next issue of TUGboat is March 20, 2026. Early submissions are welcome and greatly appreciated: https://tug.org/TUGboat/location.html -- The LaTeX 2025-11-01 release has been made and will be in the distributions shortly, if not already. Release notes: https://www.latex-project.org/news/latex2e-news/ltnews42.pdf -- Upcoming conferences: - GuIT 2025, in Pisa, Italy, November 5, 2025. https://www.guitex.org/home/en/meeting - Journ\'ee GUTenberg annual meeting, Paris, France, November 8, 2025. https://www.gutenberg-asso.fr/Journee-GUTenberg-2025 - GUTenberg Expos\'es menuels, online video presentations, in French. December 4, 2025: Valentin Dao on his intexgral package and expl3 syntax. January 8, 2026: Jean Abou Samra on Lilypond. https://www.gutenberg-asso.fr/-Exposes-mensuels- - DANTE spring meeting, March 12-14, 2026, at WiWa GmbH, Lahnau, Germany (pre-meeting get-together on March 11). https://www.dante.de/veranstaltungen/dante2026/ - EuroBachoTeX 2026, April 29-May 3, 2026, Bachotek, Poland. https://bachotex.gust.org.pl/index_en.html - OSSConf 2026, July 1-3, 2026, University of \v{Z}ilina, Slovakia, will have a dedicated TeX+R session. The conference will be multilingual. https://ossconf.fri.uniza.sk/ - We are planning for the TUG 2026 conference to take place in Calgary or Edmonton, Alberta, Canada, in one of the latter weekends in July 2026. We will make announcements and update web pages as information becomes available, as always. https://tug.org/tug2026 - ConTeXT meeting 2026: Maibach, Germany, August 24-29, 2026. Theme: Focussing. https://meeting.contextgarden.net/2026/ -- New CTAN packages, October 2025 (for all updates: https://ctan.org/ctan-ann): Information about any CTAN package is available at ctan.org/pkg/PACKAGE-NAME - arsenal-math, Arsenal Math OpenType fonts - beamertheme-bilkent-econ, LaTeX Beamer theme for the Department of Economics at Bilkent University - futharksymb, macros for entering futhark runes - kksymbols, LaTeX commands for enclosing characters in circles, squares, diamonds, or brackets - ktbox, framework for semantic color, structured highlighting, and scholarly communication - latex-formatter, a LaTeX prettyprinter written in Rust - luwa-ul, provides underlines and highlightings which can be used in vertical mode - minted-code, predefined environments for typesetting LaTeX code with minted - panda, a package to estimate the blackness of fonts - pkginfograb, collect LaTeX package information in a regular way - tkz-interval, interval brackets made with TikZ - xtufte, extend the tufte document classes to run with Unicode-aware engines - zeckendorf, Knuth multiplication and Zeckendorf representations of big integers Happy \TeX{}ing, Karl Berry, on behalf of the TUG Board From rolfturner at posteo.net Tue Nov 11 07:39:10 2025 From: rolfturner at posteo.net (Rolf Turner) Date: Tue, 11 Nov 2025 06:39:10 +0000 Subject: Problems with printing envelopes. Message-ID: <20251111193901.6e63acab@new-hp> i have been trying for some time to print "business size" envelopes on my Canon printer from my laptop (which runs Ubuntu 24.04). Note that the business size envelopes that I use are 113 mm x 225 mm. Initially I tried to use the envlab package, but it printed the main address in a very ugly small caps style (intended for optical character recognition). I could find no way to satisfactorily adjust this. I sought help on the StackExchange forum. A very kind person wrote a *.tex document to achieve the desired effect. However their effort remained flawed. I found the syntax of the StackExchange site to be impossible to understand and after a number of attempts to communicate the difficulties that I was having, I gave up. So I am asking here on texhax instead. The essential problem is that the left hand margin (this is actually the *top* margin after the document has been rotated 90 degrees clockwise so as to align the envelope correctly with the printer) is too large. The envelopes come out with a left hand margin of (at least) 35 mm. whereas I would like it to be 12 mm. In the document that my helpful interlocutor provided, the margins seem to be controlled by the quantities "return hoffset" and "return voffset". (See the attached file "demo.tex".) Setting "return voffset=12mm" works just fine. It gives a distance of 12 mm. between the upper edge of the envelope and the top of the return address. As desired. However setting "return hoffset=12mm" produces a distance between the left hand edge of the envelope and the return address which is much too large. Even if this quantity is set to 0mm or 0pt, the distance is still too large. I tried setting it to a negative value, but this had the effect of cutting off a segment of the return address. The part of the return address that actually appeared was still 35 mm. from the left hand edge of the envelope. It seems that a "hard" left hand margin of 35 mm. is imposed and my understanding of the LaTeX code provided is inadequate for me to see how to change this. Can someone, cleverer and more knowledgeable than I, point me in the right direction? I have attached the LaTeX code (that I cannot properly understand), demo.tex, and the resulting demo.pdf file. The document in demo.pdf has been rotated 90 degrees clockwise by my pdf viewer so that it is all ready to be printed onto paper/hard copy. Eternally grateful for any enlightenment that anyone can provide. cheers, Rolf Turner -- Honorary Academic Department of Statistics University of Auckland Stats. Dep't. (secretaries) phone: +64-9-373-7599 ext. 89622 Home phone: +64-9-480-4619 -------------- next part -------------- A non-text attachment was scrubbed... Name: demo.tex Type: text/x-tex Size: 2011 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: demo.pdf Type: application/pdf Size: 27885 bytes Desc: not available URL: From tomas at basun.net Tue Nov 11 13:43:13 2025 From: tomas at basun.net (Tomas By) Date: Tue, 11 Nov 2025 13:43:13 +0100 Subject: Problems with printing envelopes. In-Reply-To: <20251111193901.6e63acab@new-hp> References: <20251111193901.6e63acab@new-hp> Message-ID: <875xbg4u5a.wl-tomas@basun.net> Hello, I have checked your files (and also looked at the question you posted on [La]tex SE), and I have to say the problem seems to be imaginary. If you change to 'voffset=0mm' in the NewEnvelope command (line 73 in demo.tex) then the address is in the corner with no margins. And in your PDF (demo.pdf) the left (or top after rotation), margin seems to be zero (and you have `hoffset=0mm' in the file). Changing to `hoffset=12mm' seems to produce a margin that is the same as the other one, not much larger as you seem to be saying. If there is still an actual problem, you need to explain exactly what you are doing to produce the files, which programs and commands you use. It could be, for example, that the printer driver adds margins. (I'm using standard Latex on latest Ubuntu.) /Tomas On Tue, 11 Nov 2025 07:39:10 +0100, Rolf Turner wrote: > The essential problem is that the left hand margin (this is actually > the *top* margin after the document has been rotated 90 degrees > clockwise so as to align the envelope correctly with the printer) is > too large. The envelopes come out with a left hand margin > of (at least) 35 mm. whereas I would like it to be 12 mm. > > In the document that my helpful interlocutor provided, the margins seem > to be controlled by the quantities "return hoffset" and "return > voffset". (See the attached file "demo.tex".) > > Setting "return voffset=12mm" works just fine. It gives a distance of > 12 mm. between the upper edge of the envelope and the top of the return > address. As desired. > > However setting "return hoffset=12mm" produces a distance between > the left hand edge of the envelope and the return address which is much > too large. Even if this quantity is set to 0mm or 0pt, the distance is > still too large. > > I tried setting it to a negative value, but this had the effect of > cutting off a segment of the return address. The part of the return > address that actually appeared was still 35 mm. from the left hand edge > of the envelope. > > It seems that a "hard" left hand margin of 35 mm. is imposed and my > understanding of the LaTeX code provided is inadequate for me to see > how to change this. > > Can someone, cleverer and more knowledgeable than I, point me in the > right direction? I have attached the LaTeX code (that I cannot > properly understand), demo.tex, and the resulting demo.pdf file. > The document in demo.pdf has been rotated 90 degrees clockwise by my > pdf viewer so that it is all ready to be printed onto paper/hard copy. From tomas at basun.net Tue Nov 11 15:48:24 2025 From: tomas at basun.net (Tomas By) Date: Tue, 11 Nov 2025 15:48:24 +0100 Subject: Problems with printing envelopes. In-Reply-To: <875xbg4u5a.wl-tomas@basun.net> References: <20251111193901.6e63acab@new-hp> <875xbg4u5a.wl-tomas@basun.net> Message-ID: <87tsz039s7.wl-tomas@basun.net> On Tue, 11 Nov 2025 13:43:13 +0100, Tomas By wrote: > It could be, for example, that the printer driver adds margins. I had another look and read trough the comment discussion on SE, and it seems clear the problem must be the printer, and that the easiest solution (as suggested in a comment there) would be to rotate (and load the envelope) in the other direction. Then you should be able to set it correctly. (Or you could figure out how to change printer settings.) /Tomas From rolfturner at posteo.net Thu Nov 13 00:52:02 2025 From: rolfturner at posteo.net (Rolf Turner) Date: Wed, 12 Nov 2025 23:52:02 +0000 Subject: Problems with printing envelopes. In-Reply-To: <87tsz039s7.wl-tomas@basun.net> References: <20251111193901.6e63acab@new-hp> <875xbg4u5a.wl-tomas@basun.net> <87tsz039s7.wl-tomas@basun.net> Message-ID: <20251113125154.19d35364@new-hp> On Tue, 11 Nov 2025 15:48:24 +0100 Tomas By wrote: > On Tue, 11 Nov 2025 13:43:13 +0100, Tomas By wrote: > > It could be, for example, that the printer driver adds margins. > > > I had another look and read trough the comment discussion on SE, and > it seems clear the problem must be the printer, and that the easiest > solution (as suggested in a comment there) would be to rotate (and > load the envelope) in the other direction. Then you should be able to > set it correctly. > > (Or you could figure out how to change printer settings.) > > /Tomas Thanks. Following your suggestion I was able to successfully print the envelope that I required. I found that after doing the rotation through minus 90 degrees I needed to set "return hoffset=48mm" in order to get the appropriate left margin. This then caused the return address to be too close to the main address. I solved this problem (in a shaganappi manner) by pre-pending "\hspace*{9cm} to each line of the main address. I'm sure I could have done this in a more organised manner if I understood the LaTeX code properly. Note that before trying this I attempted to change the printer settings. I tried this both with the "Printers" item from the Control Center on my laptop, and with the LCD screen on the printer. In both instances I made changes that seemed appropriate. None had any effect. Thanks again. cheers, Rolf -- Honorary Academic Department of Statistics University of Auckland Stats. Dep't. (secretaries) phone: +64-9-373-7599 ext. 89622 Home phone: +64-9-480-4619 From karl at freefriends.org Sat Nov 15 18:24:49 2025 From: karl at freefriends.org (Karl Berry) Date: Sat, 15 Nov 2025 10:24:49 -0700 Subject: expl3 test if a string starts with a given prefix Message-ID: <202511151724.5AFHOnIb027051@freefriends.org> Using expl3, I'd like to test if a given "string" (argument) starts with a given prefix, namely "http://". For a prefix of a given length, 7 in my case, I guess the idea is to extract the first 7 tokens using str_range and then compare them with \str_if_eq? But I cannot get the details right. Here's my best attempt (with help from various bots). Is it at all close? \documentclass{article} \begin{document} \ExplSyntaxOn \cs_new:Npn \astr_if_starts_with:nnTF #1#2 { % #1 = prefix to test % #2 = full string \str_if_eq:nnTF { \str_range:nnn {#2} {1} { \str_count:n {#1} } } { #1 } } \str_if_starts_with:nnTF {abc} {abcdef} { \message{prefix} } { \message{notprefix} } \end{document} This feels like an easy expl3 programming question, but evidently I've failed to grok interface3.pdf. FWIW, the real context is this, from tugboat.dtx (with thanks to Ulrike): \def\tbsurl@#1 { \str_set:Nn\l_tmpa_str{#1} \str_if_in:NnTF \l_tmpa_str {http://} ... % an http:// url where I need to replace \str_if_in with some other function that checks if http:// is only the *beginning* of \l_tmpa_str, not anywhere within it. Because archive.org routinely embeds "http://" in their urls, e.g., https://web.archive.org/web/20090809184749/http://www.eco-log.de/ Thanks, Karl From accounts at mareipeischl.de Sat Nov 15 18:33:47 2025 From: accounts at mareipeischl.de (Marei Peischl) Date: Sat, 15 Nov 2025 18:33:47 +0100 Subject: expl3 test if a string starts with a given prefix In-Reply-To: <202511151724.5AFHOnIb027051@freefriends.org> References: <202511151724.5AFHOnIb027051@freefriends.org> Message-ID: Hi Karl, you can use \regex_if_match, which you could even extend to check https the same way: e.g. \documentclass{article} \begin{document} \ExplSyntaxOn \regex_if_match:nnTF {^https?://} {http://xxxxxxx} { \message{prefix} } { \message{notprefix} } \end{document} Best, Marei On 15/11/2025 18.24, Karl Berry wrote: > Using expl3, I'd like to test if a given "string" (argument) starts with > a given prefix, namely "http://". For a prefix of a given length, 7 in > my case, I guess the idea is to extract the first 7 tokens using > str_range and then compare them with \str_if_eq? But I cannot get the > details right. Here's my best attempt (with help from various bots). Is > it at all close? > > \documentclass{article} > \begin{document} > \ExplSyntaxOn > \cs_new:Npn \astr_if_starts_with:nnTF #1#2 > { > % #1 = prefix to test > % #2 = full string > \str_if_eq:nnTF > { \str_range:nnn {#2} {1} { \str_count:n {#1} } } > { #1 } > } > \str_if_starts_with:nnTF {abc} {abcdef} > { \message{prefix} } > { \message{notprefix} } > \end{document} > > This feels like an easy expl3 programming question, but evidently I've > failed to grok interface3.pdf. > > FWIW, the real context is this, from tugboat.dtx (with thanks to > Ulrike): > > \def\tbsurl@#1 > { > \str_set:Nn\l_tmpa_str{#1} > \str_if_in:NnTF \l_tmpa_str {http://} > ... % an http:// url > > where I need to replace \str_if_in with some other function that checks > if http:// is only the *beginning* of \l_tmpa_str, not anywhere within > it. Because archive.org routinely embeds "http://" in their urls, > e.g., https://web.archive.org/web/20090809184749/http://www.eco-log.de/ > > Thanks, > Karl From Ross.Boylan at ucsf.edu Fri Nov 21 10:06:33 2025 From: Ross.Boylan at ucsf.edu (Boylan, Ross) Date: Fri, 21 Nov 2025 09:06:33 +0000 Subject: listings fails in certain corner cases Message-ID: I was unable to latex my input file in some cases, getting the following error on a line inside of a lstlisting environment from the listings package: ERROR: Extra }, or forgotten \endgroup. --- TeX said --- \egroup l.68 and I go on I have attached a MWE, which is not so small. There seem to be at least 2 necessary ingredients: 1. The \begin{lstlisting} starts at or near the bottom of one page, but the output it produces ends up on the next page. 2. The page header and footer (fancyhdr package) contains some text that uses \lstinline. The first, alone, is insufficient. This is with listings 1.11a (r76857), but I was getting the same problem with 1.10c. After generating the attachments I upgraded listings to 1.11b; it made no difference. Possibly the problem depends on some peculiarities of shipping the section title around for extramarks. I think I have seen the problem even when the first line of the listing does end up on the bottom of the page before the rest continues on the next. Papersize is default, which should be US Letter for me. In some cases I've found putting a conditional break just before the listing (e.g., with the needspace package) is enough to clear up the problem. Removing the \lstinline from the section name also "solves" it. Even in simple cases, i.e., 1 but not 2, I still get strange behavior: later sections of the listing switch to showing spaces explicitly. It would be great if this just worked. By the way, the listings manual doesn't say anything explicitly that I could find about how or if it handles material that crosses pages, though there is some discussion of float behavior. Thanks. Ross Boylan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test2.tex Type: application/x-tex Size: 980 bytes Desc: test2.tex URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test2.log Type: application/octet-stream Size: 4393 bytes Desc: test2.log URL: From daleif at math.au.dk Fri Nov 21 10:45:14 2025 From: daleif at math.au.dk (Lars Madsen) Date: Fri, 21 Nov 2025 09:45:14 +0000 Subject: listings fails in certain corner cases In-Reply-To: References: Message-ID: Using a \lstinline inside a \section seems like a very big no-no to me. Without it the document compiles just fine. Lars Madsen Programm?r Institut for Matematik Aarhus Universitet person.au.dk/daleif at math ________________________________ From: texhax on behalf of Boylan, Ross via texhax Sent: 21 November 2025 10:06 To: 'texhax at tug.org' ; 'j.hoffmann at fh-aachen.de' Cc: Ross Boylan ; Boylan, Ross Subject: listings fails in certain corner cases I was unable to latex my input file in some cases, getting the following error on a line inside of a lstlisting environment from the listings package: ERROR: Extra }, or forgotten \endgroup. --- TeX said --- \egroup l.68 and I go on I have attached a MWE, which is not so small. There seem to be at least 2 necessary ingredients: 1. The \begin{lstlisting} starts at or near the bottom of one page, but the output it produces ends up on the next page. 2. The page header and footer (fancyhdr package) contains some text that uses \lstinline. The first, alone, is insufficient. This is with listings 1.11a (r76857), but I was getting the same problem with 1.10c. After generating the attachments I upgraded listings to 1.11b; it made no difference. Possibly the problem depends on some peculiarities of shipping the section title around for extramarks. I think I have seen the problem even when the first line of the listing does end up on the bottom of the page before the rest continues on the next. Papersize is default, which should be US Letter for me. In some cases I?ve found putting a conditional break just before the listing (e.g., with the needspace package) is enough to clear up the problem. Removing the \lstinline from the section name also ?solves? it. Even in simple cases, i.e., 1 but not 2, I still get strange behavior: later sections of the listing switch to showing spaces explicitly. It would be great if this just worked. By the way, the listings manual doesn?t say anything explicitly that I could find about how or if it handles material that crosses pages, though there is some discussion of float behavior. Thanks. Ross Boylan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wburkhard at ucsd.edu Sat Nov 29 08:30:09 2025 From: wburkhard at ucsd.edu (Walter Burkhard) Date: Fri, 28 Nov 2025 23:30:09 -0800 Subject: MetaPost question Message-ID: Hello, I have attached a mpost program that provides for me a problem. The visual result is a complete graph on 6 nodes. There are six "external" edges as well as 15 "internal" edges. All the internal edges contain a number displayed twice. However when initially writing the program, I used the assignment := on the second occurance. But the MetaPost processor doesn't accept this. But I notice the ppp path is updated 5 times with this approach. I have attached the MetaPost program sixSLP.mp, a short TeX program sixSLP.tex as well as the visual output sixSLP.pdf. Comments would be greatly appreciated. Walt Burkhard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sixSLP.mp Type: application/octet-stream Size: 3546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sixSLP.tex Type: application/x-tex Size: 51 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sixSLP.pdf Type: application/pdf Size: 7195 bytes Desc: not available URL: From andreas_tex at freenet.de Sat Nov 29 16:58:37 2025 From: andreas_tex at freenet.de (Andreas Scherer) Date: Sat, 29 Nov 2025 16:58:37 +0100 Subject: MetaPost question In-Reply-To: References: Message-ID: <2ff6d53c-7827-42d0-8852-bdb7d09ab5e5@freenet.de> Hello, Walter, > Comments would be greatly appreciated. I suggest to relabel some of the edges. Apart from that, I see no fault with either your MetaPost nor TeX codes. Best, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: sixSLP.pdf Type: application/pdf Size: 7212 bytes Desc: not available URL: From d.p.carlisle at gmail.com Sun Nov 30 21:41:54 2025 From: d.p.carlisle at gmail.com (David Carlisle) Date: Sun, 30 Nov 2025 20:41:54 +0000 Subject: Testing OpenType math fonts Message-ID: Neil Soiffer and I have put together a new website for testing OpenType Math fonts. https://mathfonts.github.io/ It's targeted mostly at MathML rendering, but also includes tests that generate PDF files (at texlive.net) that show the lualatex rendering of supplied expressions with all the fonts. There are around 30 fonts available here, which is all the freely available OpenType math fonts, as far as we know. David -------------- next part -------------- An HTML attachment was scrubbed... URL: