# [Dev-luatex] nodelist based tex.saveboxresource

Marcel Krüger tex at 2krueger.de
Thu Aug 16 18:59:24 CEST 2018



---- On Tue, 07 Aug 2018 13:00:32 +0200 Hans Hagen <j.hagen at xs4all.nl> wrote ----
> On 8/7/2018 7:23 AM, Marcel Krüger wrote:
> >   ---- On Fri, 03 Aug 2018 15:51:24 +0200 Hans Hagen <j.hagen at 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.)

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