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
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 7 Jul 2015 10:06:38 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset="utf-8"; format=flowed
From:
David Carlisle <[log in to unmask]>
Parts/Attachments:
text/plain (105 lines)
On 07/07/2015 07:02, Élie Roux wrote:
>> The LaTeX team have recently taken steps to extend the LaTeX2e kernel to
>> provide some low-level support for post-TeX90 engines.
>
> This sounds a little funny ("we recently added support for post-90
> things"), but thanks!

Funny but true, as you know:-)

>
>> We are looking for feedback in two areas. Firstly, does the
>> functionality provided cover the needs of package authors using LuaTeX?
>
> The whatsit allocation is still missing, maybe it could be added to
> lualatexsupport?

One thing to discuss: it could be added to lualatexsupport (a package)
or ltluatex (planned to be in the format) and could be handled
as a normal tex register allocation (with \count26x holding the unique
id) or handled purely in lua.  Does anyone have any examples of these
things in use??? Some real use cases would be good to check any design
decisions here.


>
>> 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.
>
> To be perfectly honest, what I'd like most is a pull request on the
> luatexbase repository... Maybe luatexbase could detect if the new format
> is loaded and just skip all the features already provided? This includes
> everything but
>
> https://github.com/lualatex/luatexbase/blob/master/luatexbase-modutils.dtx
>
> (and whatsit allocation, but I hope it can be in the format).
>
> Thank you,
>


We can certainly make a pull request when it's clearer what to do. As
you know I forked the luatexbase a week or so ago with the intention of
making a smaller pull request just for some more minor latex
2015/etex.sty alignment.  However this seemed to be progressing well
so it seemed perhaps best to hold off on that until we were ready to
make a request for this.

Of the two things you mention my own thought is that we should probably
put whatsit allocation into the kernel, it's not clear how they are
used, but it doesn't cost a lot and then we cover all the engine
provided things.

To be honest I suspect that most of luatexbase-modutils should be
deferred to a be defined by luatexbase when it detects a new format
(we would need to experiment with the details before making a pull
request:-) one of the main thing it adds is a date feature similar to

\usepackage{longtable}[2015/07/07]

and that date option on usepackage has been used almost never, and for
lua it's probably less useful as  unlike a package which is
latex-specific code, for luatex you may want to require "off-the-shelf"
lua code that is not specifically written for luatex, so you need to be
able handle code that is not using the module interface defined there.
It is a relatively large chunk of the code for something that can only
be an optional possibly-nice-to-have feature, so to me at present it
feels like something that should be in a package not in the core.
However some kind of identification banner printing is probably useful
in the kernel, so we could easily be convinced otherwise...

Again one reason for opening this thing up to the public list is to ask
that question: what features do people find essential should be in the
kernel, what features can be in package code.

As Joseph said in the initial mail, register allocation in particular
really should be in the kernel as having a package change the allocation
system after some registers are allocated is always going to be a
suboptimal design.

Other features though can easily tolerate different interface designs
in different packages (which is why the contributed latex packages are
so varied in general, not just for luatex) so some things can be left to
luatexbase, but the exact place to make the cut isn't fixed yet.

David



________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

ATOM RSS1 RSS2