[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

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------


More information about the dev-luatex mailing list