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: Jim Long
Subject: Re: Layout behaviour arising from '\set chordChanges = ##t'
Date: Wed, 9 Jan 2013 11:56:07 -0800
User-agent: Mutt/1.5.21 (2010-09-15)

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

Attachment: crowded-chords2.ly
Description: Text Data

Attachment: crowded-chords2.pdf
Description: Adobe PDF document


reply via email to

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