May 2022 - dev-luatex - NTG Mailing Lists

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 06 May '23

06 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

Re: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files
by Norbert Preining 04 May '22

04 May '22

Hi Luigi, hi all luatex devs, here at Debian we got a bug report about reproducability of luatex format dumps. It contains a patch to make the hyphenation exception list sorted. (I attach the patch) Could you please take a look whether this is still relevant for the latest release of luatex. Thanks Norbert On Fri, 08 Apr 2022, Roland Clobus wrote: > Hello maintainers of texlive-binaries, > > While working on the “reproducible builds” effort [1], I have noticed that the > live image for Cinnamon in bookworm is no longer reproducible [2]. > > The attached patch ensures that the output of the function 'exception_strings' > always uses the same order of the hyphenation exceptions. > I've written the solution in C, perhaps someone more versed in lua could > rewrite it more elegantly. > (The lua manual says for the 'next' function: 'The order in which the indices > are enumerated is not specified' [3]) > > With the attached patch applied, I'm able (with the help of FORCE_SOURCE_DATE=1 > and SOURCE_DATE_EPOCH) to reproducibly rebuild the .fmt files, as created by > 'fmtutil --sys --all'. > > Small test case to reproduce: > export FORCE_SOURCE_DATE=1 > export SOURCE_DATE_EPOCH=$(date +%s) > for i in `seq 1 10`; do luahbtex -ini -jobname=luahbtex -progname=luabhtex > luatex.ini > /dev/null; md5sum luahbtex.*; done > > With kind regards, > Roland Clobus > > [1]: https://wiki.debian.org/ReproducibleBuilds > [2]: > https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_cin… > [3]: http://www.lua.org/manual/5.4/manual.html#pdf-next > -- PREINING Norbert https://www.preining.info Mercari Inc. + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

4 14

Feature request: busy pdf
by Jérôme LAURENS 04 May '22

04 May '22

New CLI options --busy related to typesetting luatex --busy=0 default behavior, nothing new luatex --busy=1 Instead of writing the pdf output to jobname.pdf, write to jobname.pdf(busy) At the end remove any jobname.pdf and move jobname.pdf(busy) to jobname.pdf luatex --busy=2 foo.tex If there is a jobname.pdf(busy) bail out with a diagnostic message « typesetting already in progress » Otherwise do like --busy=1 Actually, the pdf is removed at the start of the typesetting process such that it is no longer available during that whole time. When the typesetting is a bit long, it is not practical at all. For continuous typesetting neither. Considering that we work in general on the end of a document, the first pages will not change a lot but are no longer available. synctex already supports this « busy » busyness such that the previous .synctex file is available during next typesetting process.

3 17