On Dec 11, 2012, at 7:29 PM, Thomas Morley <[email protected]> wrote:
> 2012/12/12 Paul Morris <[email protected]>: >> On Dec 11, 2012, at 3:32 PM, Colin Hall <[email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/bug-lilypond > > -Harm -Paul _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
