dev-luatex March 2019

dev-luatex@ntg.nl

8 participants
10 discussions

Luatex 1.08.0 announcement
by luigi scarso 28 Oct '19

28 Oct '19

============================================================== LuaTeX 1.08 2018-08-28 ============================================================== (1) This release is a prelude to 1.10, the next stable iteration of LuaTeX after version 1.00. (2) Lua 5.3 is now considered to be default and we might use 5.4 in version 1.10. There are no real functional changed expected. You still need to rename the binary for 5.3! (3) Binary mode is no longer available in MPlib but it is still available in stand alone MetaPost. This simplifies compilation and reduces dependencies. (4) The dependency on Poppler for pdf image inclusion has been removed. We now use a small dedicated library written by Pawel Jakowski. We no longer need c++ compilers. We're in the process of making it behave well on all platforms. It has been tested on intel platforms. (5) We know that there can be some (alignment) issues with the arm platform but these are looked into. Therefore, later this year we will release 1.09. Version 1.10 is planned for TeXlive. We hope that ffi works ok on intel and arm platforms at that point. (6) There have been some extensions to the Lua libraries and some callbacks have been added. Also, a few new primitives have been introduced. The documentation mentions the stable extensions. (7) There are the usual bug fixes and cleanups but there have been no real fundamental changes in the API. The LuaTeX team

2 5

win32 luatex synctex broken
by Linas Stonys 02 Apr '19

02 Apr '19

Hi, dvilualatex (from version 1.7 up till 1.10) synctex in win32 is not working properly. In linux works fine. And I tried dvilualatex 1.10 from win64 (ctan) works normally too. There is a lot of 0 coordinates in synctex file. Example from natnotes.tex file: dvilualatex 1.10 (win32): x1,183:15690374,0 x1,183:16564182,0 dvilualatex 1.10 (win64): x1,183:15690374,4810340 x1,183:16564182,4810340 Could it be fixed? Or maybe there is a luatex 1.7 (win32 or win64) somewhere with working synctex? Thanks in advance Linas

2 5

ARM_COMPLAINT
by Arfrever Frehtes Taifersar Arahesis 31 Mar '19

31 Mar '19

Commit https://github.com/TeX-Live/luatex/commit/db10e585f662630461e96938de1043a4c… added some (correct) uses of '#if ARM_COMPLIANT' and also 2 uses of '#if ARM_COMPLAINT'. They are still present in newest version of source/texk/web2c/luatexdir/luapplib/ppload.c file: https://github.com/TeX-Live/luatex/blob/eafe6e149e78c13abb435e5c1e06bb49aa5… Since ARM_COMPLAINT is never defined, presumably some code is now broken on ARM architectures :) . -- Arfrever Frehtes Taifersar Arahesis

1 0

Multiple issues with tprint
by Marcel Krüger 29 Mar '19

29 Mar '19

Hi, there are multiple issues memory issues in tprint: If the buffer passed to tprint only contains of to be escaped characters, the `xmalloc(strlen(sss)*3)` is too small: The final `\0` can not be written, so this causes a write into unallocated memory. If t_flush_buffer is called for such a buffer at the last position, there is an additional `\n` written, so `xmalloc(strlen(sss)*3+2)` is needed. Additionally, the test `if (*buffer)` is used to test if there is something to print left. If the parameter is empty, `*buffer` is never written, so valgrind complains about `if (*buffer)` depending on uninitialized memory. Instead, `if (i)` can be used: `i` is the length of the written part of the buffer, so `i==0` iff there is nothing to write. A related problem is with `max_print_line`: If the point where the line should be broken falls inside the escape sequence of an escaped character, the line limit is ignored. This can be fixed by adding if (term_offset+2>=max_print_line) { wterm_cr(); term_offset=0; } as in `wterm_char` also in tprint above `buffer[i++] = '^';`. A full patch fixing all three issues is attached. Best regards Marcel Krüger

3 7

Multiple problems with tprint
by Marcel Krüger 28 Mar '19

28 Mar '19

1 0

pdfe error / question
by Ulrike Fischer 23 Mar '19

23 Mar '19

According to the documentation pdfe.status can be use to check if a pdf has been opened. But when I try \directlua{ dict=pdfe.open("testinput.pdf") pdfe.status(dict)} \bye I get an error (./test-utf8.tex[\directlua]:1: attempt to call a nil value (field 'status') And how I'm supposed to extract an object reference from a dictionary? There are commands getinteger, getstring but nothing that looks like a "getreference". -- Ulrike Fischer http://www.troubleshooting-tex.de/

2 3

\mathchar feature request
by Linas Stonys 21 Mar '19

21 Mar '19

Hi, I was tracing \mathchar created nodes in text mode and they are just a simple glyph nodes with subtype 256. The problem is that there is no how to control the output changing the text font. It's ok if engine throws messages about missing characters in font. But if current font has a different character in this slot that is a problem. Documentation says that this command is allowed in text mode: """""" The commands \mathchar, and \Umathchar and control sequences that are the result of \math- chardef or \Umathchardef are also acceptable in the horizontal and vertical modes. In those cases, the \textfont from the requested math family is used. """""" but maybe could be any other subtype assigned to the glyph node that these characters could be traced down and one could write some control functions (for example error "\mathchar is not allowed in text mode") What do you think? Thanks, Linas

5 7

change in pdfliteral logging
by Ulrike Fischer 14 Mar '19

14 Mar '19

In the following example (which doesn't give a valid pdf, it is only for demo) the logging has changed between texlive 2018 and 2019: In texlive 2018 the log said: ...\pdfliteral page"/Artifact /BMC" In texlive 2019 I now get ...\pdfliteral page <lua data reference 770> This sadly means that my testsuites are no longer really meaningful. Is there a way to get the old behaviour back? Or to somehow add the content of the "<lua data reference 770>" to the log? \tracingoutput 1 \showboxbreadth \maxdimen \showboxdepth \maxdimen \tracingonline 1 \setbox0\hbox{a} \directlua{ for n in node.traverse(tex.box[0].list) do local bdcnode = node.new("whatsit","pdf_literal") bdcnode.data = "/Artifact /BMC" bdcnode.mode=1 tex.box[0].list = node.insert_before(tex.box[0].list,n,bdcnode) end } \box0 \bye -- Ulrike Fischer http://www.troubleshooting-tex.de/

2 1

objcompresslevel doesn't work correctly with pdf 2.0
by Ulrike Fischer 02 Mar '19

02 Mar '19

When setting the pdf version so 2.0 (by using the not really documented variable majorversion) I get a warning that objcompresslevel needs a minorversion >4: \pdfvariable majorversion 2 \pdfvariable minorversion 0 \pdfvariable objcompresslevel=1 blb \bye This is LuaTeX, Version 1.10.0 (TeX Live 2019/W32TeX) (format=luatex 2019.3.1) 2 MAR 2019 13:13 restricted system commands enabled. **test-utf8.tex (./test-utf8.tex warning (pdf backend): objcompresslevel > 0 requires minorversion > 4 -- Ulrike Fischer https://www.troubleshooting-tex.de/

1 0

lualatex (incorrectly) replaces em dashes with hyphens
by Matt Kline 01 Mar '19

01 Mar '19

Hi folks, The current version of lualatex distributed with TeX Live (as installed today via TeX Live's install-tl, or via Arch Linux's packages) replaces em dashes with hyphens if they're not separated by any space. For example, if given \documentclass{article} % This makes no difference: %\usepackage{fontspec} %\setmainfont[Ligatures=TeX]{Latin Modern Roman} % \begin{document} \noindent% I have \emph{no} idea why em dashes---these things---are being replaced with hyphens in Lua\LaTeX. But --- this only seems to happen if there is no space around them. \end{document} lualatex replaces the first two dashes with hyphens, but not the third. The problem goes away when I downgrade to a version from December (Arch's previous release of their texlive-core package was built December 1), and neither pdflatex or xelatex exhibit this behavior.

6 15

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

dev-luatex March 2019