- dev-luatex - NTG Mailing Lists

Re: [Dev-luatex] nodelist based tex.saveboxresource
by Hans Hagen 17 Aug '18

17 Aug '18

On 8/7/2018 7:23 AM, Marcel Krüger wrote: > ---- On Fri, 03 Aug 2018 15:51:24 +0200 Hans Hagen <j.hagen(a)xs4all.nl> wrote ---- > > On 8/3/2018 1:09 AM, Marcel Krüger wrote: > > > Hello, > > > > > > I want to suggest extending the tex.saveboxresource interface to accept a hlist or vlist node as an alternative to a box number as first argument. > > > Currently creating a boxresource from Lua node list requires saving the list in a TeX box register, only to delete that register again by tex.saveboxresource. > > > A direct way to transform a h/vlist into a boxresource would make such code easier and avoid potential side effects from changing the TeX registers. > > > An experimental patch with a suggested implementation is attached. > > > > ok, makes sense (but not entirely ok that way but i can fix it) > > > > > I also attached a patch implementing a node.scan method which I think would be another nice addition for LuaTeX: It scans a box with rules similar to `\setbox0` > > > and returns the node. This allows passing box-like material to LuaTeX without requiring box registers. > > > > this is tricky stuff so i need to have a close look at side effects > > (it's also more relatex to token scanning so belongs in another namespace) > > > > i'll have a go at it > > Thank you very much. Just so you know while testing the new changes I noticed that the current trunk generates a warning > > warning (pdf backend): dangling objects discarded > > for *every* non-empty document. I'm checking some backend issues and in the process that can happen. If trunk generates that then it's something else triggering it. Experimental is just that: experimental and things can change there stuff showing up there can even go. Also, if something is not documented, then don't use it. (This dangling is something i noticed and will be fixed, in addition to a possible accessor.) > Anyway there is another maybe more controversial feature I would like to see in LuaTeX: Could you add a callback replacing the built-in `do_delimiter`? > This would allow creating big delimiter in more flexible ways than just stacking boxes, especially I think about drawing custom-size delimiters using mplib > I am aware that this could be archieved by using the `mlist_to_hlist` callback but I think experimenting with delimiter construction should not require rewriting the entire mathlist conversion in Lua. Won't happen. For such fundamental extensions, changes, patches, adaptions one can use lua. In fact, drawing delimiters with e.g. mp can already be done for many years. It really makes no sense to replace each bit. We're now more than a decade in luatex and imo we can do whatever we want to extend in lua now. Also, given history it's nearly impossible to get an agreement on extensions that have hard coded behaviour. Probably the only bit that might evolve a bit is cleaning up the backend. (And I might start experimenting with a stripped down luatex follow up for context some day.) > Another option might be adding a `<function>` argument to node.mlist_to_hlist which, when not nil, is called to create delimiters. Won't happen either. Basically we're now at a stage where there will be no more extensions added. If needed there will be more parameters to replace hard coded values, but that's it. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

2 6

Re: [Dev-luatex] nodelist based tex.saveboxresource
by Marcel Krüger 17 Aug '18

17 Aug '18

---- On Fri, 17 Aug 2018 10:08:13 +0200 Hans Hagen <j.hagen(a)xs4all.nl> wrote ---- > Hi, > > Just a note: you use experimental but experimental is actually there for > me and luigi as communication channel. It happens to be public but > that's a side effect. It's unsupported, and things can come and go. Thanks for the note. I mostly use a setup to easily switch between multiple installed versions, so I mostly use the last TeX Live version (or trunk) for anything important and only use experimental when experimenting, so things coming and going is not that much of a concern. But I keep this in mind and will also avoid writing to the list about the smaller bugs in there if it is that unsupported. Also thank you and luigi very much for all your great work on LuaTeX. Best regards Marcel

1 0

Fix PDF whatsits
by Marcel Krüger 14 Aug '18

14 Aug '18

Hello, I attached a little patch to avoid SEGFAULTs when the backend encounters `pdf_annot`, `pdf_start_link`, `pdf_dest` or `pdf_thread` whatsits. The SEGFAULT was introduced in revision 6738. I also noticed that there is no backend support for pdf_start_thread nodes, so using `\pdfextension startthread` leads to ! error: (pdf backend): no output function for whatsit pdf_start_thread Maybe a note about this could be added to the documentation? Best regards Marcel Krüger

2 1

mruby
by fab1an 08 Aug '18

08 Aug '18

Hello, Is possible using mruby on Latex? for example https://github.com/matsumotory/mruby-on-Lua How to do this? Is this dificult?

2 1

Bug in lua_nodelib_new
by Marcel Krüger 07 Aug '18

07 Aug '18

Hi, the command `node.new('whatsit', '...')` with a string subtype currently always triggers the error creating a whatsit requires the subtype number as a second argument It can be fixed with the attached patch. Best regards Marcel

1 0

nodelist based tex.saveboxresource
by Marcel Krüger 05 Aug '18

05 Aug '18

Hello, I want to suggest extending the tex.saveboxresource interface to accept a hlist or vlist node as an alternative to a box number as first argument. Currently creating a boxresource from Lua node list requires saving the list in a TeX box register, only to delete that register again by tex.saveboxresource. A direct way to transform a h/vlist into a boxresource would make such code easier and avoid potential side effects from changing the TeX registers. An experimental patch with a suggested implementation is attached. I also attached a patch implementing a node.scan method which I think would be another nice addition for LuaTeX: It scans a box with rules similar to `\setbox0` and returns the node. This allows passing box-like material to LuaTeX without requiring box registers. Best regards Marcel

4 4

socket.url addition
by Josef Kleber 19 Jul '18

19 Jul '18

Hi, in addition to Reinhard's report I want to report another change in luatex's behavior. In getmap.sty I now have to add \ifluatex\directlua{os.setlocale('','ctype')}\fi% in order not to run into strange encoding issues. See https://tug.org/pipermail/tex-live/2018-June/041997.html ff. Thread is ripped! :-( This was not neccessary with older versions of luatex, for sure not with v0.85, because I had to adapt getmap.sty for this version. Maybe you have an idea why this change is needed now. Best, Josef

2 1

socket.url not recognized as a built-in library
by Reinhard Kotucha 17 Jul '18

17 Jul '18

Dear Sirs, the script texlive/2018/texmf-dist/scripts/getmap/getmapdl.lua doesn't work anymore. No problems with former versions of TeX Live. It contains the lines local http = require("socket.http"); local ltn12 = require("ltn12") local url = require("socket.url") The luatex version in TL-2018 requires that I change the last line, and *only* the last line to local url = socket.url Otherwise luatex searches socket.url (and only socket.url) in Lua's search path (/usr/local/share/...) without success, though socket.url is already compiled into the binary. Because only socket.url is affected and not socket.http or ltn12 and everything worked in the past, I suppose that socket.url is not registered as a built-in package aymore in current releases of luatex. It seems that package.loaded.socket.url._NAME and package.loaded.socket.url._PACKAGE were removed accidentally. Regards, Reinhard $ diff -u socket.url-TeX-Live-2017 socket.url-TeX-Live-2018 --- socket.url-TeX-Live-2017 2018-07-17 02:57:49.894030637 +0200 +++ socket.url-TeX-Live-2018 2018-07-17 02:58:28.469719914 +0200 @@ -1,6 +1,4 @@ -package.loaded.socket.core.url._NAME = "socket.url" -package.loaded.socket.core.url._PACKAGE = "socket." -package.loaded.socket.core.url._VERSION = "URL 1.0.2" +package.loaded.socket.core.url._VERSION = "URL 1.0.3" package.loaded.socket.core.url.absolute() package.loaded.socket.core.url.build() package.loaded.socket.core.url.build_path() @@ -8,9 +6,7 @@ package.loaded.socket.core.url.parse() package.loaded.socket.core.url.parse_path() package.loaded.socket.core.url.unescape() -package.loaded.socket.url._NAME = "socket.url" -package.loaded.socket.url._PACKAGE = "socket." -package.loaded.socket.url._VERSION = "URL 1.0.2" +package.loaded.socket.url._VERSION = "URL 1.0.3" package.loaded.socket.url.absolute() package.loaded.socket.url.build() package.loaded.socket.url.build_path() -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------

2 1

ligature in \localleftbox \localrightbox
by Hironobu Yamashita 19 May '18

19 May '18

Hi, LuaTeX does not handle ligature inside \localleftbox / \localrightbox. (I found that \localleftbox{\hbox{<<~}} is OK, but ...) The following source reproduces the problem: \hsize=300pt \font\x=ec-lmr10\x {<<~\localleftbox{<<~}The original problem to be solved was for fine French typesetting, in which guillemets are placed running down the left side of a paragraph, as in this paragraph, so long as material is being quoted.~>>} Since \TeX\ breaks paragraphs in arbitrary places, it was impossible to develop a robust macro package that could, in a single pass, place the guillemets in the right positions. \bye The source compiles fine with Aleph. Is this change intended for LuaTeX? Best regards, Hironobu Yamashita

2 3

Proposal for new primitives
by Marcel Krüger 03 May '18

03 May '18

Hi, i want to propose two new primitives for LuaTeX: - The existing `\luafunction` has some similarities to `\count`, `\dimen`, `\skip`. Especially for most use cases, you will have to allocate a number, but there is no equivalent to `\countdef` etc. I think LuaTeX would benefit from `\luafunctiondef`, such that e.g. `\luafunctiondef\something1` would define `\something`, such that `\something` is equivalent to `\luafunction1`. What is the difference to creating a regular macro? This would allow `\something` to be expandable in a single step, which is especially important for emulating primitives from other engines with lua code. - Additionally it would be useful to allow "expandable temporary macro definitions". So for example \scantexmacro#1#2\stop{-#1-#2-}abc\stop def would expand to -a-bc-def This allows using the TeX macro argument parser inside expandable macros, especially when the delimiter can change. For example if you implement a property list as `\@key key1\@value value1\@key key2\@value value2...`, you can create an expandable macro to ge the value of key `#2` without requiring recursive calls with \def\propget#1#2{% \scantexmacro##1\@key#2\@value##2\@key##3\stop{% ##2% }#1\@key#2\@value\@key\stop } Another use-case would be implementingan expandable version of functionality similar to the expl3 `\seq_map_inline:Nn`. What do think? Is there any chance to see something like this in LuaTeX? I attached a first implementation as patch against the current experimental branch. Best regards Marcel Krüger

2 1