db : Reload initiated over and over because an existing font is not found

[callegar]

I have a LaTeX (in fact lualatex) file with the following snippet

\newfontface { \institutionfont } { Cinzel[wght].ttf }
  [ Scale = 1.076, FakeStretch = 1.038,
    RawFeature = { +axis = { wght = 428 } } ]

Compiling the file I get, over and over, luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: Font "Cinzel[wght].ttf" not found.

However, the font is there and luaotfont-tool -u -vvvv shows it being found...

[cfr42]

Do you really have a font called Cinzel[wght].ttf?

[callegar]

Yes, it is the "variable" version of the Cinzel font. See https://github.com/NDISCOVER/Cinzel/tree/master/fonts/variable.
I need it to better match in appearance a proprietary Trajan font with the relatively similar Cinzel.

Unfortunately, the variable Cinzel font is not differentiated in name from the non variable one, only in the filename, so, having both installed (because not all software is compatible with variable fonts), I need to refer to the variable one by filename.

The weird aspect is that luaotfload seems to find the font in the end, but needs to "reload" every time, apparently making the compilation slower. Actually, it is unclear to me if this is an innocuous diagnostic (i.e., the compilation of the LaTeX document would be slower anyway because the variable font needs more time to load) or corresponds to some actions that while ultimately successful are carried out in an incorrect or not so efficient way.

[cfr42]

You need

\newfontface { \institutionfont } {Cinzel[wght].ttf}
  [ Scale = 1.076, FakeStretch = 1.038,
    RawFeature = { +axis = { wght = 428 } } ]

Note the lack of spaces in the font filename. luaotfload treats the name verbatim. If you include spaces, it seems to look for " Cinzel[wght].ttf ". I say 'seems' because, if so, the reporting is highly confusing, as it trims spaces when reporting what it can't find.

I would use something like

\newfontface {\institutionfont} {Cinzel[wght].ttf} [Weight=428,Scale=1.076,FakeStretch=1.038]

It's not actually recreating the database each time. It's probably checking it. Playing with this I ended up generating fatal errors which never went away and cleared the cache out. Compiling after that takes much longer.

I think the bug here is in the reporting of the error in the filename requested. It should report searching for the untrimmed name (if that is what it does) and finally using the trimmed one, with a message which makes it clear how to correct the source.

[FrankMittelbach]

Interesting observation. Is there any font name ever that has spaces on the outside? I doubt it and if not I think it might be best if fontspec would trim the outer spaces when processing the arguments to \newfontface(and probably other declarations. @wspr what is your opinion?

[callegar]

My code is actually expl3, so the space should be removed before the filename gets to luaotfload, I believe.

[FrankMittelbach]

@callegar in that case (as always) it would have helped to have a complete minimal example that shows your problem, not just a description with a code fragment. That way people can easily reproduce or can state with confidence that they can't reproduce.

[zauguin]

I think the bug here is in the reporting of the error in the filename requested. It should report searching for the untrimmed name (if that is what it does) and finally using the trimmed one, with a message which makes it clear how to correct the source.

The message is confusing since it does actually use the trimmed name, but it searches in the wrong place.

fontspec tries to detect if a filename is passed by checking if the name ends with a file extension usually associated with font files, e.g. .ttf. If the extension is followed by a space, then fontspec does not detect the extension and therefore assumes that it's a font name and not a filename. Afterwards fontspec already strips the spaces, so luaotfload ends up being called with a request to load the font name Cinzel[wght].ttf. This doesn't exist of course, the correct font name would have been Cinzel Regular. Therefore the lookup fails, leading to the message and triggering a refresh of the database in case a font with this name has recently been added (which is much faster than a full rebuild since it mostly looks for new files). Of course that still fails.

The reason that it still ends up working is that we end up falling back to just trying to load the font as a filename is the font name lookup fails, which finally succeeds.

From luaotfload's point of view we could question if this behavior is correct or if loading a font should just fail if the font command explicitly requests a font name lookup and then passes a filename. I think that the current approach of still loading the font in the end makes sense here though since it doesn't cause a significant performance impact since at that point we have a freshly updated font database anyway.

The actual issue needs to be resolved on fontspec's side if fontspec wants to support spaces around it's argument but as far as I can tell @wspr already implemented this above.

[zauguin]

My code is actually expl3, so the space should be removed before the filename gets to luaotfload, I believe.

I can't reproduce this in an \ExplSyntaxOn` block.

[ExecutorElassus]

For what it's worth, I just stumbled across this same error with Atkinson Hyperlegible having a space within the font name, which led to a bunch of formatting code getting output into the pdf document and a bunch of errors about rebuilding the luaotfload database. (I'm using the awesome-cv template). I needed to change the name to "AtkinsonHyperlegible" in the .cls file, and then the error went away along with the garbage output.

[veevang]

For what it's worth, I just stumbled across this same error with Atkinson Hyperlegible having a space within the font name, which led to a bunch of formatting code getting output into the pdf document and a bunch of errors about rebuilding the luaotfload database. (I'm using the awesome-cv template). I needed to change the name to "AtkinsonHyperlegible" in the .cls file, and then the error went away along with the garbage output.

Thanks for your solution! Anyway, I think the solution you've proposed is a good temporary solution.
I encountered the same problem when editing my old CV on a new computer. Since I haven't experienced the problem before on my old computer with old versions of Tex Live and other tools, the problem might be a new one.

[cfr42]

@ExecutorElassus @veevang If you are getting errors as a result of spaces within filenames, I think that should be reported separately because (1) it is certainly not due to a problem identifying the extension (which was the problem here) and (2) it would be a regression. However, I don't know if it would be a problem here or in fontspec.

But you need to report the problem properly i.e. with an example which enables people to reproduce the error.

[mirabilos]

I’m seeing the same…

luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: Font "GentiumPlus-Regular.ttf" not found.)

… on every single run.

Another person reported on SE that this is because they specified the font by filename (with the .ttf appended) instead of by family and report a noticeable speedup for the latter. This is bad though if you want to make sure that this exact file is used…

My environment is Debian bullseye’s packaged TL.

[u-fischer]

which luaotfload version do you use? (you can find the version of the fontloader at the begin of the log-file).

[mirabilos]

This is LuaHBTeX, Version 1.12.0 (TeX Live 2020/Debian)  (format=lualatex 2024.9.4)  5 SEP 2024 20:02
 restricted system commands enabled.
**cv.tex
(./cv.tex
LaTeX2e <2020-10-01> patch level 4
Lua module: luaotfload 2021-01-08 3.17 Lua based OpenType font support
Lua module: lualibs 2020-12-30 2.73 ConTeXt Lua standard libraries.
Lua module: lualibs-extended 2020-12-30 2.73 ConTeXt Lua libraries -- extended c
ollection.
luaotfload | conf : Root cache directory is "/home/tg/.texlive2020/texmf-var/lua
tex-cache/generic/names".
luaotfload | init : Loading fontloader "fontloader-2021-01-07.lua" from kpse-res
olved path "/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-2021-
01-07.lua".
Lua-only attribute luaotfload@noligature = 1
Lua-only attribute luaotfload@syllabe = 2
luaotfload | init : Context OpenType loader version 0x1.8e76c8b439581p+1

[u-fischer]

well that is way to old. We have 2024 and a current fontloader has the date fontloader-2023-12-28.lua. On my system \setmainfont{GentiumPlus-Regular.ttf} works flawless.

[mirabilos]

Thanks, not helpful.

[mirabilos]

Adding one of these…

 ,      Path             = /usr/share/fonts/truetype/gentiumplus/
 ,      Path             = \string~/.local/share/fonts/

… etc. (depending on where the fonts in the filesystem are) to all font specifications fixes this as well.

[cfr42]

@mirabilos,

Thanks, not helpful.

The point is that this is not a bug which can be fixed by the developers of luaotfload (or fontspec) because it is not a current bug¹. The response is as helpful as possible: it tells you you need to find a solution elsewhere.

Options:

1. Persuade Debian to backport whatever fixed the problem. (I'd guess this is highly unlikely to succeed.)
2. Persuade Debian to update their packages. (I'd guess this is unlikely.)
3. Install packages from an alternative repo, if Debian offers one for your current installation. (Don't know what you are using, except presumably not SID, or what might be available.)
4. Install vanilla TeX Live from upstream (and possibly a dummy package to satisfy apt).
5. Change your Linux distro to something which uses more current TeX Live.
6. Find a workaround (perhaps ask on TeX SE or elsewhere if you need help).
7. Live with it.

(3) may be a reasonable option, if it is an option at all, but only if you can find a reliable and trustworthy source of packages. Otherwise, I would recommend (4) or (6) unless you are frustrated by your current Linux distro for independent reasons.

_{¹This is an entirely standard upstream response, by the way: if you report a problem with the Linux kernel, your report will be closed if it can't be reproduced on a kernel which is both current and untainted - a far more stringent criterion than a current TeX install, in fact, since you may well be using a tainted kernel by default and may even be unable to run an untainted one.}