-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 2.98 crashing LuaTeX for some fonts #73
Comments
Reproducible with e.g. the following. Obviously the code doesn't like it if one uses a font, without actually accessing an existing glyph of this font:
|
An even more minimal example is
(For this font, the The problem is that LuaTeX, at least for TrueType fonts, does not count the notdef glyph as a used glyph, so if only notdef is used, it thinks that there are no used glyphs at all. I will send a patch to dev-luatex. |
It the meantime we should discuss the elephant in the room: Why is there blank output in the first place? |
@zauguin imho the elephant is in the room as @bgvoisin made a rather large testsuite for fonts to compare xelatex/lualatex/harflatex/luahblatex) and in some cases the font actually hadn't the glyphs of the test. So it is a rather academic and not very urgent problem. But if possible it should be avoided that one gets a fatal error in this case. |
@u-fischer I do not think so, because @bgvoisin explicitly mentioned and showed in his test files that harftex and luahbtex can show the missing glyphs, so they must exist somewhere. |
@zauguin I hadn't the time to look at the test files, I simply took "were yielding blank output" and "the output is still blank" as an indication that no glyph (apart from notdef) is actually used (that's why I then tried with the logix.ttf). |
Reported to the LuaTeX team in https://mailman.ntg.nl/pipermail/dev-luatex/2019-July/006287.html |
On 23 Jul 2019, at 12:50, Marcel Krüger ***@***.***> wrote:
It the meantime we should discuss the elephant in the room: Why is there blank output in the first place?
@bgvoisin Do you know about any font which shows the same problem and which is available without macOS?
Sorry for missing most of the discussion, I was off the internet for a few hours. Unfortunately I don't have access to a non-mac computer right now.
The fonts with which the problem was observed are (font name + font file + sample input exhibiting the problem)
Heiti TC Light [STHeiti Light.ttc](0) 壹貳參肆伍陸柒捌玖拾
Heiti SC Light [STHeiti Light.ttc](1) 汉体书写信息技术标准相容
Heiti TC Medium [STHeiti Medium.ttc](0) 壹貳參肆伍陸柒捌玖拾
Heiti SC Medium [STHeiti Medium.ttc](1) 汉体书写信息技术标准相容
Big Caslon Medium [BigCaslon.ttf] ABCDEFGHIJKLM
GB18030 Bitmap [NISC18030.ttf] 汉体书写信息技术标准相容
Webdings [Webdings.ttf]
Wingdings [Wingdings.ttf]
Wingdings 2 [Wingdings 2.ttf]
Wingdings 3 [Wingdings 3.ttf]
LiHei Pro [LiHeiPro.ttf] 壹貳參肆伍陸柒捌玖拾
LiSong Pro [LiSongPro.ttf] 壹貳參肆伍陸柒捌玖拾
STFangsong [STFANGSO.ttf] 汉体书写信息技术标准相容
STXihei [STXIHEI.ttf] 汉体书写信息技术标准相容
STHeiti [STHEITI.ttf] 汉体书写信息技术标准相容
Yuanti SC Light [Yuanti.ttc](4) 汉体书写信息技术标准相容
Yuanti SC [Yuanti.ttc](0) 汉体书写信息技术标准相容
Yuanti SC Bold [Yuanti.ttc](2) 汉体书写信息技术标准相容
The first group of fonts are core macOS fonts (installed in /System/Library/Fonts), the second group additional fonts (still part of the OS, but installed in /Library/Fonts) and the third group downloadable fonts (not installed by default, downloaded from Apple servers when requested automatically by apps or manually by the user). See <https://support.apple.com/en-us/HT208968>.
I don't know which fonts may be obtained independently. Based on <https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list> I imagine Webdings and Wingdings are also part of Windows, though maybe not in the same versions and formats.
The samples are the first line of the font samples in Apple's Fon Book app, pasted directly from Font Book into an UTF-8 text editor.
Bruno
|
The problem also vanishes putting :mode=base instead of :notdef=false. I don't know enough of LuaTeX to know whether that remark makes sense/is helpful. |
@bgvoisin Which problem vanishes then? Do you see the actual glyphs or just an empty line with @u-fischer Do you have access to a Mac where you can test these fonts? |
@zauguin I meant an empty line with |
@zauguin Here it is (it's actually |
I'm happy to test too, if needed. |
@bgvoisin Do you have |
@zauguin I didn't have it but just installed it, it's quite easy actually. |
@u-fischer The actual problem is that the OpenType cmap format used by these fonts isn't supported by the fontloader. We could patch |
@zauguin yes, I can naturally report it. Do you have an example that I can use in the message? And where in the file should the entries go? If the cmap isn't supported, why did the problem only appear after the missing char change? |
This file shows the error, but it requires proprietary Mac fonts. I couldn't reproduce it with any more accessible fonts. In This is the problem that the characters are not printed which appeared even before the missing char change. The missing char thing only made it more obvious because instead of printing nothing, LuaTeX started to produce error messages. |
@zauguin I just saw that Hans changed something in the file, and added |
@bgvoisin I pushed a new version in the branch https://github.com/u-fischer/luaotfload/tree/v2.9902-2019-07-24. Could you please try it? You simply need the texmf tree and add it to your system with tlmgr auxtrees add .... @zauguin |
@u-fischer I created a testing branch macfonts where I uncommented the significant element in all fontloader copies. The "pure" patch would be
|
@zauguin I'm testing right now the new version from @u-fischer. I made the mistake of using my catalog file of all macOS fonts as a test, typesetting is taking ages (1 hour and 27 minutes now, still running, still recreating many font caches from scratch – lua and luc files). For one Hiragana font the lua file is even 82 MB and took 23 minutes to create ! I should have tested font by font only. I'll let you know of the outcome as soon as typesetting completes. I'll have a look at the macfonts branch afterwards. |
@u-fischer Reporting failure unfortunately: the new v2.9902-2019-07-24 yields exactly the same fatal errors as before, for exactly the same fonts. Two caveats:
and that was it. For example,
so luaotfload-tool points to the old script not the new one
in case that matters. If time allows, I'll try doing things the more pedestrian way I'm familiar with, putting the new texmf tree in texmf-local then running mktexlsr and fmtutil-sys manually to make sure everything is properly initialized. (And changing the script symlink manually.)
I won't be back for a few hours. |
At best test only one of your fonts. E.g. with
Check the log file: It should tell you which luaotfload version you are using. It should also tell you where the fontloader is that you are using. So it should be easy to sea, if you are using the right one. We are trying here to fix that your fonts gave a blank output, the notdef business was only a side effect. |
@u-fischer It's luaotfload 2019-07-24 2.9902 and fontloader-2019-07-24.lua. With them it's still fatal error. Following is an archive with a tex test file for all the fonts that exhibit the behaviour, together with associated lua and ttx files. |
@zauguin With the macfonts branch, exactly the same errors as with the trunk fontloader-2019-07-24 unfortunately. |
@bgvoisin It did fix the problem for Big Caslon, you just have to wipe the font caches before the change applies. You can pull the latest version from the branch first to fix the other fonts too. Then delete everything in |
@zauguin Thanks. I should have thought about the caches! It does fix things for all the fonts save one, which is insignificant: GB18030 Bitmap (aka NISC18030.ttf), a bitmap font that has never worked with any TeX engine. Thanks on behalf of the Mac TeX community! |
@u-fischer With luaotfload-2.9902-2019-07-24 all the fonts are giving fatal errors. These are
With luaotfload-macfonts they all give correct output (ie not blank lines, but exactly the requested glyphs). This was with luaotfload-macfonts downloaded this morning (build 2019-07-25 02:46:50), not the version from yesterday night (build 2019-07-24 17:52:03). Looking very rapidly, it adds not only
but also
|
@u-fischer |
@bgvoisin the values suggested by @zauguin are in the newest version. It would be nice if you could test. The files are in branch https://github.com/u-fischer/luaotfload/tree/v2.9904-2019-08-02. |
@u-fischer the newest version work fine. |
This will be resolved with the next version. |
Since version 2.98, some macOS fonts which were yielding blank output with LuaTeX and luaotfload now crash it. One such font is Big Caslon Medium:
! error: (file /System/Library/Fonts/Supplemental/BigCaslon.ttf) (type 2): the
re are no glyphs in the subset
! ==> Fatal error occurred, no output PDF file produced!
Reverting back to pre-2.98 behaviour by using feature notdef=false solves the problem (the output is still blank, but it does not crash LuaTeX). The problem doesn't arise with HarfTeX or LuaHBTeX. See attached files.
luaotfload-2.98-issue.zip
The text was updated successfully, but these errors were encountered: