Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Hi Hilmar,
Thank you for your response.
I have checked this issue under TeXLive 2019 as of July 18
(installed by "install-tl") under ubuntu 19.04
(not debian/ubuntu packages)
The memory consumption of the latex file included in this
bug report was "only" 1.8 GB after rm -rf ~/.texlive2019.
Noto CJK fonts versions are those of ubuntu 19.04
(not the latest ones).
It was 6 GB when I filed this report.
Maybe 32-bit Linux can now handle the Noto CJK fonts.
At least we can say significant improvement is in the upstream,
though 1.8 GB seems a bit larger than necessary...
I again compiled the same latex file by xelatex,
but the processing finished immediately and
I could not see the memory consumption by "top"...
Ryutaroh
From: =?UTF-8?Q?Hilmar_Preu=c3=9fe?= <hille42@web.de>
Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto
CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Date: Thu, 18 Jul 2019 16:24:39 +0200
> On 18.07.19 13:39, Ryutaroh Matsumoto wrote:
>
> Hi Ryutaroh,
>
>> I believe that the problem is spotted and fixed at
>> https://github.com/u-fischer/luaotfload/issues/55
>>
>> The above seems to be uploaded to ctan on July 15.
>> Maybe the next release of texlive-luatex package will close
>> this issue without special effort.
>>
>
> 2019-05-18 luaotfload v2.97
> * fix issue #47
> * fix whatsits interfering with letterspacing (issue #53)
> * fix luaotfload-tool switches version and find not working
> correctly (PR#59)
> * fix luaotfload-tool support of ttc fonts (PR#58)
> * sync with context files from 2019-05-18 (improves handling of
> large fonts, see e.g. issue #55 and PR#58)
>
> So, I'd expect that v2.97 solves the problem. This version however is in
> Debian unstable, hence I gave it another try. I've noticed a virtual
> memory allocation of luatex having a size of 1,9 GB when building the
> cache. Not sure, if this is an significant improvement over the initial
> situation.
>
> Hilmar
> --
> sigfault
> #206401 http://counter.li.org
>
Reply to: