LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 13 Jul 2015 17:23:02 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
On 13/07/2015 17:05, Stephan Hennig wrote:
> Am 06.07.2015 um 22:10 schrieb Joseph Wright:
> 
>> We are looking for feedback in two areas. Firstly, does the
>> functionality provided cover the needs of package authors using LuaTeX?
>> Secondly, we would like input on how a transition to new support code
>> can be managed. We are reluctant to suggest a complex compatibility
>> layer for either our code or the existing packages, and suspect at this
>> stage that a clean 'step change' may be needed for packages working with
>> LuaTeX. However, this is a complex area and needs careful consideration.
> 
> Let me question the idea of implementing resource allocation stuff in
> the LaTeX kernel.  What is the appropriate way to claim resources, e.g.,
> attributes, in a format agnostic pure Lua low-level module foo.lua
> (which is then used in format specific wrappers/packages)?  That foo.lua
> module can't certainly make use of function latex.new_attribute, since
> that is only available to LaTeX users.  Or do I miss something?
> 
> Best regards,
> Stephan Hennig

We are not unmindful of the problem of code that works with multiple
formats! Most obviously, luaoftload is required for using the
higher-level fontspec interface in LaTeX but also works with plain
LuaTeX to extend the font loader. Whilst we want to work to improve the
LaTeX support in this area we certainly don't want to break working with
plain.

The luatebase package is loaded with plain TeX and is the common way to
allocate resources. There are a variety of possible approaches where we
either make it 'aware' of kernel changes or provide a new format-neutral
package which incorporates the proposed kernel code when used with
plain. There are also other possibilities and we are considering them.

Notably, the base registers are all allocated by the routines in the
formats (plain naming inherited by LaTeX and ConTeXt). The e-TeX format
continued that tradition with \newmarks, which we've recently added to
the LaTeX kernel, whilst \newXeTeXintercharclass has been in both the
plain and LaTeX format files for XeTeX for some time.

The key point we are looking at is that allocators really have to be
loaded very early, ideally as part of a format. We think that LaTeX
should address this problem but are not going to rush anything. First we
are learning what support is needed (see ongoing checkins to
http://github.com/josephwright/ltluatex) and then building on that to
examine how such support changes can work with existing code.

Not a proposed solution, but at least worth remembering, in Lua one
normally allocates local names for functions. Thus for testing at least
one can do

    new_attribute = latex.new_attribute or luatexbase.new_attribute

or similar. We are doing that ourselves to explore what we have or have
not broken or must consider: see for example
https://github.com/josephwright/ltluatex/blob/master/doctest.tex where
David has done a minimal set of 'fix ups'.
--
Joseph Wright

ATOM RSS1 RSS2