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