# Problems with luaotfload and certain font shapes

While playing around with lualatexon TL 13 I encountered a strange problem. Certain font shapes would produce an error without any visible reason. The following example is with Stempel Garamond LT Std from Adobe's Font Folio 11, but I've encountered this with other fonts as well.

\documentclass[]{scrbook}

\usepackage{fontspec}
\setmainfont[Ligatures=TeX,ItalicFont={Stempel Garamond LT Std Italic},BoldFont={Stempel Garamond LT Std Bold},BoldItalicFont={Stempel Garamond LT Std Bold Italic}]{Stempel Garamond LT Std Roman}
\begin{document}

Regular \textbf{bold}  \emph{italics \textbf{bold italics}}

\end{document}


This leads to the following error message:

LaTeX Font Info:    Font shape EU2/StempelGaramondLTStdRoman(0)/m/sl' in size <10.95> not available
(Font)              Font shape EU2/StempelGaramondLTStdRoman(0)/m/it' tried instead on input line 10.
luaotfload | load: no defaults for script “latn”, falling back to “dflt”
luaotfload | load: path lookup of “/Users/simi/FontExplorerX/S/Stempel” unsuccessful, falling back to file: ! Font \EU2/StempelGaramondLTStdRoman(0)/m/it/10.95=/Users/simi/FontExplorerX/S/
G


The really strange thing is that it produces the following output:

As you can see, luaotfload actually does find the correct font shape.

EDIT

It gets even weirder: I streamlined the directory structure. All fours shapes of Stempel Garamond Lt Std are now in Users/simi/FontExplorerX/S/StempelGaramondLTStd/. I let luaotload-tool update everything and luaotfload-tool -F --find="Stempel Garamond LT Std Roman" (or varieties of this) does give me the correct path.

When I try the MWE now, not even a PDF is produced. Instead I get the following errors:

LaTeX Font Info:    Font shape EU2/StempelGaramondLTStdRoman(0)/m/sl' in size <10.95> not available
(Font)              Font shape EU2/StempelGaramondLTStdRoman(0)/m/it' tried instead on input line 10.
luaotfload | load: no defaults for script “latn”, falling back to “dflt”
luaotfload | load: path lookup of “/Users/simi/FontExplorerX/S/Stempel” unsuccessful, falling back to file:
G
l.10 \end{document}

?
[1{/usr/local/texlive/2013/texmf-var/fonts/map/pdftex/updmap/pdftex.map}

]
(./test.aux) )


As you can see, the path given here is not complete, which is strange since luaotfload-tool does know the correct path.

EDIT 2:

This is a confirmed bug which has been resolved.

-
That means luaotfload gets passed a path /Users/simi/FontExplorerX/S/Stempel but cannot find a file of that name (is there?). Btw. funky characters like :() in your font paths won’t work. Wild guess, as I don’t have that font: does it help if you explicitly set SlantedFont=<...> (fill in your italic font name)? – Philipp Gesang Jun 1 '13 at 13:12
It definitely is there like the other font files which are at the same location and are found. But as I wrote: luaotfload does somehow find the font file, otherwise it couldn't produce the shown result which is in italics. SlantedFont on the other hand results in a regular font being for \emph{}. – Simifilm Jun 1 '13 at 13:21
You really have a file (not directory) /Users/simi/FontExplorerX/S/Stempel? The log says otherwise. What is the full path to the italic font? – Philipp Gesang Jun 1 '13 at 13:33
@phg: See my additions to the original question. – Simifilm Jun 1 '13 at 18:28
If neither the path nor the filename contain spaces it should definitely work. After moving font files around you should clear the lookup cache: luaotfload-tool --flush-lookups. – Philipp Gesang Jun 1 '13 at 20:04

This seems to be a bug in luaotfload and/or luatex with \fontname. It is triggered here because fontspec declares the italic font as a substitute for the (non-existent) slanted font. This will call latex's \do@subst@correction, which uses \fontname\font to load the substitute font. But with luatex (and luaotfload), \fontname\font wrongly returns the full path of the font (in your case /Users/simi/FontExplorerX/S/Stempel Garamond LT Std Italic/StempelGaramondLTStdItalic.otf) instead of its "name" ("StempelGaramondLTStdItalic:mode=node;script=latn;language=DFLT;+tlig;+trep;" at 10.95pt). This in turn will make \font explode.

You can prevent this from happening by specifying the slanted font explicitly, thus circumventing the substitution mess:

\setmainfont[Ligatures=TeX,
ItalicFont={Stempel Garamond LT Std Italic},
SlantedFont={Stempel Garamond LT Std Italic},
BoldFont={Stempel Garamond LT Std Bold},
BoldItalicFont={Stempel Garamond LT Std Bold Italic},
BoldSlantedFont={Stempel Garamond LT Std Bold Italic}]
{Stempel Garamond LT Std Roman}

-
Does indeed seems to do the trick (I also found out, that luaotfload is very fragile. I had to delete the font cache before this worked). I will report this bug to the luaotfload maintainers. – Simifilm Jun 1 '13 at 18:38
The problem is that \fontname reads from the filename field of the font data object. This field must contain the absolute path to the font file since if the font is outside the texmf tree, the font loader cannot find it for embedding even if the font metrics have been loaded correctly. Now, when \fontname is fed into \font, spaces in the path will be interpreted as terminating the argument unless it is enclosed in double quotes. Imo the best solution would be having the substitution do a correct path lookup: \font\foo="[\fontname\bar]" or maybe read the file name in Lua. – Philipp Gesang Jun 1 '13 at 20:27
@phg I don't know why \fontname has to read from the filename field (it didn't do that before, eg., with luatex 0.70), but in any case, \fontname should yield something that \font can digest. (And of course, latex2e will certainly not change, so your suggestion is rather futile in this case.) The problem is not only that spaces are being misinterpreted, but also that features will go missing: try \font\x="Charis SIL:+tlig"\relax\fontname\x (again, 0.70 did output the expected Charis SIL:+tlig, while 0.75 does not). BTW, xetex gets it right, too. – Robert Jun 1 '13 at 21:36
@Robert My remark about changing the call to \fontname wasn’t serious. Also, you are correct: it doesn’t read from filename but rather from the name field. I’ve set up the dev version in a way that this field is rewritten whenever the font is defined: see here if you want to test. – Philipp Gesang Jun 2 '13 at 12:29
@Ingo Yes, see here, as mentioned in the edit to the question. – Robert Aug 23 '13 at 19:32