- dev-luatex - NTG Mailing Lists

assertion error with experimental lualatex 1.11
by Ulrike Fischer 29 Jun '19

29 Jun '19

\documentclass{article} \usepackage{luatexja} \begin{document} abc \end{document} breaks down with luatex 1.11 with an assertion error : https://i.stack.imgur.com/c8Rcj.png I'm using the version from 23.6. from w32tex.org. Development id: 7167 -- Ulrike Fischer https://www.troubleshooting-tex.de/

2 4

Re: [Dev-luatex] [luatex] luatex and harfbuzz 2.5.1
by luigi scarso 18 Jun '19

18 Jun '19

On Tue, Jun 18, 2019 at 11:17 PM Ulrike Fischer <luatex(a)nililand.de> wrote: > Am Tue, 18 Jun 2019 22:45:18 +0200 schrieb luigi scarso: > > >> Is there some documentation available how to access harfbuzz from Lua > >> (jit) / FFI? > >> > >> Patrick > >> > >> > > Well, look at > > luatexdir/luaharfbuzz > > I have also used > > https://github.com/khaledhosny/harf > > to check > > %% test2-latex.tex > > \documentclass{article} > > \usepackage{fontspec} > > \newfontfamily\deva[Script=Devanagari]{NotoSansDevanagari-Regular.ttf} > > After I understood that the format is currently only found if it is > in the current folder I could test it. > sure > Like with harftex you have to use harfload and activate the harf > mode to get the right output. > > ok, so you want all .... \pdfvariable suppressoptionalinfo \numexpr1+32+64+128+512\relax \pdfvariable compresslevel 0 \pdfvariable objcompresslevel 0 \documentclass{article} \usepackage{harfload} \usepackage{setspace} \usepackage{fontspec} \usepackage{graphicx} \defaultfontfeatures{RawFeature={mode=harf}} \newfontfamily\deva[Script=Devanagari]{NotoSansDevanagari-Regular.ttf} \newfontfamily\beng[Script=Bengali]{NotoSansBengali-Regular.ttf} \newfontfamily\guru[Script=Gurmukhi]{NotoSansGurmukhi-Regular.ttf} \newfontfamily\gujr[Script=Gujarati]{NotoSansGujarati-Regular.ttf} \newfontfamily\orya[Script=Oriya]{NotoSansOriya-Regular.ttf} \newfontfamily\taml[Script=Tamil]{NotoSansTamil-Regular.ttf} \newfontfamily\telu[Script=Telugu]{NotoSansTelugu-Regular.ttf} \newfontfamily\knda[Script=Kannada]{NotoSansKannada-Regular.ttf} \newfontfamily\mlym[Script=Malayalam]{NotoSansMalayalam-Regular.ttf} \newfontfamily\Sinh[Script=Sinhala]{NotoSansSinhala-Regular.ttf} \begin{document} luatex with Harfbuzz: {\deva क्रर्कि} % krarki {\beng ক্রর্কি} % krarki {\guru ਕ੍ਰਰ੍ਕਿ} % krarki {\gujr ક્રર્કિ} % krarki {\orya କ୍ରର୍କି} % krarki {\taml கோ} % ko {\telu క్రర్కి} % krarki {\knda ಕ್ರರ್ಕಿ} % krarki {\mlym ക്രര്കി} % krarki {\Sinh කෙ} % ke \vskip 1em XeLaTeX: \hbox{\hskip5pt\includegraphics[width=8.5cm]{b0miX.png}} \end{document} copy the image from https://i.stack.imgur.com/b0miX.png (note \Sinh vs \sinh) -- luigi

1 0

On \maxdimen in LuaTeX
by Sjors Gielen 11 Jun '19

11 Jun '19

Hi all, According to the TeX in Practice book, "the largest dimension value that can be represented in a TeX program is 16383.99999pt. This value is assigned to a dimension register \maxdimen [...]." This is a tiny bit smaller than 2^14 pt. As a layman TeX user, my naive guess is that in the compiler, floating point dimension registers probably use int32_t or some other fixed-length type, and the compiler implements its own floating point arithmetics. Either way, whenever an overflow is going to happen, the compiler prints a "! Dimension too large" error. This error also occurs when using LuaTeX. My gut feeling is that the current limit of (almost) 16384 pt is perhaps mostly historic; could it nowadays be loosened somehow? Perhaps the dimension calculations are already in Lua and the error is there for legacy reasons, or perhaps the calculations are still in C and if int32_t is indeed used, int64_t could conceivably raise the max dimensions to hundreds of kilometers, more than anyone would accidentally reach. Looking forward to hearing your thoughts. Best, Sjors Gielen P.S.: The discussion I am hoping to invoke is theoretical, but for background, my motivation comes from the use of the 'mdframed' package to split a large frame over many pages. Our automated testing system creates mdframed environments containing test steps and their outcomes; we have apparently crossed some new amount of steps where the virtual vbox size goes over \maxdimen before the vbox is split over multiple pages. If the error is ignored, the generated PDF looks fine. We can also end the mdframed environment every N steps and immediately start a new one, which is an acceptable workaround but I'm a bit unsatisfied that it's necessary. Perhaps this is better considered a bug in mdframed than in the typesetting engine, but I still find the theoretical question behind \maxdimen interesting, hence this e-mail.

2 1

[PATCH] Respect find_{output,write}_file result
by Marcel Fabian Krüger 01 Jun '19

01 Jun '19

Hi, according to the documentation find_{output,write}_file should return the name of the to be written file. Currently this is mostly ignored and the original name is always used. Here is a patch to fix this. Best regards, Marcel Krüger --- source/texk/web2c/luatexdir/tex/texfileio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/texk/web2c/luatexdir/tex/texfileio.c b/source/texk/web2c/luatexdir/tex/texfileio.c index 143e694e1..158757080 100644 --- a/source/texk/web2c/luatexdir/tex/texfileio.c +++ b/source/texk/web2c/luatexdir/tex/texfileio.c @@ -347,7 +347,7 @@ boolean lua_a_open_out(alpha_file * f, char *fn, int n) messaging is left to \LUA\ then. */ - ret = open_outfile(f, fn, FOPEN_W_MODE); + ret = open_outfile(f, str_string(fnam), FOPEN_W_MODE); } } else { if (openoutnameok(fn)) { @@ -379,7 +379,7 @@ boolean lua_b_open_out(alpha_file * f, char *fn) fnam = 0; test = run_callback(callback_id, "S->s", fn, &fnam); if ((test) && (fnam != 0) && (str_length(fnam) > 0)) { - ret = open_outfile(f, fn, FOPEN_WBIN_MODE); + ret = open_outfile(f, str_string(fnam), FOPEN_WBIN_MODE); } } else { if (openoutnameok(fn)) { -- 2.21.0

3 7

[PATCH] Allow literal # in argument text by escaping
by Marcel Fabian Krüger 29 May '19

29 May '19

Hi, inspired by [a recent TeX.sx question][1] this allows delimited macros with `#` in the parameter text by doubling the `#`. It isn't needed that often but it is useful if you try to analyze the parameter text of a TeX macro using TeX code. Also it is completely backward-compatible (`##` always triggers an error without this) and it is very easy to implement. For example: \def\test#1###2{(#1)[#2]} \test hello#{world} would result in (hello)[world] Best regards, Marcel Krüger 1: https://tex.stackexchange.com/questions/491296/can-i-have-a-delimited-macro… --- source/texk/web2c/luatexdir/tex/scanning.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source/texk/web2c/luatexdir/tex/scanning.c b/source/texk/web2c/luatexdir/tex/scanning.c index 8f7e1d591..e8b9fca66 100644 --- a/source/texk/web2c/luatexdir/tex/scanning.c +++ b/source/texk/web2c/luatexdir/tex/scanning.c @@ -2095,7 +2095,8 @@ halfword scan_toks(boolean macro_def, boolean xpand) store_new_token(end_match_token); goto DONE; } - if (t == nine_token) { + if (cur_cmd == mac_param_cmd) { + } else if (t == nine_token) { print_err("You already have nine parameters"); help1("I'm going to ignore the # sign you just used."); error(); -- 2.21.0

3 6

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