[NTG-context] readposition() in mkiv font-dsp.lua

Hans Hagen j.hagen at xs4all.nl
Fri May 17 16:43:36 CEST 2019

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


\definedfont[notosanscjkkr-regular] test

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 Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl

More information about the ntg-context mailing list