khaledhosny / harf

A HarfBuzz-based font loader and shaper for HarfTeX
GNU General Public License v2.0
10 stars 1 forks source link

With fontspec luaotfload seems to still load the fonts itself #30

Closed khaledhosny closed 5 years ago

khaledhosny commented 5 years ago

Not sure if this is new, but today the LaTeX example took so long and froze my system while consuming all available memory, which usually happens when luaotfload loads Noto Serif CJK, but it shouldn’t be loading any fonts. Might be related to the fact that with fontspec both mode=node and mode=harf are used.

khaledhosny commented 5 years ago

There should be no more mode=node after d9f6ec1a269f27e214b1fc4fe4321d0255a960c4, but it still does not fix the issue.

khaledhosny commented 5 years ago

@u-fischer, @zauguin: It seems that fonts.definers.read is always called first even if mode=harfis set. Is this expected, and if yes is there any way to override it and have my fonts.readers.harf called first and only call the other when it returns nil?

u-fischer commented 5 years ago

I can look tomorrow. How do you see that fonts.definers.read is called?

khaledhosny commented 5 years ago

I add a print after https://github.com/u-fischer/luaotfload/blob/401f60d473efb5953c38ad04680412ee2b14388e/src/luaotfload-loaders.lua#L135 and after https://github.com/khaledhosny/luahbtex-harf/blob/d9f6ec1a269f27e214b1fc4fe4321d0255a960c4/src/harf-luaotfload.lua#L14, and both are always called (the issue does not seem specif to LaTeX as I initially thought).

zauguin commented 5 years ago

@khaledhosny That's by design and can not be changed without rewriting bigger parts of luaotfload (or introducing an ugly hack): fonts.definers.read is responsible for managing the whole lookup process, especially it is the function which (indirectly) is used to call fonts.readers.harf. It should not actually load the font using the fontloader through if mode=harf is set, therefore the readers implementation might be buggy. The function doing the actual loading would be fonts.readers.otf.

khaledhosny commented 5 years ago

Thanks. So I tried with opentypereader in fontloader-2018-12-19.lua; with Plain it is never called, with LaTeX it is called several times before my loaders is called. Now I’m starting to suspect that it is somehow related to fontspec.

khaledhosny commented 5 years ago

The font specifications that get through to opentypereader seem to be without any options at all, I’m pretty sure these come from fontspec as it does its many font checks before loading the font for real.

I’m not sure what to do in this case.

khaledhosny commented 5 years ago

Looks like I can force a default luaotfload mode with a luaotfload.conf file:

[default-features]
  global = mode=harf

But this causes other interesting issues I need to handle (like how to override relevant luaotfload.aux functions to work on HarfBuzz-loaded fonts). Needs more investigation.

u-fischer commented 5 years ago

What is the problem with fonts.definers.read? Does is break something? I'm currently quite unsure if your problem is with luaotfload or fontspec. Can you make a small example? I can run some tests in the evening.

khaledhosny commented 5 years ago

It does not break anything, but it can be slow for very large fonts, which is waste of time if these fonts are not going to be handled with luaotfload’s node processor (for Noto Serif CJK font, loading it for the first time freezes the system consuming all available memory).

u-fischer commented 5 years ago

Hm, yes, I already had some cjk fonts freezing my system too. A few days ago I had to kill the compilation. I think we should look at this, but it will need a bit time - I'm busy in the next weeks.

khaledhosny commented 5 years ago

Fontspec issue.