- dev-luatex - NTG Mailing Lists

Fixing \shapemode
by Marcel Krüger 12 Apr '19

12 Apr '19

Hi, I attached a patch fixing the problem Ulrike Fischer described in https://tug.org/pipermail/luatex/2019-April/007127.html and https://tug.org/pipermail/luatex/2017-November/006641.html : \shapemode=2 and \shapemode=3 should mirror the parshape, but until now this has only been done for the final entry in the parshape list, leading to inconsistant behaviour. The fix seems easy: Add `swap_parshape_indent` to ext_post_line_break in the same way as in ext_do_line_break. A reproducing example in plain TeX can be found in Ulrike's mails linked above. Best regards Marcel Krüger

3 2

segfault on example in manual
by Reinhard Kotucha 08 Apr '19

08 Apr '19

Hi, when I run the example on page 261/262 of the LuaTeX Manual and the input file ("foo.pdf" in the example) doesn't exist, I get Segmentation fault (core dumped) on x86_64-linux. Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------

3 8

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

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

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