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:
David Carlisle <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 13 Jul 2015 20:48:15 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
On 13/07/2015 20:37, Stephan Hennig wrote:
> Am 13.07.2015 um 18:23 schrieb Joseph Wright:
>
>> We are not unmindful of the problem of code that works with multiple
>> formats!
>
> I'm sure you aren't.
>
>
>> The luatebase package is loaded with plain TeX and is the common way to
>> allocate resources.
>
> Pointing to the luatexbase package reminds me on the mess^Wwealth of
> key-value packages for (La)TeX.  I've never looked at any of those just
> because there's so many to choose from.  For package contributors,
> having functionality scattered throughout many similar packages is
> really bad.  A package designer, basing on allocation in the LaTeX
> kernel and later realizing that (part of) the package can be abstracted
> from LaTeX has an additional burden of looking at alternative allocation
> mechanisms.
>
>
>> 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.
>
> I'm in favour of a format-neutral package, which is pulled into the
> (LaTeX) format.  It's a trade-off between format maintainer's and
> package contributor's burden.  From the point of view of a format
> maintainer, there a danger such centrally shared package being less
> stable than desired.  But let's see.  If a format-agnostic allocation
> package doesn't work out (technically or socially), any format
> maintainers can fork that package later still.  Why fork today?
>
> Best regards,
> Stephan Hennig
>

Hopefully there doesn't have to be a fork, just evolution, but to answer
"why today?"


Mostly because while there was time to incorporate extended etex
registers and xetex character class allocation into the latex format
in time for texlive 2015, luatex was a bigger job and was deferred until
later, ie now.

Having a package (or worse, potentially several packages) defining an
allocation scheme and being loaded after some resources are already
allocated has always been a very fragile aspect of the format.

You see this already with etex.sty not just luatex specific register
allocation, and so having the code in the format is a big improvement
really.

We are trying to get to a position where etex, xetex and luatex can all
be fully supported engines for the format, and we run the latex
regression test suite on all three engines as part of routine builds, we
can do that now for etex and xetex but not yet for luatex, but hopefully
we can get to that point sooon,

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