Patrick McCarty wrote:
On Sun, Mar 1, 2009 at 12:17 AM, Mats Bengtsson
<mats.bengts...@ee.kth.se> wrote:
Quoting Patrick McCarty <pnor...@gmail.com>:
On Sat, Feb 28, 2009 at 6:00 AM, Valentin Villenave
<v.villen...@gmail.com> wrote:
Greetings Joe,
where are we now? Does this SeparationItem thingy deserve an issue in
the tracker?
I don't think it deserves an issue.
We have two options:
1) Remove SeparationItem from LilyPond's source
(scm/define-grobs.scm). Then we would need a convert-ly rule.
2) Keep SeparationItem, even though it is never used.
I guess it all depends on whether SeparationItem will ever be used
again in the future.
The main thing is that the documentation is modified to show a solution that
works, i.e. that gives the same result as you previously could obtain
setting SeparationItem #'padding = ...
Ah, yes. I forgot that the documentation was not updated to reflect the change.
Joe added a regtest called spacing-paper-column-padding.ly that
demonstrates the new behavior.
-Patrick
I'll update the docs to reflect the change. Couple of questions first,
though.
1. The regtest mentioned above has two overrides, but as far as I can
tell only one of them has any effect. Unless I'm missing something,
only the NonMusicalPaperColumn affects the spacing. If it's commented
out, the spacing goes back to normal, but if the PaperColumn padding
override is commented out and the NonMusicalPaperColumn override is
kept, the spacing changes. Here's my minimal example made from it:
\relative c' {
% \override Score.PaperColumn #'padding = #10
\override Score.NonMusicalPaperColumn #'padding = #10
c d
}
There might be a good reason to include the first override, a reason not
evident in such a tiny example, so maybe someone with more knowledge can
tell me whether to keep it in there.
2. Doc policy discourages (forbids?) the use of @example, which is
currently how this issue is addressed in NR 4.5.1 "known issues and
warnings." It would be easy enough to change the @example currently
there to show the NonMusicalPaperColumn override, but this would
perpetuate a breach of doc policy. On the other hand, lilypond examples
with overrides are also forbidden in the main text, so this would have
to go into a snippet. Should I go ahead and quick-fix the @example
until a snippet can be added to the snippet list and then later make a
link to the snippet?
Thanks,
Jon
--
Jonathan Kulp
http://www.jonathankulp.com
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
