Re: names of vertical spacing dimensions
On 10/13/10 2:40 PM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On 10/13/10 8:29 AM, "David Kastrup" wrote: >> >>> Carl Sorensen writes: >>> David Kastrup writes: > > > So my fear is that the new scheme is both strictly logical, and not > useful for specifying a coherent document layout. But the new scheme is just a restatement (renaming) of the current scheme. >>> >>> The renaming moves from a document design perspective (high level) to an >>> implementation one (low level). The use of those variables, however, is >>> inside of the layout block which is supposed to be a document design >>> specification. >>> >>> It also moves from an essentially one-dimensional parameter realm >>> "above-x, between-x, below-x, above-y, between-y, below-y" to a >>> two-dimensional matrix "between-x-x, between-x-y" ... >>> >>> This does not make it feasible to introduce further layout components >>> for spacing since the parameter growth becomes quadratic. >> >> So you think it's better to have vague names for a fundamentally >> quadratic spacing scheme, instead of having names that reflect the >> quadratic nature of the scheme? >> >> I don't think I agree with this position. > > Can we put the strawmen aside? > > The point is that we want a sane way of specifying document layout > parameters. The current naming scheme resembles that desire. The > current code not. Adapting the naming scheme to the deficiencies of the > code is going the wrong way in my opinion. As far as I can see, we have no plans to change the code. At least nobody is stepping forward to do so. It seems to me that the unspecified new code is a strawman. Accepting the limitation that we need to stay with the current code (which I believe to be a real limitation), it seems to me that we have three alternatives: 1) Leave the variable names and the docs as they currently are. This is a confusing situation; as near as I can tell Mark and Joe are the only two people in the world who completely understand the meaning of the current variables. I think this situation is untenable. 2) Leave the variable names as they currently are, but rewrite the docs to map the current "sort-of-sane" naming scheme to the quadratic code scheme. That is, we make a table for each spacing parameter, and explain the upper and lower bound of the spacing item. This keeps the naming scheme that resembles the desired behavior. It has the deficiency that the naming scheme does not match current behavior, and that we need to look at the docs to see what the current spacing terms really mean. 3) Change the variable names to reflect the current code. This has the disadvantage of codifying the current quadratic code in the naming scheme, but the advantage of having the names reflect the current behavior. Do you feel that these alternatives are strawmen? I'm not trying to make strawmen -- I'm trying to clarify what I think the current decision is. Are there other alternatives that you think are feasible? Once we have identified a set of alternatives to choose among, we can argue for what the best alternative is. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 Vocal music
Valentin Villenave wrote Wednesday, October 13, 2010 4:03 PM Hi Trevor, here's a minor patch for Vocal music. Nothing too extraordinary so far, I quite like what you've done! I've done about a third of the file, I plan to work on the rest later (though it may have to wait for a while :) Great! Thanks Valentine. As I'm still working on the file I took the liberty to push this for you. That way I could make sure we don't get any conflicts. I also pushed a supplementary which changed a couple of things further (or back). As I haven't yet dealt with any of the TODOs that remain could you please leave these in (unless you deal with them yourself. :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Carl Sorensen writes: > On 10/13/10 8:29 AM, "David Kastrup" wrote: > >> Carl Sorensen writes: >> >>> David Kastrup writes: >>> So my fear is that the new scheme is both strictly logical, and not useful for specifying a coherent document layout. >>> >>> But the new scheme is just a restatement (renaming) of the current >>> scheme. >> >> The renaming moves from a document design perspective (high level) to an >> implementation one (low level). The use of those variables, however, is >> inside of the layout block which is supposed to be a document design >> specification. >> >> It also moves from an essentially one-dimensional parameter realm >> "above-x, between-x, below-x, above-y, between-y, below-y" to a >> two-dimensional matrix "between-x-x, between-x-y" ... >> >> This does not make it feasible to introduce further layout components >> for spacing since the parameter growth becomes quadratic. > > So you think it's better to have vague names for a fundamentally > quadratic spacing scheme, instead of having names that reflect the > quadratic nature of the scheme? > > I don't think I agree with this position. Can we put the strawmen aside? The point is that we want a sane way of specifying document layout parameters. The current naming scheme resembles that desire. The current code not. Adapting the naming scheme to the deficiencies of the code is going the wrong way in my opinion. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert: properly escape some single-backslashes. (issue2401042)
On 2010/10/12 06:23:56, dak wrote: mailto:percival.music...@gmail.com writes: Is that not a documentation string rather than a regexp? And the top level meaning is a string meaning, anyway, not a regexp one? Yes, sorry. I now see that all these changes are in the documentation strings; their effect can be seen with convert-ly -s (I'm sure David already knew this, but I'm adding this info for anybody else looking at this) I've added \\*, which produces the output "\*Staff". It's the same output whether we have \* or \\*, but the latter seems to be better style. Thanks for catching that, and sorry it took me so long to realize what was happening. (if you're wondering, then yes, I made the initial patch without realizing that the _(...) bits were doc strings -- I just saw some weird output (due to \r), saw that other parts of that file used double backslashes, then added them) http://codereview.appspot.com/2401042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unable to find \layout command in doc
On Wed, Oct 13, 2010 at 7:24 PM, James wrote:
> \layout {
> interscoreline = 1
> ...
> }
git grep interscoreline
produces nothing obvious -- although notably, there are no lily/ or
scm/ files containing the string. I suspect that it was an old
property that was never removed.
Looking at gitk, the last time it appeared in a commit was
f16a28f4844c60d12aba9dd2b6c570579b4741a9
in 2004-04-11. But the file that it was in (in that commit) is no
longer in our source tree; it was removed in
fa9f7fa41cb803a0b5df62640ddd51238f581270
on 2004-10-23.
My best guess is that these should be removed, but I'd wait a few days
to see if anybody has anything else to say.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
unable to find \layout command in doc
Hello,
Can anyone tell me what
\layout {
interscoreline = 1
...
}
Does?
This is in a couple of Doc @LilyPond examples
However if I try to compile the example with this explicit line
commented in or out it does not seem to do anything in 2.13.35
Thank you for your time.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/13/10 8:29 AM, "David Kastrup" wrote: > Carl Sorensen writes: > >> David Kastrup writes: >>> >> >>> >>> So my fear is that the new scheme is both strictly logical, and not >>> useful for specifying a coherent document layout. >> >> But the new scheme is just a restatement (renaming) of the current >> scheme. > > The renaming moves from a document design perspective (high level) to an > implementation one (low level). The use of those variables, however, is > inside of the layout block which is supposed to be a document design > specification. > > It also moves from an essentially one-dimensional parameter realm > "above-x, between-x, below-x, above-y, between-y, below-y" to a > two-dimensional matrix "between-x-x, between-x-y" ... > > This does not make it feasible to introduce further layout components > for spacing since the parameter growth becomes quadratic. So you think it's better to have vague names for a fundamentally quadratic spacing scheme, instead of having names that reflect the quadratic nature of the scheme? I don't think I agree with this position. > >> Mark is not trying to *redo* the document layout algorithms; he's >> trying to *rename* the document layout properties. >> >> It appears that this effort has been helpful in at least two ways: (1) >> it is strictly logical, and (2) it has helped to identify some of the >> limitations of the document layout algorithms. >> >> Perhaps in the future these limitations can be resolved. > > If the naming scheme is tightly coupled with the limitations, any > resolution and/or improvement would require a complete overhaul of > existing layout specifications. > > So I don't see this change of the naming scheme as a change that > encourages further work on layout specification improvement. Clarifying the quadratic nature of the layout engine functionality certainly identifies the weakness of the current approach. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What is the beef with \longa stems?
> "Valentin" == Valentin Villenave writes: Valentin> On Sat, Oct 9, 2010 at 7:01 PM, David Kastrup wrote: >> why are longas treated specially? Valentin> Though I don't know how to answer that question, I suspect Valentin> the answer might help solve Valentin> http://code.google.com/p/lilypond/issues/detail?id=826 I suspect not, because the problem with that issue isn't that lilypond itself does something wrong with the longa tail, but because lilypond-book's treatment of the bounding box cuts off the tail. -- Laura (mailto:lcon...@laymusic.org) (617) 661-8097 233 Broadway, Cambridge, MA 02139 http://www.laymusic.org/ http://www.serpentpublications.org Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgment. J.R.R. Tolkein, _The Lord of the Rings_ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book safe mode
On 12/10/2010 11:59 PM, Carl Sorensen wrote:
This patch *looks* appropriate to me, but I haven't tested it, and I'm not
sure exactly how I would test it.
Pavel, do you have a test file that can work with the patch so we can
demonstrate it works properly?
Here's one, try running it through lilypond-book with and without the
--safe command-line option.
example.lytex:
\documentclass{article}
\begin{document}
\begin{lilypond}
#(system "echo you are running in unsafe mode!")
\relative c' { c b d a }
\end{lilypond}
\end{document}
--
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.1 Vocal music
On Fri, Oct 8, 2010 at 3:24 PM, Trevor Daniels wrote:
> I've just pushed a patch to NR 2.1 Vocal music which provides a first draft
> for the last of the blank sections marked TBC ("To Be Completed"). I
> believe it's now in a much better shape than it was, even though much of the
> chapter is in "first draft" state.
>
> Next up are the 19 TODOs, and I'd like to work through them before inviting
> a review of the whole chapter, although if you or anyone else wishes to
> comment on the work so far I'd be happy with that too.
Hi Trevor, here's a minor patch for Vocal music. Nothing too
extraordinary so far, I quite like what you've done!
I've done about a third of the file, I plan to work on the rest later
(though it may have to wait for a while :)
Regards,
Valentin
From 685906048df8bf6f772cf99d54cf4e2f4ad4548b Mon Sep 17 00:00:00 2001
From: Valentin Villenave
Date: Wed, 13 Oct 2010 16:59:12 +0200
Subject: [PATCH] Doc: NR 2.1 Vocal proofreading, take 1
---
Documentation/notation/vocal.itely | 68 ++-
1 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/Documentation/notation/vocal.itely b/Documentation/notation/vocal.itely
index ba57cda..5d5a188 100644
--- a/Documentation/notation/vocal.itely
+++ b/Documentation/notation/vocal.itely
@@ -124,7 +124,7 @@ as part of the syllable, a word is valid even if it ends with
In this example, the @co...@}} is included in the final syllable, so the
opening brace is not balanced and the input file will probably not
-compile. Instead, always place white space around braces:
+compile. Instead, braces should always be surrounded with white space:
@example
\lyricmode @{ lah lah lah @}
@@ -133,10 +133,10 @@ compile. Instead, always place white space around braces:
@cindex overrides in lyric mode
@funindex \override in \lyricmode
-Similarly, a period which follows an alphabetic sequence is included
-in that sequence in lyric mode. As a consequence, spaces must be
-inserted around the period in @code{\override} commands. Do
-...@emph{not} write
+Similarly, in lyric mode, a period will be included in the
+alphabetic sequence that it follows. As a consequence, spaces
+must be inserted around the period in @code{\override} commands.
+Do @emph{not} write
@example
\override Score.LyricText #'font-shape = #'italic
@@ -149,19 +149,20 @@ but instead use
\override Score . LyricText #'font-shape = #'italic
@end example
-To enter punctuation, lyrics with accented characters, characters
-from non-English languages, or special characters (such as the heart
-symbol or slanted quotes), simply insert the characters directly
-into the input file and save it with UTF-8 encoding. For more
-information, see @ref{Text encoding}.
+Punctuation, lyrics with accented characters, characters from
+non-English languages, or special characters (such as the heart
+symbol or slanted quotes), may simply be inserted directly
+into the input file, providing it is saved with UTF-8 encoding.
+For more information, see @ref{Text encoding}.
@lilypond[quote,verbatim]
\relative c' { e4 f e d e f e2 }
\addlyrics { He said: “Let my peo -- ple go.” }
@end lilypond
-To use normal quotes in lyrics, add a backslash before the
-quotes and place the whole syllable in quotes. For example,
+Normal quotes may be used in lyrics, but they have to be preceded
+with a backslash character and the whole syllable has to be
+enclosed between additional quotes. For example,
@lilypond[quote,verbatim]
\relative c' { \time 3/4 e4 e4. e8 d4 e d c2. }
@@ -205,7 +206,7 @@ Lyrics are printed by interpreting them in the context called
@code{Lyrics}, see @ref{Contexts explained}.
@example
-\new Lyrics \lyricmode @dots{}
+\new Lyrics \lyricmode @{ @dots{} @}
@end example
Lyrics can be aligned with melodies in two main ways:
@@ -293,7 +294,7 @@ automatically. This is achieved by combining the
melody and the lyrics with the @code{\lyricsto} expression
@example
-\new Lyrics \lyricsto @var{name} @dots{}
+\new Lyrics \lyricsto @var{name} @{ @dots{} @}
@end example
@noindent
@@ -307,9 +308,9 @@ then the lyrics are specified with @code{\lyricsto}. The command
@cindex \addlyrics
-The @code{\addlyrics} command is actually just a convenient way
-to write a more complicated LilyPond structure that sets up the
-lyrics.
+The @code{\addlyrics} command is actually just a convenient shortcut
+that can be used instead of having to set up the lyrics through a more
+complicated LilyPond structure.
@example
@{ MUSIC @}
@@ -333,7 +334,7 @@ Here is an example,
@end lilypond
More stanzas can be added by adding more
-...@code{\addlyrics} sections
+...@code{\addlyrics} sections:
@lilypond[ragged-right,verbatim,fragment,quote]
\time 3/4
@@ -344,16 +345,16 @@ More stanzas can be added by adding more
@end lilypond
The command @code{\addlyrics} cannot handle polyphony settings.
-For these cases you should use @code{\lyricsto} and
+For these case
Re: names of vertical spacing dimensions
Carl Sorensen writes: > David Kastrup writes: >> > >> >> So my fear is that the new scheme is both strictly logical, and not >> useful for specifying a coherent document layout. > > But the new scheme is just a restatement (renaming) of the current > scheme. The renaming moves from a document design perspective (high level) to an implementation one (low level). The use of those variables, however, is inside of the layout block which is supposed to be a document design specification. It also moves from an essentially one-dimensional parameter realm "above-x, between-x, below-x, above-y, between-y, below-y" to a two-dimensional matrix "between-x-x, between-x-y" ... This does not make it feasible to introduce further layout components for spacing since the parameter growth becomes quadratic. > Mark is not trying to *redo* the document layout algorithms; he's > trying to *rename* the document layout properties. > > It appears that this effort has been helpful in at least two ways: (1) > it is strictly logical, and (2) it has helped to identify some of the > limitations of the document layout algorithms. > > Perhaps in the future these limitations can be resolved. If the naming scheme is tightly coupled with the limitations, any resolution and/or improvement would require a complete overhaul of existing layout specifications. So I don't see this change of the naming scheme as a change that encourages further work on layout specification improvement. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
David Kastrup writes: > > > So my fear is that the new scheme is both strictly logical, and not > useful for specifying a coherent document layout. But the new scheme is just a restatement (renaming) of the current scheme. Mark is not trying to *redo* the document layout algorithms; he's trying to *rename* the document layout properties. It appears that this effort has been helpful in at least two ways: (1) it is strictly logical, and (2) it has helped to identify some of the limitations of the document layout algorithms. Perhaps in the future these limitations can be resolved. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
David Kastrup writes: > Mark Polesky writes: > >> David Kastrup wrote: >>> The main problem I see with that naming scheme is that it >>> does not reflect score sheet design, but the current >>> implementation. >>> >>> [...] >>> >>> So the proposed scheme ties something presented as document >>> spacing parameters into internal details of their >>> implementation. >> >> What would you propose to resolve that? > > I don't think I can propose something that would not move seriously into > GLISS domain. I don't see how one could sensibly manage this in a > natural, designer-intuitive way without a spacing system that offers > some sort of inheritance/fallback/hierarchy where you can get consistent > design by specifying few parameters, but have an option to specify more > specialized spacing independently/additionally and/or combine several > simultaneously triggered spacing parameters (i.e., taking their > maximum). > > The usual kind of document spacings fall into several kinds depending on > a hierachy level. If we say that a high hierarchy level corresponds to > low letters, low hierarchy to later letters, you may have > > inter-b-spacing for b-b > > before-b-spacing for c-b, d-b, e-b > > after-b-spacing for b-c, b-d, b-e > > But after-a-spacing for a-b. > > I am not sure that this sort of pure hierarchy is good enough, or > whether one needs some max/min scheme. It is also obvious that we have pagebreak possibilities associated: c-b, d-b, e-b are good breakpoints, b-c, b-d, b-e are awful breakpoints. It is also obvious that titles have higher priorities than the material they are titling, but some markup postscriptum to a score has _lower_ priority and should not be moved to a separate page. With regard to sane document design, conflating all forms of markup including titles is not going to lead to happy campers. We need different categories for markups with different functionality within the document. On the plus side: > The basic point is that for x different document element levels, we > get along more or less with a hierarchy and 3*x settings rather than > x^2 flat settings. So my fear is that the new scheme is both strictly logical, and not useful for specifying a coherent document layout. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
