Menu
▾
▴
2 Attachments
#2910 problem with 'outside-staff-padding
Originally created by: *anonymous
Originally created by: ma...@gregoriana.sk
Originally owned by: k-ohara5...@oco.net
Reported by David Nalesnik:
http://lists.gnu.org/archive/html/bug-lilypond/2012-10/msg00127.html
In the example in the documentation of 2.17.4 relating to
'outside-staff-padding, the last line of text ought to be close to the
previous text.
The problem is visible first with 2.17.1.
Originally posted by: k-ohara5...@oco.net
At the moment when two objects meet the 'outside-staff-padding for each of them is added. Formerly, only one pad is placed between objects, with thickness decided by the object _being_placed_ outside the earlier objects. The former method is used for other padding applications. It is not hard to restore the former behavior.
This forced me to review how the various paddings apply to objects placed outside the staff. The behavior that is documented and mostly depended upon by the defaults, is:
padding -- minimum distance from the outline of the object to the staff (not protruding notes, applied before note-spacing)
staff-padding -- minimum distance from the reference point of the object to the staff (broken, issue 3026)
outside-staff-padding -- minimum distance from the outline of the object to the outline of everything placed closer to the staff than this object (broken, issue 2910)
I think we want the documented behavior, which seems flexible and useful. The naming is not perfectly descriptive, but we can adjust that after straightening out the behavior.
Owner: k-ohara5...@oco.net
Status: Started
Related
Issues:
#2910Issues:
#3026Originally posted by: k-ohara5...@oco.net
The patch for issue 2148 changed 'outside-staff-padding' to mean
one (1) pad between outside-staff items and anything on the staff
two (2) pads between outside-staff items
and cut the default padding in half, putting very many objects closer to the staff.
The simplest fix for this issue is to simply restore the old behavior, so many regression tests change by moving outside-staff items an extra 1/4 staff space away from the staff.
I had given dynamics some extra outside-staff-padding since issue 2148, but that is no longer needed, so some double-padding between dynamics is removed with this patch.
http://codereview.appspot.com/10329043/
Labels: Patch-new
Related
Issues:
#2148Originally posted by: dak@gnu.org
I think it would make much more sense to let the padding between two items with individual padding be the _maximum_ of both padding specifications rather than the _sum_. Strictly speaking, to facilitate merging skylines with different padding values, one would need to store the padding for each "Building" (line segment) then.
Originally posted by: pkx1...@gmail.com
Fails make
--snip--
.0/include -W -Wall -Wconversion -o out/beam-collision-engraver.o /tmp/lilypond-autobuild/lily/beam-coll
ision-engraver.cc
make[1]: *** [out/axis-group-interface.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/tmp/build-lilypond-autobuild/lily'
make: *** [all] Error 2
Labels: -Patch-new Patch-needs_work
Originally posted by: k-ohara5...@oco.net
On the suggestion pad between each pair of objects with the maximum of their 'outside-staff-padding's, that would be very easy to do. The skylines are kept separate at this point (so that objects can fit into holes left by earlier-placed objects) so there is no extra record-keeping required.
We would just need a patch for the documentation example at the head of this issue; currently it describes and demonstrates the old behavior.
For now, I'll correct the patch to restore the old documented behavior
http://codereview.appspot.com/10329043/
Labels: -Patch-needs_work Patch-new
Originally posted by: pkx1...@gmail.com
Passes Make, make check and a full make doc - reg test diffs can be downloaded from here:
https://www.yousendit.com/download/WFJWR0lhbEpKV044SjhUQw
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Patch on countdown for June 24 - 06:00 GMT
Labels: -Patch-review Patch-countdown
Originally posted by: pkx1...@gmail.com
Patch counted down - please push
Labels: -Patch-countdown Patch-push
Originally posted by: k-ohara5...@oco.net
We can verify with the example at the top of this issue, from notation reference section 4.4.3:
\once \override TextScript.outside-staff-padding = #0
a'^"This text is placed very close to the note"
\once \override TextScript.outside-staff-padding = #3
c^"This text is padded away from the previous text"
c^"This text is placed close to the previous text"
Labels: -Patch-push Fixed_2_17_21
Status: Fixed
Originally posted by: Elu...@gmail.com
if you only put brackets around the above code LilyPond produces
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
with \relative {
it is what you expect.
so I can't state it verified
Originally posted by: k-ohara5...@oco.net
The patch changes the space calculation in an algorithm that tries various ways of fitting the markup over the staff, so maybe it causes an infinite loop for some precise alignment of the letters in text that might fit together.
I'll revert in a day unless we have better ideas.
Originally posted by: k-ohara5...@oco.net
Reverted, and back to needs-work, with the work needed being to determine if this patch somehow caused issue 3432.
Labels: -Fixed_2_17_21 Patch_needs_work
Status: Accepted
Related
Issues:
#3432Originally posted by: PhilEHol...@googlemail.com
OK - so I now understand this a bit better - the issue is that outside-staff-padding pads on both sides of the markup. Therefore, the following gives expected behaviour, given that this is understood. Might we just document this?
\relative c'' {
\once \override TextScript.outside-staff-padding = #0
a'^"This text is placed very close to the note very close to the note"
\once \override TextScript.outside-staff-padding = #3
c^"This text is padded away from the previous text"
c^"Also padded away from the previous text"
c^"Close to the previous text"
}
Originally posted by: k-ohara5...@oco.net
We could document the behavior of padding both sides. There might be a valuable use for the former behavior, though, which lets one adjust just one gap without affecting the others.
Probably better if I reverse the revert, next time I have Linux up, so we regain the fix as reviewed. The patch is simple and did not, in fact, cause issue 3432.
Labels: -Patch_needs_work Patch_push
Related
Issues:
#3432Originally posted by: tdanielsmusic
Of the three possibilities, pad one side only, pad with sum and pad with max, I
would strongly prefer pad with max. Before we mess with documentation and reverting
what do others prefer? Keith earlier (#5) thought pad with max was easy to do.
Trevor
Originally posted by: k-ohara5...@oco.net
Confirming that padding between outside-staff objects with the maximum of each object's outside-staff-padding is easy (for anybody, just read the patch linked above).
I'll post a patch along those lines soon, unless somebody beats me to it.
First, though, I'll look for a real-music example to post here --- one that needs a padding override, to confirm that pad-with-max works. Again, unless somebody beats me to it.
Labels: -Patch_push
Owner: ---
Originally posted by: k-ohara5...@oco.net
I searched but found very few uses of outside-staff-padding in users' scores.
Using 'pad with max' gives the most natural, unsurprising results in my opinion. It makes the manual example at the head of this issue impossible to achieve with outside-staff-padding, but that was a contrived example; I changed it to something more like comment 13.
One case where we *do* want padding on one side but not the other, is to have more padding between objects and the staff than between objects, but that is best done with 'staff-padding.
Having one pad between an object and noteheads, but two pads between objects outside the staff, makes real-music output slightly uglier than with 2.16, so let's repair this for the next stable.
Changes about 100 regression tests by small amounts. As before, the space left between objects and staff gets larger and that between objects smaller.
http://codereview.appspot.com/10329043/
Labels: Patch-new
Originally posted by: pkx1...@gmail.com
Passes make and make check but fails a make doc
--snip--
./Documentation/ly-examples/bach-bwv610.preview.log
jlowe@jlowe26vm /tmp/show-2910$ more ./Documentation/ly-examples/bach-bwv610.preview.log
Changing working directory to: `./out-www'
Processing `/tmp/lilypond-autobuild/Documentation/ly-examples/bach-bwv610.ly'
Parsing...
Interpreting music...[8]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 or 2 pages...
Drawing systems.../tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/s
tencil.scm:56:7: In procedure fold in expression (fold (lambda # #) (car stils)
...):
/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/stencil.scm:56:7: W
rong type argument in position ~A (expecting ~A): ~S
--snip--
Labels: -Patch-new Patch-needs_work
Owner: k-ohara5...@oco.net
Originally posted by: dak@gnu.org
Well, the error message delivered by Patchy is total garbage. Since Keith's patch does not touch stencil.scm, I'll take a look what I can do to fix the error message and push a fix of that to staging. Keith will need to decide whether he wants to have a rerun of make doc for getting a better error message or whether he knows what to do based on the current report.
Originally posted by: dak@gnu.org
Regarding comment #19: error message looks like a bug in GUILE. I'll try to see whether it is still in current GUILE and file a proper report.
The error message is likely triggered when stack-stencils-padding-list is not given lists in both of its last arguments. Hope this helps.
Originally posted by: dak@gnu.org
Regarding comment #20: totally evades me. Can't reproduce either outside or inside of LilyPond, would need a reliable and usefully simple recipe. I don't see anything obvious inside of GUILE's implementation of fold that could produce this kind of symptom. It's unlikely that it occurs outside of LilyPond.
Originally posted by: k-ohara5...@oco.net
The failure is in a function used only by \fill-line, which is used mostly in titling layout. I do not see any possible path between the patch and the failure.
The failing .ly file is the only one in the build that uses the MutopiaProject tagline, and this tagline uses \hspace in ways that don't work after issue 3330, but the code looks robust to the point that the error Guile reports seems to be impossible.
Related
Issues:
#3330Originally posted by: k-ohara5...@oco.net
Let's try the bugfix, removing the double padding, without changes to documentation.
http://codereview.appspot.com/10329043/
Labels: -Patch-needs_work Patch-new
Originally posted by: pkx1...@gmail.com
Passes Make, make check and a full make doc.
Reg test diffs here:
https://www.hightail.com/download/bWJyTmZWT00rV3h2TzhUQw
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Patch on countdown for September 3rd - 06:00 GMT
Labels: -Patch-review Patch-countdown