- dev-luatex - NTG Mailing Lists

Problem with directlua and synctex_tag
by Jérôme LAURENS 30 Mar '22

30 Mar '22

We can use ``` \directlua{tex.set_synctex_tag(421)} \directlua{print('421=',tex.get_synctex_tag())} \bye ``` To set and read the synctex tag. But if we wrap this into a macro, things get broken and the synctex tag is not changed. ``` \def\test{\directlua{tex.set_synctex_tag(421)}} \test \directlua{print('421=',tex.get_synctex_tag())} \bye ``` For synctex_line there is no such problem. Is this a bug or a feature ?

4 13

Re: [Dev-luatex] 2 characters shift in error context
by luigi scarso 28 Mar '22

28 Mar '22

On Sun, Mar 27, 2022 at 5:11 PM Ikumi Keita <ikumikeita(a)jcom.home.ne.jp> wrote: > Hi, > > >>>>> luigi scarso <luigi.scarso(a)gmail.com> writes: > > I have checked it but luatex and pdftex manage the split the line in > > different way. > > For example this gives a different log > > Nullam eu ante vel est convallis dignissim.0123456789} Nulla posuere. > > \bye > > I will look at the xetex output closely. > > Do you have any news about this? > Sorry for the delay. I have to postpone it, no time now . I am not sure that I will fix it because I don't see a bug (yet). -- luigi

3 2

Re: [Dev-luatex] LuaLaTeX -- hyperlink with ragged right
by Suki, Venkatesan (TNQ Software) 26 Mar '22

26 Mar '22

Please send the LaTeX markup code also... SKV On Sat, 26 Mar, 2022, 8:34 am Kunchitapadam, Baskaran (TNQ Software), < n.k.baskaran(a)tnqsoftware.co.in> wrote: > Hi Team, > > I am working in LuaLaTeX templates. I have face the below issue in title > formatting. I have ragged right title content which is hyperlinked. > > Each line end blank also covered hyper link. We need to format like the > last line in below image. Kindly suggest a solution. > > -- > > Thanks and Regards > > Baskaran NK > > Tech. Lead – 4722 / 4847 > > M : +91 9840928250 > > TNQ Technologies Pvt. Ltd. > > Linkedin <https://www.linkedin.com/company/tnqtechnologies/> | Twitter > <https://twitter.com/TNQtechnologies> | Facebook > <https://www.facebook.com/TNQTechnologies> > > T : +91 44 4596 4800 | tnq.co.in <http://www.tnq.co.in/> > > > -- Disclaimer: The entire content of this email message, including any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or part of the entity, you should not disseminate, distribute, or copy this email. Please notify the sender immediately by e-mail if you have received this email by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

2 characters shift in error context
by Ikumi Keita 21 Mar '22

21 Mar '22

Hello LuaTeX developers, I have a few questions I'd like to ask you. In log message, luatex engine produces slightly different error context from what pdftex does. Here is a sample code: ---------------------------------------------------------------------- Nullam eu ante vel est convallis dignissim. } Nulla posuere. \bye ---------------------------------------------------------------------- When I process this file by luatex, it results in the following error: ------ luatex result ------------------------------------------------- ! Too many }'s. l.1 Nullam eu ante vel est convallis dignissim. } Nulla posuere. ---------------------------------------------------------------------- On the other hand, pdftex results in: ------ pdftex result ------------------------------------------------- ! Too many }'s. l.1 Nullam eu ante vel est convallis dignissim. } Nulla posuere. ---------------------------------------------------------------------- The output of luatex is shifted by two characters compared with that of pdftex. (I'm using TeX Live 2021.) This discrepancy confuses preview-latex (subsystem of AUCTeX), which depends on the precise position of the log messages: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54200 I'm not sure whether this behavior is a bug or not, but is it something I can expect to be fixed? If not, is there any workaround to make the output the same as pdftex? (e.g. command line option) Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine

3 8

bug with \showbox
by Petr Olsak 08 Mar '22

08 Mar '22

Suppose this file: -------------- \immediate\openout0=test.ref \setbox13=\hbox{aha} \showbox13 \end -------------- If I run "luatex file", it ends without errors and the \showbox result is written in the test.ref file. But if the \openout line is commented or it is opened another output stream than zero, then the behavior is correct: it ends with: ---------------- ! OK (see the transcript file). l.5 \showbox13 ? ---------------- luatex --credits: This is LuaTeX, Version 1.15.0 (TeX Live 2022) ... Development id: 7503 The luatex from TL2021 (id 7430) does have this problem, i.e the \showbox result is in transcript file always. Regards Petr Olsak

2 1

Make the late_lua node accessible from the executed code
by Marcel Fabian Krüger 01 Mar '22

01 Mar '22

Hi, one issue I regularly encounter with late_lua whatits is that they don't allow the executed code to determine which node is currently executed. Especially this means that attributes and properties can't be reliably accessed and the code can't access related nodes next to the late_lua node. This can be worked around by storing a closure in the data field which captures a reference to the node, but this breaks in hard to debug ways when the node is copied and the copied node has the same code but a different identify. Therefore it would be great if there would be a way to access the currently evaluated late_lua whatsit node. I would have suggested passing this as an argument to the executed function, but that could break compatbility and it would appear odd due to LuaMetaTeX using the second argument of lua functions is different ways. So the attached suggested implemention instead adds a separate function which allows to access this node: node.current_latelua (or node.direct.current_latelua) Best, Marcel

2 2

Weird behavior of \exceptionpenalty
by Marcel Fabian Krüger 25 Feb '22

25 Feb '22

Hi, in an discussion on TeX StackExchange \exceptionpenalty came up and it's current behavior seems a bit odd and is at odds with the documentation: According to the manual: > Because we introduced penalties in discretionary nodes, the exception syntax now > also can take a penalty specification. The value between square brackets is a multiplier for > \exceptionpenalty. Here we have set it to 10000 so effectively we get > 30000 in the example. and then shows the example \hyphenation{z{a-}{-b}{z}{a-}{-b}{z}[3]{a-}{-b}{z}[1]{a-}{-b}{z}z} As the text says, it could be expected that this causes a penalty of 30000. But the currently implemented behavior is different: It assigns a penalty of 10000 to the second discretionary. The reason is that the number in square brackets is only used as a multiplier if exception_penalty is higher than 100000 (sic). For any value of \exceptionpenalty lower or equal to 100000, the number is ignored and the value of \exceptionpenalty is used as is. I'm not sure if this is just a bug (maybe 100000 was supposed to be a upper limit and not a lower limit?) or if this is intended to be used as a marker which later gets replaced by some callback and therefore 100000 was intentionally used as a unrealistic penalty value, but I think that at least the documentation should get fixed. I'm happy to provide a patch for this if you tell me what to implement. I basically see the following options: * Just change the manual to describe the implemented behavior. I think that this would be sad since it makes the feature much less useful since having multiples of badness higher than 100000 seems to have few applications, but this could be picked up by callbacks ansd would be the most compatible option. * Decide that The documentation is more important than the implemented behavior and fix the code to implement the documentation, removing the 100000 criterium (or making it an upper limit instead of a lower one) If 100000 becomes an upper limit, it would also be possible to substract 100000 from exception_penalty before using it to allow emulating the old behavior of using a fixed exception_penalty. (Of course, the opposite: Keep the current code but reduce \exceptionpenalty by 100000 first in the multiplication case could also be done, but IMO that would be a weird interface.) * Add a new flag to select between the new and old behavior or add a new bit to \hyphenationmode. Best, Marcel

2 1

Is \toksapp assignment?
by Petr Olsak 07 Feb '22

07 Feb '22

Hello, If I try: \def\test{test} \afterassignment\test \advance\count0 by2 then \test is processed immediately after the \advance command. But if I do: \afterassignment\test \toksapp 0{xx} \the\toks0 then \test waits to another assignment than \toksapp. It means, that \toksapp <toks> (and friends \gtoksapp etc.) is not assignment. Is it an intention or a bug? Petr Olšák

4 6

What is the current lfs version?
by Jérôme LAURENS 01 Feb '22

01 Feb '22

We can obtain the current lfs version by running luatex '\directlua{tex.write(lfs._VERSION)}\bye' && open texput.pdf Then we must remove texput.pdf and texput.log. This is a bit cumbersome. It would be great if this information could be in the credits: luatex --credits luajittex --credits BTW, is lfs 1.8 planned in forthcoming? (1.7 does not play with windows very well)

3 2

Re: [Dev-luatex] bug#48064: texlive-* packages fail to build non-deterministically
by Ludovic Courtès 31 Dec '21

31 Dec '21

Hello, While investigating luatex crashes in the TeX Live 2020 package of GNU Guix¹, we identified the following heap corruption reported by Valgrind (this is on GNU/Linux, with glibc 2.33): --8<---------------cut here---------------start------------->8--- sh-5.0$ ~ludo/.guix-profile/bin/valgrind --extra-debuginfo-path=/gnu/store/f933bvd6ab6l2lg6xl6k1a6jwvcls0z6-glibc-2.33-debug/lib/debug "luatex" "-interaction=nonstopmode" "-output-directory=build" "&luatex" "amsbsy.dtx" ==28531== Memcheck, a memory error detector ==28531== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==28531== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==28531== Command: luatex -interaction=nonstopmode -output-directory=build &luatex amsbsy.dtx ==28531== This is LuaTeX, Version 1.12.0 (TeX Live 2020) restricted system commands enabled. ==28531== Invalid write of size 8 ==28531== at 0x485C691: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x45118D: main (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== Address 0xae14170 is 0 bytes after a block of size 1,168 alloc'd ==28531== at 0x483EBE1: realloc (in /gnu/store/jlmh0jbgr6zn4iyvhfbvxps8pykzj5ry-valgrind-3.16.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==28531== by 0x46695D: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x486D932: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x48660F2: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868BE7: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868FCF: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x486988B: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x485C6BB: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== ==28531== Invalid write of size 4 ==28531== at 0x485C6A2: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x45118D: main (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== Address 0xae14178 is 8 bytes after a block of size 1,168 alloc'd ==28531== at 0x483EBE1: realloc (in /gnu/store/jlmh0jbgr6zn4iyvhfbvxps8pykzj5ry-valgrind-3.16.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==28531== by 0x46695D: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x486D932: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x48660F2: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868BE7: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x4868FCF: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x486988B: ??? (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x485C6BB: lua_pushlstring (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/lib/libtexlua53.so.5.3.5) ==28531== by 0x568E03: load_hyphenation (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x56B41C: undump_language_data (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4DFB9F: load_fmt_file (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== by 0x4EF0ED: main_body (in /gnu/store/w20xxg8p0wksbrxxvj3y46fngvr3954w-texlive-bin-20200406/bin/luatex) ==28531== [...] valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 1232, hi = 68. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata. If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away. Please try that before reporting this as a bug. --8<---------------cut here---------------end--------------->8--- Does that ring a bell? Is there a chance this problem was fixed in the meantime? Thanks in advance, Ludovic. ¹ https://issues.guix.gnu.org/48064

3 4