[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Anybody has a good explanation for _this_ use of grob-transformer?
From: |
David Kastrup |
Subject: |
Re: Anybody has a good explanation for _this_ use of grob-transformer? |
Date: |
Tue, 30 Jan 2018 12:37:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
David Nalesnik <address@hidden> writes:
> Hi,
>
> On Mon, Jan 29, 2018 at 6:10 PM, David Kastrup <address@hidden> wrote:
>> David Kastrup <address@hidden> writes:
>>
>>>> %% no fail
>>>> \override TupletNumber.Y-offset =
>>>> #(ly:make-unpure-pure-container
>>>> (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1))
>>>> (lambda (grob start end) 1))
>>>> \tuplet 3/2 4 {
>>>> c,,8 d e f g a b c d e f g
>>>> c,,8^> d e f^> g a b^> c d e^> f g }
>>>> }
>>>
>>> Ok, this means that at pure time, ly:tuplet-number::calc-y-offset must
>>> not be called at all or it will ride roughshod over the X offset. We'll
>>> get the hang of it yet.
>>
>> At any rate, one point of grob-transformer is that it should work for
>> any kind of value/callback, and it clearly doesn't here. So either the
>> theory underlying it is wrong, or the implementation.
>
> I don't have time to look into the details at the moment, just to go
> by my memory, having worked on TupletNumber's interaction with kneed
> beams. The callbacks for X-offset and Y-offset are not independent.
> I forget which callback calls the other. The rationale for this
> yuckiness was tuplet number/accidental collision avoidance, for which
> both axes are necessary,
>
> I don't know whether this entanglement is the culprit, but I have my
> strong suspicions...
Ok, the default setup with tuplet-number::calc-y-offset appears to be
scm/define-grobs.scm: (Y-offset . ,ly:tuplet-number::calc-y-offset)
an ordinary callback. So the problem likely is that this function must
not be called more than once. Which seems fragile, to say the least.
--
David Kastrup