Am 27.05.2019 um 04:09 teilte Ryutaroh Matsumoto mit:
Matsumoto-san,
thanks for your interest and comment. It is (in my opinion) a well-known issue among Japanese LuaLaTeX users, and I can show a even worse example (for your fun), which needs 6 GB of real RAM and 10 minutes to compile three lines, in the first time you process a CJK tex source as below :-)
OK, after re-configuring my VM (put more RAM into it) and stopping a RAM eating process I was able to compile your document. I guess your comment in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929128#40 is completely valid. The font needed by the document is "NotoSerifCJKJPLight" and this font is provided by fonts-noto-cjk-extra, not by fonts-noto-cjk. I just checked the package from experimental. root@sid:~# dpkg -L fonts-noto-cjk|grep opentype /usr/share/fonts/opentype /usr/share/fonts/opentype/noto /usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc /usr/share/fonts/opentype/noto/NotoSerifCJK-Bold.ttc /usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc root@sid:~# dpkg -L fonts-noto-cjk-extra|grep opentype /usr/share/fonts/opentype /usr/share/fonts/opentype/noto /usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc /usr/share/fonts/opentype/noto/NotoSansCJK-DemiLight.ttc /usr/share/fonts/opentype/noto/NotoSansCJK-Light.ttc /usr/share/fonts/opentype/noto/NotoSansCJK-Medium.ttc /usr/share/fonts/opentype/noto/NotoSansCJK-Thin.ttc /usr/share/fonts/opentype/noto/NotoSerifCJK-Black.ttc /usr/share/fonts/opentype/noto/NotoSerifCJK-ExtraLight.ttc /usr/share/fonts/opentype/noto/NotoSerifCJK-Light.ttc /usr/share/fonts/opentype/noto/NotoSerifCJK-Medium.ttc /usr/share/fonts/opentype/noto/NotoSerifCJK-SemiBold.ttc
Once lualatex complies it, the same file is compiled in much shorter time and much smaller memory. (So one needs "rm -rf ~/.texlive201?" to see long compilation time.)
<snip>
I am a bit reluctant to file the above issue to texlive-lang-japanese (or texlive-luatex??) because it does not seem a packaging problem by the Debian TeX team and they tell us in "reportbug" that
Yes, I'm aware that our reportbug scripts tell this. The reason is that the Debian TeX team is currently quite small (just Norbert and me) and we have to push as much as possible work back to the submitter. However I'm willing to submit and track serious upstream bugs if I have time. Hilmar -- #206401 http://counter.li.org