3

Edit 3, re-phrasing my original question:

luaotfload expects a file /usr/local/etc/fonts/fonts.conf. Why? This seems not to be a canonical place for any fonts.conf in xubuntu, or is it?

luaotfload | db : Cannot open fontconfig file /usr/local/etc/fonts/fonts.conf.

Original post:

I'm trying to switch from XeLaTeX to LuaLaTeX, but every time I try to use fontspec I run into the luaotfload database creation problem. I reproduced that with luaotfload-tool --update -vv as shown here:

me@mycomputer:~$ luaotfload-tool --update -vv
luaotfload | db : Updating the font names database.
luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.
luaotfload | db : Updating the font names database.
luaotfload | db : Blacklisting 4 files and directories.
luaotfload | db : Whitelisting 0 files.
luaotfload | db : Scanning TEXMF and $OSFONTDIR for fonts...
luaotfload | db : Scanning system fonts...
luaotfload | db : Searching in static system directories...
.../texmf-dist/tex/luatex/luaotfload/luaotfload-parsers.lua:198: stack overflow (too many arguments)
me@mycomputer:~$ luaotfload-tool -V
luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.
.../texmf-dist/tex/luatex/luaotfload/luaotfload-parsers.lua:198: stack overflow (too many arguments)

Also shown here is that I'm unable to find out with luaotfload-tool -V which version I'm running, because before telling me the tool tries to create the database and crashes.

I'm running xubuntu with TeX Live from the distro. LuaTeX declares itself like this:

This is LuaTeX, Version beta-0.79.1 (TeX Live 2015/dev/Debian) (rev 4971)

Can anyone see what's wrong here?

Edit:

According to a hint from here I did luaotfload-tool --dry-run --update --force --verbose=5 and the last lines before the crash were:

luaotfload | db : Collected 3286 files.
luaotfload | db : Scanning system fonts...
luaotfload | db : Searching in static system directories...
luaotfload | db : Cannot open fontconfig file /usr/local/etc/fonts/fonts.conf.
.../texmf-dist/tex/luatex/luaotfload/luaotfload-parsers.lua:299: stack overflow

OK, I don't have a directory /usr/local/etc/fonts and thus no file fonts.conf therein. No wonder it can't be opened. I have only a very limited knowledge about how Linuxes manage their fonts, but I do get a "deprecated" warning whenever I start evince from a terminal:

Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. please move it to /home/thomas/.config/fontconfig/fonts.conf manually

Not sure if that is about the same matter, though.

Edit2: No it isn't. I managed to resolve the evince deprecated message but the luatex/fontspec database crash remains.

  • It is luaotfload-tool -V --version. Then you can check other diagnostics commands for further surgery. – percusse Jun 15 '15 at 10:46
  • @percusse: sorry, same crash, no version number. I'd have thought -V is just the shorthand form of --version – Blackface Jun 15 '15 at 10:54
  • Edited Question: Added results from luaotfload-tool --dry-run --update --force --verbose=5: No File /usr/local/etc/fonts/fonts.conf. Still clueless, though. – Blackface Jun 15 '15 at 11:16
2

EDIT -- located the source of the problem:

kpsewhich luaotfload-database.lua

contains a verbatim path

local fonts_conves = { --- plural, much?
        "/usr/local/etc/fonts/fonts.conf",
        "/etc/fonts/fonts.conf",
    }

But that should not hurt. I assume the stack overflow messages disturb the tool much more.

As the stack overflow happens after the /usr/local/etc/fonts/fonts.conf missing message, there might be a problem parsing the /etc/fonts/fonts.conf.

You might try

to temporarily mv /etc/fonts/fonts.conf /etc/fonts/tmprm-fonts.conf.

Original

The luaotfload-tool uses a function from luaotfload-parsers to scan for fonts.conf files.

  read_fonts_conf_indeed() -- Scan paths included from fontconfig
  configuration files recursively. Called with eight arguments.
  The first four are

      · the path to the file
      · the expanded $HOME
      · the expanded $XDG_CONFIG_HOME
      · the expanded $XDG_DATA_HOME

  determining the path to be checked. Another three arguments are
  tables that represent the state of the current job as lists of
  strings; these are always returned. Finally a reference to the
  find_files function is passed.

The snippet above is from Version 2.5-4 from texlive-2015. You can see here, why it is generally bad to install Debian Packages, when there is an integrated system with installers, as debian never changes a package version and it's hard to keep track of texlive packages. You can never say what debian packagers think about versions and if the package names will change in the next debian release.

It's again quite easy to directly install texlive by hand. Feel free to leave a personal message if you need support for this operation.

Debugging your system

You can kpsewhich luaotfload-parsers.lua, edit the filename that is written to stdout and search for read_fonts_conf_indeed. The snippet above might is part of the doc section above the function definition.

You might try to

Set the XDG_CONFIG_HOME and XDG_DATA_HOME to paths where you fonts.conf is. But I'm not sure which paths are appended to the two variables.

It should not hurt to create a path /usr/local/etc/fonts/ and touch fonts.conf there.

Check if the fontconfig package is installed

dpkg -l fontconfig

and what files belong to that package

dpkg -L fontconfig

You probably should apt-get install fontconfig if it isn't installed.

  • fontconfig is installed. The crash and error message go away when I rename fonts.confas you suggested. You are saying that the "stack overflow" crash is not a result of "Cannot open fontconfig file...", right? My version of luaotfload-parsers.lua seems to be 2.5, dated "2014-01-14 10:15:20+0100" (same as the one on CTAN). At line 299 it says acc = read_fonts_conf_indeed(path,, not sure if that's what the error msg means, or if this helps at all. – Blackface Jun 17 '15 at 17:25
  • I assume that your /etc/fonts/fonts.conf is source of your problem. I would suggest to file a bug report to the luaotfload github crew. – ikrabbe Jun 17 '15 at 18:23
2

After the hints and good guesses from @ikrabbe I inserted a line into the function read_fonts_conf_indeed in kpsewhich luaotfload-parsers.lua to logreport what path it is just looking at. The Output showed a cycle of 11 paths, some of them *.conf files, some directories. Looking at the *.conf-files I found that ~/.config/font-manager/local.conf was <include>-ing its own pretty self over and over again. Since I commented that line out, things work fine. Phew.

I'm not sure, but I guess a long time ago I may have copied the file from Font Manager's system wide config directory to my private ~/.config/... directory to use as a template for some long-forgotten modifications, and left that line in. luaotfload was the first programme to crash over that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.