[lltx] luaotfload-database.lua

Reinhard Kotucha reinhard.kotucha at web.de
Sat May 25 06:00:44 CEST 2013

On 2013-05-24 at 12:21:56 +0200, Philipp Gesang wrote:

 > Hi Reinhard,
 > ···<Datum: Friday, 24. May 2013>···<Von: Reinhard Kotucha>···
 > > I'm not familiar with the new version of luaotfload at all, but there
 > > is one thing which looks strange in luaotfload-database.lua at a first
 > > glance:
 > > 
 > >     if os_type == "windows" or os_type == "msdos" then
 > >         --- ms platfom specific stuff
 > >         path_normalize = function (path)
 > >             path = stringgsub(path, '\\', '/')
 > >             path = stringlower(path)
 > >             path = stringgsub(path, '^/cygdrive/(%a)/', '%1:/')
 > >  
 > > I assume that neither Windows nor MS-DOG are aware of /cygdrive.
 > > 
 > > And as far as Cygwin is concerned, though it's clearly a Unix system,
 > > it makes sense to scan both, the standard Unix font directories
 > > (/usr/[local/]share/fonts) as well as /cygdrive/c/windows/fonts .
 > > 
 > > It seems that only the latter is supported though Cygwin users expect
 > > that Unix font directories are supported in the first place.
 > > 
 > > Admittedly, I looked into the code a few minutes ago for the first
 > > time and don't have enough time to investigate further today, but I
 > > think that it can't hurt to mention my observations.
 > the section you are referencing has been modified recently:
 >     https://github.com/lualatex/luaotfload/commit/635541532080e2b86d9cc28b85ad96d88e57b413
 > 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.

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.

The current version runs luaotfload (and reads the cache) when the
format file is created.  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).  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
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.

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: otfl-font-def.lua.diff
Type: application/octet-stream
Size: 1647 bytes
Desc: not available
URL: <http://tug.org/pipermail/lualatex-dev/attachments/20130525/a8a81a73/attachment.obj>
-------------- next part --------------

Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.

More information about the lualatex-dev mailing list