- dev-luatex - NTG Mailing Lists

Using \global with \toksapp
by Esger Renkema 17 Jul '20

17 Jul '20

Dear list, Trying to use \global with \toksapp, e.g. when saying »\global\toksapp0{}«, luatex throws a fatal error: --------------------------------------------------------- This is LuaTeX, Version 1.13.0 (TeX Live 2021/dev) restricted system commands enabled. **! This can't happen (prefix). <*> \global\toksapp 0{} ! ==> Fatal error occurred, no output PDF file produced! Transcript written on texput.log. --------------------------------------------------------- While I know \gtoksapp exists, this seems surprising nevertheless; the error message seems to agree. Is this indeed unintended? Best wishes, Esger Renkema

1 0

Flaw in find_math_kern()
by David Jones 25 Jun '20

25 Jun '20

I recently filed a bug report on the XeTeX repo about the kerning of sub- and superscripts in OpenType fonts: https://sourceforge.net/p/xetex/bugs/175/ luaTeX's find_math_kern() has many of the same flaws. Cheers, David. P.S. I don't think the related bug https://sourceforge.net/p/xetex/bugs/173/ is relevant here because luaTeX's analyze_script() already does essentially the same thing (I haven't compared the two implementations in detail). In fact, analyze_script() does more, since it also handles the sub_box case. ________________________________ David Jones Publications Technical Specialist +1 401.455.4000 (t) [https://www.ams.org/images/ams-logo-270x72.jpg] 201 Charles Street | Providence, RI 02904-2213 USA [https://www.ams.org/images/url.jpg]<https://www.ams.org> | [https://www.ams.org/images/Facebook-icon.jpg] <https://www.facebook.com/amermathsoc> [https://www.ams.org/images/instagram-icon.jpg] <https://www.instagram.com/amermathsoc/> [https://www.ams.org/images/linkedin-icon.jpg] <https://www.linkedin.com/company/51001/> [https://www.ams.org/images/twitter-icon.jpg] <https://twitter.com/amermathsoc> [https://www.ams.org/images/youtube-icon.jpg] <https://www.youtube.com/user/amermathsoc> We appreciate your patience during the Coronavirus Emergency as staff is working remotely.

1 0

warning when trying to include pdf 2.0
by Ulrike Fischer 25 May '20

25 May '20

When I try to include a pdf 2.0 image in a pdf set to 2.0 I get a warning: PDF inclusion: found PDF version '2.0', but at most version '2.0' allowed Example: \pdfvariable compresslevel=0 \pdfvariable majorversion=2 \pdfvariable minorversion=0 \saveimageresource {version20.pdf} abc \bye The warning disappears when I set \pdfvariable minorversion=2, so it looks as if the code would set the minor version of the included pdf to 2 instead of 0. -- Ulrike Fischer http://www.troubleshooting-tex.de/

2 1

lastnodetype=7 ?
by Robert 27 Apr '20

27 Apr '20

Hi, \lastnodetype doesn't give the expected result for ligature nodes (7), registering them as char nodes (0) instead. This happens for both legacy and opentype fonts: \font\x=cmr12 \x \setbox0\hbox{fl} \unhbox0 \the\lastnodetype \ifdefined\directlua \input luaotfload.sty \font\x=[lmroman12-regular.otf]:script=latn;+trep;+tlig;%mode=base; \x \setbox0\hbox{fl} \unhbox0 \the\lastnodetype \fi \bye It seems to work fine with the other node types (but I haven't tested all of them ...). Best, -- Robert

2 1

Lower limit for math operators lost if kern <= 0
by Marcel Fabian Krüger 26 Apr '20

26 Apr '20

Look at the following document: \Umathlimitbelowbgap\displaystyle0pt \Umathlimitbelowvgap\displaystyle0pt $$ \sum_a^b $$ \bye Here the `a` subscript gets lost. In mlist.c, make_op, line 3324 the subscript (stored in variable `z`) is never coupled with the previous node if `shift_down` is smaller or equal to 0. This can be fixed by --- source/texk/web2c/luatexdir/tex/mlist.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/source/texk/web2c/luatexdir/tex/mlist.c b/source/texk/web2c/luatexdir/tex/mlist.c index 43db6adbb..570a54052 100644 --- a/source/texk/web2c/luatexdir/tex/mlist.c +++ b/source/texk/web2c/luatexdir/tex/mlist.c @@ -3321,7 +3321,9 @@ static scaled make_op(pointer q, int cur_style) shift_down = limit_below_bgap(cur_style) - height(z); if (shift_down < limit_below_vgap(cur_style)) shift_down = limit_below_vgap(cur_style); - if (shift_down > 0) { + if (shift_down == 0) { + couple_nodes(y, z); + } else { p = new_kern(shift_down); reset_attributes(p, node_attr(q)); couple_nodes(y,p); -- 2.26.1 This also allows shift_down to be negative. While a negative shift_down is kind of odd, it is already allowed for the superscript so it makes sense from a consistency point of view. Also it can't happen except when it is explicitly requested though a negative limit_below_vgap, so it doesn't have any effect if it isn't requested by the user. Best regards, Marcel

2 2

Strings in LuaTeX's pdfe
by Marcel Fabian Krüger 07 Apr '20

07 Apr '20

Hi, I recently tried to do something with the embedded pdfe library and noticed that accessing strings comes with certain problems. PDF strings are always returned in raw form without the surrounding <> or (), so any script using them will need to know if it is a hex string or a "normal" () delimited string in order to treat it correctly. So pdfe.getstring is a bit weird: It gives a Lua string but no indication which type of string is returned. So if pdfe.getstring e.g. returns "425", it can be either correspond to the actual text "425" or it can be the hexadecimal encoding of "BP". Given that PDF allows beoth upper and lowercase letters and even an odd number of digits in a hexadecimal string, even guessing the right format is hard and error-prone, making pdf.getstring not particularly useful. The same issue appears with the `__index` metafunctions of dictionaries and arrays. This is especially weird because it's inconsistent with PDF names which always get decoded before they are passed to the user. Also even after the Lua script figures out if it is a hex string or a literal string, it has to decode it. (Of course this part only applies if the actual value is needed and not if it only should be passed into another PDF string) That's not complicated, but it feels weird: After all, the underlying pplib already decoded the string, so it seems like it would be easier to make this decoded version accessible to the user. So would it be possible to maybe either change the existing functions or add new ones to 1. return the already decoded value and/or 2. give an indication if a literal or a hex string is returned? Best regards, Marcel

4 7

node.get_properties_table is broken
by Marcel Fabian Krüger 31 Mar '20

31 Mar '20

Hi, the function node.get_properties_table returns a tabe which does not contain the actual node properties and also doesn't allow setting the node properties. See for example \directlua{ node.set_properties_mode(true, true) } \directlua{ local indirectprops = node.get_properties_table() local directprops = node.direct.get_properties_table() local n = node.new'glue' % Type doesn't really matter local p = {} node.setproperty(n, p) assert(node.getproperty(n) == p, "Assert failed: getproperty after setproperty") % works fine local directn = node.direct.todirect(n) assert(node.direct.getproperty(directn) == p, "Assert failed: direct.getproperty after setproperty") % works fine assert(directprops[directn] == p, "Assert failed: direct.get_properties_table after setproperty") % works fine assert(indirectprops[n] == p, "Assert failed: get_properties_table after setproperty") % This breaks node.free(n) } \bye Here a property is set using node.setproperty and then we try to access it through different methods. All of them work, except for node.get_properties_table because this uses a different table which is unrelated to the actual property table returned by e.g. node.direct.get_properties_table. This issue appear because the metatable __index and __newindex functions for node.get_properties_table set the property in the table passed as first parameter, which is the (non-direct) node.get_properties_table table instead of node.direct.get_properties_table(). Here is a possible fix which passes the actual property table as upvalue to the metafunctions: --- source/texk/web2c/luatexdir/lua/lnodelib.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/source/texk/web2c/luatexdir/lua/lnodelib.c b/source/texk/web2c/luatexdir/lua/lnodelib.c index d5ab00a55..4e713aaa2 100644 --- a/source/texk/web2c/luatexdir/lua/lnodelib.c +++ b/source/texk/web2c/luatexdir/lua/lnodelib.c @@ -8406,7 +8406,7 @@ static int lua_nodelib_get_property_t(lua_State * L) if (n == null) { lua_pushnil(L); } else { - lua_rawgeti(L,1,n); + lua_rawgeti(L,lua_upvalueindex(1),n); } return 1; } @@ -8417,7 +8417,7 @@ static int lua_nodelib_set_property_t(lua_State * L) halfword n = *((halfword *) lua_touserdata(L, 2)); if (n != null) { lua_settop(L,3); - lua_rawseti(L,1,n); + lua_rawseti(L,lua_upvalueindex(1),n); } return 0; } @@ -8831,16 +8831,19 @@ static const struct luaL_Reg nodelib_p[] = { static void lua_new_properties_table(lua_State * L) { - lua_pushstring(L,"node.properties"); lua_newtable(L); + lua_pushstring(L,"node.properties"); + lua_pushvalue(L,-2); lua_settable(L,LUA_REGISTRYINDEX); lua_pushstring(L,"node.properties.indirect"); lua_newtable(L); luaL_newmetatable(L,"node.properties.indirect.meta"); - luaL_openlib(L, NULL, nodelib_p, 0); + lua_pushvalue(L,-4); + luaL_openlib(L, NULL, nodelib_p, 1); lua_setmetatable(L,-2); lua_settable(L,LUA_REGISTRYINDEX); + lua_pop(L,1); } /* node.direct.* */ -- 2.26.0 Best regards, Marcel

3 4

Misleading documentation for node.setglue
by Marcel Fabian Krüger 26 Mar '20

26 Mar '20

Hi, according to the LuaTeX manual for node.setglue: > When you pass values, only arguments that are numbers are assigned so > node.setglue(n,655360,false,65536) > will only adapt the width and shrink. This does not correspond to the actual behaviour. In practise, arguments which are not numbers are treated as zero: \directlua{ local n = node.new'glue' node.setglue(n, 100000, 100000, 100000, 2, 2) print('BEFORE', node.getglue(n)) node.setglue(n, 655360, false, 655360) print('AFTER', node.getglue(n)) node.free(n) } \bye prints BEFORE 100000 100000 100000 2 2 AFTER 655360 0 655360 0 0 The documentation should probably be adjusted to reflect the actual behaviour. - Marcel

1 0

depth of glyph nodes with y_displacement<0
by Marcel Fabian Krüger 13 Mar '20

13 Mar '20

Hi, I found a curiosity in LuaTeX's treatment of `y_displacement` in glyph nodes: Take the following ConTeXt example: \usetypescript[pagella] \setupbodyfont[pagella,12pt] \starttext f\char776\char776\char776\char807\char807\char807\vrule \stoptext (See https://github.com/latex3/luaotfload/issues/134 for a more practical case where this leads to issues) Here the \vrule shows that the marks attached at the top get their y_displacement added to their height, while for the marks added at the bottom the additional depth is ignored. (The first \char807 is still covered by the rule because that is the natural height of this glyph) This is explicitly done in texnodes.c: For glyph_height, the displacement is always added. For glyph_depth, the displacement is only added if it is positive: scaled glyph_height(halfword p) { scaled w = char_height(font(p), character(p)) + y_displace(p); if (w < 0) w = 0; return w; } scaled glyph_depth(halfword p) { scaled w = char_depth(font(p), character(p)); if (y_displace(p) > 0) w = w - y_displace(p); if (w < 0) w = 0; return w; } This seems inconsistant. Is there a reason why this would be required or could it be changed to handle height and depth consistently? Best regards, Marcel

2 5

append_to_vlist with single return value broken
by Marcel Fabian Krüger 07 Mar '20

07 Mar '20

Hi, according to the documentation for `append_to_vlist_filter`: > The prevdepth is also optional so it should be allowed to only return a box in which case the prevdepth value shouldn't change. But if we actually try this: \directlua{ callback.register("append_to_vlist_filter", function(b) return b end) } abc \bye LuaTeX answers with warning (pdf backend): no pages of output. because it discards all boxes. This is caused by a bug in luanode.c, lua_appendtovlist_callback: The callback is called with lua_pcall(Luas, 4, 2, 0). Then LuaTeX tries to determine if one or two values have been returned by looking at the type of slot -1: If this is a number, the second return value have been a number and it is evaluated as new prevdepth. Otherwise else if (lua_type(Luas, -1) != LUA_TNIL) { p = check_isnode(Luas, -1); *result = *p; } is evaluated to scan for a single return value which is a node. But because lua_pcall(Luas, 4, 2, 0) explicitly requested two return values, a callback with one return values would result in a stack where the one return value is followed by `nil`. Therefore this `if` block is not entered. The problem can be fixed by always looking at stack slot -2 for the returned node: source/texk/web2c/luatexdir/lua/luanode.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/source/texk/web2c/luatexdir/lua/luanode.c b/source/texk/web2c/luatexdir/lua/luanode.c index a0c97e37d..d4baab96d 100644 --- a/source/texk/web2c/luatexdir/lua/luanode.c +++ b/source/texk/web2c/luatexdir/lua/luanode.c @@ -183,12 +183,9 @@ int lua_appendtovlist_callback(halfword box, int location, halfword prev_depth, if (lua_type(Luas,-1) == LUA_TNUMBER) { *next_depth = lua_roundnumber(Luas,-1); *prev_set = true; - if (lua_type(Luas, -2) != LUA_TNIL) { - p = check_isnode(Luas, -2); - *result = *p; - } - } else if (lua_type(Luas, -1) != LUA_TNIL) { - p = check_isnode(Luas, -1); + } + if (lua_type(Luas, -2) != LUA_TNIL) { + p = check_isnode(Luas, -2); *result = *p; } return 1; -- Best regards, Marcel

3 3