lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Layout behaviour arising from '\set chordChanges = ##t'


From: Colin Hall
Subject: Re: Layout behaviour arising from '\set chordChanges = ##t'
Date: Thu, 10 Jan 2013 00:56:49 +0000
User-agent: mu4e 0.9.9.5-dev6; emacs 23.3.1

Jim Long writes:

> On Wed, Jan 09, 2013 at 03:33:27AM -0800, Eluze wrote:
>> thanks, Jim
>> 
>> added to the tracker as
>> https://code.google.com/p/lilypond/issues/detail?id=3092&thanks=3092&ts=1357730898
>> 
>> another - not perfect - workaround is using less chordnames than there are
>> notes:
>> 
>> { aes*1*:7.5-9- q q q }
>> 
>> Eluze
>
> Thank you for putting it into the tracker.  I feel I ought to
> stress that the example I used wasn't meant to be musically
> useful or typical, it just shows the layout problem.
>
> A more common real-world example is attached, along with
> a stencil workaround and a spacer workaround.
>
> I truly didn't mean to open a second can of worms, but this
> example inadvertently reproduced a problem that I see only rarely
> with chordname collisions involving long chord markup.  The most
> obvious workaround to the collision problem is to add manual line
> breaks to tell Lily to break lines sooner than she would
> otherwise.
>
> I do think it would be an improvement to have the implementation
> of '\set chordChanges = ##f' de-activate the stencil, rather than
> just make the chord markup transparent.
>
> The collision problem seems unrelated, but I'm not in a position
> to be certain.
>
> I remain at your service in this matter.
>
> Jim

Thanks, Jim, I've added your new material to the bug tracker.

Cheers,
Colin.

-- 
Colin Hall
Bug squad



reply via email to

[Prev in Thread] Current Thread [Next in Thread]