Menu
▾
▴
#3281 3 or 4 pages
Originally created by: *anonymous
Originally created by: colingh...@gmail.com
Originally owned by: k-ohara5...@oco.net
Jan Nieuwenhuizen reported here:
http://lists.gnu.org/archive/html/bug-lilypond/2013-03/msg00122.html
as follows:
Hi,
Why is this on four pages, it seems to fit on three.
This is with v2.17.12
#(set-default-paper-size "a8")
\paper
{
indent = 2\mm
tagline = #f
}
\relative c'
{
f2 f f4 f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
f f f f f f f f
}
Originally posted by: dak@gnu.org
Any pointers whether this might have worked differently in older versions?
Originally posted by: thomasmo...@gmail.com
With 2.12.3
12 pages(!)
with 2.13.47, 2.14.2, 2.15.40, 2.16.2, 2.17.17, 2.17.19 (from current master)
always 4 pages.
Originally posted by: PhilEHol...@googlemail.com
If you set ragged-last-bottom = ##f then it fits on 3 pages. My guess is that there's a penalty for a full last page when ragged-last-bottom = ##t, and so Lily spaces the lines to avoid such a thing.
Originally posted by: dak@gnu.org
Comment #3 does not convince me. I don't think that setting ragged-last-bottom to ##f should lead to _fewer_ pages. It is _adding_ a constraint. Normally one of the most important evils to avoid should be unnecessary pages. If they can be avoided with a non-ragged bottom, that should be done. A non-ragged bottom combined with one page less is the best result, anyway, even if allowing for a ragged last bottom.
Originally posted by: k-ohara5...@oco.net
The page-breaker does, in fact, forbid any compression at all of 'ragged' pages. In the example, the four staves need just a bit of compression to fit within a page.
We all seem to think that "ragged" should mean to allow extra space at the bottom of a page (rather than its current meaning of constraining the spaces between staves to their nominal distances).
http://codereview.appspot.com/25710043
Labels: Patch-new
Owner: k-ohara5...@oco.net
Originally posted by: lemzw...@googlemail.com
I indeed think that `ragged' implicates that pages are neither stretched nor compressed vertically. To change that, I strongly suggest to add a new flag, say, `ragged-compression' which probably should be set to ##t by default.
Originally posted by: k-ohara5...@oco.net
Okay. But then page-breaking works as above, depending on ragged-bottom, which does surprise people https://code.google.com/p/lilypond/issues/detail?id=347#c5
Labels: -Patch-new
Owner: ---
Originally posted by: lemzw...@googlemail.com
Well, everything is a matter of documentation :-)
Originally posted by: k-ohara5...@oco.net
The documentation was accurate, but the behavior was so surprising that no-one interpreted the documentation to mean what it meant -- except apparently Phil.
I hesitate to add the complexity of switchable behavior, without an example where the behavior shown at the top of this issue could be desirable.
Add backward compatibility for Werner
http://codereview.appspot.com/25710043
Labels: Patch-new
Owner: k-ohara5...@oco.net
Cc: lemzw...@googlemail.com
Status: Started
Originally posted by: pkx1...@gmail.com
Passes Make, Make check and a full make doc.
Reg test diff gives me
--snip--
@@ -4,6 +4,8 @@
Preprocessing graphical objects...
Calculating page and line breaks (1 possible page breaks)...[1]
Drawing systems...
+warning: cannot fit music on page: overflow is 2.439188
+warning: compressing music to fit
Writing header field `texidoc' to `/tmp/build-lilypond-autobuild/out/lybook-testdb/d6/lily-aeb0033e.texidoc'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/d6/lily-aeb0033e.eps'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/d6/lily-aeb0033e-1.eps'...
input/regression/page-turn-page-breaking-auto-first-page.log
--snip--
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
Thanks, James.
That regression test was supposed to change, but should not have changed so much to cause that warning, and I missed it. New patch is up.
This test is multi-page so `make check` doesn't show the image difference, so I'll attach before and after. Before the patch (left) the page-breaker squeezes more music on the first page so it will not have to squeeze the ragged-bottom second page, but then the page layout squeezes the second page anyway to match the first page (issue 1377; maybe we should only stretch to match the penultimate page). After the patch, the tightness is more even.
I looked quickly through the sixty other multi-page tests and found no problems.
http://codereview.appspot.com/25710043
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make check and a full make doc.
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
I still hesitate to add this backward-compatibility switch, because I can't see any use for it. Thinking through all the combinations of options (in the code for page-turn-breaking, where we need to estimate page-fits) was difficult, at least for me.
I asked on -user, what people use ragged-bottom for.
We could keep 'ragged-bottom' behaving as it does now, and change only 'ragged-last-bottom' to allow vertical compression or a gap on the last page. That makes the code simpler. I inserted a page doing this in the Rietveld page, leaving the patch currently under review at the end.
Originally posted by: pkx1...@gmail.com
Patch on countdown for Nov 19th - 06:00 GMT
Labels: -Patch-review Patch-countdown
Originally posted by: k-ohara5...@oco.net
The response on -user <http://lists.gnu.org/archive/html/lilypond-user/2013-11/msg00563.html> implies that users accept how ragged-bottom pages currently behave --- except of course that the last page should allow compression by default when the earlier pages are best-fit.
So, a patch to change only the behavior of ragged-last-bottom, with docs update:
http://codereview.appspot.com/25710043/
Regression tests show some "compressing music to fit" messages replaced by one that includes the relevant page number, if there is a page number to report.
Labels: -Patch-countdown Patch-new
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Labels: -Patch-new Patch-needs_work
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests. The new warnings look a bit worse than the old. For the one-page case, only the previous warning: cannot fit music on page: overflow is 13.096881 remains, with the warning: compressing music to fit message complete elided. For the multi-page case, we get warning: cannot fit music on page: overflow is 7.297150, warning: cannot fit music on page 1; this page was compressed. It would be better to deliver the information (page + overflow) in a single line to avoid the repetitive nature. No idea how feasible that is.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Since the patchy run for comment #19 overlapped with the apparent change committed with comment #18, resetting to Patch-new. But the remark for the warning behavior remains even if the warnings get factored out into a different issue.
Labels: -Patch-review Patch-new
Originally posted by: pkx1...@gmail.com
OK passes make, make check and a full make doc but I get the following:
--snip--
input/regression/profile-property-access.log
@@ -122,8 +122,8 @@
grob properties, top 50 rounded to 10
-TOTAL : 294530
-outside-staff-priority : 66470
+TOTAL : 295550
+outside-staff-priority : 67500
cross-staff : 14520
staff-symbol : 13840
cause : 12010
@@ -135,7 +135,7 @@
direction : 7360
meta : 6070
vertical-skylines : 6060
-pure-Y-offset-in-progress : 5610
+pure-Y-offset-in-progress : 5600
stencil : 5100
Y-extent : 4690
duration-log : 4690
input/regression/page-breaking-end-of-score.log
@@ -10,7 +10,7 @@
Fitting music on 1 or 2 pages...
Drawing systems...
warning: cannot fit music on page: overflow is 6.119719
-warning: compressing music to fit
+warning: cannot fit music on page 2; this page was compressed
Writing header field `texidoc' to `/tmp/build-lilypond-autobuild/out/lybook-testdb/f7/lily-b9567f71.texidoc'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/f7/lily-b9567f71.eps'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/f7/lily-b9567f71-1.eps'...
input/regression/page-overflow-compression.log
@@ -6,7 +6,7 @@
Fitting music on 1 page...
Drawing systems...
warning: cannot fit music on page: overflow is 3.124461
-warning: compressing music to fit
+warning: cannot fit music on page 1; this page was compressed
Writing header field `texidoc' to `/tmp/build-lilypond-autobuild/out/lybook-testdb/c6/lily-73a13001.texidoc'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/c6/lily-73a13001.eps'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/c6/lily-73a13001-1.eps'...
input/regression/page-breaking-min-systems-per-page2.log
@@ -6,7 +6,7 @@
Fitting music on 1 page...
Drawing systems...
warning: cannot fit music on page: overflow is 92.080959
-warning: compressing music to fit
+warning: cannot fit music on page 1; this page was compressed
Writing header field `texidoc' to `/tmp/build-lilypond-autobuild/out/lybook-testdb/94/lily-32d78681.texidoc'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/94/lily-32d78681.eps'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/94/lily-32d78681-1.eps'...
input/regression/page-breaking-page-count3.log
@@ -13,7 +13,7 @@
continuing, cross fingers
Drawing systems...
warning: cannot fit music on page: overflow is 7.297150
-warning: compressing music to fit
+warning: cannot fit music on page 1; this page was compressed
Writing header field `texidoc' to `/tmp/build-lilypond-autobuild/out/lybook-testdb/15/lily-7dccbf09.texidoc'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/15/lily-7dccbf09.eps'...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/15/lily-7dccbf09-1.eps'...
input/regression/rest-positioning.log
@@ -5,7 +5,6 @@
Calculating line breaks...
Drawing systems...
warning: cannot fit music on page: overflow is 13.096881
-warning: compressing music to fit
Writing header field `texidoc' to `/tmp/build-lilypond-autobuild/out/lybook-testdb/9e/lily-347a89b1.texidoc'...
Writing /tmp/build-lilypond-autobuild/out/lybook-testdb/9e/lily-347a89b1-1.signature
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-testdb/9e/lily-347a89b1.eps'...
input/regression/repeat-sign-global-size-5.log
@@ -9,7 +9,6 @@
Calculating line breaks...
Drawing systems...
warning: cannot fit music on page: overflow is 32.587000
-warning: compressing music to fit
Writing header field `texidoc' to `/tmp/build-lilypond-autobuild/out/lybook-testdb/9f/lily-e80b4547.texidoc'...
Writing /tmp/build-lilypond-autobuild/out/lybook-testdb/9f/lily-e80b4547-1.signature
Writing /tmp/build-lilypond-autobuild/out/lybook-testdb/9f/lily-e80b4547-2.signature
--snip--
James
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
The code that discovers a page is over-full is rather distant from the code that counts out the page-number. If we want to be told which page was over-full, it is much cleaner to have a separate message from the one that told us how much it was over-full. Thus the two lines. I can streamline the messages, though, if you think leaving out some details made them a bit worse than the old.
In most regression tests, there are no page numbers, so we don't get the second line.
http://codereview.appspot.com/25710043/
Labels: -Patch-review Patch-new
Originally posted by: lemzw...@googlemail.com
Why not make lilypond always emit the page number? Probably even multiple times if necessary or useful. Then warning messages don't need to take care of page numbers.
I think that lilypond could be much more verbose here to entertain the waiting user.
Originally posted by: dak@gnu.org
I think you overestimate the entertainment value of a sudden dump of a large bunch of numbers at the end of a long wait.
Originally posted by: lemzw...@googlemail.com
Well, if it improves warning messages (or rather, the ability to better locate where the warning happens), why not?
Originally posted by: dak@gnu.org
First you have to notice there's a warning in the midst of the end-of-run dump of numbers.
They are easy enough to overlook anyway.
No, I don't think the default amount of verbosity is too low, and Keith's approach fit pretty well into that.