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:
Thu, 16 Jul 2015 20:45:08 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
On 16/07/2015 20:10, Stephan Hennig wrote:
> Am 13.07.2015 um 21:48 schrieb David Carlisle:
>> On 13/07/2015 20:37, Stephan Hennig wrote:
>>>
>>> I'm in favour of a format-neutral package, which is pulled into the
>>> (LaTeX) format.

We have checked that ltluatex does work with plain, so essentially
that is what we have here.

>>> 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?
>>
>> Hopefully there doesn't have to be a fork,
>
> Well, what is a fork?  For me, feature duplication is one defining
> characteristic of a fork.

It is more a suggested update than a fork.

>
> But I might well have misunderstood your approach.  If basic LaTeX
> resource allocation is only used internally and not targeting at package
> authors (with one exception), I'm fine.  The one exception being the
> luatexbase package, which provides format independent allocation
> functions, but builds upon the LaTeX implementation for that format
> (because there can be only one).  Third-party package authors always
> refer to the luatexbase API instead of the LaTeX API for resource
> allocation.  Is that near what you have in mind?

I was planning to send out a mail asking for examples for further
testing, but the code is mostly a refactoring of the implementation
to make it more suitable for being included in the format (and in some
places taking advantage of changes in the luatex engine).

The API is very compatible, as the examples on github show, luaotfload
and fontspec can both run over the new implementation without any
change as far as I know.

There are some differences, and I hope to document them, but may need to
be during quiet periods at TUG 2015 next week:-) but it would be
interesting to know of other packages building on luatexbase and whether
the new code supports them and if not whether the package could easily
change or if the ltluatex implementation needs to support more features.

ltluatex is usable with latex and with plain (see the ltluatex.tex file
for plain support)

So I do not think there are two API, just a new refactored and extended
implementation. Certainly the differences are small enough that if a
small compatibility layer is needed an updated luatexbase.sty could, if
the luatexbase maintainers agree, input ltluatex and fill any gaps, but
it may be by the time we are done, there are no gaps that need filling.

>
> Best regards,
> Stephan Hennig
>

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