Re: Errors when doing 'make' for the first time when building the fonts
I've always these errors when I 'make' for the first time (i.e. when I have a fresh out of tree build). I expect most of them have always been there, but I wondered if they are problematic or not? They are problematic, and they have not `always been there' :-) Please use a recent version of FontForge, and please compile it with `--enable-double'. More details can be found in the archive of this email list. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR: Updated snippet for MMR Positions (1931) (issue 5155045)
Had problems uploading new patch to Rietveld after I ran makelsr.py - there are 60+ files changed (all the comittishes for the translations) - patch applies but my internet connection seems to be flakey and/or Rietveld is unforgiving it seems. I want to check that this is ok (with all those files changed). Patch attached here. http://code.google.com/p/lilypond/issues/detail?id=1931#c11 http://codereview.appspot.com/5155045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Errors when doing 'make' for the first time when building the fonts
Werner On Sat, Oct 8, 2011 at 7:05 AM, Werner LEMBERG w...@gnu.org wrote: I've always these errors when I 'make' for the first time (i.e. when I have a fresh out of tree build). I expect most of them have always been there, but I wondered if they are problematic or not? They are problematic, and they have not `always been there' :-) Please use a recent version of FontForge, and please compile it with `--enable-double'. Can you tell me which command I add the --enable-double to? 'make -j7 --enable-double' or '../configure --enable-double' or something else? More details can be found in the archive of this email list. yes I remember Trevor's email Can you tell me though what the ramifications are in terms of reg test checkig that I do if I am getting these errors? Thanks again. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows NoteColumns to be skipped over by glissandi. (issue 5242041)
On Oct 8, 2011, at 7:26 AM, pkx1...@gmail.com wrote:
passes make and make check only throws out
@@ -14,9 +14,9 @@
Writing graph `#f'...digraph G {
rankdir=LR
node [shape=rectangle]
-41 [label=caching Stem.stencil\n# - #]
+41 [label=caching LedgerLineSpanner.stencil\n# - #]
40 [label=caching VerticalAxisGroup.stencil\n# - #f]
-39 [label=caching LedgerLineSpanner.stencil\n# - #]
+39 [label=caching Stem.stencil\n# - #]
38 [label=caching StaffSymbol.stencil\n# - #]
37 [label=caching Stem.Y-extent\n# - (-2.812186 . 0.5)]
36 [label=caching Stem.length\n# - 6.624372]
@@ -56,7 +56,7 @@
2 [label=NoteHead\n/home/jlowe/lilypond-git/lily/engraver.cc:60\ncause
- # 41
+37 - 39
36 - 37
35 - 36
34 - 35
--snip--
James
I swear that I didn't see this sorta thing before I pushed my first cosmetic
patch - graphviz seems to be going berzerk now. Are people sure that this
sorta thing happens often?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Argument scanning, take II
Short of changing the argument syntax of music functions to something
less fuzzy altogether (implying GLISS), one needs a somewhat mixed
approach. It is clear that something like
\relative c' c' vs \relative { c' }
offer some significant challenges with regard to argument parsing.
Something like c' can be interpreted in multiple ways, and Lilypond
can't back up when scanning (and humans are not all too good at double
takes either, so the syntax should not become too complex).
So one thing I'll be doing is to form one syntactic class item mostly
a superset of current scalar. Its principle characteristic is that it
can be parsed without requiring lookahead. So something like music
or {music} or 42 or string or even \repeat volta 2 {music} is fine,
but Lilypond can't look for \addlyrics or \alternative or \cm or similar
behind it. Things like \markup { ... } or \markuplines { ... } are also
fine as well as #something which makes it possible to specify a value as
##{ 4\cm #} or #(* 4 cm) if you really want the value for 4\cm in a
place where only items are acceptable.
Now if we have an item not requiring lookahead, the parser will be able
to back it up and use it for something else as long as it can be
interpreted in the same manner.
Now to the context-dependent interpretation of function arguments: if we
want most function arguments to be grouped into the item class where
the parser can consider the implication by calling the predicate of the
argument rather than looking at the predicate and parsing in a specific
manner, we have the following situation:
If we have an optional argument of class item, the parser must be able
to look at it and decide it does not want it. But that means that
somebody else has to take it, in the indiscriminate syntactic form of
item. Since music lists can accommodate quite other things rather
than items, those can't escape into the surroundings of a function call.
So there is a rule that a _skipped_ optional item will usually have to
be followed by optional or mandatory arguments that can make use of an
item. In order not to make argument matching all too nonlinear, I want
stay with the decision that once an optional argument is skipped, all
following optional arguments get skipped as well. So the following
mandatory mandatory argument has to accept the item regardless of its
syntactic class (it may choose to barf at its type, but it can't
delegate the barfing to the parser via the normal course of a syntax
error).
So most of the parser would not bother about distinguishing items but
just take what it gets, leaving the complaints about wrong type to the
semantics. That would make most of the code in
Lily_lexer::try_special_identifiers trying to sort an expression into
*_IDENTIFIER classes unnecessary.
Of course, some things still have to be sorted out by the parser.
Things like pitches and durations can't easily become items because
their parsing usually requires lookahead (to see whether additional
octave marks or duration dots follow). You can force them into items by
doing something like
pitch = #(define-scheme-function (parser location p)(ly:pitch?)p)
and then using ##{\pitch c'#}.
Not all that pretty... Anyway, the main point was that if one wants
reasonable syntactic power in music functions without too many fine
points and breakage, a considerable amount of responsibility for
interpreting material in the typical course of operation has to be
withdrawn from the parser and put into other code. That's a tricky
challenge when one wants to integrate it with existing uses of the
hard-coded syntax.
On the plus side, things like #xxx and xxx or #3 and 3 will be
perfectly equivalent in all conceivable circumstances, so one can just
forget about educating users about fine points like that. You want to
use Scheme? Feel free. You don't want to? Feel free.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Errors when doing 'make' for the first time when building the fonts
Werner LEMBERG w...@gnu.org writes: and the version string contains `-D' or `-LD', e.g. Executable based on sources from 23:14 GMT 25-Feb-2011-ML-TtfDb-D. ^^ Unfortunately, Ubuntu Maverick (11.04) only ships a version from 2010: reinhold@eeepc:~$ fontforge --version Copyright (c) 2000-2010 by George Williams. Executable based on sources from 11:21 GMT 1-May-2010. At that time the additional configuration flags aren't shown in the version string of FontForge; this feature has been added later to the source code. In other words, you have to look up Ubuntu's compilation script to find out whether they are using --enable-double or not. The upcoming Oneiric (11.10) states fontforge --version Copyright (c) 2000-2011 by George Williams. Executable based on sources from 13:48 GMT 22-Feb-2011-ML. Library based on sources from 13:48 GMT 22-Feb-2011. fontforge 20110222 libfontforge 20110222-ML So you better file a problem report if you want this changed. Not likely for Oneiric, but you may be lucky for 12.04. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Errors when doing 'make' for the first time when building the fonts
On Sat, Oct 08, 2011 at 08:05:12AM +0200, Werner LEMBERG wrote: I expect most of them have always been there, but I wondered if they are problematic or not? They are problematic, and they have not `always been there' :-) Correction: using our official development environment lilydev, they *have* always been there. Please use a recent version of FontForge, and please compile it with `--enable-double'. This warning is in the installation instructions, but it would be nice if we didn't have warnings like that. ../configure should check it. Fontforge 20110222 even shows the status of whether you used --enable-double in the version string, so it would be an easy check to make! http://code.google.com/p/lilypond/issues/detail?id=1637 Unfortunately we cannot (in good faith) require this until it's in lilydev. http://code.google.com/p/lilypond/issues/detail?id=1683 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Errors when doing 'make' for the first time when building the fonts
They are problematic, and they have not `always been there' :-) Correction: using our official development environment lilydev, they *have* always been there. Hmm. Please use a recent version of FontForge, and please compile it with `--enable-double'. This warning is in the installation instructions, but it would be nice if we didn't have warnings like that. ../configure should check it. Fontforge 20110222 even shows the status of whether you used --enable-double in the version string, so it would be an easy check to make! Yep. If my memory serves right, someone has even written a patch for that already. No time to check the archives, sorry. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Markup implementation
Not finding a more suitable thread to hook onto.
Nicolas Sceaux nicolas.sce...@gmail.com writes:
Le 17 sept. 2011 à 17:41, m...@apollinemike.com a écrit :
I've been toying with the idea for some time now of making markups
at all levels behave more like grobs. It would require a massive
code rewrite, but it'd allow a much more uniform approach to exactly
this sort of thing (markups could, for example, issue errors like
grobs, which gives the user the place in the code where the bad
markup is). It'd also allow for some code-duping in the footnote
code to go away and would allow for object-oriented references
between markups (which would help with spacing, advanced
inter-markup communication for layout stuff, etc.).
Would anyone be interested in co-taking this on?
Hi Mike,
Just writing quickly, I hope I don't write nonsense.
I see several problems wrt to markups:
1) the markup / markup-list duality sucks. I tend to implement every
markup command twice (with its markup-lines counterparts).
== markup and markuplines should be unified, somewhat.
How about letting markup be either, and markup lists are identified by
satisfying the list? predicate? Seems simple enough.
== it shall be possible to set some characteristics to toplevel markups
(e.g. before/after padding and spacing stuff.)
3) mixing several lines of text and music in a single paragraph is just
not possible. One or two years ago, someone provided an implementation
sketch, where a markup is given some extra context when interpreted, to
figure out where on the current line it appears.
I am currently working with the parser to have scalars possible to be a
number of different things if properly recognizable. That would allow
wheezing music expressions into a number of things. For example, it
would be reasonably easy to allow \tempo { c4. [c8 8] } = 56, and have
the tempo command haul any music it encounters through a simplified
rhythmic Staff (\tempoStaff ?) without staffline and in a proper size.
Currently, the internal representation of a markup is a simple list:
(markup-command arg1 arg2 ...)
And a markup a interpreted by applying the markup-command on the args
(plus the layout and properties special arguments).
This is not expressive enough. A more elaborate data structure shall
be used.
I'd want that for markups that are not already scalars like integers,
strings, and similar, so that anything satisfying list? is interpreted
like a markup list, and everything else as what we call a markup so
far.
A first step could be to move the internal representation of markups
to C++, like grobs, music expressions, etc, with similar accessors.
At this point the functionnality would be unchanged. Then we could
add some logics to deal with the mentionned problems. But this pass
most probably leads to backward incompatibility at some point.
I think with the changes I am currently plotting to the parser, changes
would remain rather confined.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Friday, October 07, 2011 7:24 PM Subject: GUB On Fri, Oct 07, 2011 at 07:09:57PM +0100, Phil Holmes wrote: Tail of target/tools/log/perl.log tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now Command barfed: tar -C /media/IntelSSD/lilypond/git-gub/gub/target/tools/src/perl-5.10.0 --strip-component=1 -v -z -xf /media/IntelSSD/lilypond/git-gub/gub/downloads/perl/perl-5.10.0.tar.gz If I try to open perl*.tar.gz I get unexpected end-of-file. I get the same with the re-downloaded version from CPAN. I'm assuming it's corrupt. Find another one? Let's change the subject line here. I guess we'll need a different one... let's use perl-5.10.1 http://www.cpan.org/src/5.0/perl-5.10.1.tar.gz since that's the least likely to break stuff that used to work in 5.10.0. Cheers, - Graham Patch for GUB git to update locations of relevant files that were missing. make bootstrap now complete. What next? -- Phil Holmes 0001-Updates-to-locations-of-source-files.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote: Patch for GUB git to update locations of relevant files that were missing. Thanks, I'll apply it in about 90 minutes. (I'm making a release right now and it's doing the regtest comparison, so it needs to build the docs and upload, then I can safely play with the repo) make bootstrap now complete. What next? I /think/ it's this command you want: python bin/gib --platform=mingw --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond (all on one line) but it might be this one instead: bin/gub --platform=mingw 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable' (again, all on one line) If both of those fail, just do: bin/gub lilypond that won't create the installable .exe, but it'll trigger a downloadcompile of all the extra tools it needs to build lilypond (in addition to building lilypond itself), so that'll keep you busy for another 1-2 hours before the question of the .exe is actually relevant. At that point, I'll be done the release build, so I can play around and find the exact command for a windows .exe build. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Saturday, October 08, 2011 4:23 PM Subject: Re: GUB On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote: Patch for GUB git to update locations of relevant files that were missing. Thanks, I'll apply it in about 90 minutes. (I'm making a release right now and it's doing the regtest comparison, so it needs to build the docs and upload, then I can safely play with the repo) make bootstrap now complete. What next? I /think/ it's this command you want: python bin/gib --platform=mingw --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond Nope. (all on one line) but it might be this one instead: bin/gub --platform=mingw 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable' Yep. (again, all on one line) If both of those fail, just do: bin/gub lilypond that won't create the installable .exe, but it'll trigger a downloadcompile of all the extra tools it needs to build lilypond (in addition to building lilypond itself), so that'll keep you busy for another 1-2 hours before the question of the .exe is actually relevant. At that point, I'll be done the release build, so I can play around and find the exact command for a windows .exe build. Cheers, - Graham Stuff doing, as above. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On 8 October 2011 16:23, Graham Percival gra...@percival-music.ca wrote: I /think/ it's this command you want: python bin/gib --platform=mingw --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond (all on one line) but it might be this one instead: bin/gub --platform=mingw 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable' (again, all on one line) bin/gub mingw::lilypond-installer is what I use. I had to restore shallow cloning and hack specs/lilypond.py to get it to fetch changes from the local repository (otherwise it just builds master). Cheers, Neil PS I've just posted times on the tracker, since I always have an up-to-date mingw build to test changes. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)
Hi Betrand, This should be split into two patches: one for the optimization and another for adding robust_symbol2string lookups outside note-head.cc. Cheers, Neil http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc File lily/lily-guile.cc (left): http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc#oldcode72 lily/lily-guile.cc:72: Ugh. this is not very efficient. why have you removed this comment? http://codereview.appspot.com/5233042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On Sat, Oct 08, 2011 at 04:46:58PM +0100, Neil Puttock wrote: bin/gub --platform=mingw 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable' bin/gub mingw::lilypond-installer is what I use. I had to restore shallow cloning and hack specs/lilypond.py to get it to fetch changes from the local repository (otherwise it just builds master). Yeah, that's the point of using one of the other commands; you can specify the branch. There's also some way of specifying the branch using the bin/gub method too... it'd be listed in lilypond.make... but I don't have it written down handy. It might be nice to determine the recommended command to build the installer for a specific binary and a specific platform -- and to easily support giving it a local repository -- but I'm not offering to do that. Maybe since Phil is new to GUB, he'll be energetic about fixing and documenting usage and bugs for the next couple of weeks until gets jaded like us. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On 8 October 2011 17:41, Graham Percival gra...@percival-music.ca wrote: Yeah, that's the point of using one of the other commands; you can specify the branch. There's also some way of specifying the branch using the bin/gub method too... it'd be listed in lilypond.make... but I don't have it written down handy. Heh, I couldn't work out any command which would do the same, so just hacked it instead. :) It might be nice to determine the recommended command to build the installer for a specific binary and a specific platform -- and to easily support giving it a local repository -- but I'm not offering to do that. Maybe since Phil is new to GUB, he'll be energetic about fixing and documenting usage and bugs for the next couple of weeks until gets jaded like us. :) Haha, can't we just kidnap Jan and get him to tell us? :) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On Sat, Oct 08, 2011 at 05:47:25PM +0100, Neil Puttock wrote: On 8 October 2011 17:41, Graham Percival gra...@percival-music.ca wrote: It might be nice to determine the recommended command to build the installer for a specific binary and a specific platform -- and to easily support giving it a local repository -- but I'm not offering to do that. Maybe since Phil is new to GUB, he'll be energetic about fixing and documenting usage and bugs for the next couple of weeks until gets jaded like us. :) Haha, can't we just kidnap Jan and get him to tell us? :) He could tell us what it thinks it was, a few years ago. I'm willing to bet that there's at least one bug (like that shallow clone thing) that would need fixing before it fully works. Granted, the bugfix would almost certainly be less than 4 lines of python code... but if I were working on this, I'd budget an hour to do such a fix. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Saturday, October 08, 2011 4:23 PM Subject: Re: GUB On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote: Patch for GUB git to update locations of relevant files that were missing. Thanks, I'll apply it in about 90 minutes. (I'm making a release right now and it's doing the regtest comparison, so it needs to build the docs and upload, then I can safely play with the repo) make bootstrap now complete. What next? I /think/ it's this command you want: python bin/gib --platform=mingw --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond (all on one line) but it might be this one instead: bin/gub --platform=mingw 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable' (again, all on one line) If both of those fail, just do: bin/gub lilypond that won't create the installable .exe, but it'll trigger a downloadcompile of all the extra tools it needs to build lilypond (in addition to building lilypond itself), so that'll keep you busy for another 1-2 hours before the question of the .exe is actually relevant. At that point, I'll be done the release build, so I can play around and find the exact command for a windows .exe build. Cheers, - Graham OK. This gives: libtool: Version mismatch error. This is libtool 2.2.6, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 libtool: and run autoconf again. make: *** [gen-scmconfig] Error 63 Command barfed: cd /media/IntelSSD/lilypond/git-gub/gub/target/tools/build/guile-1.8.7/libguile make LD_LIBRARY_PATH=/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/lib CFLAGS='-O2 -I/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/include' LDFLAGS='-L/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/lib -Wl,-rpath -Wl,\$$ORIGIN/../lib -Wl,-rpath -Wl,/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/lib' gen-scmconfig guile_filter_doc_snarfage -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On Sat, Oct 08, 2011 at 06:13:23PM +0100, Phil Holmes wrote: OK. This gives: libtool: Version mismatch error. This is libtool 2.2.6, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 libtool: and run autoconf again. make: *** [gen-scmconfig] Error 63 Command barfed: cd /media/IntelSSD/lilypond/git-gub/gub/target/tools/build/guile-1.8.7/libguile Now we're into screaming and running away territory. There's either some incompatibilty with your system libtool, or some part of GUB is calling your system libtool when it should be calling the GUB libtool instead, or something like that. The libguile is a vitally important part. That probably means that we're either looking at a problem in gub/specs/guile*.py. Nothing in guile.py looks particularly helpful to me, though. Oh, what exact package were you building? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)
Thanks Neil, I'll make two commits. Do you want to see them both on codereview? Comment in lily-guile restored. http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc File lily/lily-guile.cc (left): http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc#oldcode72 lily/lily-guile.cc:72: Ugh. this is not very efficient. This was a mistake, sorry. http://codereview.appspot.com/5233042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ragged-last-bottom should not ignore stretching on the last page
On Sat, 08 Oct 2011 14:57:33 -0700, Xavier Scheuer x.sche...@gmail.com wrote: Maybe this has been already discussed, but I do not like the current vertical spacing behaviour of the last page when using ragged-last-bottom (##t by default). It has been discussed, most recently at http://lists.gnu.org/archive/html/lilypond-user/2011-08/msg00043.html For now, we can get more space on the last page by adjusting things like system-system-spacing #'basic-distance = #18 page-breaking-system-system-spacing #'basic-distance = #10 Let's enter an enhancement request. Possibly LilyPond could remember the most recently-used stretching force, and use that force or the flush-bottom force on the final page, whichever is less. Possibly we want to be able to enter stretchable space by hand in between and after \scores, with a variable stretchability, and use that as a more flexible replacement for ragged-bottom. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
