[luatex] luaotfload in format file

Reinhard Kotucha reinhard.kotucha at web.de
Sun Jan 10 02:11:54 CET 2016


On 2016-01-09 at 14:29:39 +0000, Joseph Wright wrote:

 > On 09/01/2016 00:34, Reinhard Kotucha wrote:
 > > Hi,
 > > when I run
 > > 
 > >   lualatex '\RequirePackage{luaotfload}\stop'
 > > 
 > > luaotfload is loaded without errors.
 > > 
 > > For a particular project I have to load luaotfload when the format
 > > file is created.  This worked fine in the past.
 > > 
 > > Now I'm trying to make it work with TL2015.  I've updated the LaTeX
 > > stuff in my .ini file but now I encounter a problem with luaotfload.
 > > 
 > > Here is a minimal example:
 > > 
 > > 
 > > 
 > > 
 > > What am I doing wrong?
 > > 
 > > Regards,
 > >   Reinhard
 > > 
 > 
 > How could this ever work? LuaTeX doesn't dump the Lua part of the
 > set up into the format.

This needs some explanation indeed.  I don't need the Lua part in the
format but I need it in order to load fonts when the format file is
created.

What I'm doing is what TeX did from the beginning: Preload font
metrics when the format file is created.  TeX doesn't have to load tfm
files at run-time when their content is in the format file already.
Though you can load additional fonts in plain TeX any time later, it's
neither needed nor desired in my case.

Of course I can't use nfss2 which assumes that fonts can be loaded at
run-time.

Sure, I'm using luatex here in a crazy way.  Maybe it's best to look
at an example file first (created with TL-2014):

  http://ms25.ath.cx/printecg.pdf

Loading otf/ttf fonts at run-time is problematic.  The most
problematic part is the font cache because absolute paths are used.
I'm developing under Linux but end users are using Windows, hence
everything needs to be as portable as possible.

There are a few other things you should know.  We can't ship the
complete TL distribution.  It's too big and installation would take
too much time.  Thus I've written a program from which I can invoke
luatex.  It runs luatex as usual but traces system calls (exec, stat,
open) in order to create a tiny TeX distribution in a separate (TDS
compliant) directory tree on-the-fly.  This tiny TeX distribution is
what we distribute.  It doesn't contain luaotfload and doesn't try to
access the font cache because fonts are preloaded in the format file
already.  Hence the most problematic parts are run on my machine only
and I don't have to worry about Windows.

Like pdftex, luatex has to embed the actual fonts at run-time.
Because luaotfload supports system fonts too, these files are
specified with their absolute paths.  In a former version of my
program I had to patch luaotfload, this made it difficult to
maintain.  Philipp then added a callback which allows me to strip the
path component.  Without a full path the fonts can be found by
kpathsea.  This is quite portable.

Though one might think that the file mentioned above is created by a
usual LaTeX document, it's not the case.  There is no external program
which creates LaTeX code.  The capacitive ECG device (electrodes have
no electrical contact to the skin) sends data via Bluetooth to a
computer.  The program which receives data from the device displays
curves on screen in real-time.  When everything looks good, one can
tell the device to stop data transmission.  Then one can instruct the
computer program to make a printed copy of what it received last.

The program creates two Lua files, ecg-data.lua and ecg-info.lua, adds
the tiny TeX distribution to PATH, and invokes my program (ecgtex).
Both Lua files contain Lua data structures (nested tables).  The first
one contains vectors for plotting and information about scaling, the
second one contains strings for typesetting the (LaTeX) tables.  But
none of them contain TeX control sequences.  Everything else is done
by Lua code.  In order to create the plots, I tested Metapost first but
it was too slow and created too large files.  The solution was to
provide Lua code which creates PDF directly.  Sounds more difficult
than it actually is.

There is a tiny LaTeX master file.  But it more or less
only calls functions defined in Lua.  LaTeX is used though, but LaTeX
code is created by Lua from the content of the Lua files.  There is
nothing which looks like a LaTeX file.

There are a few constraints:

  * Computers are fast nowadays.  But since end users (usually
    physicians and nurses) expect a reaction immediately when they
    press a button, speed still matters.  Windows is much slower than
    Linux, but if the file system is the culprit then it makes a lot
    of sense to put as much as possible into the format file.

  * Though I can create a tiny TeX distribution easily on-the-fly at
    any time, the whole distribution is using an installer from
    Microsoft which doesn't allow to change the directory structure
    easily.  Adding a file requires a lot of manual work.  Whatever I
    can put into the format file in order to reduce the number of
    files needed at run-time is fine.  Admittedly, I still haven't
    groked why Microsoft bothers its users with such a braindead
    installer.

  * Using the font cache at run-time is nearly impossible in my case.
    It has to be created at install time.  The tiny TeX installation I
    provide contains all the fonts my program needs, hence the font
    cache is only used when I create the format file on my machine,
    there is no need to create it on custumer's machines.

    Suppose that the font cache has to be created at run-time.  It's
    disastrous.  The program looks for system fonts.  Some of them are
    broken and creating an entry in the cache can take an indefinite
    amount of time.  There is a black list but there is no way to
    create entries to this black list automatically in advance.  The
    installer will always hang for an indefinite amount of time.
    The only reasonable solution is to avoid the font cache.

Until TL-2014 everything worked fine.  I didn't have to load
luatexbase-loader explicitly.  I doubt that your changes to the format
file break it.  Either luaotfload was changed or my enableprimitives setup
needs some adaptions, or both.

Regards,
  Reinhard

-- 
------------------------------------------------------------------
Reinhard Kotucha                            Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                    mailto:reinhard.kotucha at web.de
------------------------------------------------------------------


More information about the luatex mailing list