- dev-luatex - NTG Mailing Lists

Issues with settex() and glue
by Michal Vlasák 28 Aug '21

28 Aug '21

Hello, as part of [1] I also noticed that, the "settex" function (used as metamethod for the "tex" table and for "tex.set") doesn't work for glue specified by (up to) five values case. There are multiple issues. Firstly this is the Lua stack when this function is called (i = lua_gettop()): tex.set("global", "parskip", 1, 2, 3, 4, 5) -> i-6 i-5 i-4 i-3 i-2 i-1 i "global" "parskip" 1 2 3 4 5 The function essentially doesn't do anything for the five number glue case, because of the outer most check: if (lua_type(L, i - 1) == LUA_TSTRING) { Even if it did, it wouldn't respect the "global" setting, because it is checked like this: if (i == 3 && (lua_type(L,1) == LUA_TSTRING)) { const char *s = lua_tostring(L, 1); if (lua_key_eq(s,global)) And even then, it would try to use values beyond the top of the stack: width(value) = lua_roundnumber(L,i); if (i > 1) { stretch(value) = lua_roundnumber(L,i+1); } if (i > 3) { shrink(value) = lua_roundnumber(L,i+2); } if (i > 4) { stretch_order(value) = lua_tointeger(L,i+3); } if (i > 5) { shrink_order(value) = lua_tointeger(L,i+4); } The manual also mentions the 5 value case twice in the same paragraph: --- a/manual/luatex-tex.tex +++ b/manual/luatex-tex.tex @@ -271,9 +271,7 @@ \type {tex.get} you get the width of the glue and when you pass \type {true} you get all five values. Otherwise you get a node which is a copy of the internal value so you are responsible for its freeing at the \LUA\ end. When you set a -glue quantity you can either pass a \nod {glue_spec} or upto five numbers. If -you pass \type {true} to \type {get} you get 5 values returned for a glue and -when you pass \type {false} you only get the width returned. +glue quantity you can either pass a \nod {glue_spec} or upto five numbers. And then the contradicts itself: 10.3.2.4 Glue parameters The glue parameters accept and return a userdata object that represents a glue_spec node. I tried to fix the issues, but the "settex" function is also complicated by the fact, that it also is a __newindex metamethod of the tex table, which means that its stack can also look like this: tex.parskip = n -> i-2 i-1 i tex "parskip" n So one can't easily just index from the the bottom. Also the line: int a = isglobal; in the glue case would deserve a comment, since it is subtle, but required for define() to work properly (it looks at the variable called "a"). I would prefer something like: int a = isglobal; /* for define() */ In the end I am not even sure how to handle the issues. I leave it to the more experienced. Kind regards, Michal Vlasák [1]: https://mailman.ntg.nl/pipermail/dev-luatex/2021-August/006542.html

1 0

lastnodetype, again
by Robert 22 Aug '21

22 Aug '21

Hi, while the last problem with \lastnodetype (cf. https://mailman.ntg.nl/pipermail/dev-luatex/2020-April/006414.html) has been fixed, there are still incompatibilities if it is preceded by \relax. The following outputs 7,0,8,7,7,7 with pdftex and etex, but 7,0,0,0,0,0 with luatex: %\input luaotfload.sty %\font\x=[lmroman12-regular.otf]:script=latn;+trep;+tlig;%mode=base; %\x % no difference \setbox0\hbox{--} \unhbox0 \the\lastnodetype % OK --\the\lastnodetype % OK --\relax\the\lastnodetype \setbox0\hbox{--\relax\the\lastnodetype} \unhbox0 \toks0={--} \setbox0\hbox{\the\toks0\relax \the\lastnodetype} \unhbox0 \setbox0\vbox{\hbox{--\relax\the\lastnodetype}} \unvbox0 \bye Best, -- Robert

2 4

harfbuzz 2.8.2
by luigi scarso 18 Aug '21

18 Aug '21

I have pushed harfbuzz 2.8.2 into experimental, if it's ok I will sync with the texlive repo. -- luigi

1 0

Improvements for glyph_stream_provider with TTF fonts
by Marcel Fabian Krüger 09 Aug '21

09 Aug '21

Hi, while working with the glyph_stream_provider callback I noticed that it has some issues, especially around TTF fonts. Especially LuaTeX analyzes the glyph streams *before* the callback get involved to identify composite glyphs. If composite glyphs are found, the corresponding components get added to the subset bug get new glyph ids. Later, when glyph_stream_provider is called to get the glyph streams, the parameters are the new glyph ids which are assigned by LuaTeX and the mapping is not made available. This leads to two issues: - When glyph_stream_provider is used, composite glyphs can't be preserved but have to be expanded since the callback has no way of knowing the final (remapped) glyph ids of the components. This can not only make the file bigger, it can also invalidate hinting instructions. - Even though the remapped components can't be found from the composite glyphs, they still trigger a call to the callback which can't be distinguished from normal calls and therefore still lead to something being added to the embedded font. Since only the remapped GID is made available, this will not even be the correct component glyph which happens to be in the slot described by the glyph id the component got mapped to (typically glyphs 1, 2, etc. since the remapping maps to the smallest unused glyph ids). This mostly just makes the embedded font bigger and it's confusing when looking at these subsetted fonts with weird glyphs included in the subset. - Somewhat independently, this current code does not allow the side bearings and advance widths to be modified which means that some table values can get inconsistent for variable fonts which change these values. This this is used by existing code and mostly just causes inefficiencies and not outright errors, the existing behavior should probably be kept available for compatibility, so I suggest the following addition: When a font has font_streamprovider set to 3, behave exactly as if the streamprovider was 2, except that before the "normal" glyph_stream_provider provider calls for a font happen (with arguments fontid, (remapped) gid, 2) call the `glyph_stream_provider` once for every glyph with the four arguments (fontid, remapped gid, 3, original gid) and expect four return values, corresponding to horizontal advance width, left side bearing, vertical advance width and top side bearing. This ensures that when the glyphstreams are generated, the callback code is aware of the full mapping between original and remapping GIDs and can therefore use these remapped GIDs correctly. An example implementation is attached. Best regards, Marcel

2 7

[PATCH] luaharfbuzz: Provide interface for variable fonts
by Marcel Fabian Krüger 04 Aug '21

04 Aug '21

Hi, please consider the attached patch for luahbtex. It adds a Lua interface for HarfBuzz's functions around variable fonts. It is an adoption of recent upstream luaharfbuzz changes with additional LuaJIT support. While corresponding busted tests are included too, the font needed to actually run these tests has not been added to the fonts directory since sending binary files in diffs via email is problematic and I don't think that anyone is running these tests from the LuaTeX repo anyway. Best regards, Marcel

2 7

Dump sharing - redundant copying/allocations
by Michal Vlasák 22 Jul '21

22 Jul '21

Hello, when NO_DUMP_SHARE is not defined and the system is Little endian, then for the possibility of sharing format files between architectures all dumped multi-byte valules are byte swapped by the function "swap_items" in "tex/texfileio.c". The origin of the function is in Web2C's "texmfmp.c" and it seems that it was added to LuaTeX in the version 1.08 when the source was converted from CWeb (or am I reading the history wrong?). However, there are two differences between Web2C's and LuaTeX's "swap_items": 1) LuaTeX also supports 12 byte values. and more importantly: 2) LuaTeX essentially does this: - allocate temporary array - copy input to temporary array - [common code with web2c] - copy temporary array back to input to serve as output - free temporary array This all seems redundant and causes many small allocations (~350K allocations for a ~800K format file), because most allocations are of only 4 bytes. Curiously the gcc -O2 optimizer doesn't catch this even though it is a static function (and changing xmalloc/xfree to the "intrinsic" malloc/free doesn't help it). Maybe the possible unsigned int overflow prevents the optimization? Or am I missing some side effect/purpose of the copying/allocating? See my proposal below. (Note that in the LuaTeX repository --disable-dump-share is the default, while it isn't in TeX Live, I think.) Michal Vlasák --- a/tex/texfileio.c +++ b/tex/texfileio.c @@ -1125,13 +1125,9 @@ static gzFile gz_fmtfile = NULL; */ -static void swap_items(char *pp, int nitems, int size) +static void swap_items(char *p, int nitems, int size) { char temp; - unsigned total = (unsigned) (nitems * size); - char *q = xmalloc(total); - char *p = q; - memcpy(p,pp,total); /*tex Since `size' does not change, we can write a while loop for each case, @@ -1201,8 +1197,6 @@ static void swap_items(char *pp, int nitems, int size) default: FATAL1("Can't swap a %d-byte item for (un)dumping", size); } - memcpy(pp,q,total); - xfree(q); } #endif

5 12

\tracingtokens=1, ( ) are logged curiously
by Petr Olsak 21 May '21

21 May '21

Suppose: ----------------------------------------- \tracingscantokens=1 \scantextokens{first} \scantextokens{second} \bye ----------------------------------------- and run luatex test. Then the ( and ) are logged curiously: ( ( ... )) Why all closing )) are logged after end command? If we change \scantextokens to \scantokens, then ( and ) behaves more logical in log file and in the terminal: ( ) ( ). Petr Olsak

3 3

BUG: Luatex gets high unicode codepoints with an offset
by Sergio Callegari 12 May '21

12 May '21

Hi, please consider this sample code|:| ||||\documentclass{article} \usepackage{fontspec} \newfontface\MDI{Material Design Icons}[] \begin{document} Look at this character {\MDI \char"F1372}! \end{document} It is meant to work with the materialdesignicons-webfont.ttf font downloadable from https://materialdesignicons.com/ <https://materialdesignicons.com/> . The code works just fine with xelatex, but with lualatex it picks a wrong char (there seems to be an offset by 14). See also https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large… . Seems a bug to me, certainly an inconsistency with xelatex. Any idea? Best, Sergio ||

2 1

Potential race condition in makefiles
by Dmitry Kalinkin 08 May '21

08 May '21

Hi, We are observing a following build failure: ../../../texk/web2c/luatexdir/luamd5/md5lib.c:197:10: fatal error: 'utilsha.h' file not found #include "utilsha.h" ^~~~~~~~~~~ 1 error generated. For the full log, see https://hydra.nixos.org/build/142527628/nixlog/2 Best regards, Dmitry

2 3

\protrusionboundary
by Robert 07 May '21

07 May '21

Hi, the command \protrusionboundary could potentially be very useful, but I'm not sure I understand how it's supposed to work. The manual gives the example (p.43): | \protrusionboundary1\llap{!\quad}«Who needs protrusion?» However, with the following: \input luaotfload.sty \parindent=0pt \protrudechars=2 \directlua{ fonts.protrusions.setups['test'] = { [0x00AB] = { 1, 0 } % left guillemet } } \font\x=[lmroman10-regular.otf]:protrusion=test; \x Who\par «Who\par \protrusionboundary1\llap{!\quad}«Who \bye the guillemet on the last line is not protruded as I would have expected. Or am I missing something? Secondly, the documentation says that \protrusionboundary will ignore the next/previous node (singular). What would be much more practical in real life, I think, is to have a command that would simply say, "consider the current point as left/right/both margin(s)", because more often than not, you'd find a succession of hboxes, penalties etc. (plural) that you'd want to skip. Would that be feasible? Best, -- Robert

1 0