12

When a font is first used with lualatex, luaotfload does some magic to produce font cache files.

For large fonts (e.g., Noto Sans CJK) this can take a lot of time and a lot of memory.

I have an old computer (5 year old MacBook air with 4GB RAM) running Linux with a 4GB swap partition. The initial cache generation of this font can take more than 15 min and render my computer unusable. Sometimes I just run out of memory and the process is killed.

Let's say I want to use the font as such:

\documentclass{article}
\usepackage{fontspec}
\setmainfont[Script=CJK,Language=Chinese Simplified]{Noto Sans CJK SC}
\begin{document}
中文
\end{document}

What is the least resource intensive way and/or fastest way to generate the required cache files?

At the moment, I quit everything (even X11) and run lualatex from the console, but it still takes a long time, and quitting everything is a bit of a pain.

  • 1
    That is a very good question, but I don't think you can do any better as you do now. Here is Hans' statement about this: mailman.ntg.nl/pipermail/ntg-context/2018/092703.html – Henri Menke Mar 16 at 7:49
  • xelatex might be an alternative if you don't need lua-specifics, just fontspec. – Joseph Mar 16 at 11:23
  • @Joseph, yes xelatex has no problems of course. Although I notice something curious with xelatex. I use the true type collection font: NotoSansCJK-Regular.ttc. When I run pdffonts on the the PDF file produced by xelatex it gives: ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Notice jp for Japanese instead of sc for Simplified Chinese as requested). I don't know where the error is though. I guess it xelatex could be embedding the right font from the ttc but with the wrong name. – David Purton Mar 16 at 11:38
  • As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the jp one. All the language specific fonts contain all glyphs and the right language seems to be automatically used by xelatex when you request a language specific font without manually specifying the Language= option of fontspec. – David Purton Mar 16 at 13:11
13

You can do as proposed in section 9.2.1 “Trimming fonts“ in Fonts out of ConTeXt and remove all the glyph names in the font.

enter image description here

Adapted to LaTeX and your example:

\documentclass{article}
\usepackage{fontspec,luacode}
\begin{luacode*}
fonts.handlers.otf.readers.registerextender {
    name   = "remove names from Noto Sans CJK SC",
    action = function(fontdata)
        if string.match(fontdata.metadata.fullname, "Noto Sans CJK SC") then
            texio.write_nl("Trimming font " .. fontdata.metadata.fullname)
            for k, v in next, fontdata.descriptions do
                v.name = nil
            end
        end
    end
}
\end{luacode*}
\setmainfont[Script=CJK,Language=Chinese Simplified]{Noto Sans CJK SC}
\begin{document}
中文
\end{document}
  • Can this solution be problematic in some cases? – Paul Gaborit Mar 16 at 8:21
  • @PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is \getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient. – Henri Menke Mar 16 at 8:28
  • Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something. – David Purton Mar 16 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.