Re: Issue 2245: always align dynamics and lyrics on "main" notehead (issue 108270044 by address@hidden)

[Janek Warchoł]

Hi Mark,

do you have any objections against putting this patch on countdown?
As i wrote, this is a transitional phase: the patch improves the
situation, but i intend to make more changes when it becomes clear how
they should look like.

best,
Janek

PS i've fixed whitespace/ordering issues in the patch for issue 3978,
where they belong.

2014-07-02 21:22 GMT+02:00 Janek Warchoł <address@hidden>:
> Hi,
>
> 2014-07-02 20:58 GMT+02:00  <address@hidden>:
>> Janek Warchoł wrote:
>>>
>>> While I think that it's better to always align lyrics to
>>> the "main notehead", I knew that some people would prefer
>>> to do this otherwise, so the patch allows to choose how to
>>> align LyricTexts (and DynamicTexts)
>>
>>
>> Okay, this is less problematic than I thought it was, and
>> I'm slowly convincing myself that for LyricText,
>> main-notehead-alignment is better than NoteColumn-alignment.
>> However, for DynamicText, I think NoteColumn-alignment is
>> preferable, especially when the main notehead is on the
>> right of the stem.  Gould (p.103) writes:
>>
>>   "When vertical space is limited, move a dynamic to the
>>   left of the note -- never to the right, since the note has
>>   already started!"
>
> Hm.  Sounds reasonable.  On the other hand, if you have many staves
> with dynamics, it's better if these dynamics are aligned - and with
> alignment on NoteColumns, this would not happen.
>
>>> \override LyricText.X-align-on-main-noteheads = ##f
>>
>>
>> I think this interface (with booleans) is confusing; I would
>> prefer a choice of symbols, something like this:
>>
>>   \override LyricText.X-alignment-anchor = #'NoteHead
>>   \override LyricText.X-alignment-anchor = #'NoteColumn
>
> Yeah, i'm also thinking about providing an interface like this in the
> future iterations of the alignment rewrite.  However, can we push this
> patch as-is, and make such changes later?  The thing is, there will be
> so many changes in the alignment code that trying to come up with a
> generic interface now (in the middle of work) is IMO a waste of
> effort, because i'd continue to rewrite such code with every next
> patch.  I think it will be much more efficient to first get all the
> features in (using simple solutions), and then look at the resulting
> code and generalize that - when we'll know what exactly we need.
>
>>>> git complains about trailing whitespace here.
>>> It was already there before, but i'll remove it in the
>>> next patchset.
>>
>> I have this in my .vimrc:
>>
>>   " Remove trailing whitespace on write
>>   autocmd BufWritePre * :%s/\s\+$//e
>
> bad luck that i'm not using vim :)
>
>> https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm
>> File scm/define-grobs.scm (right):
>>
>> https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm#newcode589
>> scm/define-grobs.scm:589: (X-offset .
>> ,ly:self-alignment-interface::aligned-on-x-parent)
>> Not a requirement, but you might as well alphabetize the prop-list while
>> you're there (case-insensitive, so 'X-extent comes after
>> 'vertical-skylines).  Same for the other prop-lists you modify below.
>
> Ok, i'll remember this.
>
> best,
> Janek