On 2020-01-22 7:26 am, Paolo Prete wrote:
The problem is associated with:
https://lists.gnu.org/archive/html/lilypond-user/2020-01/msg00467.html
Sorry if I insist again with this: is there a fix (or work-around) for
it?
The function is ***very*** useful, You can really see what happens with
the
discussed property, and you can really use therefore a ruler for fine
tuning .
I started to take a look at this, but got side-tracked. My work
schedule is erratic at the best of days, plus I have been trying to get
over a cold; so I am uncertain I will be able to dig in more deeply.
My initial impression is that accessing certain properties out of
sequence can cause problems. The NR includes a brief section on
unpure-pure-containers mentioning how one must be careful when accessing
properties relating to Y-axis concerns. Beam in particular is called
out as something to avoid touching, and I imagine that TupletBracket
cares about Beam. I also know there is internal caching of computed
results at various stages of processing, so perhaps an unintended
side-effect of these things is that it all goes awry when the normal
pattern of access is interrupted. And since much of this work is done
at the C++ level, it becomes difficult for Scheme code to influence
effectively.
All of my helper functions for overlaying stencils are really just
hacks; they might work for some grobs and fail for others. And when
things stop working, you just have to look for another hack. For
instance, if messing with the stencil for TupletBracket is not working,
perhaps you could use another grob to host the debug annotation.
TupletNumber might be more accepting of modification, which you should
be able to get via (ly:grob-object bracket-grob 'number). But be aware
that you might have to do things the other way around, working from
TupletNumber.after-line-breaking which would mean getting the bracket
from the number: (ly:grob-object number-grob 'bracket).
-- Aaron Hill
