Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I am using MiKTeX 2.9 on Windows. luaotfload does not find the fonts located in the MiKTeX-maintained root directory (which is C:\Program Files (x86)\MiKTeX 2.9\ on my system) and I am therefore unable to load them directly with LuaLaTeX and fontspec. My distribution and packages seem up-to-date; where could the problem come from?

Here is a minimal working example:

\documentclass{minimal}

\usepackage{fontspec}
\setmainfont{Latin Modern Roman}
\setsansfont{Latin Modern Sans}
\setmonofont{Latin Modern Mono}

\begin{document}
Hello world.
\end{document}

I know that fontspec loads Latin Modern fonts as the default fonts but specifying them manually should work; however, I get the following errors:

The font "LatinModernRoman" cannot be found.
The font "LatinModernSans" cannot be found.
The font "LatinModernMono" cannot be found.

It appears that, indeed, they are not in the database otfl-names.lua. And the situation is the same for all other fonts in MiKTeX directories. However, there is no problem with the fonts located in my local TEXMF: they do appear in the database and I can access them easily (well… not completely! — see my second question). I tried to play with the OSFONTDIR environment variable but got no luck. With XɘTeX, the previous example works fine (although fonts in local TEXMF “cannot be loaded by font name, only file name” [from fontspec documentation]).

I have a second question about fonts which, this time, are in the database otfl-names.lua but can’t be accessed directly by their full name because of their unusual subfamily parameter. This issue is discussed here and here. It seems the situation has not changed, has it?

Any clarification on those points is welcome.

share|improve this question
    
Hi Marc, Welcome to TeX.sx! I removed the thanks. This is just the style here. Thanks is best expressed in the upvoting of helpful answers. –  qubyte Mar 7 '12 at 17:28
2  
You may want to check if the problem persists if you provide exact file names, i.e., \setmainfont{lmroman10-regular.otf, \setsansfont{lmsans10-regular.otf}, and \setmonofont{lmmono10-regular.otf}. –  Mico Mar 7 '12 at 17:49
    
@MarkS.Everitt I’ll remember this. Thanks for the link (I assume it is O.K. here). –  Marc ROGER de CAMPAGNOLLE Mar 7 '12 at 18:01
    
Of course. Good luck! :) –  qubyte Mar 7 '12 at 18:04
    
@Mico That works, indeed: the fonts can be accessed by their file name. However, it is quite a pain to have to use file names as the loading of variants (bold, italic, optical sizes, etc.) is not automatic (which is if you use font names). Is there any other solution? Anyway, thank you for your answer; at least, I can access the fonts. –  Marc ROGER de CAMPAGNOLLE Mar 7 '12 at 18:07

3 Answers 3

up vote 8 down vote accepted
+50

I've finally found a solution (with the hint by Ulrike Fischer): Simply edit (with administrator rights):

C:\Program Files (x86)\MiKTeX 2.9\tex\luatex\lualibs\lualibs-dir.lua

And paste add these lines to the filter (around line 95) just before "P(1)"

P("(")  / "%%(" +
P(")")  / "%%)" +

The brackets will be escaped and therefore the fonts in the "program files (x86)/miktex" folder can be found.

share|improve this answer
    
That seems to work fine. Thank you very much! –  Marc ROGER de CAMPAGNOLLE Mar 19 '12 at 13:27
2  
There are a few other characters that can cause problems: [, %, ^ and $. If they appear in a path, this path will not be usable. This is a bug that should be reported. –  Paul Gaborit Aug 1 '12 at 22:36
2  
I've reported this alread in March, 2012 to Khaled Hosny –  the_nic Aug 2 '12 at 14:47

Your example works fine for me on two PC with miktex 2.9.

Possible differences that come into my mind:

  1. I don't have spaces in my pathes.
  2. I have a single user installation.
  3. At least one of the PC I'm using a unstable version of luaotfload
  4. I have other fonts than you: This can affect the generation of the database.

I think you should at first run on the command line mkluatexfontdb -vvv to see which directories are actually searched and if there is somewhere a problem.

share|improve this answer
2  
In my case, the example does not work on two different computers with MiKTeX 2.9. This is strange: the verbose option does indeed show that all the locations which should be scanned are scanned (recursively) but the script does not find fonts in directories that yet do contain fonts (like, getting back to my first example, C:/Program Files (x86)/MiKTeX 2.9/fonts/opentype/public/lm/, which contains the Latin Modern fonts). However, there are no errors; it just says: 0 'otf' fonts found (and the same for OTF, ttf, TTF, ttc, TTC, dfont, DFONT). –  Marc ROGER de CAMPAGNOLLE Mar 7 '12 at 19:58
    
You said that fonts in your local texmf are found. If you move one of the latin modern otf to this local texmf, is it found then? And the other way round: if you move on of the fonts of the local texmf to main tree: is it found then? –  Ulrike Fischer Mar 8 '12 at 8:24
    
Yes, if I move the Latin Modern fonts to my local TEXMF, they are found and do appear in the database so that I can load them by their font name. But, if I put them back in their original location, as soon as I rebuild the database, they are not found any more. The same is true for other fonts. –  Marc ROGER de CAMPAGNOLLE Mar 8 '12 at 12:49
4  
I made some tests by renaming a local texmf tree: mkluatexfontdb doesn't like it if the name/path of the tree contains braces ` () `. –  Ulrike Fischer Mar 8 '12 at 13:27
    
I see… Thank you for your investigations. –  Marc ROGER de CAMPAGNOLLE Mar 8 '12 at 13:37

For Linux this works if your new fonts are in ~/.fonts and not being recognized by mkluatexfontdb:

 OSFONTDIR=${HOME}/.fonts:/usr/share/fonts//:/usr/share/texmf/fonts// mkluatexfontdb --force --verbose=-1 -vvv

Something similar ought to apply for Windows...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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