Re: luaotfload no longer finding fonts in TEXMF

···<date: 2013-07-02, Tuesday>···<from: Evan Cooch>···

> 
> On 7/2/2013 9:31 AM, Evan Cooch wrote:
> >Pre-recent updates to MikTeX 2.9, in order to allow luaotfload to
> >'find' fonts installed in TEXMF (say, XITS), especially (only?) if
> >you installed for 'all users', you had to tweak lualibs-dir.lua,
> >adding
> >
> >P("(")  / "%%(" +
> >P(")")  / "%%)" +
> >
> >around line around line 95, just before "P(1)". This worked perfectly.
> >
> >After the updates, you (in theory) needed to tweak 2 files (around
> >line 150 in the updated files)
> >
> >lualibs-dir.lua (in tex\luatex\lualibs)
> >
> >luaotflod-lib-dir.lua (in tex\luatex\luaotfload)
> >
> >
> >However, despite making these changes, luaotfload-tool doesn't
> >seem to find the finds. If I run
> >
> >luaotfload-tool --update --force --vvv
> >
> >and watch things chug along, I can see it entering into (say the
> >XITS subdirectory), but not finding any fonts, even though the
> >fonts are actually there.
> >
> >
> >So, something isn't working. The fact that we need to hack things
> >to get luaotfload to find the fonts in the first place seems
> >problematic -- not sure why it isn't the default to escape ( and )
> >to let it find the fonts (although apparently that hack no longer
> >works).
> >
> >Suggestions? I can brute-force a solution by moving fonts from
> >TEXMF to OS fonts directory (whereupon luaotfload-tool finds them
> >just fine), but...I shouldn't have to.
> >
> >
> 
> So, I did another re-install, re-hacked the files (as noted above),
> but this time, ran luaotfload-tool --update --force twice: once as
> admin, and once as user. Seems to have cured the problem. The first
> time I tried it, I ran luaotfload-tool as user only. Apparently, I
> either need to run it as admin, or need to run it as both user and
> admin.

You should never run luaotfload-tool with root privileges. In
fact if there was a cross-platform way to check for the uid I
would make it refuse to run as root. The font index is created in
the $TEXMFCACHE or $TEXMFVAR of each user. You can find out where
that is like so:

    kpse.set_program_name "luatex"
    local dirs = { "$TEXMFCACHE", "$TEXMFVAR" }
    for i=1, #dirs do
      print(dirs[i], kpse.expand_path (dirs[i]))
    end

Of the printed paths the first one that proves to be writable
wins and is created if it does not yet exist. Since the paths are
different for root, the index would be written at a location that
is not writable (or even accessible) with ordinary privileges.

> Either way, seems to work. My original query about 'why we need to
> do this in the first instance' stands.

The alternative is sticking with ASCII-only paths.

Anyways, as globbing appears to be unreliable on Windows systems
I just replaced the calls to dir.glob () with generic directory
walks. A nice side effect is that the dependency on l-dir.lua is
unnecessary now, so the next version of luaotfload will ship
without it.

Best,
Philipp

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBCgAGBQJR0vI0AAoJEI7yfcKNwM1+Ku8H/1l0ZwqDg1St8pp3h1H/b51v
dkoIUkYSb/5PDarjQ3ztnFH3KnUtxB+RDr3AzIrjT2nfYkf+7DnW+ldo0QTDUZb6
tDR2dtO5NZp6B6BMhTDN8ofLnZU2l8GZ4FkndWYXa6PN9EScCpx1a2ZE0sxRYcX5
+AP5L7xT2kHUtMzB36BVCfcqDZxM2jcsgrK8KYipUHR7JrLINoE1PE6kpbJv2tkv
5ouyp3V7w/OvtaMyXx+NArJ4FNpGK6OH8KeOm1zXt3ibgWmxa0EreelPsJ8PWPrY
CnXnuMa9bU8xtTWyRVrmSiBZEYHQE2PjMyZDh5GmEGOcaW6toeu2SoKk3D9AlcE=
=9sAG
-----END PGP SIGNATURE-----