David Kastrup [Wed, 30 Jul 2014 15:34:55 +0000 (17:34 +0200)]
Issue 2507: Stop the entanglement of context properties and grob property internals
This introduces a semi-opaque structure Grob_properties meeting the
predicate ly:grob-properties? that is algorithmically handled at the C++
level via a wrapper structure Grob_property_info.
Encapsulating grob properties in that manner reduces the potential for
clashes and makes it easier to change algorithms and/or internal
representation.
While the principal distinction between context properties (one value
per context) and context-based grob property templates (one stack per
context) remains, at least the separation of the handling is more
pronounced.
David Kastrup [Thu, 14 Aug 2014 20:20:35 +0000 (22:20 +0200)]
Issue 3072: Nested overrides get confused with multiple contexts in play
The main problem with nested overrides lies not as much with the
override (which can be done reasonably well) but rather with the
corresponding reverts. Detecting and undoing a previously established
nested override by its effects on an alist, particularly when nested
overrides may be present at several different levels in several
different contexts and/or stack depths and may be undone in different
order from being established, is a complex problem. It is complex
enough that it is not clear that a satisfactory solution does even
exist: at least LilyPond's implementation breaks down for a number of
test cases.
The approach of this implementation is to not even try reverting nested
overrides from looking at their effects on the final result. Instead
nested overrides like
with ... filled in from other parts of the alist (which may change
independently at a later point of time) but rather by using
(bound-details left text) itself as a key and thus storing
((bound-details left text) . "foo")
as the representation of the override. Consequently, reverting an
override with the same nested property path is straightforward. Neither
the action of overriding nor of reverting now require referring to or
updating any part of the property stack outside of the current context.
The downside is that an actual reference to the resulting grob alist
requires expanding the nested overrides at the time of creating a grob
or otherwise asking for ly:context-grob-properties.
Since issue 2507 encapsulated grob property access into the
Grob_property_info algorithm container structure relying on data stored
in context properties of elements of type Grob_properties, changing the
respective algorithms can be facilitated completely in those classes.
In order to provide similarly efficient access and reasonable caching
and just-in-time reevaluation of previously computed values,
Grob_properties needed to be significantly extended in size.
Rewrite paths relative to the lily-output-dir or the output dir
depending on which one is being used. Always use forward slashes
since this is what lilypond expects, even on Windows.
James Lowe [Sun, 10 Aug 2014 08:34:20 +0000 (09:34 +0100)]
Doc: Appendix - Articulations and Ornamentation - part 3
Issue 1189
Create Texifo @multitable entries for the
List of Articulations appendix.
As there are a lot of separate scripts being
documented this Issue is going to be split
into multiple, smaller, parts to aid in the
review process. Part 2 was commit 4d6f2a27cc
This is part 3 and while not strictly
'Articulations and ornamentations' covers
the percussion scripts.
I have also set the @code{} script examples into
the same column as the @lilypond examples; saving
a significant amount of wasted page space. I have
removed unnecessary lilypond-book variables making
the texinfo code less noisy.
David Kastrup [Sun, 17 Aug 2014 08:14:44 +0000 (10:14 +0200)]
Fix issue 3826
Commit 2d3a5d87166caa13feb036e23086b0d4f23283f4 let
scripts/auxiliar/update-with-convert-ly.sh call the non-existent
Makefile target "make pythonmodules" instead of "make python-modules".
Until now, numbers indicating clef transposition (for example
in \clef "G_8") were simply centered against the clef glyph.
This was not optimal, because clef glyphs aren't symmetrical
- for example the hook of the treble clef isn't exactly at its
horizontal center, and thus the octavation number shouldn't
be exactly centered.
This commit allows to specify alignment separately for each
clef, taking into account their individual characteristics.
Alignments are stored in clef-alignments property.
* Check for tracker issues missing OWNER or SUMMARY fields.
* Convert tabs to spaces in tracker issue summaries.
* Add lilypond-issues.csv to .gitignore.
* Add Heikki to mailmap.
* Update documentation.
* Fix typos.
David Kastrup [Sun, 15 Jun 2014 23:01:57 +0000 (01:01 +0200)]
Issue 4056: Let \partial in mid-piece work via a finalization hook
That allows all other processing to complete before measurePosition is
adjusted. In particular, this avoids problems when multiple parallel
contexts invoke \partial and/or bar checks.
Janek Warchoł [Sat, 9 Aug 2014 19:08:08 +0000 (21:08 +0200)]
Grob alignment: get back 2.19.9 behaviour
A series of commits
* 0bc7f77 Issue 3978: Merge alignment cleanup
|\
| * d6604b0 define-grobs.scm: reorder properties alphabetically
| * 6f3f8f0 TextScript, CombineTextScript: use aligned_on_parent
| * 1d76502 Replace XY-offset closures with aligned_on_parent where possible
| * 09412c2 Clean up DynamicText horizontal alignment.
|/
changed how some grobs (notably DynamicTexts) reacted to overriding
self-alignment-X property. The new behaviour was confusing for some
users, so this commit gets back the old behaviour. The possibility
of using separate alignment factors for grob and its parent, introduced
by previous commit (see Issue 4022), makes it possible to get pre-0bc7f77
behaviour just by changing default values of parent-alignment-*; leaving
up the possibility to easily change them in the future.
See http://lists.gnu.org/archive/html/lilypond-user/2014-07/msg00691.html
and https://code.google.com/p/lilypond/issues/detail?id=4036
for details.
Abraham Lee [Sat, 2 Aug 2014 16:17:01 +0000 (18:17 +0200)]
Allow changing of notation fonts
This commit changes the behaviour of make-pango-font-tree in the
following ways:
- Make all arguments optional key/value pairs
keeping the current default values (emmentaler/Century Schoolbook)
- Allow changing of music fonts too.
Currently alternative music fonts have to be present in the font
directory besides Emmentaler fonts, and they have to be manually installed.
But now there are a number of alternative and compatible fonts available.
David Kastrup [Sun, 27 Jul 2014 13:21:22 +0000 (15:21 +0200)]
Replace remaining uses of unsmob_xxx with Xxx::unsmob
This runs
sed -i 's/unsmob_\(engraver\|global_context\|input\|item\|music\|paper_score\|performance\|performer\|spanner\|stream_event\)\b/\u\1::unsmob/g' $(git grep -l unsmob_ lily)
as the mechanical part of the conversion. A separate commit provides
the required definitions.
David Kastrup [Fri, 25 Jul 2014 17:00:42 +0000 (19:00 +0200)]
unsmob_pitch -> Pitch::unsmob and related
This is part of moving away from implementing LilyPond infrastructure
via the C preprocessor rather than C++ features since C++ features tend
to be more transparent to IDEs, debuggers, editors, and newcomers.
David Kastrup [Sun, 27 Jul 2014 16:01:09 +0000 (18:01 +0200)]
Issue 4033: All subsequent clef transpositions are marked as optional
This removes a bug cover-up in scm/parser-clef.scm, implements the
necessary functionality in display-lily-music and adds some regtests
for that functionality.
James Lowe [Tue, 15 Jul 2014 21:21:10 +0000 (22:21 +0100)]
Doc: Appendix - Articulations and Ornamentation - part 2
Issue 1189
Create Texifo @multitable entries for the
List of Articulations appendix.
As there are a lot of separate scripts being
documented this Issue is going to be split
into multiple, smaller, parts to aid in the
review process. Part 1 was commit 8553021
This is part 2 and covers 'Fermata', 'Instrument
specific', 'Repeat signs' and 'Ancient' scripts.
Also, after more consideration, a third example
of each script has been added to show the
explicit differences between the up/down/neutral
positions. Not every script has a different
up/down glyph nor is positioned up/down when
placed on a note that is either top or bottom of
the Staff without explicit positioning. So this,
I hope just clarifies things (regardless whether
the position is musically 'correct' notation).
I have also sey the @code{} script examples into
the same column as the @lilypond examples; saving
a significant of wasted page space. Also I have
removed unnecessary lilypond-book variables making
the texinfo code less noisy.
Remove warning when there are no noteheads to attach lyrics to.
The warning was added to address issue 248, but it is now moot after
issue 3254 (c73b41b3e7be6d7): attaching lyrics to a note-less context
(like Devnull) is perfectly legal now.
As far as I can see, we don't want TextScript.cross-staff to be true
in any situation, because it would result in unwanted collisions.
Why it worked before: cross-staff property in this example evaluated to #f,
but only because of a bug in Script_interface::calc_cross_staff. That
function should have marked the TextScript as cross-staff if the stem
of the note to which TextScript was attached was cross-staff, but it
didn't work correctly because it expected the parent of the TextScript
to be a NoteColumn, while it actually was a PaperColumn. When I changed
the parent to be a NoteColumn, the function started working correctly
and marked the TextScript as cross-staff, so I had to change the default
value of the property.
Mark Polesky [Tue, 15 Jul 2014 19:34:15 +0000 (12:34 -0700)]
Issue 4015: Add \magnifyStaff.
* Add \magnifyStaff.
* Rewrite parts of the \magnifyMusic function so that it can share
some scheme code with the new \magnifyStaff function.
* Add regtests.
* Update documentation.
Mark Polesky [Wed, 9 Jul 2014 00:04:25 +0000 (17:04 -0700)]
Issue 3999: Make tablature half-note stem-spacing adjustable.
This adds a new property to the Stem grob called
'double-stem-separation (default=0.5), that allows users to adjust
the space between the double-stemmed half-notes in tablature: