On 5/17/2019 3:01 PM, Dohyun Kim wrote:
Hi,
I am using luaotfload.sty in TexLive 2019, that is latex. On my mac, everything is flawlessly working.
But I've heard from somebody that NotoSansCJKkr-Regular etc fonts are not usable on Windows machine; so I tested on 32-bit Windows 10 virtual machine with small memory (2GB) and it was really unusable.
I did some digging into the source code of luaotfload package. Now I have a guess that readposition() in font-dsp.lua might be the culprit. For instance, when format == 0x04 and the result of readshort(f) == 0, then the return value of the function is currently "true". After it has been changed to "false", NotoSansCJKkr fonts are working quite well on 32-bit Windows.
With the same changes of readposition() on my 64-bit Mac, the elapsed time for making cache file of NotoSansCJK fonts has been dramatically reduced: from 25 seconds to 10 seconds. And the resulting cache file is perfectly the same as before.
So I would like to suggest those return values to be changed to "false". Certainly, I do not know much about opentype spec, so I might be wrong and there could be good reasons for current code state. Hm, just changing somethign from true to false is not a good idea
- what font are you talking about - how does yuour test file look here, \starttext \definedfont[notosanscjkkr-regular] test \stoptext gives "otf loading > loading, optimizing, packing and caching time 11.1" with context lmtx (and 12.9 seconds with regular mkiv) on a not that new laptop (64 bit windows), with the latest context beta. So, I need more info. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------