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.
Neil Puttock [Wed, 20 Jul 2011 14:49:45 +0000 (15:49 +0100)]
Fix #1695: Clef change placed outside score.
A MetronomeMark represents a special case for a break-alignable grob, since
sometimes it will be aligned on noteheads rather than prefatory material. In
this case, we don't want it to be acknowledged by the Break_align_engraver,
since it will hijack the X-parent before the Metronome_engraver can set it at
the end of the timestep. This causes the Paper_column_engraver to add the
MetronomeMark to the 'elements list of a NonMusicalPaperColumn. If this paper
column is loose, its X-extent calculation will be incorrect, since it includes
the extent of the MetronomeMark whose refpoint is different (a System).
This results in the column being translated away from the MetronomeMark into the
left margin.
This patch fixes issue 1695 by removing the default setting for 'non-musical and
setting it dynamically in the Metronome_engraver. Note that this isn't
sufficient in itself since `non-musical' checks use Item::non_musical (), which
recursively checks parents; in the case where a MetronomeMark is effectively
musical (i.e., aligned on a notehead, and parented by a PaperColumn), we also
need to return from the Break_align_engraver without potentially creating a
new BreakAlignment and setting the temporary X-parent.
Neil Puttock [Sun, 17 Jul 2011 21:58:19 +0000 (22:58 +0100)]
Move \RemoveEmptyStaves to new file for context modifications.
This allows \RemoveEmptyStaves to be invoked outside \layout blocks, i.e.,
directly following a context instantiation:
\new Staff \RemoveEmptyStaves { ... }
or
\new Staff \with { \RemoveEmptyStaves } { ... }
* input/regression/remove-empty-context-mod.ly
new regtest
* ly/context-mods-init.ly:
new file for context modification identifiers
* ly/declarations-init.ly:
include context-mods-init.ly; placed before engraver-init.ly to ensure
\RemoveEmptyStaves is accessible for deprecated \RemoveEmptyStaffContext
and analogues
for some people it's not clear enough how tiny
a tiny example should be. So i used a recently
discussed example to illustrate it, and also
changed some wording and style.
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.
Fix issues 75 and 1256: Allow multiple concurrent slurs
Rewrite the Slur_engraver and the Phrasing_slur_engraver to support
multiple concurrent slurs. The default lilypond syntax using parentheses
still supports only one slur at a time, but by adding a spanner-id property
to the (Phrasing)SlurEvent music expression, one can create multiple
concurrent slurs, each with a different spanner-id.
This finally allows appoggiaturas and acciaccaturas (which both create a
slur from the grace note the the next note) to be placed inside a slur.
If we observe a new slur start while a slur is already present, we now
totally ignore the new slur event, so it does not influence the appearance
of the existing slur (bug 1256)
fix 750: No warning for non-found voice in lyrics combine when lyrics are empty
Use a bool flag to store whether the Lyrics context was ever really created
(i.e. one moment was processed). If that's not the case, then the lyrics
are empty, and we shouldn't print any warning about non-existing voices
(since we never even tried to find an appropriate voice; and we also don't
need one anyway).