- dev-luatex - NTG Mailing Lists

Argument checking in ltexlib.c
by Marcel Fabian Krüger 23 Aug '19

23 Aug '19

Hello, in tex_setmathparm and tex_getmathparm from ltexlib.c, `i` stores the index of the math parameter to query or set. Given that `i` is obtained through luaL_checkoption it should never have a invalid value. The function still check that `i` is in the valid range using the check if (i<0 && i>=math_param_last) { /* invalid spec, just ignore it */ I think this is a typo because i>=math_param_last (with math_param_last=114) implies i>0 and therefore this condition can never be true. Maybe || could be used instead of && or the check could be removed entirly. Marcel

3 2

tex.{get,set}math argument names
by Marcel Fabian Krüger 23 Aug '19

23 Aug '19

Hello, in tex/texmath.c, the `math_param_names` array is missing the entries `skewedfractionvgap` and `skewedfractionhgap`. This causes all array indices to be shifted and therefore a mismatch between the parameter names in Lua and the real names. For example: \showthe\Umathlimitabovevgap\displaystyle \showthe\Umathskewedfractionvgap\displaystyle \directlua{ print('limitabovevgap:', tex.getmath('limitabovevgap', 'display')) print('skewedfractionvgap:', tex.getmath('skewedfractionvgap', 'display')) } \bye results in > 1.11111pt. l.1 \showthe\Umathlimitabovevgap\displaystyle ? > 0.0pt. l.2 \showthe\Umathskewedfractionvgap\displaystyle ? limitabovevgap: 0 [\directlua]:1: bad argument #1 to 'getmath' (invalid option 'skewedfractionvga p') -- Marcel

1 0

Re: [Dev-luatex] Embedding minimally used TTF fonts
by Marcel Krüger 23 Jul '19

23 Jul '19

On 23 July 2019 16:21:18 CEST, luigi scarso <luigi.scarso(a)gmail.com> wrote: >On Tue, Jul 23, 2019 at 1:03 PM Marcel Fabian Krüger <tex(a)2krueger.de> >wrote: > >> Hi, >> >> whenever LuaTeX loads a TTF font but only uses a single glyph, >> which happens to be the notdef glyph (GID=0), LuaTeX complains about >> >> (type 2): there are no glyphs in the subset >> >> Of course this isn't true, because the notdef *is* in the subset. >> >> This happens because LuaTeX always includes the notdef glyph, so it >is >> never counted. The problem can be fixed by explicitly testing for >this >> case. >> >> >Do you have an example ? Of course: \starttext \font\test=logix.ttf\test \char"F0000 \stoptext See https://github.com/u-fischer/luaotfload/issues/73 for some context.

2 2

Embedding minimally used TTF fonts
by Marcel Fabian Krüger 23 Jul '19

23 Jul '19

Hi, whenever LuaTeX loads a TTF font but only uses a single glyph, which happens to be the notdef glyph (GID=0), LuaTeX complains about (type 2): there are no glyphs in the subset Of course this isn't true, because the notdef *is* in the subset. This happens because LuaTeX always includes the notdef glyph, so it is never counted. The problem can be fixed by explicitly testing for this case. Best regards, Marcel Krueger diff --git a/source/texk/web2c/luatexdir/font/writetype2.c b/source/texk/web2c/luatexdir/font/writetype2.c index 49193579b..0f889f707 100644 --- a/source/texk/web2c/luatexdir/font/writetype2.c +++ b/source/texk/web2c/luatexdir/font/writetype2.c @@ -289,7 +289,7 @@ boolean make_tt_subset(PDF pdf, fd_entry * fd, unsigned char *buff, int buflen) num_glyphs++; } - if (num_glyphs == 1) { + if (num_glyphs == 1 && used_chars[0] == 0) { normal_error("type 2","there are no glyphs in the subset"); } if (tt_build_tables(sfont, glyphs, fd) < 0) {

1 0

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