- dev-luatex - Mailing Lists

Fwd: luatex engine new option request
by Taco Hoekwater 05 Feb '19

05 Feb '19

> Begin forwarded message: > > From: Linas Stonys <lstonys(a)vtex.lt> > Subject: luatex engine new option request > Date: 5 February 2019 at 12:26:35 CET > To: dev-luatex-owner(a)ntg.nl > > Hi, > tex engine provides several compilation modes: > --interaction=STRING set interaction mode (STRING=batchmode/nonstopmode/scrollmode/errorstopmode) > --halt-on-error stop processing at the first error > > But it lacks one very important where one could hide > all the output from terminal except errors (when tex waits for stdin). > And tex engine would interact with user by letting him decide what to do next instead of killing at first error or compiling with errors til the end. > > For typsetter or a simple tex user terminal messages ar just a "white noise". While there is no errors. It just slows down all the compilation. If there is a lot of messages you can gain several seconds by hiding all the output. > > What I want to offer is a new option: > --output-on-prompt=LINES_NO output to terminal only on input prompt (LINES_NO lines of buffered stdout, all of it if 0) > > It works like a "batchmode" but pics all the stdout. And when stdin > is required it will print latest nuber of stodout lines (LINES_NO). > After hitting enter (or what ever tex says to do) it will hide the output again till next stdin. > Lets say --output-on-prompt=20 then on error user will see all the error > and can decide what to do next. > > We have implemented such a feature to luatex 1.09.2 and it works perfectly. Could we send some how a patch to request implement this feature for future releases? We could provide the code for the latest release. > > Thanks, Linas > Taco Hoekwater Elvenkind BV

2 2

pre everydisplay hook feature request
by Linas Stonys 05 Feb '19

05 Feb '19

Hi luatex developers, I want to ask your opinion about new hook (token list) "\everypredisplay". This should work just before $$ (display start) while math group is not started. There is \everydisplay but it works immediately after math mode start. Why one would need it? Now there is now how to control spaces between to equations. Lets say journal requires spaces around displays (and in display inner lines) and text 6pt. I can do with tex macros by hooking into every latex display environment and putting some code right before $$. In that code I add \par; then I do manipulations of \abovedisplayskip by checking \lastskip; and controling \panalty by looking at \prevgraf. Finaly I add \noindent to remove empty boxes. Everything is perfect while I do not get plain display makros $$ a+b $$. Manualy to retype them is not an option. So the hook of \everypredisplay where \par could work would be very useful. What do you think? I'm using luatex 1.09.2.

2 3

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 27 Nov '18

27 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