December 2018 - dev-luatex - NTG Mailing Lists

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

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