···<date: 2013-08-07, Wednesday>···<from: Wolfgang Jeltsch>···
> Am Mittwoch, den 07.08.2013, 09:14 +0200 schrieb Philipp Gesang: > > ···<date: 2013-08-06, Tuesday>···<from: Wolfgang Jeltsch>··· > > > > > Am Montag, den 05.08.2013, 23:01 +0200 schrieb Philipp Gesang: > > > > In most documents the fallback is available through luaotfload or > > > > lualibs since l-lua.lua establishes a compatibility layer [1]. > > > > > > I think it would be best if the compatibility code would exist in only > > > one core Lua module, which is then imported by the other modules. I > > > think the current solution, where the same patching of table (or _G) is > > > done in several modules, is somehow wrong. > > > > The code was written by Hans, it is him you have to address your > > feature requests to. > > Hmm, the lualibs and luaotfload packages don’t list Hans as a > maintainer, but they do list you. ;-) To be fair, although the library code is written by Hans he doesn’t actually “maintain” the lualibs package. > Furthermore, luaotfload wasn’t > developed by Hans at all from what I can see on the CTAN package > description. First sentence of the manual: This package is an adaptation of the ConTEXt font loading system. This is just one of multiple attributions. Also read the file headers: they make it precisely clear who contributed which file. As to the CTAN package: Hans does not maintain luaotfload, he supplies the fontloader which we integrate into the Latex ecosystem. Luaotfload does not modify the fontloader code in any way. > Is lualibs actually a fork of some parts of ConTeXt that is now further > developed by the lualibs maintainers? Or does it just mirror some parts > of ConTeXt, so that it gets its changes from the upstream ConTeXt code? The libraries are imported from Context untouched on a regular basis. We only package them into two self-contained files for convenience. Lualibs is not a fork, and you could as well achieve the same effect by using the files from Context directly, if you know how. > > Although there is a good deal of duplication between Lualibs and > > Luaotfload code for obvious reasons, I don’t see a problem > > insofar as the basic modules do not break when loaded multiple > > times. Anyways, it would be possible to have the Lualibs detect > > the presence of Luaotfload and then differentiate as to which > > libraries it loads. But then the parts would be loaded out of > > order. I’m not optimistic regarding the outcome as some code uses > > fallbacks for missing functionality and we would have to isolate > > those regions and reinject them so they use the correct version. > > Naturally that is going to be a fragile arrangement which would > > have to be checked every time there is a change to the core > > libraries. I don’t think that’d be worth the effort since the > > gain is at best marginal. > > I think you have misunderstood me. I proposed to put the compatibility > code into a core package that is loaded by all packages that need it. > There is already luatexbase-compat. Why not use this? Good question. It wouldn’t hurt, I guess, but in any case the code in the Lualibs and Luaotfload will stay as it is. Philipp
pgpfQRpdbCr22.pgp
Description: PGP signature
