What is the least resource intensive way to generate the luatex font cache for a new font?
9
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.
fonts luatex fontspec luaotfload
asked yesterday
David PurtonDavid Purton
10.7k2939
add a comment |
9
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.
fonts luatex fontspec luaotfload
asked yesterday
David PurtonDavid Purton
10.7k2939
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
yesterday
xelatexmight be an alternative if you don't need lua-specifics, justfontspec.
– Joseph
yesterday
@Joseph, yesxelatexhas no problems of course. Although I notice something curious withxelatex. I use the true type collection font:NotoSansCJK-Regular.ttc. When I runpdffontson the the PDF file produced byxelatexit gives:ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Noticejpfor Japanese instead ofscfor Simplified Chinese as requested). I don't know where the error is though. I guess itxelatexcould be embedding the right font from thettcbut with the wrong name.
– David Purton
yesterday
As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always thejpone. All the language specific fonts contain all glyphs and the right language seems to be automatically used byxelatexwhen you request a language specific font without manually specifying theLanguage=option offontspec.
– David Purton
yesterday
add a comment |
9
9
9
2
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.
fonts luatex fontspec luaotfload
asked yesterday
David PurtonDavid Purton
10.7k2939
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.
fonts luatex fontspec luaotfload
fonts luatex fontspec luaotfload
asked yesterday
David PurtonDavid Purton
10.7k2939
asked yesterday
David PurtonDavid Purton
10.7k2939
asked yesterday
David PurtonDavid Purton
10.7k2939
asked yesterday
David PurtonDavid Purton
10.7k2939
asked yesterday
David PurtonDavid Purton
10.7k2939
10.7k2939
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
yesterday
xelatexmight be an alternative if you don't need lua-specifics, justfontspec.
– Joseph
yesterday
@Joseph, yesxelatexhas no problems of course. Although I notice something curious withxelatex. I use the true type collection font:NotoSansCJK-Regular.ttc. When I runpdffontson the the PDF file produced byxelatexit gives:ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Noticejpfor Japanese instead ofscfor Simplified Chinese as requested). I don't know where the error is though. I guess itxelatexcould be embedding the right font from thettcbut with the wrong name.
– David Purton
yesterday
As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always thejpone. All the language specific fonts contain all glyphs and the right language seems to be automatically used byxelatexwhen you request a language specific font without manually specifying theLanguage=option offontspec.
– David Purton
yesterday
add a comment |
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
yesterday
xelatexmight be an alternative if you don't need lua-specifics, justfontspec.
– Joseph
yesterday
@Joseph, yesxelatexhas no problems of course. Although I notice something curious withxelatex. I use the true type collection font:NotoSansCJK-Regular.ttc. When I runpdffontson the the PDF file produced byxelatexit gives:ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Noticejpfor Japanese instead ofscfor Simplified Chinese as requested). I don't know where the error is though. I guess itxelatexcould be embedding the right font from thettcbut with the wrong name.
– David Purton
yesterday
As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always thejpone. All the language specific fonts contain all glyphs and the right language seems to be automatically used byxelatexwhen you request a language specific font without manually specifying theLanguage=option offontspec.
– David Purton
yesterday
1
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
yesterday
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
yesterday
xelatex might be an alternative if you don't need lua-specifics, just fontspec.– Joseph
yesterday
xelatex might be an alternative if you don't need lua-specifics, just fontspec.– Joseph
yesterday
@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
yesterday
@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
yesterday
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
yesterday
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
yesterday
add a comment |
1 Answer
1
active
oldest
votes
9
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.
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}
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
Can this solution be problematic in some cases?
– Paul Gaborit
yesterday
@PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there isgetnamedglyphdirectwhich will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.
– Henri Menke
yesterday
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 yourluacode I didn't manage to complete the compile without it being killed. So that's something.
– David Purton
yesterday
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f479744%2fwhat-is-the-least-resource-intensive-way-to-generate-the-luatex-font-cache-for-a%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
9
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.
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}
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
Can this solution be problematic in some cases?
– Paul Gaborit
yesterday
@PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there isgetnamedglyphdirectwhich will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.
– Henri Menke
yesterday
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 yourluacode I didn't manage to complete the compile without it being killed. So that's something.
– David Purton
yesterday
add a comment |
9
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.
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}
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
Can this solution be problematic in some cases?
– Paul Gaborit
yesterday
@PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there isgetnamedglyphdirectwhich will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.
– Henri Menke
yesterday
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 yourluacode I didn't manage to complete the compile without it being killed. So that's something.
– David Purton
yesterday
add a comment |
9
9
9
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.
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}
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
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.
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}
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
answered yesterday
Henri MenkeHenri Menke
76.9k8168283
76.9k8168283
Can this solution be problematic in some cases?
– Paul Gaborit
yesterday
@PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there isgetnamedglyphdirectwhich will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.
– Henri Menke
yesterday
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 yourluacode I didn't manage to complete the compile without it being killed. So that's something.
– David Purton
yesterday
add a comment |
Can this solution be problematic in some cases?
– Paul Gaborit
yesterday
@PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there isgetnamedglyphdirectwhich will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.
– Henri Menke
yesterday
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 yourluacode I didn't manage to complete the compile without it being killed. So that's something.
– David Purton
yesterday
Can this solution be problematic in some cases?
– Paul Gaborit
yesterday
Can this solution be problematic in some cases?
– Paul Gaborit
yesterday
@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
yesterday
@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
yesterday
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
yesterday
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
yesterday
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f479744%2fwhat-is-the-least-resource-intensive-way-to-generate-the-luatex-font-cache-for-a%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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
yesterday
xelatexmight be an alternative if you don't need lua-specifics, justfontspec.– Joseph
yesterday
@Joseph, yes
xelatexhas no problems of course. Although I notice something curious withxelatex. I use the true type collection font:NotoSansCJK-Regular.ttc. When I runpdffontson the the PDF file produced byxelatexit gives:ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Noticejpfor Japanese instead ofscfor Simplified Chinese as requested). I don't know where the error is though. I guess itxelatexcould be embedding the right font from thettcbut with the wrong name.– David Purton
yesterday
As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the
jpone. All the language specific fonts contain all glyphs and the right language seems to be automatically used byxelatexwhen you request a language specific font without manually specifying theLanguage=option offontspec.– David Purton
yesterday