Re: Alternative music font
On 2009-10-28, Patrick McCarty wrote: > On 2009-10-28, Neil Puttock wrote: > > 2009/10/20 Neil Puttock : > > > 2009/10/20 Patrick McCarty : > > > > > >> This should be fixed now in latest git. > > > > > > Works for me. > > > > I guess I spoke a bit prematurely here, since the fix you pushed > > always loads aybabtu, even when font-defaults has been redefined. > > I've tried amending the code to allow switching to gonville-brace, but > > it still doesn't work properly. It seems that select_font () always > > selects the default font for fetaBraces (or the first entry in the > > node). > > Changing font-defaults to > > #(define font-defaults > '((font-family . gonville) (font-encoding . fetaBraces))) > > only loads "gonville-brace", and not "gonville". So we need to > override both encodings. I'm not entirely sure how to do that, but > I'll look at it shortly. This isn't entirely true, now that I look at it again. In this case, gonville, gonville-brace, and aybabtu are all loaded, but aybabtu is used for the braces. Also, I checked \numericTimeSignature, and that's broken with gonville. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fwd: Tracker 836:]
On 10/28/09 4:39 PM, "Neil Puttock" wrote: > 2009/10/28 Ian Hulin : >> I managed to get set up and put the patch for Tracker 836 on as tracker >> 141076. > > This issue doesn't exist; did you delete it after uploading? > >> Message: >> ly/engraver-init.ly in not part of this patch and I didn't change it. > > You should apply your patch to master, then you won't get previous > commits showing up. > > The way I normally do it is as follows: > > -) create a patch which you want to upload > -) reset master branch (if necessary, pull any changes) > -) create a new branch for uploading to Rietveld > -) checkout new branch and apply patch > -) upload using `git cl upload origin' > >> http://codereview.appspot.com/141076/diff/2001/2006#newcode144 >> Line 144: (ly:parser-lookup parser 'book-filename >> Coding >> (book-filename >> here using the local variable caused an "invalid type" error from Scheme > > Please read my suggestion again (and Carl's explanation). Neil's suggestion did *not* have a parenthesis before the book-filename (book-filename) tries to evaluate a procedure book-filename and return the results. But book-filename isn't a procedure; hence the invalid type. book-filename just returns the value of the variable book-filename. Unlike in most languages, in Scheme you can't insert unnecessary parentheses in expressions; every parenthesis is significant. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Paper default margins
2009/10/28 Michael Käppler : > Okay. I hadn't thought about this. Fixed now. I only noticed it myself yesterday for reasons which should become clear if you check out the attached PNG. ;) Thanks for all the work you've done on this patch. I've just pushed it to master, so we can move on to the documentation. Regards, Neil <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative music font
On 2009-10-28, Neil Puttock wrote: > 2009/10/20 Neil Puttock : > > 2009/10/20 Patrick McCarty : > > > >> This should be fixed now in latest git. > > > > Works for me. > > I guess I spoke a bit prematurely here, since the fix you pushed > always loads aybabtu, even when font-defaults has been redefined. > I've tried amending the code to allow switching to gonville-brace, but > it still doesn't work properly. It seems that select_font () always > selects the default font for fetaBraces (or the first entry in the > node). Hi Neil, Thanks for noticing this. It's a rather complicated problem involving the font tree, as you pointed out. Changing font-defaults to #(define font-defaults '((font-family . gonville) (font-encoding . fetaBraces))) only loads "gonville-brace", and not "gonville". So we need to override both encodings. I'm not entirely sure how to do that, but I'll look at it shortly. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Tracker 836: Add facility to change output file-name for a \book block
Reviewers: Neil Puttock, Description: Tracker 836: Add facility to change output file-name for a \book block or to set a suffix to prevent multiple files over-writing each other during a compilation. This change allows user to to this via functions rather than having to do so by manipulating semi-documented parser variables. ignore .gitignore Please review this at http://codereview.appspot.com/144047 Affected files: M .gitignore M lily/parser.yy M ly/init.ly M ly/music-functions-init.ly M scm/lily-library.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative music font
2009/10/20 Neil Puttock : > 2009/10/20 Patrick McCarty : > >> This should be fixed now in latest git. > > Works for me. I guess I spoke a bit prematurely here, since the fix you pushed always loads aybabtu, even when font-defaults has been redefined. I've tried amending the code to allow switching to gonville-brace, but it still doesn't work properly. It seems that select_font () always selects the default font for fetaBraces (or the first entry in the node). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NEWS/changes entry for font switching
2009/10/26 Graham Percival : > Could we get an entry in Documentation/changes.tely about the font > switching? I guess we can't show an actual example of it working > (unless we make the new font required for compiling lilypond), but it > would be nice to have a bullet point about this, at least. I've moved the news entry to the top of the list, though on second thoughts it might've been better to leave it at the bottom until the remaining issues surrounding font switching are resolved. :) Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Fwd: Tracker 836:]
2009/10/28 Ian Hulin : > I managed to get set up and put the patch for Tracker 836 on as tracker > 141076. This issue doesn't exist; did you delete it after uploading? > Message: > ly/engraver-init.ly in not part of this patch and I didn't change it. You should apply your patch to master, then you won't get previous commits showing up. The way I normally do it is as follows: -) create a patch which you want to upload -) reset master branch (if necessary, pull any changes) -) create a new branch for uploading to Rietveld -) checkout new branch and apply patch -) upload using `git cl upload origin' > http://codereview.appspot.com/141076/diff/2001/2006#newcode144 > Line 144: (ly:parser-lookup parser 'book-filename > Coding > (book-filename > here using the local variable caused an "invalid type" error from Scheme Please read my suggestion again (and Carl's explanation). > http://codereview.appspot.com/141076/diff/2001/2006#newcode154 > Line 154: (define-public current-outfile-name #f) ; for use by > regression tests > current-outfile-name was added to help write a regression test for this > patch. Don't keep us in suspense then; add the regression test to the patch so we can review it. :) There's one more bug with output-count. I suspect this line (assoc-set! counter-alist output-suffix (1+ output-count))) needs tweaking: (assoc-set! counter-alist alist-key (1+ output-count))) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line breaks and broken beams
On Wed, 2009-10-28 at 21:54 +0100, Nicolas Sceaux wrote: > Le 28 oct. 09 à 08:37, David Kastrup a écrit : > > > Carl Sorensen writes: > > > >> Isn't the problem that beams create melismata in vocal music, and you > >> don't want to have a line break in the middle of a melisma? > > > > Baroque melisme can go on for lines. Do we have a way to discourage > > breaks but not completely disallow them? > > Absolutely. > Last week, while typesetting a chorus from Messiah with many beams > crossing > bar lines, I was about to report that as a bug. The lines were just > running out > of the page, which is a bug, period. > In an ideal world, LilyPond would try not to break beams, but not > forbid it. > In a "worst is better" world (that is, our world), breaking beams is > just not > forbidden. The line breaker has support for arbitrary penalties. If we had a thorough set of examples, we could try to find a penalty that works well. I'm reluctant, though, to just stick in an arbitrary penalty. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line breaks and broken beams
Le 28 oct. 09 à 08:37, David Kastrup a écrit : Carl Sorensen writes: Isn't the problem that beams create melismata in vocal music, and you don't want to have a line break in the middle of a melisma? Baroque melisme can go on for lines. Do we have a way to discourage breaks but not completely disallow them? Absolutely. Last week, while typesetting a chorus from Messiah with many beams crossing bar lines, I was about to report that as a bug. The lines were just running out of the page, which is a bug, period. In an ideal world, LilyPond would try not to break beams, but not forbid it. In a "worst is better" world (that is, our world), breaking beams is just not forbidden. Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[Fwd: Tracker 836:]
I managed to get set up and put the patch for Tracker 836 on as tracker 141076. However it looks like I had a bad mail address for this list in my git-cl configuration. Cheers, Ian --- Begin Message --- Reviewers: , Message: ly/engraver-init.ly in not part of this patch and I didn't change it. http://codereview.appspot.com/141076/diff/2001/2003 File ly/engraver-init.ly (left): http://codereview.appspot.com/141076/diff/2001/2003#oldcode353 Line 353: \consists "Bar_engraver" This file and this change are not part of the changes in the patch-set on my local repo. Ian Hulin. http://codereview.appspot.com/141076/diff/2001/2006 File scm/lily-library.scm (right): http://codereview.appspot.com/141076/diff/2001/2006#newcode144 Line 144: (ly:parser-lookup parser 'book-filename Coding (book-filename here using the local variable caused an "invalid type" error from Scheme http://codereview.appspot.com/141076/diff/2001/2006#newcode151 Line 151: (ly:parser-lookup parser 'book-output-suffix) Coding (book-output-suffix) here for the the clause of the if statement - using the local variable - caused an "invalid type" error from Scheme. http://codereview.appspot.com/141076/diff/2001/2006#newcode154 Line 154: (define-public current-outfile-name #f) ; for use by regression tests current-outfile-name was added to help write a regression test for this patch. Description: Tracker 836: Add facility to change output file-name for a \book block or to set a suffix to prevent multiple files over-writing each other during a compilation. This change allows user to to this via functions rather than having to do so so by manipulating semi-documented parser variables. Merge branch 'master' of git://git.sv.gnu.org/lilypond Tracker 836: Add facility to change output file-name for a \book block or to set a suffix to prevent multiple files over-writing each other during a compilation. This change allows user to to this via functions rather than having to do so so by manipulating semi-documented parser variables. [PATCH] Add missing documentation strings in property-init.ly and music-functions-init.ly. Please review this at http://codereview.appspot.com/141076 Affected files: M lily/parser.yy M ly/engraver-init.ly M ly/init.ly M ly/music-functions-init.ly M scm/lily-library.scm __ This email has been scanned by Netintelligence http://www.netintelligence.com/email --- End Message --- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] [PATCH]: Tracker 836 - Allow output filename and output-suffix to be specified for a \book block
On 10/27/09 7:05 PM, "Neil Puttock" wrote:
> 2009/10/27 Carl Sorensen :
>
>> The patch looks good to me. Neil?
>
> Not bad, Ian, but you need to keep an eye on trailing spaces and indentation.
To try to save you time, I'm going to explain the indentation issues.
>
> +PARSER->lexer_->set_identifier (ly_symbol2scm
> ("book-output-suffix"), SCM_BOOL_F);
> +PARSER->lexer_->set_identifier (ly_symbol2scm
> ("book-filename"), SCM_BOOL_F);
>
> indentation
These lines are indented one column relative to the previous line.
>
> +bookOutputName =
> +#(define-music-function (parser location newfilename) (string?)
> +(_i "Direct output for the current book block to @var{newfilename}")
> +(set! book-filename newfilename)
> +(make-music 'SequentialMusic 'void #t))
> +
> +bookOutputSuffix =
> +#(define-music-function (parser location newsuffix) (string?)
> +(_i "Set the output filename suffix for the current book block to
> +...@var{newsuffix}")
> +(set! book-output-suffix newsuffix)
> +(make-music 'SequentialMusic 'void #t))
> +
(set! and (make-music should not be indented relative to the docstring.
Also, the docstring is probably indented too far.
> +%% why a function?
>
> indentation
>
> +(make-music 'SequentialMusic 'void #t))
>
> You could add a `make-void-music' function for this as it's used in
> quite a few places.
If you choose to do this, there should also be a convert-ly rule added to
make this substitution in the docs, regtests, input files, and snippets.
>
> +;; return any suffix value for output filename allowing for settings by
> +;; calls to \bookOutputName
>
> I'd document this inside the function as a string (ditto for
> get-current-suffix).
>
> +(define (get-current-filename parser)
> +(let* (
> +(book-filename (ly:parser-lookup parser 'book-filename)))
> +(if (not book-filename)
> +(ly:parser-output-name parser)
> +(ly:parser-lookup parser 'book-filename
>
> indentation
(let* should be aligned with the "d" or the "e" in "define"
(if should be aligned with the "l" or the "e" in let
(book-filename should not begin on a new line
(ly:parser-output and (ly:parser-lookup should be aligned with (not
>
> +(define (get-current-filename parser)
> +(let* (
> +(book-filename (ly:parser-lookup parser 'book-filename)))
>
> (let (book-filename (ly:parser-lookup parser 'book-filename)))
Only use let* if you have multiple variable declarations in the let, and if
later declarations need to use the result of an earlier declaration.
Otherwise use let. And keep the first declaration on the same line as the
let.
>
> +(ly:parser-lookup parser 'book-filename
>
> book-filename)))
You already had the result of (ly:parser-lookup parser 'book-filename),
so there's no need to do the call again.
>
> +(define (get-current-suffix parser)
> + (let* (
> +(book-output-suffix (ly:parser-lookup parser
> 'book-output-suffix)))
> +(if (string? book-output-suffix)
> +(ly:parser-lookup parser 'book-output-suffix)
> +(ly:parser-lookup parser 'output-suffix
>
> indentation
>
> + (let* (
> +(book-output-suffix (ly:parser-lookup parser
> 'book-output-suffix)))
>
> (let (book-output-suffix (ly:parser-lookup parser 'book-output-suffix)))
>
> +(ly:parser-lookup parser 'book-output-suffix)
>
> book-output-suffix
>
> +(define-public current-outfile-name #f) ; for use by regression tests
>
> I don't understand this; have you added it for use later?
>
> +(define (get-outfile-name parser)
> +;; user can now override the base file name, so we have to use
> +;; the file-name concatenated with any potential output-suffix value
> +;; as the key to out internal a-list
> + (let* (
> + (base-name (get-current-filename parser))
> + (output-suffix (get-current-suffix parser))
> + (alist-key (format "~a~a" base-name output-suffix))
> + (counter-alist (ly:parser-lookup parser 'counter-alist))
> + (output-count (assoc-get alist-key counter-alist 0))
> + (result base-name))
>
> indentation
first declaration on the same line as the let*, all others indented to
match.
In Scheme we *never* end a line with an open parenthesis.
A good discussion of Scheme indenting is found at
>
> + (let* (
> + (base-name (get-current-filename parser))
>
> (let* ((base-name (get-current-filename parser))
>
> The patch doesn't work due to the following gremlins:
>
> base (string-regexp-substitute
>
> base-name (string-regexp-substitute
>
> (outfile-name (get-outfile-name parser base)))
>
> (outfile-name (get-outfile-name parser)))
>
> BTW, have you installed git-cl yet? It would be much easier to review
> your patches using Rietveld.
Now that you're up and goin
Re: Paper default margins
Hi Neil,
Looks fine.
Good.
Sorry to be a pain, but there's one more thing I missed: all the
regtests which rely on default settings need to reset the default
paper size, otherwise the line-width setting from the lilypond-book
preamble messes up the spacing.
Okay. I hadn't thought about this. Fixed now.
Cheers,
Michael
>From 99e7ed230c22109e7c93ff26dcbbcd26a76a5539 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sat, 12 Sep 2009 21:55:17 +0200
Subject: [PATCH] Let default margins depend on paper size.
* Make indent and short-indent defaults accessible in paper-defaults-init.ly
* Default margins apply to the paper size set by (ly:set-option 'paper-size)
and are linearly scaled for other paper sizes
* Modify input/regression/page-turn-page-breaking-auto-first-page.ly to work
with the new margin sizes
---
.../page-turn-page-breaking-auto-first-page.ly |4 +-
input/regression/paper-default-margins-a6.ly | 24 +++
input/regression/paper-default-margins-def.ly | 25
input/regression/paper-margins-consistency.ly |4 +-
input/regression/paper-margins-left-margin.ly |5 +-
input/regression/paper-margins-line-width.ly |4 +-
input/regression/paper-margins-no-checks.ly|4 +-
input/regression/paper-margins-overrun.ly |4 +-
input/regression/paper-margins-right-margin.ly |5 +-
input/regression/paper-margins.ly |8 ++-
lily/output-def.cc |4 +-
ly/paper-defaults-init.ly | 14 +++-
scm/lily-library.scm | 37 +---
scm/paper.scm | 66 +---
14 files changed, 176 insertions(+), 32 deletions(-)
create mode 100644 input/regression/paper-default-margins-a6.ly
create mode 100644 input/regression/paper-default-margins-def.ly
diff --git a/input/regression/page-turn-page-breaking-auto-first-page.ly b/input/regression/page-turn-page-breaking-auto-first-page.ly
index a9c3f31..0aa5570 100644
--- a/input/regression/page-turn-page-breaking-auto-first-page.ly
+++ b/input/regression/page-turn-page-breaking-auto-first-page.ly
@@ -17,6 +17,6 @@ number to 2 in order to avoid a bad page turn."
\book {
\score {
-{\repeat unfold 40 {a b c d}}
+\relative c' {\repeat unfold 60 {a b c d}}
}
-}
\ No newline at end of file
+}
diff --git a/input/regression/paper-default-margins-a6.ly b/input/regression/paper-default-margins-a6.ly
new file mode 100644
index 000..163a9bf
--- /dev/null
+++ b/input/regression/paper-default-margins-a6.ly
@@ -0,0 +1,24 @@
+\version "2.13.7"
+
+\header {
+ texidoc = "Default margin values are accessible in paper-defaults-init.ly
+and apply to the default paper size returned by (ly:get-option
+'paper-size). For other paper sizes, they are scaled linearly.
+This also affects head- and foot-separation as well as indents."
+}
+
+someNotes = \repeat unfold 30 { c4 d e f }
+
+\paper {
+ #(set-paper-size "a6")
+}
+
+\book {
+ \markup { For other paper sizes, margins are scaled accordingly. }
+ \score {
+\relative c' {
+ \someNotes
+}
+ }
+}
+
diff --git a/input/regression/paper-default-margins-def.ly b/input/regression/paper-default-margins-def.ly
new file mode 100644
index 000..8e9
--- /dev/null
+++ b/input/regression/paper-default-margins-def.ly
@@ -0,0 +1,25 @@
+\version "2.13.7"
+
+\header {
+ texidoc = "Default margin values are accessible in paper-defaults-init.ly
+and apply to the default paper size returned by (ly:get-option
+'paper-size). For other paper sizes, they are scaled linearly.
+This also affects head- and foot-separation as well as indents."
+}
+
+someNotes = \repeat unfold 30 { c4 d e f }
+
+\paper {
+ #(set-paper-size (ly:get-option 'paper-size))
+}
+
+\book {
+ \markup { If the paper size remains default, the margin values from
+paper-defaults-init.ly remain unchanged. }
+ \score {
+\relative c' {
+ \someNotes
+ \someNotes
+}
+ }
+}
diff --git a/input/regression/paper-margins-consistency.ly b/input/regression/paper-margins-consistency.ly
index 1b58b15..a3a7a40 100644
--- a/input/regression/paper-margins-consistency.ly
+++ b/input/regression/paper-margins-consistency.ly
@@ -16,4 +16,6 @@ someNotes = \relative c' { \repeat unfold 40 { c4 d e f } }
line-width = 100 \mm
}
-\score { \someNotes }
+\book {
+ \score { \someNotes }
+}
diff --git a/input/regression/paper-margins-left-margin.ly b/input/regression/paper-margins-left-margin.ly
index 5876196..23268e2 100644
--- a/input/regression/paper-margins-left-margin.ly
+++ b/input/regression/paper-margins-left-margin.ly
@@ -7,7 +7,10 @@
someNotes = \relative c' { \repeat unfold 40 { c4 d e f } }
\paper {
+ #(set-paper-size (ly:get-option 'paper-size))
left-margin = 40 \mm
}
-\score { \someNotes }
+\book {
+ \score { \someNotes }
+}
diff --git a/input
Re: line breaks and broken beams
Carl Sorensen writes: > Isn't the problem that beams create melismata in vocal music, and you > don't want to have a line break in the middle of a melisma? Baroque melisme can go on for lines. Do we have a way to discourage breaks but not completely disallow them? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line breaks and broken beams
> Isn't the problem that beams create melismata in vocal music, and > you don't want to have a line break in the middle of a melisma? Hmm. How often does this happen in real scores? I think that in most circumstances good (and thus flexible) spacing is much more important, and a user should locally disable such line breaks if there is ever a need for it. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
