there are no glyphs in the subset! ==> Fatal error occurred, no output PDF file produced

[emojifreak]

This issue seems very similar (or the same) as the already closed #73

% luatex (not lualatex)
\input luaotfload.sty
% ❤ is U+2764
\font\a=[/usr/local/texlive/2019/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf]
\a ❤
\bye

processed by luatex + luaotfload 3.1, and

% luahbtex (not luatex)
\input luaotfload.sty
% ❤ is U+2764
\font\a={[/usr/local/texlive/2019/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf]:mode=harf}
\a ❤
\bye

by luahbtex + luaotfload 3.1, cause the runtime error there are no glyphs in the subset! ==> Fatal error occurred, no output PDF file produced A difference with #73 is that luahbtex also causes the error, while in #73 luahbtex did not have this error.

On the other hand, the following file

% luatex (not lualatex)
\input luaotfload.sty
% ❤ is U+2764
\font\a=[/usr/local/texlive/2019/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf]
\a test❤
\bye

produces a PDF (attached notdef4.pdf) which has some glyph after test. The same glyph should appear in the first two cases, maybe. notdef4.pdf

In addition, mode=base does not cause runtime error and produced a PDF with an empty line, as below:

\input luaotfload.sty
% ❤ is U+2764
\font\a={[/usr/local/texlive/2019/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf]:mode=base}
\a ❤
\bye

Examples are based on one given by Hironori Kitagawa at https://osdn.net/projects/luatex-ja/ticket/39740

[u-fischer]

Well yes, the font doesn't have the glyph. We can look at it, but what is luatexja doing here? Why does it process a content that should be set in another font with ipaexm.ttf?

\documentclass{article}
\usepackage{luatexja} %gives error.
\begin{document}
\font\segoe={name:Segoe UI Emoji:+colr;+ccmp;+dist;}
\noindent
\segoe ❤
\end{document}

[emojifreak]

@u-fischer Thank you for your response.

Why does it process a content that should be set in another font with ipaexm.ttf?

When luatexja is used, the unicode codepoints are divided into the two categories, the ALchar (for non-Japanese) and the JAchar (for Japanese). ❤ (U+2764) is categorized as JAchar and ❤ is typeset in ipaexm.ttf. If one uses \jfont in place of \font as below, ❤ is typeset in Segoe UI Emoji...

\documentclass{article}
\usepackage{luatexja}
\begin{document}
% \jfont in place of \font. \jfont requires jfm=something.
\jfont\segoe={name:Segoe UI Emoji:+colr;+ccmp;+dist;jfm=ujis;}
\noindent
\segoe ❤
\end{document}

[zauguin]

@emojifreak The problem is the same as first part of #73: LuaTeX does not like including TTF fonts where the only used glyph is the .notdef glyph.

The issue has been reported upstream back in July, but it doesn't look like the LuaTeX team is interested in fixing it anytime soon.

[u-fischer]

@emojifreak well while it would be nice if luatex wouldn't fail if only .notdef is used, it sounds as if your font command is wrong, and also as if the category of the ❤ is wrong in luatexja.

[emojifreak]

@zauguin

but it doesn't look like the LuaTeX team is interested in fixing it anytime soon.

Thank you, I see the situation. It is interesting that ConTeXt does not have this problem as it handles the following file with no error:

\definefont[ipafont][file:/usr/local/texlive/2019/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf]
% ❤ is U+2764
\starttext
\ipafont ❤
\stoptext

@u-fischer

and also as if the category of the ❤ is wrong in luatexja.

The categories of ❤ and other emoji related codepoints have been discussed several times in luatexja problem reports such as https://osdn.net/projects/luatex-ja/ticket/39513 https://osdn.net/projects/luatex-ja/ticket/39740

[zauguin]

@emojifreak The problem is related to the nitdef glyph (it doesn't happen if the notdef glyph isn't inserted) If you don't insert any font glyph (e.g. because the glyphs don't exists like in your ConTeXt example, LuaTeX doesn't try to embed the font. The problem only appears if .notdef is inserted but nothing else, which happens by default when luaotfload doesn't find any of the glyphs you use from a font. So it is expected to be a luaotfload specific problem. Of course, as Ulrike wrote the bigger problem is that you try to select a font which doesn't have any of the glyphs you use. Even if that would work you would probably just get a collection of empty boxes.

[emojifreak]

Of course, as Ulrike wrote the bigger problem is that you try to select a font which doesn't have any of the glyphs you use. Even if that would work you would probably just get a collection of empty boxes.

I agree that the current behavior (runtime error) is unlikely to cause a problem in practical situations, as at least one glyph is almost always used from a font.

[jtojnar]

I agree that the current behavior (runtime error) is unlikely to cause a problem in practical situations, as at least one glyph is almost always used from a font.

I just encountered this in practice – not being fluent in LaTeX, I learnt to introduce macros to my documents incrementally and checking if the document still builds in between to make debugging issues easier. Here I introduced a new font and it broke the build even though the macro use looked completely fine until I found this issue.