Re: Some "Cheat cheet" nitpicks
> If the makefile sets it to 0mm, then what happens for longer > examples with bar numbers? Presumably somebody needs to go through > all the docs to find multi-line examples, then add >[left-padding=3mm] > to those examples. Exactly. However, in most multi-line examples of the lilypond documentation the right thing to do IMHO is to remove bar numbers, too. > This is too much work for not enough payoff. Especially since (I > think) a one-line patch to the C file that Sven identified would > render this work unnecessary. Regardless of the difficulty or (simplicity) to implement this in the lilypond binary, I'm not sure whether this is a good idea at all. The left padding is a kind of metadata since you need some context to align to. In other words, a call to the lilypond binary can't find the right left padding value of a snippet. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
Graham Percival writes: > On Wed, Dec 16, 2009 at 2:02 PM, Werner LEMBERG wrote: The best solution is probably to add a new command line option `--default-left-padding' to lilypond-book (which is then used in the Makefile with value 0mm to override the default setting of 3mm), and adding a snippet option `left-padding' to the lilypond environments (within lilypond-book) to override the default left padding if necessary. >>> >>> No. We're not adding that option to 90% of the snippets in the >>> docs. It can't be done automatically, and it's way too much work to >>> do it manually. >> >> ??? I've just suggested the `--default-left-padding' option to >> exactly avoid that! Ideally, we would simply change the default value >> of lilypond-book's `--left-padding' option to 0mm, but this breaks >> backwards compatibility. Thus my suggestion to have a means to >> control the default value instead. > > If the makefile sets it to 0mm, then what happens for longer examples > with bar numbers? Presumably somebody needs to go through all the > docs to find multi-line examples, then add >[left-padding=3mm] > to those examples. > > This is too much work for not enough payoff. Especially since (I > think) a one-line patch to the C file that Sven identified would > render this work unnecessary. It is common to have the first line of multiple lines indented and adjusted (they look like paragraphs essentially), but it makes little sense to indent single lines. In particular if you interchange single lines with text, or treat them as inline material. So it might be nice to be able to specify special padding/adjustment for single-line formatting. If there was a way to find out post-fact what kind of formatting was actually employed for any snippet, this might also be nice. But one can probably guess somewhat reliably by checking the width of the result. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
On Wed, Dec 16, 2009 at 2:02 PM, Werner LEMBERG wrote: >>> The best solution is probably to add a new command line option >>> `--default-left-padding' to lilypond-book (which is then used in >>> the Makefile with value 0mm to override the default setting of >>> 3mm), and adding a snippet option `left-padding' to the lilypond >>> environments (within lilypond-book) to override the default left >>> padding if necessary. >> >> No. We're not adding that option to 90% of the snippets in the >> docs. It can't be done automatically, and it's way too much work to >> do it manually. > > ??? I've just suggested the `--default-left-padding' option to > exactly avoid that! Ideally, we would simply change the default value > of lilypond-book's `--left-padding' option to 0mm, but this breaks > backwards compatibility. Thus my suggestion to have a means to > control the default value instead. If the makefile sets it to 0mm, then what happens for longer examples with bar numbers? Presumably somebody needs to go through all the docs to find multi-line examples, then add [left-padding=3mm] to those examples. This is too much work for not enough payoff. Especially since (I think) a one-line patch to the C file that Sven identified would render this work unnecessary. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
> It's part of the lilypond binary (or scheme functions) itself, not > lilypond-book. OK. >> The best solution is probably to add a new command line option >> `--default-left-padding' to lilypond-book (which is then used in >> the Makefile with value 0mm to override the default setting of >> 3mm), and adding a snippet option `left-padding' to the lilypond >> environments (within lilypond-book) to override the default left >> padding if necessary. > > No. We're not adding that option to 90% of the snippets in the > docs. It can't be done automatically, and it's way too much work to > do it manually. ??? I've just suggested the `--default-left-padding' option to exactly avoid that! Ideally, we would simply change the default value of lilypond-book's `--left-padding' option to 0mm, but this breaks backwards compatibility. Thus my suggestion to have a means to control the default value instead. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
2009/12/15 Graham Percival
> On Tue, Dec 15, 2009 at 09:55:10AM +0100, Werner LEMBERG wrote:
> >
> > [all lilypond documentation snippets running through lilypond-book get
> > a horizontal offset of 3mm to the right]
> >
> > > We have code that detects if the example is a single line; if so, it
> > > adds ragged-right=##t.
> >
> > I think you are wrong; at least I haven't found anything into this
> > direction in lilypond-book. It only suppresses ragged-right output if
> > a line width is given.
>
> It's part of the lilypond binary (or scheme functions) itself, not
> lilypond-book.
>
> http://lists.gnu.org/archive/html/lilypond-devel/2008-03/msg00097.html
>
> I don't know exactly when it was implemented, but we spent a lot
> of time removing [ragged-right] from the docs, so it definitely
> *was* implemented.
>
> > > That same piece of code could set left-padding to 0.
> >
> > `This piece of code' has to be written yet, I believe. However, I
> > think it's a bad idea in general since it means that you have to run
> > lilypond twice on a single snippet: the first time to find out whether
> > there is more than a single line, and the second time to apply
> > left-padding.
>
> I have no clue how Joe worked his magic, but I trust that he did
> it the proper way. :) (or else he and Han-Wen decided that the
> initial spacing could be done fast enough that it wouldn't matter)
>
Jyst FYI: the code in question is in lily/constrained-breaking.cc
in SHA 6673b8fee.
The patch looks like this:
+ /* As a special case, if there is only one line in the score and
ragged-right
+ hasn't been specifically forbidden and the line is stretched, use
+ ragged spacing. */
+ if (last && i == 0
+ && lines_.at (i, j).force_ >= 0
+ && !scm_is_bool (pscore_->layout ()->c_variable ("ragged-right"))
+ && !scm_is_bool (pscore_->layout ()->c_variable ("ragged-last")))
+ragged = true;
--
Sven Axelsson
++[>++>+++>++>++
><-]>.+..>+.>+.<<-.>>+.>.<<.
+++.>-.<<++.>>.<++.>>>++..>>.<.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
On Tue, Dec 15, 2009 at 09:55:10AM +0100, Werner LEMBERG wrote: > > [all lilypond documentation snippets running through lilypond-book get > a horizontal offset of 3mm to the right] > > > We have code that detects if the example is a single line; if so, it > > adds ragged-right=##t. > > I think you are wrong; at least I haven't found anything into this > direction in lilypond-book. It only suppresses ragged-right output if > a line width is given. It's part of the lilypond binary (or scheme functions) itself, not lilypond-book. http://lists.gnu.org/archive/html/lilypond-devel/2008-03/msg00097.html I don't know exactly when it was implemented, but we spent a lot of time removing [ragged-right] from the docs, so it definitely *was* implemented. > > That same piece of code could set left-padding to 0. > > `This piece of code' has to be written yet, I believe. However, I > think it's a bad idea in general since it means that you have to run > lilypond twice on a single snippet: the first time to find out whether > there is more than a single line, and the second time to apply > left-padding. I have no clue how Joe worked his magic, but I trust that he did it the proper way. :) (or else he and Han-Wen decided that the initial spacing could be done fast enough that it wouldn't matter) > The best solution is probably to add a new command line option > `--default-left-padding' to lilypond-book (which is then used in the > Makefile with value 0mm to override the default setting of 3mm), and > adding a snippet option `left-padding' to the lilypond environments > (within lilypond-book) to override the default left padding if > necessary. No. We're not adding that option to 90% of the snippets in the docs. It can't be done automatically, and it's way too much work to do it manually. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
[all lilypond documentation snippets running through lilypond-book get a horizontal offset of 3mm to the right] I redirect this discussion to lilypond-devel. >> [...] The lilypond-book option --left-padding controls this; if >> not given, a default value of 3mm is used. Main reason to use have >> a non-zero default is to take care of bar numbers sticking out to >> the left. >> >> It's debatable, however, whether we should have that in the >> lilypond documentation, given the vast amount of small snippets >> which consist of a single line only. > > We have code that detects if the example is a single line; if so, it > adds ragged-right=##t. I think you are wrong; at least I haven't found anything into this direction in lilypond-book. It only suppresses ragged-right output if a line width is given. > That same piece of code could set left-padding to 0. `This piece of code' has to be written yet, I believe. However, I think it's a bad idea in general since it means that you have to run lilypond twice on a single snippet: the first time to find out whether there is more than a single line, and the second time to apply left-padding. The best solution is probably to add a new command line option `--default-left-padding' to lilypond-book (which is then used in the Makefile with value 0mm to override the default setting of 3mm), and adding a snippet option `left-padding' to the lilypond environments (within lilypond-book) to override the default left padding if necessary. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
On Mon, Dec 14, 2009 at 04:41:31PM +0100, David Kastrup wrote: > Then every example contains a violin clef but not other non-example > elements (like time signatures). However, this is not true for the time > signature example itself. And the clef example contains the treble clef > in its default size, but the bass clef in its clef-change size. True. I hardly think that's the worst thing about the "cheat sheet" page, but I'll definitely accept a patch that fixes this. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
On Mon, Dec 14, 2009 at 05:26:28PM +0100, Werner LEMBERG wrote: > > the table does not line up properly in the last column. This is > > because of additional white space _inside_ of the graphics (the > > cursor box is on the first graphical image, so one can see that > > indeed the graphics are responsible). > > This is normal, AFAIK. The lilypond-book option --left-padding > controls this; if not given, a default value of 3mm is used. Main > reason to use have a non-zero default is to take care of bar numbers > sticking out to the left. > > It's debatable, however, whether we should have that in the lilypond > documentation, given the vast amount of small snippets which consist > of a single line only. We have code that detects if the example is a single line; if so, it adds ragged-right=##t. That same piece of code could set left-padding to 0. No, I don't have a clue where this detection occurs; Joe added it in reponse to documentation requests a few years ago. Investigation and patches would be appreciated. :) Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some "Cheat cheet" nitpicks
> the table does not line up properly in the last column. This is > because of additional white space _inside_ of the graphics (the > cursor box is on the first graphical image, so one can see that > indeed the graphics are responsible). This is normal, AFAIK. The lilypond-book option --left-padding controls this; if not given, a default value of 3mm is used. Main reason to use have a non-zero default is to take care of bar numbers sticking out to the left. It's debatable, however, whether we should have that in the lilypond documentation, given the vast amount of small snippets which consist of a single line only. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Some "Cheat cheet" nitpicks
If you take a look at the following screen shot, you'll notice a few blemishes: <> First, the table does not line up properly in the last column. This is because of additional white space _inside_ of the graphics (the cursor box is on the first graphical image, so one can see that indeed the graphics are responsible). Then every example contains a violin clef but not other non-example elements (like time signatures). However, this is not true for the time signature example itself. And the clef example contains the treble clef in its default size, but the bass clef in its clef-change size. I _think_ that these effects would likely be visible in the HTML documentation as well. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
