Re: NoteHead X-offset, conflict with ly:grob-relative-coordinate

[Paul Morris]

On Dec 11, 2012, at 7:29 PM, Thomas Morley <address@hidden> wrote:

> 2012/12/12 Paul Morris <address@hidden>:
>> On Dec 11, 2012, at 3:32 PM, Colin Hall <address@hidden> wrote:
>> 
>>> On Tue, Dec 11, 2012 at 04:32:57AM +0000, Keith OHara wrote:
>>>> Colin Hall <colinghall <at> gmail.com> writes:
>>>> 
>>>>> I'm going to post a link to this on the dev forum and see if we can
>>>>> identify what the bug is, and then I can create a tracker.
>>>>> 
>>>> I don't see any bug; reasoning is on -devel.
>>> 
>>> That's great, Keith, thanks.
>>> 
>>> Paul, here's a link to Keith's explanation on the lilypond-devel
>>> mailing list archive:
>>> 
>>> http://lists.gnu.org/archive/html/lilypond-devel/2012-12/msg00116.html
>>> 
>>> I believe Thomas gave you some ideas of how to obtain the engraving
>>> you wanted.
>>> 
>>> OK?
>> 
>> Hi Colin,
>> 
>> Ok, as Keith is saying, if this is how it is supposed to work then I guess 
>> it shouldn't be considered a bug.  And luckily there's another way to get 
>> the same results (thanks to Thomas for that tip).
>> 
>> I guess that means that a NoteHead's X-offset has not been designed to be a 
>> property that can be reliably overridden.  I wonder if it would be worth 
>> documenting this somehow, to keep people from trying to go down this path in 
>> the future.
>> 
>> Currently the internals page for NoteHead[1] makes it sound like X-offset is 
>> simply a number that you can easily override:
>> 
>>  X-offset (number):
>>  ly:note-head::stem-x-shift
>>  The horizontal amount that this object is moved relative to its X-parent.
>> 
>> but apparently something more complicated is going on, involving the other 
>> notes in a chord, and the function for determining their placement.
> 
> Well, quoting
> 
> NR 5.5.1 Aligning objects:
> 
> Note: Many objects have special positioning considerations which cause
> any setting of X-offset or Y-offset to be ignored or modified, even
> though the object supports the self-alignment-interface. Overriding
> the X-offset or Y-offset properties to a fixed value causes the
> respective self-alignment property to be disregarded.
> 
> http://lilypond.org/doc/v2.17/Documentation/notation/aligning-objects

Ah, ok, so that page is already documenting this.  


> But I found no hint about it in the IR

Would it make sense if under "X-offset" in the IR it said something like this?

"The horizontal amount that this object is moved relative to its X-parent.  The 
amount may be set directly or may be set to be calculated by procedures in 
order to achieve alignment with the parent object."  

(Added a borrowed sentence from the page linked above.)


>> Anyway, documenting this somehow would be my suggestion, but I don't have 
>> the knowledge to do it, and I realize that there may be higher priorities, 
>> so take it FWIW.
>> 
>> On a related note, I just added a snippet for this to the LSR[2] that uses 
>> ly:grob-translate-axis! instead of X-offset, and I could add a comment to it 
>> saying that overriding a NoteHead's X-offset does not always work, and to 
>> use ly:grob-translate-axis! instead.
>> 
>> (The snippet is not currently working in the LSR, but it works fine for me 
>> on 2.16, so I am guessing that there is a compatibility problem with 2.14.)
> 
> Will have a look at it.

Thanks.  I tried to install 2.14.2 to confirm that this was the problem, but 
was unable to install it. (Maybe it is incompatible with my OS?)


>> Thanks,
>> -Paul
>> 
>> [1] http://www.lilypond.org/doc/v2.16/Documentation/internals/notehead
>> [2] http://lsr.dsi.unimi.it/LSR/Item?u=1&id=861
>> 
>> 
>> 
>> 
>> _______________________________________________
>> bug-lilypond mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> 
> -Harm


-Paul