[lltx] luaotfload-database.lua

[Philipp Gesang]

···<Datum: Saturday, 25. May 2013>···<Von: Reinhard Kotucha>···

> On 2013-05-24 at 12:21:56 +0200, Philipp Gesang wrote:
> 
>  > Cygwin should now be handled the same way as linux. Could you
>  > check if the changes address your point and report back? The code
>  > should be on CTAN in soon.
> 
> Yes, it looks good now.

Great.

> BTW, there is another thing I'd like to mention:
> 
> I've written a program using luaotfload.  This program is called by
> another program and runs in the background, i.e. users don't see what
> LuaTeX prints to screen.  I develop under Linux but the program is
> usually run under Windows.
> 
> The first version invoked luaotfload at run time.  It turned out that
> the font cache is problematic for many reasons in this application.
> Everything has to work out-of-the-box, I can't expect that users
> (physicians) are able to fix problems with file permissions or so
> themselves and the fact that some system fonts have to be blacklisted
> manually is even more problematic.

I agree, it’s unfortunate. But since faulty fonts freeze the
interpeter there isn’t much we can do about it at the Lua end.
(Context has the same problem, but afaics it doesn’t occur while
building the database because only .otf files are analyzed with
fontloader.open().)

Btw. you sound like this happens more often than it we are aware
of. Do you by any chance have some candidates for the blacklist
that you’d like to share?

> The current version runs luaotfload (and reads the cache) when the
> format file is created.

I don‘t understand. There shouldn’t be any cache files at that
time. Also, which format are you using?

>                          This solves many problems.  Everything is
> extremely fast and the cache isn't used at all (it even doesn't exist
> in the runtime environment).

I don’t think that’s the case. It should be darned slow without
the cache.

>                               However, at run time fonts are loaded
> with absolute paths and I had to patch otfl-font-def.lua in order to
> strip the path component from the font filename.  Then the font is
> found by kpathsea at run time.
> The patch (see attachment) works fine for me, but in general it would

1) Use the patch_font callback for this kind of hack.
2) fontdata.filename = fontdata.filename and string.gsub(fontdata.filename, "^.*/", "")
3) With a file: and path: lookup this would be mapped back to an
   absolute path for the reason listed below, so it’s kind of
   pointless.

> make more sense to check in luaotfload whether a font is in a system
> font directory or in a TEXMF tree and strip the path component only if
> the latter is true.

Can you give the current Luaotfload a try (in the pretest)? We
don’t actually require kpse to load fonts anymore, only to
collect their whereabouts for the database. File names are hashed
and the corresponding absolute paths are retrieved from the
index. At runtime there is no distinction between texmf and
system fonts whatsoever anymore.

> It doesn't make a difference when luaotfload is loaded at run time
> (because the cache is re-generated if necessary) but it makes a
> difference if it's in a format file.
> 
> In short:  Everything in TEXMF trees should be found by kpathsea.

Why? The files are already indexed.

Best regards
Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://tug.org/pipermail/lualatex-dev/attachments/20130525/16dcbcbb/attachment.bin>