James Lowe [Sun, 7 Aug 2011 10:45:53 +0000 (11:45 +0100)]
Doc: NR 5.5.4 - Modifying ties and slurs
Started off as adding a @cindex for 'control points'.
Ended up tidying up the overall description of how the bezier
curve describes its arc.
Then noted a reference to a non-existant property of the TieColumn
object - so I have referred to the correct interface for this property
and added an @seealso.
Mike Solomon [Thu, 14 Jul 2011 20:02:49 +0000 (22:02 +0200)]
Institutes property checks for non-event context property settings.
This fixes issue 1734 in addition to any potential incorrect settings
of properties in the layout block. While this entails a property check
for all property settings in the ly/ folder, the time this takes is
negligible.
(cherry picked from commit a811a3c91c05f33474c1d447bedaa1e089522532)
Graham Percival [Mon, 1 Aug 2011 19:19:33 +0000 (20:19 +0100)]
Grand fixcc.py run on all .hh .cc files.
Apologies for the inconvenience in patch handling, but getting
this done at once will cause less long-term problems than trying
to do this piecemeal.
Note for future git historians: this patch was created by running
scripts/auxiliar/fixcc.py \
$(find flower lily -name '*cc' -o -name '*hh' | grep -v /out)
with astyle 2.02 installed. No manual changes were made.
Mike Solomon [Thu, 28 Jul 2011 14:47:08 +0000 (16:47 +0200)]
Adds automatic numbering to footnotes.
There are currently two types of automatic numbering possible:
automatic numbering where the footnote resets on each page
and automatic numbering where the footnotes increase in
sequence over pages. The bulk of the commit lies in
paper-layout-problem.cc. The two new regtests show how this
is done.
Fix 153: \once\set properly restores the context property
\once\set works by installing a finalization hook in the iterator.
To restore the context property value before the \once\set, we simply
cache the old value and pass it to the finalization hook as third
argument. The finalization hook then sends a SetProperty event with
the old value rather than an UnsetProperty event, which would revert
the value to the default.
Fix 1259/1433: linebreaks with \breakDynamicSpan or spanners with style=#'none
This patch changes the way DynamicLineSpanners are handled when
\breakDynamicSpan is called or when the DynamicTextSpanner's style=#'none
(i.e. no line should be used and thus the spanner should also not
unneccessarily shift the dynamic text spanner up/down).
So far, this was handled by simply ending the DynamicLineSpanner prematurely,
while leaving its children at their full length. As a consequence, the child
spanners were no longer fully contained in the DynamicLineSpanner, which
caused several problem at line breaks.
This patch changes it as follows:
-) All spanner breaks are handled by a flag set on the spanner itself
-) The breakDynamicSpan events are handled by the dynamic engraver, which will
set that flag (no longer handled by the dynamic span engraver!).
This allows to obey the order of \breakDynamicSpan and \> (i.e. if the
break was before the \< then break the previous spanner, if it was placed
afterwards then end the newly created spanner)
-) When a DynamicTextSpanner with style=#'none or a \breakDynamicSpan
is encountered, I also set that flag immediately after spanner creation
-) From then on, no new dynamics are added to the line spanner and no
new support points are added that would otherwise shift the spanner
if there is a very high/low note or articulation. If the spanner creates
a grob (like a hairpin), that grob would still be shifted as a grob
to prevent collisions, though.
-) When the current child spanner is ended, we also end the DynamicLineSpanner
(and store it in a temporary variable so that we can properly end it
in stop_translation_timestep). If a new dynamic is encountered, it will
then create a completely new DynamicLineSpanner, which provides the
independent alignment that we want.
Mike Solomon [Thu, 28 Jul 2011 07:56:26 +0000 (09:56 +0200)]
Ignores rests in tuplet bracket calculations.
Where there is a tie in directions, tuplets are typeset closer
to the staff. While this does not fix the problem of tuplets
colliding with extreme noteheads reported in issue 992, it makes
it less likely that this type of problem will occur.
Fix 1563: System start bars interpreted collapse-height as absolute length.
If you increased the staff-space, this meant sometimes the collapse-height
would not be enough to hide the start-bar for a staff, while in other cases
it was enough...
This patch interprets the collapse-height in multiples of the staff-space.
However, I think that the notion of a collapse-height (as a length) for
hiding/showing the system start delimiter is not the best approach in
general. Sooner or later, we should change the system to show/hide the
system start bar/bracket depending on the number of staves involved rather
than on grob height.