Am 18.07.2015 um 15:33 schrieb Élie Roux:
> Le 18/07/2015 12:26, Stephan Hennig a écrit :
>> Say I write a pure Lua package replacing
>> all A glyphs by Z in whatever callback. How do I hook into that
>> callback in a format independent way? A luatexbase package that
>> abstracts from minimal format implementations (as far as such are needed
>> in a format) would solve that issue.
> This seems highly theoretical to me...
Lua adds a /completely new programming layer/ to typesetting besides the
TeX macro layer. And both layers are rather orthogonal to another. Any
formats should play nice with the Lua layer. That is, they shouldn't
force Lua package authors to target a particular format.
> If you want a package developped in a format-independant way, I guess
> you mean Plain, LaTeX, ConTeXt, and home-made formats.
I think there are a few more formats in TL. But anyway, while different
formats satisfy different demands, they make up for fragmentation of the
TeX ecosystem. This is bad when the same typesetting problems are
solved multiple times each solution targeting another format. The Lua
programming layer has the potential of bringing different users
(developers) of formats together again, making for more effective
contributions (hopefully). Side-stepping format independence by design
is, well, a crazy idea.
> But luatexbase is not ported to ConTeXt and as far as I know, there
> is no callback management in ConTeXt, you can't hook into a callback
> without breaking everything...
Ouch, I've not been aware of that. That's certainly ConTeXt's fault and
should be fixed on their side. But LaTeX should learn from that instead
of making the same mistake again (inherently coupling format and Lua
> So format-independant packages are already technically impossible an
> I fail to really understand your point... can you give a more precise
> example of a possible problem?
Come on, you are an experienced open-source programmer. "Technically
impossible" is a polemic term for "not yet implemented". ConTeXt is
buggy. That's all.
For a real-life example, the spelling package is actually a pure Lua
package with a LaTeX .sty file wrapping the Lua API. Have a look at
spelling.sty. You won't find any TeX foo there, but tons of \direclua
calls. The manual has this:
> The spelling package requires the LuaT E X engine. All functionality of the
> package is implemented in Lua. The L A T E X interface, which is described
> below, is effectively a wrapper around the Lua interface.
> Implementing such wrappers for other formats shouldn’t be too difficult.
> The author is a L A T E X-only user, though, and therefore grateful for contri-
(I should note that the spelling package is in fact a highly
experimental piece of code I've written two years ago. It needs a
complete redesign w.r.t. node list handling, but that won't change the
For other examples, please have a look at the padrinoma (PAttern DRIven
NOde list MAnipulation) repository at
<URL:https://github.com/sh2d/padrinoma>. Examples can be found in the
examples directory. Please read examples/README. The padrinoma package
is/will be a pure Lua package targeting problems such as pattern driven
ligature handling, pattern driven non-standard hyphenation, pattern
driven long-s replacement in black-letter fonts, etc. LuaTeX is a great
opportunity for lots of new approaches to typesetting problems! Please
play nice with pure Lua packages! Don't cut anyone's user/developer
base by design.
> Also, luatexbase has not moved for a couple of years, and there's no one
> to maintain or develop it, so I think what's currently happening is
> quite a good thing.
If LaTeX people take-over maintenance the same people can do that as
well outside the format. No, that won't necessarily be more expensive
than an in-kernel solution. What's needed is a defined programming API.
With two implementations (luatexbase and ltlatex) that is more or less
already there. Compatibility modules that bind a format with its
minimal resource allocation implementation (as far as that's needed in a
format) and the proposed format-independent package can be contributed
by a format's community just like .ldf files for babel. As soon as
ConTeXt fix their resource allocation, ConTeXt users can magically use
the spelling package to check spelling in their documents with
I can't see the downside of a format-neutral approach.