[luatex] luaotfload-tool lists fonts in subfolders
Philipp.Gesang at alumni.uni-heidelberg.de
Fri Jul 26 13:12:44 CEST 2013
···<Datum: Friday, 26. July 2013>···<Von: Ulrike Fischer>···
> 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.
Then it comes from texmf.cnf. You might have to temporarily set
it to the empty string before running luaotfload-tool. Maybe
there could be an option to skip $OSFONTDIR and the likes.
> 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).
This should be harmless, except for the quirks of the lfs
> >> 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 ;-)
I noticed TL tends to be more forgiving for Unixish assumptions.
> 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
Because I didn’t consider that case when I rewrote the directory
scanner. I just commited a change that suppresses recursion into
subdirs so the problem might disappear with the next release.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: not available
More information about the luatex