[luatex] [lltx] Speeding up otf lua cache file load

[Paul Isambert]

Reinhard Kotucha <reinhard.kotucha at web.de> a écrit:
> On 2013-03-29 at 23:35:54 +0100, Paul Isambert wrote:
>
>  > Dumping formats in order to save time is probably a very good
>  > solution, even though not very widespread as far as I can tell (I
>  > myself don't use it, but I'm constantly modifying the files I use...).
>
> I could do it because users can't change things anyway.  In medical
> environments they aren't even allowed to install software themselves
> and the IT departments will not change anything because they don't
> want to be responsible if somethings goes wrong.
>
> In general it's quite problematic to provide dedicated format files.
> Suppose you've written a LaTeX .cls file for your students in order to
> write their theses.  Providing a dedicated format file would speed up
> things significantly, especially if packages like tikz or pgfplots are
> used, which load zillions of files.
>
> But format files are not portable among different versions of a
> particular program, a format file created under TeX Live 2012 will not
> work under TeX Live 2013.  The only reasonable way to distribute such
> a .cls file is to provide a .zip file which can be extracted either in
> TEXMFLOCAL or in TEXMFHOME.
>
> Font preloading makes sense for particular documents.  But the
> portability issue of format files remains.

That decided me: I've dumped my usual files into a format; I'd never
really done it because, besides changing my files a lot, I didn't
really know how to create a format in TeXLive (a simple shell script
is a safeguard against my forgetting again), and I knew Lua code
wasn't dumped so I had to tweak all Lua material so that it is both
loaded and stored into \everyjob.

The gain in time is quite wonderful. I'm even thinking about writing a
format for every document, with the relevant fonts preloaded; again a
simple script could automate that easily.

>  > > There is not much text in the PDF files, just a few small tables.
>  > > Maybe this is the reason why the font subsetting doesn't take much
>  > > time.  The main content of the file are ECG plots created with
>  > > \pdfliteral.  BTW, my first attempt was to use Metapost but it was
>  > > much too slow.  Processing data with Lua and writing PDF stuff
>  > > directly into the PDF file is extremely fast.  It's similar to what
>  > > you described in a TUGboat article.  The difference is that your
>  > > approach is more Metapost orientated while mine is more PostScript
>  > > orientated, just because I don't need a user interface.
>  >
>  > Nice to know that article rang some bells.
>
> I'm absolutely convinced that many readers enjoyed this article.  Of
> course, I was interested even more because I was doing something
> similar already.
>
>  > I think there's a lot to do in that area, and I'll even bet the
>  > next new graphic kid on the TeX block will be in Lua.
>
> The main problem with our approach is that there is no graphics state
> stack.  Without a graphics state stack there is no currentpoint and
> without a currentpoint there is no rmoveto.

Actually, in the code I'd written which gave me the basic ideas for
the article, all points could be relative, so that paths could be
reused, and rmoveto was a basic function. Coordinates were made
absolute only when writing to the PDF.

>                                              It's easy to turn a
> circle into an ellipse by modifying the transformation matrix, but
> it's useless because the shape of the pen is distorted too.

Transformations were dealt with in Lua (modifying paths), not with the
transformation matrix, so I did not encounter that problem.

On the other hand, my pen had no shape anyway, because pen shapes were
way beyond my programming skills. That's one of the reasons why I
dropped the project (there were just too many things I couldn't do; I
even tried to tackle 3D, and that definitely killed me).

> In order to use the full power of PostScript, it makes more sense to
> use Escrito.  It's probably a bit slower than our approach but it
> dosn't have all these nasty limitations.
>
> I'm not sure whether a "new graphic kid" will solve our problems.
> Taco provided Escrito already.  It currently supports PS Level 1 only,
> supporting newer PS levels is planned.

Since everything boils down to Lua code itself producing PDF code, I
don't see why an interface in Lua couldn't be achieved, all the more
as it would integrate nicely with the rest of LuaTeX. Note that I've
never really done anything in PS, so to me it's just yet another weird
language I'd gladly trade for our nice little Lua.

Best,
Paul