June 2019 - dev-luatex - NTG Mailing Lists

wrong no-file-line-error option
by Hironobu Yamashita 17 Jan '20

17 Jan '20

Hi, The command-line option -no-file-line-error behaves exactly the same as -file-line-error. hironobu$ cat test.tex \x hironobu$ echo x | luatex test This is LuaTeX, Version 1.10.0 (TeX Live 2020/dev) restricted system commands enabled. (./test.tex ! Undefined control sequence. l.1 \x ? warning (pdf backend): no pages of output. Transcript written on test.log. hironobu$ echo x | luatex -file-line-error test This is LuaTeX, Version 1.10.0 (TeX Live 2020/dev) restricted system commands enabled. (./test.tex ./test.tex:1: Undefined control sequence. l.1 \x ? warning (pdf backend): no pages of output. Transcript written on test.log. hironobu$ echo x | luatex -no-file-line-error test This is LuaTeX, Version 1.10.0 (TeX Live 2020/dev) restricted system commands enabled. (./test.tex ./test.tex:1: Undefined control sequence. l.1 \x ? warning (pdf backend): no pages of output. Transcript written on test.log. hironobu$ Best, Hironobu

1 1

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

linebreak_filter
by Marcel Fabian Krüger 20 Jul '19

20 Jul '19

Hi everyone, in current LuaTeX versions, the result of `linebreak` filter is ignored and instead it is always treated as if no node has been returned (so the internal linebreak algorithm is applied). A minimal example: \directlua{ callback.register("linebreak_filter", function(nodes) return node.hpack(nodes) end) } Some very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very long paragraph. \bye You would expect the whole paragraph to be set in a single line, but normal paragraph breaking is applies instead. This is caused by a change in revision 6686 from Mar 29 2018 "experimental) possible fix for for lua stack issue + consistent error handling (HH)". There in the function lua_linebreak_callback, the change return ret; } + lua_settop(Luas, s_top); p = lua_touserdata(Luas, -1); if (p != NULL) { a = nodelist_from_lua(Luas); try_couple_nodes(*new_head,a); ret = 1; } - lua_settop(Luas, s_top); return ret; has been applied. I am not sure what kind of stack issue this was supposed to fix, but as a side effect this moves the check for the node return value after `lua_settop`, so the return value is already removed from the stack when the test is done. So it is ignored. Best regards, Marcel Krüger

2 3

luatex and harfbuzz 2.5.1
by luigi scarso 08 Jul '19

08 Jul '19

In experimental there is now luatex 1.11.0 with harfbuzz 2.5.1 It follows from the development of harftex by K. Hosny. Please note that the code is 1) in experimental 2) marked as work in progress so it can stay as is, it can be changed , it can be removed completely. We have relaxed the constrain "only C" so a recent C++ is required; but we keep the contrain on the size the must be "small" --- the current size of the binary is around 8M so still good. Feedbacks are welcome: it would be nice to have it in texlive 2020 modulo that constrains are satisfied. -- luigi

4 7

luatex 1.11: bfchar entry empty in mode=harf
by Ulrike Fischer 01 Jul '19

01 Jul '19

When I load a font in harf mode the bfchar entry is empty: \pdfvariable compresslevel0 \pdfvariable objcompresslevel0 \documentclass{article} \usepackage{harfload} %is actually in my format ... \begin{document} \font\test={texgyreheros:mode=harf;} abcäüö \end{document} gives in the pdf /CMapName /TeX-Identity-GXAFXV-LMRoman10-Regular def /CMapType 2 def 1 begincodespacerange <0000> <FFFF> endcodespacerange 0 beginbfrange endbfrange 0 beginbfchar endbfchar With harftex or an older luatex I get: 1 beginbfchar <0052> <0031> endbfchar What's going on here? -- Ulrike Fischer https://www.troubleshooting-tex.de/

3 8

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