# [Dev-luatex] nodelist based tex.saveboxresource

Hans Hagen j.hagen at xs4all.nl
Thu Aug 16 19:44:28 CEST 2018

On 8/16/2018 6:59 PM, Marcel Krüger wrote:
>   > > 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?

the 'context' way which is not the 'latex' way so of not much relevance
here as context does math a bit different

> 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.

you can indeed walk over that list and mess with specific nodes, you can
do that before calling mlist_to_hlist or after (and then maybe fix soem
things) .. in fact locating the delimiters in no big deal, and you could
mark them beforehand (with an attribute or user node) and then
afterwards mess a bit with the created boxes

> - 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.

well, that's math ... heuristics ... interferences within fonts ...
conflicting demands ... also depending on taste

> - 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.

indeed, that's the most reasonable route .. often macro packages wrap
stuff in macros anyway .. it also gives you precise control

> 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.

adding all kind of extra callbacks for handling such cases is opening
cans of worms ... radicals, accents then follow too so we would have
probably more that this hack ... in the end the tex math machinery is
kind of a standard and we keep it that way ... after all it served the
community well

also, it is not the intention of the project to open up every tiny bit
of tex and so for now mlist_to_hlist has to do (so far all i wanted to
do could be done one wya or the other); this kind of opening up would
mean tons of extra callbacks (which also adds overhead that we don't want)

also, keep in mind that the more callbacks there are, the more users can
kick in code and in the end all has to work together; so in fact, this
kind of opening up and patching with lua code will backfire at some
point ... interferences, expectations of how a list looks, etc etc ... i
guess that it can be a macro package integrators nightmare

> 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)?

by design ... these slanted (skewed) things are not really delimiters
and most fonts don't even offer many variants (in fact, only a few
symbols can really grow using the variants mechanism as slopes are not
part of the game)

also, middle is kind of special (introduced in etex btw) and
conceptually fuzzy .. there is some more control in luatex but it will
never be perfect

anyway, concernign more callbacks, i'll keep it in mind when i look at
math again, but any change in that department is not happening in 1.10
(one of these days we will relase 1.09 as prelude for a stable 1.10) and
even if we would add some more control it would not be a quick hack
either (as with many such mechanism probably a few years testing in
context before settling on something would be part of the game)
Hans

-----------------------------------------------------------------