lilypond-auto
[Top][All Lists]
Advanced

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

Re: [Lilypond-auto] Issue 1296 in lilypond: Progerrors when using \laiss


From: lilypond
Subject: Re: [Lilypond-auto] Issue 1296 in lilypond: Progerrors when using \laissezVibrer in a cross-staff context
Date: Thu, 18 Apr 2013 11:01:42 +0000


Comment #12 on issue 1296 by address@hidden: Progerrors when using \laissezVibrer in a cross-staff context
http://code.google.com/p/lilypond/issues/detail?id=1296

In summary:

--) Lilypond wants to set spacing rods between columns in various contexts. One of these are ledger lines, which require knowing note head X extents.
--) Lilypond looks for these extents, which requires looking for offsets.
--) The offset is determined by the stem x position.
--) The stem x position triggers the stem's calc positioning done.
--) For beamed stems, this requires knowing the direction of the beam.
--) When the beam considers auto knees for direction, it needs to know the pure height of stems.
***this is the tricky bit***
--) For cross-staff stems, the common-Y grob used to do the pure height is a VerticalAlignment, _not_ a VerticalAxisGroup. So, the pure height calculation triggers the VerticalAlignment minimum translation calculations. --) Minimum translation calculations require knowing the pure heights of the vertical axis groups, which requires a call to Axis_group_interface::adjacent_pure_heights. --) Adjacent pure heights in a vertical axis group never consider cross staff grobs, as by definition, the grobs do not really belong to a single vertical axis group but rather several. --) LaissezVibrer, which is currently not cross-staff, gets its pure height checked.
--) This depends on stem direction.

And there's your circular dependency.

For non cross-staff stems, the tricky bit never arises because the common Y grob is a VerticalAxisGroup, so the VerticalAlignment minimum translations aren't calculated till later.

Setting to cross staff means that the grob extent should never factor into a vertical axis group because it is not part of said vertical axis group. So its height will never factor into an adjacent pure height via the continue on line 259 of axis-group-interface.cc and this problem won't creep up.

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

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