- dev-luatex - NTG Mailing Lists

Not searching the font cache
by Jouke Witteveen 08 Jan '19

08 Jan '19

Hi, I ran into an inconvenience with lualatex and would like some help debugging it. Consider the following .tex file: ---- documentclass{article} \usepackage{bbm} \begin{document} $\mathbbm{1}$ \end{document} ---- When compiling with pdflatex, the font file for the bbm font is created in the local cache (~/.texlive/texmf-var/fonts) only if it does not exist. When the font exists in the cache, it is used without warning. When compiling with lualatex, the font file is created every time. When the font exists, this results in a simple warning ("mktexpk: [...] already exists."). Trying to create the fonts slows down compilation noticeably. How do I go about debugging this? The fact that pdflatex has no problems suggests that this is not an issue with my texmf.cnf, right? Regards, - Jouke

2 3

require "lfs" doesn't work on LuajitTeX
by ARATA Mizuki 27 Dec '18

27 Dec '18

Hi, Even though LuajitTeX has lfs as a built-in library, trying to load it via `require` doesn't work. (LuaTeX with Lua 5.2/5.3 doesn't have this problem) This is because the field package.loaded["lfs"] is not set during initialization. To fix this, change Luas_open to set the module (returned by the module loader) to the package.loaded table, which is available as _LOADED on the registry table. Also, zlib suffers from a similar problem, both on LuaTeX and LuajitTeX. Here is a proposed patch to fix these problems: diff --git a/source/texk/web2c/luatexdir/lua/luastuff.c b/source/texk/web2c/luatexdir/lua/luastuff.c index 0d9342223..a0590c400 100644 --- a/source/texk/web2c/luatexdir/lua/luastuff.c +++ b/source/texk/web2c/luatexdir/lua/luastuff.c @@ -36,9 +36,14 @@ int lua_active = 0; #define Luas_load(Luas,getS,ls,lua_id) \ lua_load(Luas,getS,ls,lua_id); #define Luas_open(name,luaopen_lib) \ + luaL_findtable(L, LUA_REGISTRYINDEX, "_LOADED", 1); \ lua_pushcfunction(L, luaopen_lib); \ lua_pushstring(L, name); \ - lua_call(L, 1, 0); + lua_call(L, 1, 1); \ + lua_pushvalue(L, -1); /* copy of module */ \ + lua_setfield(L, -3, name); /* _LOADED[name] = module */ \ + lua_setglobal(L, name); /* _G[name] = module */ \ + lua_pop(L, 1); /* pop _LOADED table */ #else #define Luas_load(Luas,getS,ls,lua_id) \ lua_load(Luas,getS,ls,lua_id,NULL); @@ -347,8 +352,7 @@ void luainterpreter(void) luatex_socketlua_open(L); } /*tex |zlib|'s slightly odd calling convention */ - luaopen_zlib(L); - lua_setglobal(L, "zlib"); + Luas_open("zlib", luaopen_zlib); luaopen_gzip(L); /*tex our own libraries register themselves */ luaopen_fio(L); -- Mizuki

2 3

epdf libray <EmbFile>:save()
by Reinhard Kotucha 26 Dec '18

26 Dec '18

Hello everybody, I'm working on a script ATM which is using the epdf library. The manual says <boolean> = <EmbFile>:save() -- will go The manual also says <string> = <EmbFile>:name() -- not (yet) implemented Will the latter allow me to save the file to the disk as usual e.g., using the IO library? Don't know what <EmbFile>:name() is supposed to do. Would't it be better if <FileSpec>:getEmbeddedFile() returns the file as a string instead of userdata? Everything would be easier then. At least at user level. The removal of <EmbFile>:save() will break existing scripts anyway, so I think that changing the behavior of <FileSpec>:getEmbeddedFile() is even less invasive. Merry Christmas, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------

2 1

Unicode-Math in LuaLaTeX and XeLaTeX
by Mathias Schickel 12 Dec '18

12 Dec '18

Dear LuaTeX and XeTeX teams, it seems that recent versions of LuaLaTeX and XeLaTeX contain some issues regarding the rendering of opentype fonts using the unicode-math package. I have already contacted Will Robertson about these bugs because I supposed the unicode-math package could cause them. According to Will the math rendering is done by the engines and not by unicode-math. This is why I am contacting you now. The first issue is the usage of the staircase kerning boxes of opentype math fonts. They are obviously not applied in expressions like $f_j$ using LuaLaTeX. The index is rendered too far away from the glyph. If we use XeLaTeX we get the correct output. The second issue is present in both LuaLaTeX and XeLaTeX. If we have an index together with an exponent like j the index is rendered too high – in fact it is risen compared to the expression that uses an index only. A typical example is $f_n^j$. I have prepared a minimal example that shows the problems and have attached it and the outputs using the current versions of LuaLaTeX and XeLaTeX contained in TeXLive. For the sake of completeness it should be mentioned that ConTeXt using the LuaTeX engine as well does not show any of these issues. This leads me to the conclusion that either LuaLaTeX does not use the most recent version of LuaTeX or that the issues are not caused by the engine itself. Maybe you have a clue what leads to the bugs I mentioned. I hope they can be solved soon. Kind regards, Mathias Schickel

2 2

reproducibility issue of pdf inclusion of LuaTeX 1.09.0
by Hironobu Yamashita 07 Dec '18

07 Dec '18

Hi, I'm suffering from reproducibility issue of pdf inclusion of LuaTeX. The output file size differs from time to time, and the largest one is more than twice of the smallest one! Please find the attached 20181203-luatex-pdfobj.tar.xz ======== Details: ======== My binaries are based on TeX Live svn r49302 (self-build on macOS) and I am using LuaTeX with Lua5.2: $ luatex --version This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev) [.. snip ..] LuaTeX is Copyright 2018 Taco Hoekwater and the LuaTeX Team. With the attached source, I run $ export SOURCE_DATE_EPOCH=0 $ export FORCE_SOURCE_DATE=1 $ for i in `seq 0 256`; do lualatex -jobname=include-$i include; done (SOURCE_DATE_EPOCH and FORCE_SOURCE_DATE are set above, to ensure that all output binaries are expected to be identical) The output file (include-[num].pdf) sizes differ from time to time as follows: [size] - [frequency] 63928 bytes - 230 63947 bytes - 1 63958 bytes - 1 110923 bytes - 2 110924 bytes - 10 110925 bytes - 2 110928 bytes - 1 110931 bytes - 1 110932 bytes - 1 110935 bytes - 7 157913 bytes - 1 The largest one is more than twice of the smallest one (= the most frequent one)! Attached are some representatives, and I noticed that the log files also show some strange difference of object numbers: * include-0: 63928 bytes PDF statistics: 72 PDF objects out of 1000 (max. 8388607) 36 compressed objects within 1 object stream * include-11: 110924 bytes PDF statistics: 86 PDF objects out of 1000 (max. 8388607) 44 compressed objects within 1 object stream * include-201: 158913 bytes PDF statistics: 100 PDF objects out of 1000 (max. 8388607) 52 compressed objects within 1 object stream I never experienced this kind of difference with LuaTeX 1.07.0 of TeX Live 2018. Could you examine this issue? Thanks -- Hironobu ---- 山下弘展 (Hironobu Yamashita) e-mail: h.y.acetaminophen(a)gmail.com

3 7

Re: [Dev-luatex] reproducibility issue of pdf inclusion of LuaTeX
by Ulrike Fischer 03 Dec '18

03 Dec '18

(sorry but gmane seems not to work for this list, so I can't send proper "answers") > The output file (include-[num].pdf) sizes differ from time to time > as follows: I can reproduce the issue with Development id: 6871. I looked into the uncompressed pdf and made a diff found that some font resources are sometimes twice in the pdf: 13 0 obj ... %%BeginResource: CMap (TeX-CJZVFX-LibertinusSerif-0) %%Title: (TeX-CJZVFX-LibertinusSerif-0 TeX CJZVFX-LibertinusSerif 0) 63 0 obj ... %%BeginResource: CMap (TeX-CJZVFX-LibertinusSerif-0) %%Title: (TeX-CJZVFX-LibertinusSerif-0 TeX CJZVFX-LibertinusSerif 0) -- Mit freundlichen Grüßen Ulrike Fischer mailto:luatex@nililand.de

1 0

\pdfextension startlink / endlink and boxing level problems
by Ulrike Fischer 01 Dec '18

01 Dec '18

(A similar question has been sent to the tex live list for pdftex) After some discussion in the latex team I have two questions about \pdfextension startlink/endlink in luatex and boxing levels. 1. Currently the commands give a fatal error if used in different boxing levels: x\hbox{\pdfextension startlink attr {/Border[0 0 1]} user{ /Subtype/Link% /A<<% /Type/Action% /S/URI% /URI(blkub)% >>% } Linktext} \pdfextension endlink \bye ! error: (pdf backend): 'endlink' ended up in different nesting level than 'startlink' ! ==> Fatal error occurred, no output PDF file produced! This doesn't happen very often in documents, but if the galley is split and reboxed it is possible that long links end in different levels. One example involving two column mode and top floats has been discussed on the latex2e github: https://github.com/latex3/latex2e/issues/94 Is the fatal error really sensible here? Couldn't the engine close the last annotation with some more or less sensible coordinate and continue with a warning? A pdf with a wrong link area seems better than no pdf at all (and would release formats and packages from the need to carefully keep track of boxing levels when splitting and reassembling stuff). 2. The engine interrupts linking if the boxing level of intermediate text is less than the boxing level at the start of the link: x\hbox{\hbox{\pdfextension startlink attr {/Border[0 0 1]} user{ /Subtype/Link% /A<<% /Type/Action% /S/URI% /URI(blkub)% >>% } Linktext}} not linked \hbox{\hbox{still not linked} \hbox{\hbox{more Linktext\pdfextension endlink}} \bye This allows to some extend to exclude e.g. header and footer from link areas. But doesn't work e.g. with the latex package fancyhdr which adds an additional box level to the footer. xetex/xdvidfpmx has here a quite useful special \special{pdf:nolink} which can be used to suppress the unwanted link area: \documentclass[a4paper]{article} \usepackage{fancyhdr} \pagestyle{fancy} \cfoot{some longer text that should not be linked} \usepackage{ifxetex} \ifxetex %\cfoot{\special{pdf:nolink}some longer text that should not be linked\special{pdf:link}} \fi \usepackage{hyperref} \begin{document} \vspace*{48\baselineskip} xxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxx \href{xxxxx}{link link link link } \end{document} Would it be possible to add to luatex something similar? -- Ulrike Fischer http://www.troubleshooting-tex.de/

2 1

Error reading fonts with version 0 OS/2 table
by Khaled Hosny 26 Nov '18

26 Nov '18

Hi all, LuaTeX stops with an error when reading version 0 OS/2 table, and this is is because it unconditionally reads ulCodePageRange1 and ulCodePageRange2 fields that were not defined in version 0. Such fonts can be found here [1] (from the question [2]). I’m attaching a patch that makes this conditional, it also fixed reading version 2 specific fields that would be skipped for tables with versions greater than 2. It does not look like these fields are used anywhere, so another fix is to only read the fields LuaTeX actually needs. Regards, Khaled 1. https://mp.uu.se/documents/432512/911262/18350_Typsnitt_PC.zip/4c0954cf-84b… 2. https://tex.stackexchange.com/q/430837/729

1 0

Recalculating tail of the list in ligaturing callback
by Esger Renkema 16 Nov '18

16 Nov '18

Dear list, Running the following one-liner: \directlua{callback.register('ligaturing', node.ligaturing)}ffi\bye results in: ------------------------------------------- This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev/Debian) restricted system commands enabled. **\directlua{callback.register('ligaturing', node.ligaturing)}ffi\bye ! error: (linebreak): invalid list tail, probably missing glue ! ==> Fatal error occurred, no output PDF file produced! ------------------------------------------- The problem seems to be that, when restoring the original ‘tail of the list’ after applying the ligaturing callback (in this case consisting of the parfillskip glue), it is appended to the tail of the /original/ list-to-be-ligatured. The latter, of course, has been lost if the paragraph ends in a ligature. According to the manual, the first node of the list passed to the callback is guaranteed not to be a glyph_node. Should the same not hold for the last one, too? The manual states that it ‘normally’ is a glue, but that is clearly not the case here. Best, Esger

3 5

Reading tounicode from shared fonts
by Khaled Hosny 14 Nov '18

14 Nov '18

Hi, While debugging an issue with PDF /ToUnicode, I found code for reading character-level tounicode from the fonts, always takes them from the first font in fonts in merges in the PDF. Usually this is not an issue since the font loader will have identical tounicode values for all characters in the same font loaded multiple times. However, my code sets character-level tounicode only after processing the nodes (to avoid parsing the cmap and GSUB tables ahead of typesetting), so the same font loaded multiple times can have different tounicodes and characters used only in later instances of the font will not have their tounicodes in the PDF file. It seems to be one character fix to instead check the font the character is used in, and looks to me like a typo since the first revision this code was introduced (r710) that went unnoticed. Patch attached. Regards, Khaled

2 1