[luatex] luaotfload-tool lists fonts in subfolders

Philipp Gesang 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
> all?

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
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://tug.org/pipermail/luatex/attachments/20130726/9d026348/attachment.bin>

More information about the luatex mailing list