Re: A few questions regarding markup
Carl Sorensen writes: > On 11/14/09 1:29 AM, "David Kastrup" wrote: > >> >> >> Ok, I am digging through harp-pedals.scm and looking at >> define-builtin-markup-command. >> >> Now from the definition of define-builtin-markup-command it looks to me >> like you can specify default properties and those are let to the >> specified default values (#f if unspecified) or the respective >> properties from the list. >> >> Now the harp-pedal command defines the property signature >> >> ((size 1.0) >>(harp-pedal-details) >>(thickness 0.5)) > > The property signature is a documentation-only convention. It has no > functionality except for producing documentation. Thanks, but wrong. Please look in the definition of define-builtin-markup-command. The property signature symbols are let-bound to the respective property values (or the default if none are there) within the body of define-builtin-markup-command. Here is the respective part from the macro that does it: `(define-public (,command-name ,@args) ,documentation (let ,(filter identity (map (lambda (prop-spec) (if (pair? prop-spec) (let ((prop (car prop-spec)) (default-value (if (null? (cdr prop-spec)) #f (cadr prop-spec))) (props (cadr args))) `(,prop (chain-assoc-get ',prop ,props ,default-value))) #f)) properties)) ,@real-body))) If indeed no active Lilypond developer _realises_ that this is the case, then the respective code should just be thrown out instead of wasting performance with property lookups that are ignored. I find it unfortunate that the arguments of define-builtin-markup-command and define-markup-command diverge in this manner, since converting a markup routine to an internal one _in style_ should just entail adding the documentation, not restructuring the code. The idea to have properties automatically defaulted and looked up at the top is nice, however. But if the lookup results are needed in a different scope (as is the case with harp pedals) or only conditionally in some code paths, the scheme gets less workable. And if nobody realises what the functionality actually does, this does not help. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few questions regarding markup
On 11/14/09 1:29 AM, "David Kastrup" wrote: > > > Ok, I am digging through harp-pedals.scm and looking at > define-builtin-markup-command. > > Now from the definition of define-builtin-markup-command it looks to me > like you can specify default properties and those are let to the > specified default values (#f if unspecified) or the respective > properties from the list. > > Now the harp-pedal command defines the property signature > > ((size 1.0) >(harp-pedal-details) >(thickness 0.5)) The property signature is a documentation-only convention. It has no functionality except for producing documentation. To the extent that it is inconsistent with the defaults in chain-assoc-get, it is in error. > > So far, so fine. It > then calls make-harp-pedal without passing it those let-bound > variables. As far as I understand Scheme and its closures, this means > that the defaults specified in this manner are ignored. Yes -- the defaults aren't really specified with the property signature; they're simply documented. > > make-harp-pedal then starts off with > > (let* ((size (chain-assoc-get 'size props 1.2)) > (details (chain-assoc-get 'harp-pedal-details props '())) > > Which looks rather like defaulting to a size of 1.2 if none is > specified, conflicting with the documented default value which is > ignored. Yes, that is correct. > > That does not really make much sense. > > Is my understanding of the code correct so far? > > Now there are several possible remedies I can see. > > a) don't use chain-assoc-get in this manner, consistently. Instead pass > everything from the defined markup function into the helper function > explicitly, as extra arguments. This would involve fixing the current > definition of harp-pedal and its helpers. The ultimate solution would > be to never even pass props on, but rather only the defaults picked from > it. Advantage would be that the documentation would be consistent with > declaring which values are possibly used with which defaults, no white > lies permitted. Disadvantage is maintenance of the passed argument list > with possibly many values, from all defined markup commands. But all the default values can be overridden by properties that are set elsewhere in the code. And we don't want to add defaults to the call, in case there are values added to props. chain-assoc-get is, in my opinion, a very nice mechanism for handling default values and keeping the code from breaking/segfaulting if the props list gets messed up. I would not be in favor of modifying the chain-assoc-get calls. > > b) fixup props also by let-binding, binding the default values to the > end of the property chain. This requires a copy of the property chain. > Consing overhead. Disadvantage is that access to the fixed property > chain can access values not declared in the documentation. I guess this is possible, but I don't really like the overhead. > > c) fixup props by let-binding, binding any undefined default values to > the start of the property chain. No copying overhead, but lookup > overhead. But could probably be combined with the lookup that happens > anyway for let-binding the default values. I'd have to see a sample of this to see what it might look like. > > d) make the duplicate default values consistent but don't touch the > code. This is my recommended step right now. > > e) redesign everything > > Option d) appears simplest but most error-prone. > > Other than that, I think one should go for a). Likely cleanest. > Disadvantage is that that makes the code diverge from what one would use > for define-markup-command rather than define-builtin-markup-command. > I strongly disagree with going for a). In my opinion there are two possible fixes. The simple is option d). The complex is to modify the documentation generator so that instead of reading values from the documented properties, it scans through the actual markup function code looking for chain-assoc-get calls on props and reading the key and the default value from the code. I think this is correct because it modifies the documentation code to be consistent with the functional code, rather than modifying the functional code to be consistent with the documentation code. The current documentation code is a bit of a hack, as you correctly observe, but it works. > So one should probably add this default-let behavior to the > define-markup-command macro as well. We already have a fine way of defining defaults for properties, so I don't think we need to add the documentation overhead to define-markup-command. I appreciate your look at this system with new eyes. I think there's something that could be done here. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Allow nested properties to be set with \tweak
2009/11/14 Han-Wen Nienhuys : > Shouldnt this be something recursive? I thought properties could nest > beyond one level. I don't see how it can be, unless you mean building the property alist given the list of symbols and a value to set. The problem with the current behaviour is that it's only possible to use \tweak on something like 'bound-details if you pass the whole alist, e.g., c-\tweak #'bound-details #'(...all subproperties...) \glissando Since the current value of 'bound-details isn't accessible at this stage it's not possible just to override one subproperty: it clears out all the default values. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Language and \inlcude
On Sun, Nov 15, 2009 at 11:24 AM, Ichiro Watanabe wrote: > Would it be possible to promote > \include "english.ly" > to a first-class command that is allowed in safe mode? Something like > \language "english" Thanks, this is a very good idea and we've been discussing such a change, but I had never added it to the tracker -- which I have now. http://code.google.com/p/lilypond/issues/detail?id=903 Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: My "make doc" is broken
> For info I had the needed packages provided by a "sudo apt-get
> build-dep lilypond" command with the only difference that
> I used texi2html-1.82 (compiled from sources) instead of 1.78 (in
> Ubuntu's repository), as recommended when running ./autogen.sh.
did not know that (not in CG): I did the sudo apt-get build-dep
lilypond. I have already tex2thml 1.82 (installed manually).
redone git pull, make clean, make all, make doc.
After a few hours, I get the same error (see below). It is true that
the required file (examples/tab-example-small*) does not exists but
why?
Frédéric
cd ./out-www; texi2pdf -I ./out-www -I
/home/bronf/lilypond/Documentation/out -I
/home/bronf/lilypond/Documentation -I
/home/bronf/lilypond/Documentation --batch general.texi
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
...
(./general.texi (/home/bronf/lilypond/tex/texinfo.tex
Loading texinfo [version 2009-08-14.15]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, environments,
defuns, macros, cross references, insertions,
(/usr/share/texmf-texlive/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 <23 July 2005>
) localization, formatting, and turning on texinfo input format.)
(./general.aux) (/home/bronf/lilypond/tex/txi-en.tex)
(/home/bronf/lilypond/Documentation/macros.itexi (./version.itexi)
(/home/bronf/lilypond/Documentation/common-macros.itexi)) [1{/var/lib/texmf/fon
ts/map/pdftex/updmap/pdftex.map}] <./pictures/double-lily-modified3.png>
(/home/bronf/lilypond/Documentation/general/news-front.itexi)
l.111: Undefined cross reference `old news-snt'.
l.111: Undefined cross reference `old news-snt'.
...
(./general.toc) (./general.toc)
(/home/bronf/lilypond/Documentation/general/introduction.itexi (Introduction) <
./pictures/flat-design.png (PNG copy)>
l.41: Undefined cross reference `freedom-snt'.
l.41: Undefined cross reference `freedom-snt'.
...
/home/bronf/lilypond/Documentation/general/introduction.itexi:0: Could not find
image file examples/tab-example-small for pdf.
@dopdfimage ...uld not find image file #1 for pdf}
@else @gdef @pdfimgext {PD...
@imagexxx ...ndent @ifpdf @dopdfimage {#1}{#2}{#3}
@else @setbox 0 = @hbox
{...@...
@image ...true @fi @else @imagexxx #1,@finish
@fi
l.12 ...le}-small,,,@xeatspaces {tab-example},png}
@scanmacro ...ceisspace @scantokens {...@endinput }
@endgroup
@macnamexxx ...xeatspaces {#1},png}...@end ifinfo}
@egroup
l.283 @exampleImage{tab-example}
!pdfTeX error: pdfetex (file examples/tab-example-small.): cannot find image fi
le
==> Fatal error occurred, no output PDF file produced!
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
make[2]: *** [out-www/general.pdf] Error 1
...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] functional-or returned #f for (functional-or #f #t #f). Fixed.
On 2009-11-15, David Kastrup wrote: > > --- > scm/lily-library.scm |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/scm/lily-library.scm b/scm/lily-library.scm > index 4a7973a..5853744 100644 > --- a/scm/lily-library.scm > +++ b/scm/lily-library.scm > @@ -273,7 +273,7 @@ > (define (functional-or . rest) >(if (pair? rest) >(or (car rest) > -(apply functional-and (cdr rest))) > +(apply functional-or (cdr rest))) >#f)) > > (define (functional-and . rest) Thanks, pushed. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] harp-pedal: make documented default 'size match implemented value
On 2009-11-15, David Kastrup wrote:
>
> ---
> scm/harp-pedals.scm |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scm/harp-pedals.scm b/scm/harp-pedals.scm
> index 876e392..f476783 100644
> --- a/scm/harp-pedals.scm
> +++ b/scm/harp-pedals.scm
> @@ -8,7 +8,7 @@
>
> (define-builtin-markup-command (harp-pedal layout props definition-string)
> (string?)
>instrument-specific-markup ; markup type for the documentation!
> - ((size 1.0)
> + ((size 1.2)
> (harp-pedal-details)
> (thickness 0.5))
>"Make a harp pedal diagram.
> @@ -66,7 +66,7 @@ divider) and @code{space-after-divider} (box spacing after
> the divider).
> ;;
> ;; (define-builtin-markup-command (harp-pedal-verbose layout props
> pedal-list) (list?)
> ;; instrument-specific-markup ; markup type
> -;; ((size 1.0)
> +;; ((size 1.2)
> ;;(harp-pedal-details)
> ;;(thickness 0.5))
> ;; "Make a harp pedal diagram containing the directions indicated in
> @var{pedal-list}."
Thanks, pushed.
-Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few questions regarding markup
Reinhold Kainhofer writes: > Am Sonntag, 15. November 2009 20:16:51 schrieb Nicolas Sceaux: >> Le 14 nov. 2009 à 09:29, David Kastrup a écrit : >> > Now the harp-pedal command defines the property signature >> > >> > ((size 1.0) >> > (harp-pedal-details) >> > (thickness 0.5)) >> > >> > So far, so fine. It >> > then calls make-harp-pedal without passing it those let-bound >> > variables. As far as I understand Scheme and its closures, this means >> > that the defaults specified in this manner are ignored. > > I wrote that code, and I have to admit that I don't understand this part at > all. I simply copied code from somewhere else and tweaked it so that it > worked > >> > make-harp-pedal then starts off with >> > >> > (let* ((size (chain-assoc-get 'size props 1.2)) >> >(details (chain-assoc-get 'harp-pedal-details props '())) >> >> Just remove the useless binding of `size' in the let form, >> and give the appropriate default in the property argument. > > Ah, interesting... So, in the make-harp-pedal function, the properties > defined in the harp-pedal markup function are available? Not if make-harp-pedal is not defined in the scope of the harp-pedal markup function. If I understand Scheme correctly. size is automatically let-bound to the correct value (default if not specified in properties) within the markup function defined with define-builtin-markup-command. > That's cool! Yes and no: the coolness does not inherit into called functions. My personal preference with the harp pedals would be to throw out make-harp-pedal altogether (it is just used as a shared helper function for an outcommented different definition which should likely just get removed altogether). But I think I covered most issues in my first post anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few questions regarding markup
Am Sonntag, 15. November 2009 20:16:51 schrieb Nicolas Sceaux: > Le 14 nov. 2009 à 09:29, David Kastrup a écrit : > > Now the harp-pedal command defines the property signature > > > > ((size 1.0) > > (harp-pedal-details) > > (thickness 0.5)) > > > > So far, so fine. It > > then calls make-harp-pedal without passing it those let-bound > > variables. As far as I understand Scheme and its closures, this means > > that the defaults specified in this manner are ignored. I wrote that code, and I have to admit that I don't understand this part at all. I simply copied code from somewhere else and tweaked it so that it worked > > make-harp-pedal then starts off with > > > > (let* ((size (chain-assoc-get 'size props 1.2)) > >(details (chain-assoc-get 'harp-pedal-details props '())) > > Just remove the useless binding of `size' in the let form, > and give the appropriate default in the property argument. Ah, interesting... So, in the make-harp-pedal function, the properties defined in the harp-pedal markup function are available? That's cool! Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few questions regarding markup
Le 14 nov. 2009 à 09:29, David Kastrup a écrit : > Now the harp-pedal command defines the property signature > > ((size 1.0) > (harp-pedal-details) > (thickness 0.5)) > > So far, so fine. It > then calls make-harp-pedal without passing it those let-bound > variables. As far as I understand Scheme and its closures, this means > that the defaults specified in this manner are ignored. > > make-harp-pedal then starts off with > > (let* ((size (chain-assoc-get 'size props 1.2)) >(details (chain-assoc-get 'harp-pedal-details props '())) > Just remove the useless binding of `size' in the let form, and give the appropriate default in the property argument. Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code formatter
Graham Percival writes: > On Fri, Nov 13, 2009 at 11:23:55AM -0700, Carl Sorensen wrote: >> Jan believes that code formatting standards should be no more restrictive >> than the GNU standards. > > By the way, if somebody has a compelling argument why we should > differ from the GNU standards, I'm willing to go up against Jan. > But before I do that, I need to be *convinced* that the > alternative is right. > >> This same issue is relevant in the discussion about going to Lua. >> Lua is not GNU software. It does use the MIT license, which is GPL >> compatible, according to the FSF. > > That's not an issue. The issue is that rewriting lilypond would take > thousands of hours of work, and nobody wants to do that work. Yes. > Besides, I really thought that the Lua-talk was a joke. It was a quite serious hypothetical. "If xxx were to be started from scratch" is rarely an option. If you want to, take it as "if only Lilypond had been written using Lua". Because there are quite a number of compelling advantages, not least of all performance. > Some people at my university want to rewrite lilypond in Haskell -- > again, they weren't serious about it. The notion was just a "hey, > wouldn't it be cool if...?" thing. This hypothetical was not "wouldn't it be cool", but rather "wouldn't it be nice". The Haskell rewrite sounds like potentially squeezing the source code size by a factor of 2, squeezing the developer pond by a factor of 20. The Lua rewrite would likely squeeze the source code by a similar size and double the developer pool. Because one simple language that can be efficiently used for _everything_ sure beats two complex languages that can only be used in tandem for doing everything, in particular when we are talking about efficiency. And that's before we even take a look _which_ languages we are talking about. > The core developers have a better estimate of the enormous amount of > work it would take to rewrite lilypond in lua, java, or whatever was > being proposed. Also possibly rewriting it to avoid using various > libraries... so maybe re-implementing fontforge, pango, etc etc etc. Reimplementation libraries is not an option, I think. Lua is pretty good for integrating libraries, and quite a number of external bindings exist. But the bottom line of course remains: any porting requires developers. Another option would be to pull in Lua as an _additional_ extension language, then move existing code in pieces to Lua. That's the approach that the Context/LuaTeX development team has taken. The process has a large "evolutionary rather than planned" taste to it. But it shows intermediate results that keep the motivation going. Again: I am not proposing to actually do this. It was just a "wouldn't it be nice". Not cool, nice. Because diving into the current system is to a large degree fighting with the implementation rather than the implemented system. For anybody who thinks that I am fantasizing because of some arbitrary language preferences, I recommend reading through the "Programming in Lua" manual for which slightly older versions are completely online. Very worthwhile, for programmers used to _any_ language. > If anybody has a CONCRETE proposal on how to make things easier > for non-Linux developers... along with the manpower required to > IMPLEMENT those proposals... I'm more than willing to listen. If > their proposal includes a relatively minor amount of work from the > core developers, I'm willing to do it. If the proposal boils down > to "hey, how about you guys rewrite it in visual basic, while I > continue to complain about bugs and the lack of a wiki"... then > they won't get anywhere. Sure. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: My "make doc" is broken
Le Sat, 14 Nov 2009 19:57:05 +0100, Frédéric Bron a écrit : > Since I upgraded ubuntu to 9.10, make doc does not work anymore but > why? Is it because of the ubuntu upgrade or because of git pull? Hi Frédéric. I have Ubuntu 9.10 too and I tried to compile (after the first commit, the first compiling)... And to my great surprise it succeeds! > !pdfTeX error: pdfetex (file examples/tab-example-small.): cannot > find image fi le > ==> Fatal error occurred, no output PDF file produced! > /usr/bin/texi2dvi: pdfetex exited with bad status, quitting. > make[2]: *** [out-www/general.pdf] Error 1 > make[2]: Leaving directory `/home/bronf/lilypond/Documentation' > make[1]: *** [WWW-1] Error 2 > make[1]: Leaving directory `/home/bronf/lilypond' > make: *** [doc-stage-1] Erreur 2 For info I had the needed packages provided by a "sudo apt-get build-dep lilypond" command with the only difference that I used texi2html-1.82 (compiled from sources) instead of 1.78 (in Ubuntu's repository), as recommended when running ./autogen.sh. Since your error seems related to pdfetex it may be relevant to add that I also have texlive-full that is installed on my computer. Sincerely, Xavier -- Xavier Scheuer signature.asc Description: PGP signature ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue #768 - chord repetition shortcut: patch for review
Kieren MacMillan writes:
> Hi David,
>
>> OTOH, something like
>> { 8-. -^ }*2
>> is not doable with the q approach.
>
> Of course it is:
> \repeat unfold 2 { 8-. q-^ }
Well, not exactly a shortcut for saving typing.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] functional-or returned #f for (functional-or #f #t #f). Fixed.
--- scm/lily-library.scm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scm/lily-library.scm b/scm/lily-library.scm index 4a7973a..5853744 100644 --- a/scm/lily-library.scm +++ b/scm/lily-library.scm @@ -273,7 +273,7 @@ (define (functional-or . rest) (if (pair? rest) (or (car rest) - (apply functional-and (cdr rest))) + (apply functional-or (cdr rest))) #f)) (define (functional-and . rest) -- 1.6.5.1.36.g54298 -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
A few questions regarding markup
Ok, I am digging through harp-pedals.scm and looking at define-builtin-markup-command. Now from the definition of define-builtin-markup-command it looks to me like you can specify default properties and those are let to the specified default values (#f if unspecified) or the respective properties from the list. Now the harp-pedal command defines the property signature ((size 1.0) (harp-pedal-details) (thickness 0.5)) So far, so fine. It then calls make-harp-pedal without passing it those let-bound variables. As far as I understand Scheme and its closures, this means that the defaults specified in this manner are ignored. make-harp-pedal then starts off with (let* ((size (chain-assoc-get 'size props 1.2)) (details (chain-assoc-get 'harp-pedal-details props '())) Which looks rather like defaulting to a size of 1.2 if none is specified, conflicting with the documented default value which is ignored. That does not really make much sense. Is my understanding of the code correct so far? Now there are several possible remedies I can see. a) don't use chain-assoc-get in this manner, consistently. Instead pass everything from the defined markup function into the helper function explicitly, as extra arguments. This would involve fixing the current definition of harp-pedal and its helpers. The ultimate solution would be to never even pass props on, but rather only the defaults picked from it. Advantage would be that the documentation would be consistent with declaring which values are possibly used with which defaults, no white lies permitted. Disadvantage is maintenance of the passed argument list with possibly many values, from all defined markup commands. b) fixup props also by let-binding, binding the default values to the end of the property chain. This requires a copy of the property chain. Consing overhead. Disadvantage is that access to the fixed property chain can access values not declared in the documentation. c) fixup props by let-binding, binding any undefined default values to the start of the property chain. No copying overhead, but lookup overhead. But could probably be combined with the lookup that happens anyway for let-binding the default values. d) make the duplicate default values consistent but don't touch the code. e) redesign everything Option d) appears simplest but most error-prone. Other than that, I think one should go for a). Likely cleanest. Disadvantage is that that makes the code diverge from what one would use for define-markup-command rather than define-builtin-markup-command. So one should probably add this default-let behavior to the define-markup-command macro as well. Do I overlook something important? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] harp-pedal: make documented default 'size match implemented value
---
scm/harp-pedals.scm |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scm/harp-pedals.scm b/scm/harp-pedals.scm
index 876e392..f476783 100644
--- a/scm/harp-pedals.scm
+++ b/scm/harp-pedals.scm
@@ -8,7 +8,7 @@
(define-builtin-markup-command (harp-pedal layout props definition-string)
(string?)
instrument-specific-markup ; markup type for the documentation!
- ((size 1.0)
+ ((size 1.2)
(harp-pedal-details)
(thickness 0.5))
"Make a harp pedal diagram.
@@ -66,7 +66,7 @@ divider) and @code{space-after-divider} (box spacing after
the divider).
;;
;; (define-builtin-markup-command (harp-pedal-verbose layout props pedal-list)
(list?)
;; instrument-specific-markup ; markup type
-;; ((size 1.0)
+;; ((size 1.2)
;;(harp-pedal-details)
;;(thickness 0.5))
;; "Make a harp pedal diagram containing the directions indicated in
@var{pedal-list}."
--
1.6.5.1.36.g54298
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing of lyrics
Christian Hitz wrote:
Hi,
the new vertical spacing is evaluating the skyline of the lyrics lines for
spacing. This leads to situations with a very uneven look, as the example
below shows. IMHO the tallest glyph in the used font should be used to
derive the height of the lyrics line.
This very much depends on what you engrave. If you're making larger
scores with many staves per system, vertical space is pretty much more
important than everything else, and it's common practice to fit the
lyrics as tight to the staves and as close together as possible.
If you want to have a more equal spacing, try modifying the LyricText
#'minimum-Y-extent or (not sure if this works out) the new
Lyrics.VerticalAxisGroup #'inter-loose-line-spacing [1]. E.g., in your
example, adding
\layout {
\context {
\Lyrics
\override LyricText #'minimum-Y-extent = #'(-1.5 . 1.5)
}
}
to the score seems to solve the problem for me.
There are simple "workarounds" to simulate the
one-box-to-rule-all-glyphs-approach, but if you decide to drop the
skyline algorithm, it's nearly impossible to automatically achieve the
tighter setting.
Cheers,
Alexander
[1] http://lists.gnu.org/archive/html/lilypond-user/2009-10/msg00215.html
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Vertical spacing of lyrics
Hi,
the new vertical spacing is evaluating the skyline of the lyrics lines for
spacing. This leads to situations with a very uneven look, as the example
below shows. IMHO the tallest glyph in the used font should be used to
derive the height of the lyrics line.
Regards,
Christian
\version "2.13.7"
\score {
<<
\context Voice = "I" \relative c' {
c4 d e f
}
\new Lyrics \lyricsto "I" \lyricmode { g a a a }
\new Lyrics \lyricsto "I" \lyricmode { t a a a }
\new Lyrics \lyricsto "I" \lyricmode { a a a a }
>>
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Language and \inlcude
Hi there, The --safe flag disallows \include directives. I'm sure there are very good reasons for it. However, this seems to unnecessarily prevent users who need to compile their source in safe mode from choosing one of the supported languages for notes and accidentals. Would it be possible to promote \include "english.ly" to a first-class command that is allowed in safe mode? Something like \language "english" If it's not too hard I'm happy to look into it and offer a patch. Thank you and regards ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
