- dev-luatex - NTG Mailing Lists

Potential bug with kerning in math mode
by Matthias Nagel 07 Mar '20

07 Mar '20

Dear all, as I am unsure what is the officially correct way to submit a potential bug, I post it here and would like to draw your attention to this post, because I do not now of the tracker is still in use. http://tracker.luatex.org/view.php?id=1019 My apologies, if this is a double posting. Also, I already have posted this problem to the Libertinus project as I initially thought this would be a bug in the font, but the maintainer of Libertinus said it is an issue with LuaTex. Bests, M.N.

3 5

os.setenv()
by Reinhard Kotucha 21 Feb '20

21 Feb '20

Hi, I just tried this with texlua 1.10.0: -------------------------------------------- local function time_of_day (TZ) os.setenv('TZ', TZ) local time = os.gettimeofday() print(os.date('%c', math.floor(time))) end time_of_day ('America/New_York') time_of_day ('Europe/Paris') time_of_day ('Asia/Tokyo') -------------------------------------------- It seems that os.setenv() is only executed once and all results are in Eastern Standard Time: Fri Feb 21 16:37:13 2020 Fri Feb 21 16:37:13 2020 Fri Feb 21 16:37:13 2020 When I call "time_of_day ('Asia/Tokyo')" first I get Sat Feb 22 06:39:46 2020 Sat Feb 22 06:39:46 2020 Sat Feb 22 06:39:46 2020 Is it possible to fix this behavior? Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------

2 3

Some legacy fonts cause "invalid list tail, probably missing glue"
by Daniel Benjamin Miller 19 Feb '20

19 Feb '20

There is an issue with lualatex which comes about when using a document such as this (based on a discussion here https://tex.stackexchange.com/questions/525898/combining-french-and-greek-b…) Try running lualatex on the following document, and an error will be returned. This seems to apply for all fonts whose packages were generated by autoinst (step is just an example). \documentclass[12pt]{article} \usepackage[utf8]{luainputenc}\usepackage[LGR,T1]{fontenc}\input{lgrenc.dfu} \usepackage{step} \usepackage[greek.ancient,main=french]{babel} \title{Ça marche?} %\date{} \author{me} \begin{document} \maketitle un, deux, trois \foreignlanguage{greek}{ἀγαγεῖν} \end{document} According to Marcel Krüger, this is related to an issue which was reported over a year ago: https://mailman.ntg.nl/pipermail/dev-luatex/2018-November/006138.html.

3 7

Disappearing quoteleft in luatex
by Norbert Preining 06 Feb '20

06 Feb '20

Dear all, I see a strange thing happening with the following document all with uptodate TeX Live: \documentclass{article} \usepackage{fontspec} \setmainfont{Gaultier} \begin{document} Hello `World' \end{document} xelatex: ok lualatex: quoteleft character is missing lualatex-dev with [RawFeature={mode=harf;}]: ok So it seems that the lualatex font loader seems to be broken here. The character is present in the font 325 (0x145) U+2018 "quoteleft" LEFT SINGLE QUOTATION MARK and separate from the quoteright. Any suggestions how to fix these kind of errors? Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

2 2

Updates for (lua)HarfBuzz
by Marcel Fabian Krüger 25 Jan '20

25 Jan '20

Hello, would it be possible to pull a new version of luaharfbuzz in before TeXLive 2020 is frozen? There hasn't been an official release, but there are some new interfaces which would be very useful for luaotfload. There are also at least two bugs in HarfBuzz affecting luaotfload for which the fixes are in the repo but not yet released, but I guess the HarfBuzz version is controlled by the TeXLive team? Best regards, Marcel

3 4

Request for bugfix - rule nodes (subtypes: 1 = box, 2 = image, 3 = empty, 4 = user) in DVI mode
by Sigitas Tolusis 24 Jan '20

24 Jan '20

Three things to be fixed for the rule nodes with subtypes 1 to 4 in DVi mode. (Function dvi_place_rule from dvigen.c file) void dvi_place_rule(PDF pdf, halfword q, scaledpos size) { synch_dvi_with_pos(pdf->posstruct->pos); if ((subtype(q) >= box_rule) && (subtype(q) <= user_rule)) { /*tex place nothing, only take space */ if (textdir_is_L(pdf->posstruct->dir)) dvi.h += size.h; } else { /*tex normal_rule or >= 100 being a leader rule */ if (textdir_is_L(pdf->posstruct->dir)) { /*tex movement optimization for |dir_*L*| */ dvi_out(set_rule); dvi.h += size.h; } else dvi_out(put_rule); } dvi_four(size.v); dvi_four(size.h); } Problem 1. Bad dvi file due the arguments output without dvi command (misplaced the two last lines in the code). Possible fix: void dvi_place_rule(PDF pdf, halfword q, scaledpos size) { synch_dvi_with_pos(pdf->posstruct->pos); if ((subtype(q) >= box_rule) && (subtype(q) <= user_rule)) { /*tex place nothing, only take space */ if (textdir_is_L(pdf->posstruct->dir)) dvi.h += size.h; } else { /*tex normal_rule or >= 100 being a leader rule */ if (textdir_is_L(pdf->posstruct->dir)) { /*tex movement optimization for |dir_*L*| */ dvi_out(set_rule); dvi.h += size.h; } else dvi_out(put_rule); dvi_four(size.v); dvi_four(size.h); } } Problem 2. Not reserved space for the rule in the output. Possible fix: void dvi_place_rule(PDF pdf, halfword q, scaledpos size) { synch_dvi_with_pos(pdf->posstruct->pos); if ((subtype(q) >= box_rule) && (subtype(q) <= user_rule)) { /*tex place nothing, only take space */ if (textdir_is_L(pdf->posstruct->dir)) dvi.h += size.h; movement(size.h, right1); } else { /*tex normal_rule or >= 100 being a leader rule */ if (textdir_is_L(pdf->posstruct->dir)) { /*tex movement optimization for |dir_*L*| */ dvi_out(set_rule); dvi.h += size.h; } else dvi_out(put_rule); dvi_four(size.v); dvi_four(size.h); } } Problem 3. Broken consistency with PDF mode as process_rule callback is missing in DVI mode. Possible fix: void dvi_place_rule(PDF pdf, halfword q, scaledpos size, int callback_id) { synch_dvi_with_pos(pdf->posstruct->pos); if ((subtype(q) >= box_rule) && (subtype(q) <= user_rule)) { /*tex place nothing, only take space */ if (textdir_is_L(pdf->posstruct->dir)) dvi.h += size.h; if (subtype(q) == user_rule && callback_id != 0) { run_callback(callback_id, “Ndd->”, q, size.h, size.v); } movement(size.h, right1); } else { /*tex normal_rule or >= 100 being a leader rule */ if (textdir_is_L(pdf->posstruct->dir)) { /*tex movement optimization for |dir_*L*| */ dvi_out(set_rule); dvi.h += size.h; } else dvi_out(put_rule); dvi_four(size.v); dvi_four(size.h); } } and fix in dvigen.h < extern void dvi_place_rule(PDF pdf, halfword q, scaledpos size); > extern void dvi_place_rule(PDF pdf, halfword q, scaledpos size, int callback_id); Regards, Sigitas P.S. Some point for the discussion. For the wider usabillity maybe the rules with zero dimensions (width, height+depth) can be allowed in the output.

2 1

wrong no-file-line-error option
by Hironobu Yamashita 17 Jan '20

17 Jan '20

Hi, The command-line option -no-file-line-error behaves exactly the same as -file-line-error. hironobu$ cat test.tex \x hironobu$ echo x | luatex test This is LuaTeX, Version 1.10.0 (TeX Live 2020/dev) restricted system commands enabled. (./test.tex ! Undefined control sequence. l.1 \x ? warning (pdf backend): no pages of output. Transcript written on test.log. hironobu$ echo x | luatex -file-line-error test This is LuaTeX, Version 1.10.0 (TeX Live 2020/dev) restricted system commands enabled. (./test.tex ./test.tex:1: Undefined control sequence. l.1 \x ? warning (pdf backend): no pages of output. Transcript written on test.log. hironobu$ echo x | luatex -no-file-line-error test This is LuaTeX, Version 1.10.0 (TeX Live 2020/dev) restricted system commands enabled. (./test.tex ./test.tex:1: Undefined control sequence. l.1 \x ? warning (pdf backend): no pages of output. Transcript written on test.log. hironobu$ Best, Hironobu

1 1

LuaTeX 1.10.0 cannot embed properly PDFs with 4-bit images
by L. E. Segovia 17 Jan '20

17 Jan '20

Hello, I would like to report that since TeX Live 2019, LuaTeX is unable to embed properly a certain type of image I have. These sort of images are embedded in the PDFs generated by the tool "Comprobantes en línea" of Argentina's IRS (Administración Federal de Ingresos Públicos, https://www.afip.gob.ar) This is an example: https://comunadealvear.gob.ar/wp-content/uploads/2017/03/30710518803_01_000… (or just search online for the string "Esta Administración Federal no se responsabiliza por los datos ingresados en el detalle de la operación"). Embed this file using the following snippet: \documentclass{article} \usepackage{luatex85} \usepackage{incgraph} \begin{document} \incgraph{30710518803_01_0002_00000009.pdf} \end{document} Where the white-and-grey AFIP logo appears in the original, LuaTeX instead embeds a grey-on-grey image, probably by messing with the alpha channel. I have consistently reproduced this on every update since the 2019 release. XeLaTeX and pdfTeX do not have this issue. Please let me know if I can be of more assistance. I hope I've posted to the right mailing list. Best regards, Leonardo -- Leonardo E. Segovia https://www.amyspark.me

3 6

PNG file inclusion
by Reinhard Kotucha 05 Jan '20

05 Jan '20

Hi, I just encountered a problem with a broken PNG file. The PNG file was created with Microsoft's "Snipping Tool". The problem affects both, LuaTeX and pdfTeX and proably XeTeX too (not tested). When I include a PNG file created by Microsoft's "Snipping Tool", Okular crashes. No Problem when I convert PNG->PNM->PNG with ImageMagick. In both cases the header is: 1 0 obj << /Type /XObject /Subtype /Image /Width 1942 /Height 878 /BitsPerComponent 8 /ColorSpace /DeviceRGB /Length 5115228 >> stream .... endstream endobj I would expect that the number of bytes between "stream" and "endstream" is exactly the number of bytes denoted by /Length. When I use the original PNG file, 6820463 bytes are inserted between stream and endstream, with the converted file exactly 5115228 bytes are written. The value of /Length is obviously derived from the header: 1942 × 878 × 3 = 5115228 Assuming that a PDF viewer uses the value of /Length to demermine the amount of memory to allocate, crashes are quite likely and maybe this behavior can be abused to inject code into unallocated memory. Assuming that libpng is used for PNG decompression, it's probably the culprit. But I don't know whether the PNG standard allows to add additional information to the file. In this case the size cannot be determined from the header. My suggestion is, instead of relying entirely on external libraries, to make sure that (pdf|Lua)TeX always inserts exactly /Length bytes to the stream. If this is not possible, abort with an meaningful error message. At the end TeX has to create valid PDF and without such a check such problems get undetected. I've got the PNG file from someone writing his master thesis on Windows. He didn't encounter any problem himself. Here only Okular crashed, Evince and two versions of Adobe Reader didn't complain. And a minimal example which contains only the PNG file is accepted by Okular. Thus I can't provide a minimal example. But I've copied the PNG and PDF files to http://ms25.ddns.net/texlive/png-inclusion.tar.xz The PDF files were created by pdfTeX, using only the \pdfximage and \pdfrefximage primitives. Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------

2 1

Allow skippig the font cache in font.getfont
by Marcel Fabian Krüger 12 Dec '19

12 Dec '19

Hello, could font.getfont get an option to always return a new font table instead of returning the current one? While for many fonts a cached table makes sense, sometimes it would be useful to also have access to the ooriginal table, e.g. to see which characters are `used`, inspect the result of `font.addcharacters` or inspect other changes which might be applied to the underlying font from TeX. I attached a patch implementing this by adding a `nocache` parameter to `font.getfont`, such that `font.getfont(true, font_id)` always generates a new table. IMO `font.getfont(font_id, true)` would look nicer, but that wouldn't be compatible to older LuaTeX versions which always expect the font is as last parameter. Best regards, Marcel

2 1