Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by h1439878.stratoserver.net (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t6IFoQfw009218 for ; Sat, 18 Jul 2015 17:50:27 +0200 Received: from relay2.uni-heidelberg.de ([129.206.210.211]) by mx-ha.gmx.net (mxgmx104) with ESMTPS (Nemesis) id 0MYcW6-1ZT1J9029y-00VSID for ; Sat, 18 Jul 2015 17:50:21 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t6IFmrSB004419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2015 17:48:53 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t6I58JNH032578; Sat, 18 Jul 2015 17:48:52 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 12365902 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 18 Jul 2015 17:48:52 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t6IFmq9R006756 for ; Sat, 18 Jul 2015 17:48:52 +0200 Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id t6IFmlJf030144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Jul 2015 17:48:49 +0200 Received: from dovecot04.posteo.de (unknown [185.67.36.27]) by mx02.posteo.de (Postfix) with ESMTPS id 033D725A212B for ; Sat, 18 Jul 2015 17:48:47 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot04.posteo.de (Postfix) with ESMTPSA id 3mYYdV4qGvzFpWB for ; Sat, 18 Jul 2015 17:48:46 +0200 (CEST) References: <559AE0A8.3080907@morningstar2.co.uk> <55A3E1DD.8050707@posteo.net> <55A3E5E6.2060405@morningstar2.co.uk> <55A4137A.7030807@posteo.net> <55A415FF.8030305@nag.co.uk> <55A801A8.5090702@posteo.net> <55A809C4.70009@nag.co.uk> <55AA1554.3050509@posteo.net> <55AA24D9.1050904@latex-project.org> <55AA29B9.9050104@posteo.net> <55AA5596.4090007@telecom-bretagne.eu> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Message-ID: <55AA755E.5000609@posteo.net> Date: Sat, 18 Jul 2015 17:48:46 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Stephan Hennig Subject: Re: LuaTeX support in the LaTeX kernel To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <55AA5596.4090007@telecom-bretagne.eu> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-MIME-Autoconverted: from 8bit to quoted-printable by relay2.uni-heidelberg.de id t6IFmrSB004419 Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:DlYbsJ9lo24=:I3YoYotK7S+zqYRZdnkXnVZJbj NhsdBlWoc3o4ZMSfTe09RHurRVOMW8ytrEgfTvJpCiUT8uOd/zicitvxCVSvTnI/jGICjhj6Y sXhtnS8hVjHzoU6jJAOqt+HHWfNjvfX4TozRDg16zSv2byaAxkO77G3W0iNqqcA3mk5SWhhqm A8UM1tX251iULcPYk4V1McGhNz0ggHBa9/4w2ODxrez3jaPbtUp7Xkr0VmumsDTIhbkfwWhq6 IB5uxMSjDBlroKO0r24eElKOo7Nm5tY5+RUqVLO/pdPWTwLfoHuDFs/a+ulw95Z2frkiivOsm xpWzYnUAg0b/pmHK9YG7UessJjDcl98ZquOO0uCf2obc0EwWbd4HYAlD+vpWVuAGFs2+VhQ2h N5u/63kyTL5nYrjZLui9k6sPeM4Pbqi8GeHzBVpg7i3ig9t8E9Z281QReDU+0QopC5crVNWBj OjJ/DL4kOsE97kD08K12YNMx1W8NZUzDMHMzFUe7jxiflvB2otTay0KWWFwHMPinFTgDcrNP5 nZuqdLounguWsrinna7wSNOaSA0HZmY6hHso7u4K0pkthspQA8A7k7Ij7XhiWj7hVx/YCYu5x U8BxryHaPdv5JS1z6P7Cq0DlSUxfQsM+5ySRum83xdnwUmJ5+gkGODJa8PlAl4HZdTZRGJDXN ib8eWC52Pm3WWbC7eRghXFLCKQLdcbQ86vMNU1MAkY7A3+p0b1Zu/+9PBW7tA8EMd/GeSZzlW gPvD3aDu9ACeDkZGdl8iWrD0xgxVBPK29AU37jQJPzxxb/xbM5asU/6FnXhghK4xtGvXXAxVR aOhX4jIHm0yGRq/gHkcRIZULnQ7bxSziJxgR9sZNR2GwMBtFX/DFHefULnFdAl/pAWdDmvT/9 DN7QAtrcj2z4HyD3qR4FMiYEY1rs1mUwvgyTfWrlnpT7wTxZjbbJ/BkLqvnYb5hgttim8wLVF qbYq2pYzmW7Xo3xevzXecYmOOrqnlImEwfECGCNAWL2QSuOpCfDadNGpviycu0wXWsnRjTdBY 3xDPoQvI/VIvYvrluaQLwsDnvsAlKBpmXyBLAM3WtTCFu/PxTqM8ruTa4kydvw9DMk8KdryMg wMNx8aqsMQO1ami0l+gCvjzouonyvYxL3eER1p7tE4bdw2wcd8DykPOZZeZ0Cw2B9bbjxOUur YYVDibUIavPhJIbE2kPlwzIi7H5JWyKnE0C7/SNLrlww9+BKQro97r51aAxLU8l3ghWfiZ/Mr 0IKjYQ7tfgq1p/BnqMAZbV4QeN9slq7R5sNhcxE/FUVNvDH/ZJsNX5RwUTcv+q4q3c5b+7VZ6 WMLN+mgQKrBxnxfqujXOxPgsKTFvaJgj1BjFWQ8yI4trgxA9eCceuMOOaV6T9HqfwKESzuUlP hHzLj29fp/QgxkMHuxZt11m9lpLPwm3gQ9iNjaYux7vvVBkdyZ8GxMrARhRWPk3HPhgc3vBcw 6afRu+lHwZf5pUDVUKjmxQC7R4DoWPVG1o7lTP/8Jc1HSP2EDN X-UI-Loop:V01:oeMOLzMChWw=:lH5hVMbKHZzPYJrr5Jq7Xk/6P6mfZJQ1ze8Gj2rzT2w= X-UI-Out-Filterresults: notjunk:1;V01:K0:al0REQpANvk=:C6O4OpFVVr96DzW5ISQW/X hmSxwsKJZ5dS01B/J+tRgWb9jueXHwqu2HOPi+/TXMWiit3YFvZFympbuDuoN/9tRRBMrdeTU vCz4TzGD7zUlQEE/t5jZFSZsAYc2y5KSY1WAYi8pRYBiVeAsgYVBwotyqxWPm8f3o0FVd/Xf3 a7p0nSYptAijXIPTuQJ7BwgIUidxrHvQi1llq9T4Ru6ItjzNZ7W/b1iz1c2Z5TVyqVOw4yTQF RJrhYecs3U28KrCh+6C1yKqoelaIq5rgbCwyUseGOcBgiCM8x7BKWtewP2Cy+z6ayywpKWiq0 KFW8Ro/Hi7S0GyG0eNmKt48RTQCt93e4I8O3oZw9Kp75rouLNhBy9J3He5efROJHJl/CM97Mn yAxu008iD5+xtUjhp4FzW0jQNQ4jBorPxaSlTMOHplFOrUqaHbdvDh1wGypHXIkSZzu/OU1S8 BL1vnWcayOgvQbQVFxixALcVvk9EAfMABtZD0LeKZ4lTy/Oc2URs X-Scanned-By: MIMEDefang 2.71 on 85.214.41.38 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by h1439878.stratoserver.net id t6IFoQfw009218 Status: R X-Status: X-Keywords: X-UID: 7798 Am 18.07.2015 um 15:33 schrieb Élie Roux: > Le 18/07/2015 12:26, Stephan Hennig a écrit : >> Say I write a pure Lua package replacing >> all A glyphs by Z in whatever callback. How do I hook into that >> callback in a format independent way? A luatexbase package that >> abstracts from minimal format implementations (as far as such are needed >> in a format) would solve that issue. > > This seems highly theoretical to me... Lua adds a /completely new programming layer/ to typesetting besides the TeX macro layer. And both layers are rather orthogonal to another. Any formats should play nice with the Lua layer. That is, they shouldn't force Lua package authors to target a particular format. > If you want a package developped in a format-independant way, I guess > you mean Plain, LaTeX, ConTeXt, and home-made formats. I think there are a few more formats in TL. But anyway, while different formats satisfy different demands, they make up for fragmentation of the TeX ecosystem. This is bad when the same typesetting problems are solved multiple times each solution targeting another format. The Lua programming layer has the potential of bringing different users (developers) of formats together again, making for more effective contributions (hopefully). Side-stepping format independence by design is, well, a crazy idea. > But luatexbase is not ported to ConTeXt and as far as I know, there > is no callback management in ConTeXt, you can't hook into a callback > without breaking everything... Ouch, I've not been aware of that. That's certainly ConTeXt's fault and should be fixed on their side. But LaTeX should learn from that instead of making the same mistake again (inherently coupling format and Lua programming layers). > So format-independant packages are already technically impossible an > I fail to really understand your point... can you give a more precise > example of a possible problem? Come on, you are an experienced open-source programmer. "Technically impossible" is a polemic term for "not yet implemented". ConTeXt is buggy. That's all. For a real-life example, the spelling package is actually a pure Lua package with a LaTeX .sty file wrapping the Lua API. Have a look at spelling.sty. You won't find any TeX foo there, but tons of \direclua calls. The manual has this: > The spelling package requires the LuaT E X engine. All functionality of the > package is implemented in Lua. The L A T E X interface, which is described > below, is effectively a wrapper around the Lua interface. > Implementing such wrappers for other formats shouldn’t be too difficult. > The author is a L A T E X-only user, though, and therefore grateful for contri- > butions. (I should note that the spelling package is in fact a highly experimental piece of code I've written two years ago. It needs a complete redesign w.r.t. node list handling, but that won't change the format-independent approach.) For other examples, please have a look at the padrinoma (PAttern DRIven NOde list MAnipulation) repository at . Examples can be found in the examples directory. Please read examples/README. The padrinoma package is/will be a pure Lua package targeting problems such as pattern driven ligature handling, pattern driven non-standard hyphenation, pattern driven long-s replacement in black-letter fonts, etc. LuaTeX is a great opportunity for lots of new approaches to typesetting problems! Please play nice with pure Lua packages! Don't cut anyone's user/developer base by design. > Also, luatexbase has not moved for a couple of years, and there's no one > to maintain or develop it, so I think what's currently happening is > quite a good thing. If LaTeX people take-over maintenance the same people can do that as well outside the format. No, that won't necessarily be more expensive than an in-kernel solution. What's needed is a defined programming API. With two implementations (luatexbase and ltlatex) that is more or less already there. Compatibility modules that bind a format with its minimal resource allocation implementation (as far as that's needed in a format) and the proposed format-independent package can be contributed by a format's community just like .ldf files for babel. As soon as ConTeXt fix their resource allocation, ConTeXt users can magically use the spelling package to check spelling in their documents with TEX-unaware spell-checkers. I can't see the downside of a format-neutral approach. Best regards, Stephan Hennig