Re: [Dev-luatex] nodelist based tex.saveboxresource

---- On Tue, 07 Aug 2018 13:00:32 +0200 Hans Hagen wrote ----

On 8/7/2018 7:23 AM, Marcel Krüger wrote:

...

---- On Fri, 03 Aug 2018 15:51:24 +0200 Hans Hagen 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.)

I'm sorry, of course I meant experimental and not trunk.

...

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.

I already expected a response along these lines. When you write that "drawing delimiters with e.g. mp can already be done" are you referring to a specific way? I experimented with this and could think of three approaches, but I'm not happy about any of them: - Rewriting `mlist_to_hlist` in Lua, at least the recursion into sub_mlists. I tried to avoid this because it looked like there are a lots of special cases and some internal state which would hard to track. - Use dummy delimiters marked with attributes and replace them after mlist to hlist conversion. This works quite well except that changing e.g. the width of vertical delimiters does not really work, especially when horizontal delimiters are involved too. - Do not use TeX delimiters (\left, \right, \middle, \radical, etc.) but emulate them using Lua/TeX macros. This wan't really an option because I had to be compatible with legacy input using the TeX functionality. Is there a better way I missed? For my current use-case I was able to solve my problems by using a patched LuaTeX version to accept glyph specific Lua functions in the `horiz_variants` and `vert_variants`, but I would love to see a nicer way which doesn't require tampering with the engine. On another note, I noticed that `\Uskewed` uses a delimiter for the middle character but it is always set with minimal height. This seems to be against the point of using a delimiter in the first place and it also isn't compatible with the handling of skewed fractions in other OpenType Math renderers like MS Word, so I wanted to ask if this is by design or if dynamic height of the fraction slash simply isn't implemented (yet)? Best regards Marcel Krüger