November 2019 - dev-luatex - NTG Mailing Lists

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

Revive Type 3 fonts
by Marcel Fabian Krüger 15 Nov '19

15 Nov '19

Hey, LuaTeX currently supports only a very special kind of Type 3 fonts: They are generated for traditional TeX bitmap fonts. While this used to be the most common use case for Type3 fonts, the fully general concept of these fonts has recently been reinvented under the name of SVG fonts (and friends). While they can be implemented in LuaTeX to some degree through virtual fonts/node processing etc., converting them into "real" Type 3 fonts in the PDF file would give some important advantages: Such fonts are called like other fonts and can get tounicode vectors, allowing better accessibillity and better Copy&Paste behaviour. Also viewers generally treat them as text instead of graphics, allowing proper interaction with features of PDF viewers. Beside from supporting SVG fonts, it also allows to use general MetaPost fonts which might not be easily convertable into normal formats for vector fonts. As far as I can tell there used to be an implementation of general Type 3 fonts for pdfTeX which was dropped in LuaTeX, mostly because it was never actually used. My suggested new implementation is a bit more flexible by not requiring external files defining the font but instead generating each font character based on individual node lists for every glyph. One way to make this work would be to add a special `format` named e.g. `node` (given that `type3` is already used to imply bitmap fonts) and add a field `node`/`list`/`head` to the character table referencing a node list which should become the font glyph. The detaily like bounding box calculations etc. would be the responsibility of the Lua code loading the font. The intended usage would be e.g. \directlua{ local l = token.scan_list() local wi = node.new('whatsit', 'pdf_literal') wi.mode = 3 wi.data = math.floor(l.width / tex.sp'1bp') .. ' 0 d0' wi.next = l.head l.head = wi font.current(font.define{ name = "exp-nodefont", format = "node", designsize = tex.sp("10pt"), size = tex.sp("10pt"), characters = { [42] = { width = l.width, height = l.height, depth = l.depth, node = node.direct.todirect(l), } } })}\hbox{ABC} \char42 \char42 \bye What do you think? (I'll attach a patch I used for experiments (mostly with MetaPost fonts) which implements this in a slightly hacky way.) -- Marcel

6 7

Improvement for `glyph_info`
by Marcel Fabian Krüger 15 Nov '19

15 Nov '19

Hi, the new `glyph_info` callback is called in two pretty different cases: in `short_display(_n)` where a pretty short representation of the actual output characters is required, and in `print_font_and_char`, which creates the representation for `print_node_list`. Here, more details can be useful, e.g.: Which variant of a character is used, are displacements applied etc. These could be added through `glyph_info`, but then these additional fields are also printed in `short_display`, leading to significantly worse overfull warnings etc. This could be improved if `glyph_info` could return different values in different situations. So I suggest to add an additional parameter to the `glyph_info` callback which states if the current context could handle longer output. A possible implementation is attached. Best regards, Marcel

4 4

require doesn't get recorded
by Marcel Fabian Krüger 08 Nov '19

08 Nov '19

Hi, based on an observation by Karl Berry on the TeX Live list I discovered an inconsistency in LuaTeX's handling of `-recorder`: While LuaTeX does record files loaded through `loadfile`, files loaded through `require` are ignored: For example if the current directory contains two empty files l1.lua and l2.lua, then the document \directlua{ loadfile'l1.lua'() require'l2' } \bye compiled with `luatex -recorder recorded` IMO should write to recorded.fls the entries PWD /some/weird/pwd INPUT /usr/local/texlive/2019/texmf-var/web2c/luatex/luatex.fmt INPUT ./recorded.tex OUTPUT recorded.log INPUT l1.lua INPUT ./l2.lua but it does write PWD /some/weird/pwd INPUT /usr/local/texlive/2019/texmf-var/web2c/luatex/luatex.fmt INPUT ./recorded.tex OUTPUT recorded.log INPUT l1.lua I do not think that this is intentional, so I added a patch to add recorder entries iff the file is loaded successfully (similar to `loadfile`) -- Marcel

3 6

Re: [Dev-luatex] Broken \adjdemerits on Linux due to unspecified enumeration type
by Marcel Fabian Krüger 05 Nov '19

05 Nov '19

Hi, thanks for fixing the \adjdemerits problem. One remark about the fix: The line if ( (fit_class>(fitness(r)+1)) || (fitness(r)>(fit_class+1)) ) is indented by one tab "\t" and four spaces, while all surrounding code is only indented with spaces. (Confusingly, tabs are also used as indentation in line 117-119) This leads to confusing appearence if the file is viewed in an editor which does not use 8 spaces for one tab. Maybe this could be changed to be a bit more consistant? Best regards, Marcel

2 1