dev-luatex November 2022

dev-luatex@ntg.nl

5 participants
7 discussions

Luatex 1.12.0 announcement.
by luigi scarso 27 May '23

27 May '23

============================================================== LuaTeX 1.12.0 2020-03-15 ============================================================== This is the release for TeX live 2020. --shell-restricted now forbids loading of dso (dll/so object) Scaled virtual font Aadditional primitives \eTeXglue[stretch|shrink]order for querying order the etex way. Extra features runtoks tex.getmodenames() (as these can differ per engine/version) Permit nested runtoks in more complex situations of nesting (HH) More accurate and correct test for tex.[set|get]math Minor clean-up and bugs fixed -- luigi

4 8

Fix for pdf_literal Lua string / token list conversions
by Michal Vlasák 07 May '23

07 May '23

Hello, take this plain LuaTeX example: \setbox0=\hbox{\pdfextension literal{0 g}} % 1) \directlua{ local literal = tex.getbox(0).head texio.write_nl("log", "literal.data="..literal.data) } \showbox0 % 2) \directlua{ local literal = tex.getbox(0).head literal.data = "test" literal.token = "toks" texio.write_nl("log", "literal.token="..(literal.token or "nil")) } \showbox0 % 3) patch test \directlua{ tex.set("everyjob", "asd") texio.write_nl("log", tex.get("everyjob")) } \bye Expected log output (abridged): 1) literal.data=0 g .\pdfliteral origin{0 g} 2) literal.token=toks .\pdfliteral origin{toks} Actual output: 1) literal.data=data .\pdfliteral origin{0 g} 2) literal.token=characters .\pdfliteral origin <lua data reference 153> In the first case the Lua accessor returns a value which happens to be on top of the stack (the key "data" itself). In the second case an index into TeX memory is misinterpreted as a Lua registry index, so the returned data is essentially garbage. Patch for both issues is attached. I also extended `tokenlist_from_lua` (which is what `nodelib_gettoks` is defined as) to allow an index argument. The previous version used the value on top of the stack, which probably worked for every use currently in LuaTeX, but seemed rather dangerous and subtle. The patch is from git, though it can be applied normally with patch -Np1 < pdf_literal.patch Kind regards, Michal Vlasák

2 3

Wrong tail in node.ligaturing
by Marcel Fabian Krüger 03 Dec '22

03 Dec '22

Hi, in LuaTeX node.ligaturing should return the head and the tail of the list after ligatures got applied. But in the case that the tail of the new list is a discretionary the current code returns the passed in tail instead, assuming that it didn't change. This breaks if the discretionary node wasn't the tail before the ligature pass:. Take for example \directlua{ local b = token.scan_list() local h = b.head local t = node.tail(h) local post_h, post_t = node.ligaturing(h, node.tail(t)) print(node.tail(post_h), post_t) }\hpack{a\discretionary{}{f}{f}f} \bye Here the `f`s in the discretionary form ligatures with the `f` after the discretionary, so after node.ligaturing the list if effectively `a\discretionary{}{ff}{ff}` and therefore `post_t` should point to the discretionary node. But as the output shows, post_t instead is a glyph node while node.tail(post_h) is the expected disc node. This is caused by `handle_lig_word` in luafont.c. `handle_lig_word` is used in `handle_ligaturing` as while (cur != null) { if (type(cur) == glyph_node || (type(cur) == boundary_node)) { cur = handle_lig_word(cur); } prev = cur; cur = vlink(cur); } so it is expected that handle_lig_word returns the last node already handled so that afterwards the loop can continue at vlink(cur). But if the handled segment ends with a discretionary `handle_lig_word` returns the node `after` the last already handled node instead. This is fine if the last node is a non glyph/non boundary node, but if the discretionary ends the segment passed to handle_ligaturing than this means that `handle_lig_word` returns null, therefore settings `prev` to `null` instead of tracking the tail. Also this relies on `vlink(null)` being null, causing issues if this ever gets corrupted (see my next mail for an example...). It can be fixed by making sure that handle_lig_word always returns the last handled node, e.g. using diff --git a/source/texk/web2c/luatexdir/font/luafont.c b/source/texk/web2c/luatexdir/font/luafont.c index 2e08facb1..c33037244 100644 --- a/source/texk/web2c/luatexdir/font/luafont.c +++ b/source/texk/web2c/luatexdir/font/luafont.c @@ -2242,6 +2242,7 @@ static halfword handle_lig_nest(halfword root, halfword cur) static halfword handle_lig_word(halfword cur) { halfword right = null; + halfword last = null; if (type(cur) == boundary_node) { halfword prev = alink(cur); halfword fwd = vlink(cur); @@ -2481,9 +2482,10 @@ static halfword handle_lig_word(halfword cur) } else { /*tex We have glyph nor disc. */ - return cur; + return last; } /*tex Goto the next node, where |\par| allows |vlink(cur)| to be NULL. */ + last = cur; cur = vlink(cur); } return cur; -- Best regards, Marcel

2 2

Dropped kerning around automatic hyphens
by Marcel Fabian Krüger 03 Dec '22

03 Dec '22

Hi, currently LuaTeX does not insert kerning between hyphens and characters before discretionary hyphens if the hyphen was inserted automatically. Take for example (here `a` is used as hyphenation character to simulate a font where kerning with the hyphen is mmre common than in cmr): \showboxdepth=\maxdimen \showboxbreadth=\maxdimen \tracingonline=1 \lefthyphenmin1 \righthyphenmin1 \hyphenation{V-b} \prehyphenchar=`a \setbox0=\vbox{Vb} \showbox0 \bye This results in [...] ..\tenrm V ..\discretionary (penalty 50) ...< \tenrm a ..\tenrm b [...] with no kern between the `V` and the `a`. If the hyphenation point is inserted manually by using \setbox0=\vbox{V\-b} instead the problem disappears and we get the expected [...] ..\tenrm V ..\discretionary (penalty 50) ...< \kern-0.83334 (font) ...< \tenrm a ..\tenrm b [...] Additionally the broken version writes the dropped kern node to vlink(null) breaking any code which relies on vlink(null) being null (see e.g. my previous mail). The issue is that `add_kern_before` in luafont.c relies on alink of the right glyph being valid. Since the right glyph here is the "hyphen" glyph in a discretionary this depends on what `alink` for the beginning of a discretionary list is. Currently this is inconsistent. When set through `set_disc_field` then the `alink` is explicitly set to null to avoid exposing the temporary "nodes" in discretionaries to Lua code. his triggers the bug since the kern gets added after null instead of before the right glyph. If the discretionary gets inserted through a discretionary_cmd by append_discretionary in maincontrol.c then the alink gets explicitly set to these pseudo nodes instead avoiding the issue. It doesn't make much sense to handle this inconsistently this is likely and internal nodes are already exposed in other places, so IMO the best solution is to alink to these nodes in set_disc_field too, e.g. with diff --git a/source/texk/web2c/luatexdir/lang/texlang.c b/source/texk/web2c/luatexdir/lang/texlang.c index a0d067251..3cbbdd3b4 100644 --- a/source/texk/web2c/luatexdir/lang/texlang.c +++ b/source/texk/web2c/luatexdir/lang/texlang.c @@ -470,12 +470,7 @@ static halfword compound_word_break(halfword t, int clang) void set_disc_field(halfword f, halfword t) { if (t != null) { - /*tex - No |couple_nodes(f, t);| as we can better not expose |f| as |prev| - pointer. - */ - vlink(f) = t ; - alink(t) = null ; + couple_nodes(f, t); tlink(f) = tail_of_list(t); } else { vlink(f) = null; -- Best, Marcel

2 1

Re: [Dev-luatex] \Udelcodenum doesn't work properly
by Hans Hagen 18 Nov '22

18 Nov '22

On 11/18/2022 12:25 PM, Petr Olsak wrote: > Sorry, > > I need to set delcodes to Unicode fonts and read them. LuaTeX manual > says that > > ----- > > The following new primitives are compatible with XƎTEX: > > ... > > \Udelcode > > \Udelcodenum > > ----- > > and XeTeX manual says that \Udelcode <charnum>=<family><slot> can save > delcode. and \Udelcodenum can read or save packed <family>/<slot> data > (the packed format isn't specified, but it doesn't matter). I am using > \Udelcode for setting delcode data. I don't know nothing else how to do > this. Now, I need to read saved delcode data using \Udelcodenum for > debugging purposes. Is there another way for saving and reading it? I am > talking only about Unicode fonts, i.e. there is only single pair > <family><slot>, no two pairs like in the classical \delcode. \def\theUdelcodesmallfam {\directlua{tex.print(tex.getdelcode(token.scan_int())[1])}} \def\theUdelcodelargefam {\directlua{tex.print(tex.getdelcode(token.scan_int())[3])}} \def\theUdelcodesmallchar {\directlua{tex.print(tex.getdelcode(token.scan_int())[2])}} \def\theUdelcodelargechar {\directlua{tex.print(tex.getdelcode(token.scan_int())[4])}} \theUdelcodesmallfam \la\ \theUdelcodelargefam \la\ \theUdelcodesmallchar\la\ \theUdelcodelargechar\la\ (as you can also set them there's actually always two pairs) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

1 0

\Udelcodenum doesn't work properly
by Petr Olsak 18 Nov '22

18 Nov '22

Hello The XeTeX manual says that \Udelcodenum sets or return packet information about family/slot of the \Udelcode data. It seems that it doesn't work in LuaTeX: \chardef\lx="027E8 \Udelcode\lx=1 "027E8 \the\Udelcodenum\lx % prints 42893312, i.e. "28E8000 \Udelcodenum\lx=\Udelcodenum\lx \the\Udelcodenum\lx % prints -381681664 \bye The slot code "027E8 is mixed with 01 family and \Udelocodenum returns "28E8000. Of course, if I set new Udelcode data using \Udelcodenum\lx=\Udelcodenum\lx then I get totally bad result. On the other hand, XeTeX runing on the same testing file prints in both cases 1075849192, i.e "402027E8. The slot code "027E8 isn't mixed with the family number. Petr Olsak

2 1

\intop without \nolimits gives bas spacing
by Petr Olsak 17 Nov '22

17 Nov '22

Hello suppose following testing file: ------------------- CM, intop+nolimits: $\intop\nolimits_0^1$ CM, intop directly: $\intop_0^1$ \ifx\directlua\undefined \else \input luafonts \fi \font\fA=[latinmodern-math]:mode=base;script=math;ssty=0; \font\fB=[latinmodern-math]:mode=base;script=math;ssty=1; at7pt \Umathchardef\intop="1"00"00222B \textfont0=\fA \scriptfont0=\fB LM, intop+nolimits $\intop\nolimits_0^1$ LM, intop directly $\intop_0^1$ \bye ------------------- The first two output lines print integral via classical PlainTeX setting with Coputer Modern fonts. We can see that there is no difference between \intop without \nolimits and with \nolimits. The following two output lines shows LatinModern-math Unicode font. First prints \intop with \nolimits, the result is with somewhat tightly spacing but it is not our problem. This is due to suboptimal font parameters. But the last line prints \intop without \nolimits and there is significantly difference: big space after \intop before limits. IMHO, it is a bug in LuaTeX. If we run the same testing file via XeTeX then there is no difference between third and last line of output. Petr Olsak

2 2

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

dev-luatex November 2022