Rutger Hofman <address@hidden> writes:
Can you run this in a debugger so that one can get a backtrace and see
where the defective indexing actually occurs? Then it should be
possible to code an explicit behavior there.
Right.
My lilypond is built without debugging symbols. It is full of:
#4 0x000000000040e1c0 in ?? ()
etc etc, no useful lilypond frames (there is a meaningful frame in
assert.c:101).
Do you still want the backtrace?
I looked at your example code and, well, it would be pointless to get a
backtrace here. Sorry, I had assumed that you set some argument in some
LilyPond call to CENTER and caught LilyPond on the wrong foot. If I had
looked more closely, I would not have asked for a backtrace which really
could not tell a better story than your original post.
You actually explicitly and manually call the Scheme function
(ly:stencil-combine-at-edge
(ly:stencil-aligned-to stencil X RIGHT)
Y CENTER
; Y DOWN
(ly:stencil-aligned-to (grob-interpret-markup grob text) X
RIGHT))
and that's just meaningless. There is no thing like a "center" edge.
The documentation string is clear here:
-- Function: ly:stencil-combine-at-edge first axis direction second
padding
Construct a stencil by putting SECOND next to FIRST. AXIS can be 0
(x-axis) or 1 (y-axis). DIRECTION can be -1 (left or down) or 1
(right or up). The stencils are juxtaposed with PADDING as extra
space. FIRST and SECOND may also be â'()â or â#fâ.
and it would be meaningless to apply padding when you just want to
superimpose two stencils. This rather sounds like you want to use
ly:stencil-add on the stencils, just combining them on the same
reference point.
I don't think there is _any_ point in letting ly:stencil-combine-at-edge
accept CENTER as the direction since I cannot think of anything useful
to do with the padding then: in which direction would one be supposed to
shift the second stencil when it overlapped the first one?