Am Fri, 26 Jul 2013 12:25:26 +0200 schrieb Philipp Gesang:
>>>>> 1. $OSFONTDIR includes “.”; >>>> No, it is simply C:\windows\fonts > > Btw. as you were asking to distinguish texmf from system fonts > earlier: $OSFONTDIR as a kpathsea variable will be treated in the > texmf category. Set $OSFONTDIR to the empty string to avoid that. > Luaotfload will then scan $WINDIR/fonts independently. I haven't set $OSFONDIR myself. There is no environment variable. But miktex outputs a value when I use kpsewhich --expand-var. (BTW: the output of TL and miktex is here too slightly different: Miktex: C:/Windows/Fonts TL: C:/Windows/fonts// (notice the // at the end). >> I also ran >> G:\Z-Test>kpsewhich --expand-path=$OPENTYPEFONTS >> >> and can see there the same behaviour: Miktex shows the actual name >> of the current folder, while TL shows ".". > > *That’s it*, exactly! > >> So probably luaotfload doesn't realize that G:\test is the current >> folder and so starts to scan the subfolders. Should this problem be >> addressed in luaotfload or should miktex change the output of >> --expand-path? > > I probably could add a check for whether a path equals the > abspath of “.”, though I find Miktex’s behavior counterintuitive > to say the least. Is that expected on Win? Well my TeXlive is also in Windows ;-) Imho the question is if in an expanded path a variable like "." should be expanded to the current directory or not. But the question is: Why does luaotfload add a scan of subfolders at all? The output of kpse.expand_path "$OPENTYPEFONTS" contains already all sensible subfolders, e.g. "D:/MiKTeX2.9/fonts/opentype/public/asana-math" "d:/texlive/2013/texmf-dist/fonts/opentype/public/Asana-Math", -- Ulrike Fischer http://www.troubleshooting-tex.de/
