[lltx] [MacTeX] fontspec for LuaTeX

[Will Robertson]

On 30/05/2010, at 9:02 PM, Bruno Voisin wrote:

> It took some steps to reach that point:

Thank you very much, Bruno, for the pain-staking testing.
I had no idea there would be so many stumbling blocks.


> - First problem: there is no mkluatexfontdb symlink [...]
> - Second, more serious problem:
> [...]
> Calling the symlink alt_getopt.lua did work

These will both be resolved, I hope, on the TeX Live side of things.
I'll confirm with Manuel.


> With that in mind, I think there should be two versions of mkluatexfontdb: one, the current one, using $TEXMFVAR for output, and the other, mkluatexfontdb-sys, using $TEXMFSYSVAR so that the LuaTeX font database can be created system-wise, not account-by-account.

The eventual goal is to have mkluatexfontdb operate transparently in much the same way as XeTeX does things. This being the case, I (personally) think it's okay to only have a local-user font cache. Is there an important reason I'm overlooking that this should be possible for all users?

(I admit having a system-wide cache for system-wide fonts makes sense, but it does add to the complexity of the code.)


> - What happens with font duplicates? For example OS X contains the usual Microsoft Office fonts in .ttf format in /Library/Fonts, but upon installation Office installs its own versions, often in old FFIL suitcase format, in /Library/Fonts/Microsoft. I resolved the duplicates manually in Font Book by disactivating the Microsoft versions, but what happens with mkluatexfontdb?

To the best of my knowledge, mkluatexfontdb will only use the first of a set of duplicate fonts; it doesn't attempt to detect which is newer or anything like that.

This could be a problem but the code is still new. Suggestions on how to deal with conflicts very welcome (specifically how the user interface would work). Is it enough to make it clear in the log that duplicates have been found and the user needs to sort it out themselves? (I can definitely work on improving the log output; additional logic will probably be beyond me for now.)

(And as you've perhaps noticed, it doesn't use Mac OS X's idea of "installed fonts" -- as understood by Font Book -- at all; it just looks in the standard locations.)

[...]


> Does this mean subdirs of
> 
>    ~/Library/Fonts          /Library/Fonts
>    /System/Library/Fonts    /Network/Library/Fonts
> 
> aren't searched? If so, that would mean things would work differently as for OS X (hence XeLaTeX) which does see fonts in subdirs of these.

I just tried it out myself and I can confirm that subdirectories *are* searched. In your case, I can only imagine that the fonts that aren't being found are older FFIL fonts *only* -- LuaTeX will only deal with otf, ttf, and dfont fonts. (ttc fonts are broken but might work one day.)


> Finally I tried to typeset in LuaLaTeX a document written for XeLaTeX and using Verdana as its main font. Didn't work:
> 
> 	/usr/local/texlive/2010/texmf-dist/tex/luatex/luaotfload/luaotfload.sty:47: Lua
> 	TeX error ...e/2010/texmf-dist/tex/luatex/luatexbase/modutils.lua:56: module 'l
> 	uaotfload' not found:

I just discovered this problem, too, with the latest version (v1.8a) of luaotfload.
I have no idea where it came from.
It might well be a Mac OS X-only problem, which would explain why it didn't turn up until after the update was put on CTAN. (The other LuaLaTeX guys are all on Linux.)


> and I gave up there.

Sorry for the disappointing ending.
I really appreciate the effort.
We'll fix these problems as fast as possible.

-- Will