Re: names of vertical spacing dimensions
Carl Sorensen c_soren...@byu.edu writes: On 10/13/10 2:40 PM, David Kastrup d...@gnu.org wrote: 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. Let me put it bluntly: the new scheme cements the decision to make markups and titles have the same spacing. A score followed by a title needs a solid amount of spacing and is an excellent position for a page break. A score followed by an editorial note * this may be f# instead needs a small amount of spacing and is an awfully bad position for a page break. If those cases are treated the same, it is a bug. We are now transplanting this bug from the code into the user interface where it will be rather cemented. I don't think that this is a sensible change for 2.14. -- 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 wrote Thursday, October 14, 2010 8:42 AM Carl Sorensen c_soren...@byu.edu writes: On 10/13/10 2:40 PM, David Kastrup d...@gnu.org wrote: 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. And certainly not before 2.14 is released. So the decision we have to make is what documentation we place in the 2.14 release. Let me put it bluntly: the new scheme cements the decision to make markups and titles have the same spacing. A score followed by a title needs a solid amount of spacing and is an excellent position for a page break. A score followed by an editorial note * this may be f# instead needs a small amount of spacing and is an awfully bad position for a page break. If those cases are treated the same, it is a bug. We are now transplanting this bug from the code into the user interface where it will be rather cemented. Although this is a good point, the problem is not as stark as this might suggest. There are many situations when writing LilyPond code when score-wide settings are inappropriate. This is just another. \override permits appropriate setting to be made at each point in the score. Variables or music functions can be used to make this less painful, e.g. \editorialNote could be defined to set the spacing parameters, set \noPageBreak, print the following markup and then revert the spacing parameters. I don't think that this is a sensible change for 2.14. I do. If at some time in the future the code is changed to recognise the distinction between a title and a footnote the names of the new spacing parameters would naturally follow the new naming pattern, although I think that change is unlikely to happen. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Trevor Daniels t.dani...@treda.co.uk writes: Although this is a good point, the problem is not as stark as this might suggest. There are many situations when writing LilyPond code when score-wide settings are inappropriate. This is just another. \override permits appropriate setting to be made at each point in the score. You don't know in advance where the pagebreaks are. And you don't get coherent document design if you have to place a bunch of manual parameters at every element. Variables or music functions can be used to make this less painful, e.g. \editorialNote could be defined to set the spacing parameters, set \noPageBreak, print the following markup and then revert the spacing parameters. I don't think that this is a sensible change for 2.14. I do. If at some time in the future the code is changed to recognise the distinction between a title and a footnote the names of the new spacing parameters would naturally follow the new naming pattern, although I think that change is unlikely to happen. And it is particularly unlikely to happen, because then we need to invent and maintain score-footnote-spacing, system-footnote-spacing, markup-footnote-spacing, footnote-footnote-spacing, footnote-score-spacing, footnote-markup-spacing, footnote-system-spacing, footnote-bottom-spacing, top-footnote-spacing and the associated page break penalties. In short, we are going down a road now where any user-visible improvement (for which the necessity is clear) will become increasingly painful to do for both developers and users. Since obviously I am alone with this opinion among the developers, I would suggest polling the users on the Lilypond user list whether they think this change a step in the right direction and desirable for 2.14. After all, they will be affected most. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Thu, Oct 14, 2010 at 9:42 AM, David Kastrup d...@gnu.org wrote: Let me put it bluntly: the new scheme cements the decision to make markups and titles have the same spacing. Greetings David, Quoting Mark (the man through whom the scandal cometh!) in the very first mail in this thread, Obviously not all markups are titles, but all titles are markups, right? A score followed by a title needs a solid amount of spacing and is an excellent position for a page break. A score followed by an editorial note * this may be f# instead needs a small amount of spacing and is an awfully bad position for a page break. If those cases are treated the same, it is a bug. We are now transplanting this bug from the code into the user interface where it will be rather cemented. Fair point. However I don't remember LilyPond having the ability to print footnotes (or proper endnotes, for that matter) *at all*. http://code.google.com/p/lilypond/issues/detail?id=737 Perhaps we're looking at this the wrong way, and that would be because markup is such a vague term in LilyPond. Basically, anything and everything can be done through markups (as Mark sensibly reminded us, even titles are actually markups). My point is, (speaking from a purely user-perspective, btw): your suggestion seems valid to me, but worded in a manner (differentiating titles and markups) that is a bit confusing -- since, from what I gather, what you're really trying to distinguish is official-markup-that's-defined-as-a-title and user-custom-markup-that-isn't-meant-to-be-regarded-as-an-official-title (well, I can understand the need for a single word :) As you said, we need to have different levels of hierarchy, and ideally, a scheme where we could add as many levels as we'd like. - Perhaps we could use HTML naming? h1-spacing, h2-spacing, h3-spacing, hn-spacing,... etc? (where h1 would be the book title, h2 the piece title, etc.) - Perhaps we could give a number as a parameter? markup-1-spacing, markup-2-spacing, etc. (and possibly add something like markup-unprioritized-spacing, like, for endnotes/footnotes) ? Anyway, as you said yourself, this may very well be a GLISS discussion already. (.2$, obviously) GLHF Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Valentin Villenave valen...@villenave.net writes: On Thu, Oct 14, 2010 at 9:42 AM, David Kastrup d...@gnu.org wrote: Let me put it bluntly: the new scheme cements the decision to make markups and titles have the same spacing. Greetings David, Quoting Mark (the man through whom the scandal cometh!) That is the wrong characterization of Mark's work. He is just dragging it into the light: as far as I understand, his patch does not change behavior as much as names. in the very first mail in this thread, Obviously not all markups are titles, but all titles are markups, right? All titles are markups, all markups should get the same spacing, sane document design. Pick any two. Fair point. However I don't remember LilyPond having the ability to print footnotes (or proper endnotes, for that matter) *at all*. http://code.google.com/p/lilypond/issues/detail?id=737 Lilypond has the ability to place markup below, above and between scores, and the documentation has ample examples. As you said, we need to have different levels of hierarchy, and ideally, a scheme where we could add as many levels as we'd like. Is that ideally in the meaning of not now or too cumbersome? Numbers would likely work reasonably well as a priority. We use them for things like outside-staff-spacing without too much of a complaint. Other than that, I don't see that one needs a formal grouping of layout elements. We've been getting along with one name per element reasonably well. Being able to specify topological relations instead of numerical priorities might be cooler, but we don't have that elsewhere. -- 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 wrote Thursday, October 14, 2010 10:05 AM Trevor Daniels t.dani...@treda.co.uk writes: Although this is a good point, the problem is not as stark as this might suggest. There are many situations when writing LilyPond code when score-wide settings are inappropriate. This is just another. \override permits appropriate setting to be made at each point in the score. You don't know in advance where the pagebreaks are. And you don't get coherent document design if you have to place a bunch of manual parameters at every element. Well IWBN if LilyPond could be clever enough to deal with all possible layouts perfectly, but a music score is much more complex that textual layout, and that is hard enough. There is also a fair amount of personal preference involved to, so I don't see how manual tweaks can be avoided. One possibility is to define a number of different settings which might give tight spacing, loose spacing, one suitable for a book of songs, one for a vocal score, etc. That might get users off to an acceptable start. Variables or music functions can be used to make this less painful, e.g. \editorialNote could be defined to set the spacing parameters, set \noPageBreak, print the following markup and then revert the spacing parameters. I don't think that this is a sensible change for 2.14. I do. If at some time in the future the code is changed to recognise the distinction between a title and a footnote the names of the new spacing parameters would naturally follow the new naming pattern, although I think that change is unlikely to happen. And it is particularly unlikely to happen, because then we need to invent and maintain score-footnote-spacing, system-footnote-spacing, markup-footnote-spacing, footnote-footnote-spacing, footnote-score-spacing, footnote-markup-spacing, footnote-system-spacing, footnote-bottom-spacing, top-footnote-spacing and the associated page break penalties. In short, we are going down a road now where any user-visible improvement (for which the necessity is clear) will become increasingly painful to do for both developers and users. OK, I take that point. This clearly can't happen. So we're back to making this easier by defining suitable music functions for common situations which employ \markup, like the \editorialNote I suggested earlier to place an editorial note underneath a system. That would seem to deal with that example. Do you have any others? Could they also be handled in a similar way? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
David Kastrup wrote: In short, we are going down a road now where any user-visible improvement (for which the necessity is clear) will become increasingly painful to do for both developers and users. Since obviously I am alone with this opinion among the developers, I would suggest polling the users on the Lilypond user list whether they think this change a step in the right direction and desirable for 2.14. After all, they will be affected most. I just want to state (for the record), that I think the points David has raised are important ones. I didn't want to start a war here (and I don't think I did), but I wanted to expose and confront what I saw as a problem. And now, thanks to David's eloquence, I think we all see the problem. I think this is a good time to rethink how LilyPond uses the \markup command. Perhaps the code is too casual in this respect? It would be nice instead to have a more semantic command vocabulary to replace top-level markups, for example: \alternateVerse \footnote \dialogue \stageDirections ...or whatever. Then, \markup could be used really as an un-semantic backup command for cases when nothing else fits. Personally, I think \footnote would be a good place to start. On the topic of this actual thread, I have a patch all ready to go -- http://codereview.appspot.com/2505041/ -- but I'm in no real rush, and I'm happy to wait for everyone to converge on a realistic proposal for a long-term solution, even if it's totally different. So let me know what you guys think I should do with my patch. Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky markpole...@yahoo.com writes: David Kastrup wrote: In short, we are going down a road now where any user-visible improvement (for which the necessity is clear) will become increasingly painful to do for both developers and users. Since obviously I am alone with this opinion among the developers, I would suggest polling the users on the Lilypond user list whether they think this change a step in the right direction and desirable for 2.14. After all, they will be affected most. I just want to state (for the record), that I think the points David has raised are important ones. I didn't want to start a war here (and I don't think I did), but I wanted to expose and confront what I saw as a problem. And now, thanks to David's eloquence, I think we all see the problem. I think this is a good time to rethink how LilyPond uses the \markup command. Perhaps the code is too casual in this respect? It would be nice instead to have a more semantic command vocabulary to replace top-level markups, for example: \alternateVerse \footnote \dialogue \stageDirections I am not sure new top-level primitives are the solution. If we take a look at TeX/LaTeX, the engine TeX does not bother with niceties like that apart from being able to deal with penalties, and removing discardable items like penalties and vertical space after a page break. If you want to have anything along the line of consistent document layouts, you need to program them on your own, built upon the primitives. Which is what LaTeX does. And there exist extension packages where you can declare new sectional material and so on. I don't think that there is anything wrong with implementing things like titles by using markups. The problem is that at some point of time, markups were promoted to top-level document elements (giving them spacing and distances to other top-level document elements), and the top-level document elements are dependent on the document design. ...or whatever. Then, \markup could be used really as an un-semantic backup command for cases when nothing else fits. That's my gut feeling as well. But it also would seem to make sense if it can be used as an un-semantic building block inside of semantic commands. So how do we get the semantics into/around markup or other document layout elements? And how does Lilypond get them out again? On the topic of this actual thread, I have a patch all ready to go -- http://codereview.appspot.com/2505041/ -- but I'm in no real rush, and I'm happy to wait for everyone to converge on a realistic proposal for a long-term solution, even if it's totally different. So let me know what you guys think I should do with my patch. Well, it did wake me up. That may have been a good effect of it, depending on one's views. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Thu, Oct 14, 2010 at 07:57:02AM -0700, Mark Polesky wrote: David Kastrup wrote: In short, we are going down a road now where any user-visible improvement (for which the necessity is clear) will become increasingly painful to do for both developers and users. Sure. Let's bite the bullet. Since obviously I am alone with this opinion among the developers, I would suggest polling the users on the Lilypond user list whether they think this change a step in the right direction and desirable for 2.14. No, because users know nothing about our state of development. David, can you produce patches -- by yourself -- that fix the title-markup-spacing thing within a month ? If yes, then I'm ok with rejecting Mark's patch. If no, then I say we accept the patch and move on with life. I just want to state (for the record), that I think the points David has raised are important ones. Yes, they are. I expect that they'll be addressed in GLISS 2. I didn't want to start a war here (and I don't think I did), but I wanted to expose and confront what I saw as a problem. Syntax changes always cause wars. I think this is a good time to rethink how LilyPond uses the \markup command. ... after the second alpha test of a stable release, and a month or two before a comprehensive review of all our syntax which has been planned for years? I say we should push your patch, get 2.14 out the door, and start GLISS. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Thu, Oct 14, 2010 at 4:57 PM, Mark Polesky markpole...@yahoo.com wrote: I think this is a good time to rethink how LilyPond uses the \markup command. Perhaps the code is too casual in this respect? It would be nice instead to have a more semantic command vocabulary to replace top-level markups, for example: \alternateVerse \footnote \dialogue \stageDirections [At the risk of sounding like a Web-addict geek (which I happen to be), this makes me think, again, of the HTML: whereas with HTML2/3/4 so far we only had the div that, that was used everywhere for everything without any sense of hierarchy whatsoever, in HTML5 they've added such tags as header,article, section, aside etc. that do not do anything new at all compared to divs, but do confer quite an elegant structure to the code.] (Granted, this post was useless, pedant, off-topic and hardly worth $0.2, but I believe it's quite appropriate in any 70-long mails discussion -- and counting :-) GLHF, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
David Kastrup d...@gnu.org writes: Mark Polesky markpole...@yahoo.com 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
Re: names of vertical spacing dimensions
David Kastrup d...@gnu.org 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
Carl Sorensen c_soren...@byu.edu writes: David Kastrup d...@gnu.org 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
On 10/13/10 8:29 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: David Kastrup d...@gnu.org 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: names of vertical spacing dimensions
Carl Sorensen c_soren...@byu.edu writes: On 10/13/10 8:29 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: David Kastrup d...@gnu.org 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: names of vertical spacing dimensions
On 10/13/10 2:40 PM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 10/13/10 8:29 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: David Kastrup d...@gnu.org 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: names of vertical spacing dimensions
On 2010-10-09 17:46, Mark Polesky wrote: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-markup between-title markup-markup after-titlemarkup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system Huh. Sorry that I missed the weekend discussion; in general I support these names. I'm not quite sure if they will be clearer to the everyday user who mainly thinks in terms of titles and scores, headers and footers, though, and probably won't have a bunch of settings for all of these, but rather uses the default for everything but what used to be 'after-title-spacing. [1] But since the new names are consistent and I definitely lack to come up with something more clever, I'm satisfied. (At least until GLISS, that is.) [1] I tried to figure out what's the buzz with scoreTitleMarkups and bookTitleMarkups. From a user's POV, both of them are top-level-markups, right? Is there anything different because one belongs to the score and the other to the book (aka real top-level)? I think after-title and between-title are the perfect identifiers for the spacing between those, but the whole naming system gets messed up if you include custom markups. /Perhaps/ I'd like aliases, but I don't want to think about this until GLISS. And, essentially, aliases are ugly anyway, so encapsulating headers in a separate category (score - markup - headerMarkup?) may be better, or... Not something to discuss now. By the way, right now it isn't possible to change spacing /in between/ of a book environment, is it? It's reasonable to think that the very main header (and the very first music line) will need a different spacing than all other markup-system-pairs, even if a scoreTitleMarkup is absent. So it'd be cool to allow changing the spacing variables inside the book block, or have some LaTeX-\vfill-like command with the four spacing variables as arguments: \vspace #'((spacing . 5) (stretchability . 20)), ... you get the point. But again, this looks like a major (read: postponed) change is necessary. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Hello, On 12/10/2010 10:13, Alexander Kobel wrote: On 2010-10-09 17:46, Mark Polesky wrote: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-markup between-title markup-markup after-title markup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system Why do we have 'top-system' but 'system-bottom' and not instead, 'bottom-system'? James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
James james.l...@datacore.com writes: Hello, On 12/10/2010 10:13, Alexander Kobel wrote: On 2010-10-09 17:46, Mark Polesky wrote: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-markup between-title markup-markup after-title markup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system Why do we have 'top-system' but 'system-bottom' and not instead, 'bottom-system'? Because there is no system after the bottom? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Tue 12 Oct 2010, 13:54 David Kastrup wrote: James james.l...@datacore.com writes: top-system top-system top-title top-markup between-title markup-markup after-title markup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system Why do we have 'top-system' but 'system-bottom' and not instead, 'bottom-system'? It would be more clear top-to-system, top-to-markup, system-to-bottom etc. But this is rather overengineering, probably. Don't know. Sorry for the noise. Because there is no system after the bottom? -- Dmytro O. Redchuk Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Hello, On 12/10/2010 12:54, David Kastrup wrote: Jamesjames.l...@datacore.com writes: Hello, On 12/10/2010 10:13, Alexander Kobel wrote: On 2010-10-09 17:46, Mark Polesky wrote: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-markup between-title markup-markup after-title markup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system Why do we have 'top-system' but 'system-bottom' and not instead, 'bottom-system'? Because there is no system after the bottom? ? I'll stop if I am really showing my ignorance (I am not a code developer), but from a user-point of view it would be much more 'logical' if the naming was split *consistently* into What you are changing (system, markup, title etc) and where you are changing. I still think a *user* (not programmer or code developer) is going to really get frustrated when they don't know what a system is i.e... 'oh you mean the stuff with the notes in...we call that a 'score' where I come from. Also Top-Markup As I see it my 'scores' are broken into 1. Titles (composer, arranger, instrument etc also includes tagline and page numbers) 2. Score (the stuff where the notes go) 3. Markup (the stuff that includes dynamics, textual markups, rehearsal marks, hairpins and so on that can hang above or below a score but stuff that is NOT in 'Titles' and is not the notes themselves). Then you simply have 'above', 'below', 'between'. Somethings would be redundant like 'above-titles' or 'titles-above' (I don't care which would come first, as long as the signifiers are consistent) To me 'markup-system' and 'system-system' are plain annoyingly obfuscating and I am obviously missing a trick because 'score-system' in my 'world' would be nonsensical. Between-score-system which is what it was would simply be 'score-between' or 'between-score'. Thanks 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
Hi James, I still think a *user* (not programmer or code developer) is going to really get frustrated when they don't know what a system is i.e... 'oh you mean the stuff with the notes in...we call that a 'score' where I come from. The entire music engraving world -- not just Lilypond, but Finale/Sib/etc. and the traditional hand-engravers -- call a single line of music spanning the width of a single page a system, and the entire collection of systems a score. If Lilypond users are confused because they don't have an understanding of that basic and universal terminology, they should read (1) some engraving books, and (2) the Lilypond introductory documentation. Best regards, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 2010-10-12 14:27, James wrote: On 12/10/2010 12:54, David Kastrup wrote: Jamesjames.l...@datacore.com writes: Why do we have 'top-system' but 'system-bottom' and not instead, 'bottom-system'? Because there is no system after the bottom? ? I'll stop if I am really showing my ignorance (I am not a code developer), but from a user-point of view it would be much more 'logical' if the naming was split *consistently* into What you are changing (system, markup, title etc) and where you are changing. That's what I meant when I wrote after-title-spacing and before-title-spacing (as is) are good names IMHO. /But:/ The more consistent naming scheme is the new one; on this I agree with Mark, Carl, David, and some of the others. All these variables describe vertical spacing, which means there is always a Foo above the space and a Baz below the space. Thus, foo-baz-space sounds fine, doesn't it? (This logic implies system-bottom-spacing, of course.) Of course, the user usually thinks of your three-divisioned scheme titling/headers, music, markups, but Lily's state of the art is that titling and top-level markups are the same. If we were to introduce this distinction as a separate, well, object-taking-vertical-top-level-space category, we'd have even more meaningful and understandable names; but this looks like it's /far/ out of the scope of this patch and discussion. And as to where you are changing: The settings just do not allow controlling the spacing independent of the subsequent element. That'd look like - similar to the (horizontal) space-alists for some grobs - the following, if I understand you correctly: after-staff-spacing = #'((Staff . ((space . 5) (stretchability 7))) (Lyrics . ((minimum-distance . 7))) (Markup . ((padding . 3))) (Titling . ((space . 8) (stretchability 20) (minimum-distance . 8) (padding . 5 ... and so on. This looks theoretically possible, but to me it does not look better than the current approach. Rather worse: what if you want to change just a single entry? Rewrite the whole thing? I see your point, but do you think it's worth it before GLISS? Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
James wrote Tuesday, October 12, 2010 1:27 PM On 12/10/2010 12:54, David Kastrup wrote: Jamesjames.l...@datacore.com writes: Hello, On 12/10/2010 10:13, Alexander Kobel wrote: On 2010-10-09 17:46, Mark Polesky wrote: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-markup between-title markup-markup after-title markup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system Why do we have 'top-system' but 'system-bottom' and not instead, 'bottom-system'? Because there is no system after the bottom? ? I'll stop if I am really showing my ignorance (I am not a code developer), I'm afraid you're showing your ignorance as a musician. System and score are not synonomous. A system is a line of music which includes the all the staves which are grouped together. Conductor scores will usually have one system per page; vocal scores of SATB plus piano reduction will usually have two systems per page. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Alexander Kobel n...@a-kobel.de writes:
On 2010-10-09 17:46, Mark Polesky wrote:
CURRENT NAME PROPOSED NAME
-
top-system top-system
top-title top-markup
between-title markup-markup
after-titlemarkup-system
between-system system-system
before-title system-markup
bottom-system system-bottom
between-scores-system score-system
Huh. Sorry that I missed the weekend discussion; in general I support
these names.
The main problem I see with that naming scheme is that it does not
reflect score sheet design, but the current implementation.
In the design of score sheets, you arrange titles and scores, with
scores having intersystem spacing.
That titles are a form of markup is an implementation detail and nothing
that describes the layout of a score sheet.
That other forms of markup, like top level markup intermissions, don't
get spacing parameters different from titles, again is an implementation
details inherent in the current code base, but without something like an
inherent necessity.
So the proposed scheme ties something presented as document spacing
parameters into internal details of their implementation.
--
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 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? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky markpole...@yahoo.com 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. 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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Tue, Oct 12, 2010 at 02:24:37PM +0100, Trevor Daniels wrote:
I'll stop if I am really showing my ignorance (I am not a code
developer),
I'm afraid you're showing your ignorance as a musician.
System and score are not synonomous. A system is a line
of music which includes the all the staves which are
grouped together.
Yes, but I see some weaknesses in our docs.
- Glossary: staff should link to system
- Glossary: both staff and system could benefit from images
- Learning: add some link(s) to Glossary: system. Currently we
have none!
gperc...@futoi:~/src/lilypond/Documentation/learning$ git grep
@rgloss{system}
I would recommend adding this to Learning 2 Tutorial. Maybe
somewhere in 2.3 Multiple notes at once; maybe somewhere in
2.5 Final touches. I'll let somebody else think about it in more
detail and produce a patch.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 12/10/10 00:55, Graham Percival wrote: Why not push it as one patch? It seems like all of those pieces need to be accomplished in order to have a fully-buildable release (i.e. if the variable names in lilypond don't match the variable names in the docs, make doc will fail. If he has them as separate patches, that might help future debugging efforts if there's any problem with this. I don't think it matters much, but pushing them as separate patches gives us a bit more information in the history, and it certainly doesn't hurt anything. If it's multiple patches then it's best committed as multiple patches. There's actually a git case for exactly this (to do with git bisect). I remember reading it on the git list recently - you can push a group of patches and tell git-bisect to use them as a single unit. The idea being that they're a lot easier to verify individually, but any one of them depends on the others and will break the system if processed in isolation. Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 12/10/10 14:02, Kieren MacMillan wrote: Hi James, I still think a *user* (not programmer or code developer) is going to really get frustrated when they don't know what a system is i.e... 'oh you mean the stuff with the notes in...we call that a 'score' where I come from. The entire music engraving world -- not just Lilypond, but Finale/Sib/etc. and the traditional hand-engravers -- call a single line of music spanning the width of a single page a system, and the entire collection of systems a score. If Lilypond users are confused because they don't have an understanding of that basic and universal terminology, they should read (1) some engraving books, and (2) the Lilypond introductory documentation. 3) Take a basic music theory course. For a musician to get that wrong is as seriously incompetent as for a computer guy to refer to a hard disk as ram (I know the man-in-the-street tends to call them both memory). Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/12/10 4:20 PM, Wols Lists antli...@youngman.org.uk wrote: On 12/10/10 14:02, Kieren MacMillan wrote: Hi James, I still think a *user* (not programmer or code developer) is going to really get frustrated when they don't know what a system is i.e... 'oh you mean the stuff with the notes in...we call that a 'score' where I come from. The entire music engraving world -- not just Lilypond, but Finale/Sib/etc. and the traditional hand-engravers -- call a single line of music spanning the width of a single page a system, and the entire collection of systems a score. If Lilypond users are confused because they don't have an understanding of that basic and universal terminology, they should read (1) some engraving books, and (2) the Lilypond introductory documentation. 3) Take a basic music theory course. For a musician to get that wrong is as seriously incompetent as for a computer guy to refer to a hard disk as ram (I know the man-in-the-street tends to call them both memory). Yes, but some of us who use LilyPond don't qualify as musicians. When I first started using LilyPond, I didn't know all the terminology I know now. In particular, system was not part of my understanding. It was on the LilyPond lists that I learned what a system was. Let's not avoid teaching people the terminology just because they already ought to know it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 12/10/10 22:05, Graham Percival wrote:
On Tue, Oct 12, 2010 at 02:24:37PM +0100, Trevor Daniels wrote:
I'll stop if I am really showing my ignorance (I am not a code
developer),
I'm afraid you're showing your ignorance as a musician.
System and score are not synonomous. A system is a line
of music which includes the all the staves which are
grouped together.
Yes, but I see some weaknesses in our docs.
- Glossary: staff should link to system
- Glossary: both staff and system could benefit from images
- Learning: add some link(s) to Glossary: system. Currently we
have none!
gperc...@futoi:~/src/lilypond/Documentation/learning$ git grep
@rgloss{system}
Add stave to this. Actually, I would have defined a stave as a line of
music, and a system as a group of linked staves played simultaneously.
But that all depends on how you understand the word line :-)
I would recommend adding this to Learning 2 Tutorial. Maybe
somewhere in 2.3 Multiple notes at once; maybe somewhere in
2.5 Final touches. I'll let somebody else think about it in more
detail and produce a patch.
Cheers,
- Graham
Cheers,
Wol
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 2010-10-13 00:20, Wols Lists wrote: On 12/10/10 14:02, Kieren MacMillan wrote: Hi James, [...] If Lilypond users are confused because they don't have an understanding of that basic and universal terminology, they should read (1) some engraving books, and (2) the Lilypond introductory documentation. 3) Take a basic music theory course. For a musician to get that wrong is as seriously incompetent [...] On 2010-10-12 15:24, Trevor Daniels wrote: I'm afraid you're showing your ignorance as a musician. System and score are not synonomous. [...] Come on, guys, calm down. First, not everybody's a native speaker, and even if they are or know the terms, score-system-spacing is confusing at the first glance. After all, the user might think: My scores consist of systems - why should I specify a distance between the system and the score it is in? Ah, okay, it probably means the spacing between different systems in a score. Well, bang, you're dead - wrong conclusion drawn. I'd understand this way of reasoning if somebody only sees the name of the variable without further explanation, and thus I see James' point. But really, the logic upper object - lower object is simple enough to explain in one sentence, and if the user reads it, he should be fine. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Tue, Oct 12, 2010 at 04:23:49PM -0600, Carl Sorensen wrote: On 10/12/10 4:20 PM, Wols Lists antli...@youngman.org.uk wrote: For a musician to get that wrong is as seriously incompetent as for a computer guy to refer to a hard disk as ram (I know the man-in-the-street tends to call them both memory). Yes, but some of us who use LilyPond don't qualify as musicians. Yes. In particular, the ONLY PERSON who is actually working as a general documentation editor. Wols: it would be nice if you did at least 1% of the work that James Lowe has done for LilyPond. He has spent a huge amount of time fixing problems in the docs, using tools he didn't know, on aspects of music that he's not familiar, and without complaint about the poor quality of documentation bug reports that he has been resolving. He is not, by any stretch of the imagination, seriously incompetent. Show him some respect. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 2010-10-13 00:27, Wols Lists wrote: Add stave to this. Actually, I would have defined a stave as a line of music, and a system as a group of linked staves played simultaneously. But that all depends on how you understand the word line :-) Stave or staff?! Are these identical? I thought stave is just a wrong singular form of staves, which itself is the correct plural of staff? Merriam-Webster says nothing about these words in a musical context... :-( Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/12/10 4:27 PM, Wols Lists antli...@youngman.org.uk wrote:
On 12/10/10 22:05, Graham Percival wrote:
On Tue, Oct 12, 2010 at 02:24:37PM +0100, Trevor Daniels wrote:
I'll stop if I am really showing my ignorance (I am not a code
developer),
I'm afraid you're showing your ignorance as a musician.
System and score are not synonomous. A system is a line
of music which includes the all the staves which are
grouped together.
Yes, but I see some weaknesses in our docs.
- Glossary: staff should link to system
- Glossary: both staff and system could benefit from images
- Learning: add some link(s) to Glossary: system. Currently we
have none!
gperc...@futoi:~/src/lilypond/Documentation/learning$ git grep
@rgloss{system}
Add stave to this. Actually, I would have defined a stave as a line of
music, and a system as a group of linked staves played simultaneously.
But that all depends on how you understand the word line :-)
Isn't staff singular, and staves (or staffs) plural?
Read describes a staff; multiple staves (his word) are grouped together into
a system.
Stone uses the terms staff, staves, and system, but without definition.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Wed, Oct 13, 2010 at 12:45:33AM +0200, Alexander Kobel wrote: On 2010-10-13 00:27, Wols Lists wrote: Add stave to this. Actually, I would have defined a stave as a line of music, and a system as a group of linked staves played simultaneously. But that all depends on how you understand the word line :-) Stave or staff?! Are these identical? I thought stave is just a wrong singular form of staves, which itself is the correct plural of staff? In GDP, we standardized on either staffs or staves, but I forget which one we picked, and it didn't make it into the General writing section of the CG. The answer should be in the mailing list archives, though. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: names of vertical spacing dimensions
Hello It's OK, I am not offended. I am sure that none of it was meant maliciously. So don't fret, I am sure I'll be showing my ignorance again in the future on these lists. =8 ) As I said to Trevor earlier, the conductor of my orchestra (and wind band) gives me a score to play not a system, when I use LilyPond I personally create/transcribe/copy 'scores' not systems and also while I am not anywhere near diploma level of Musicianship I have gone back through my basic Music Theory primers and no where (at all) is the term 'system' used or even mentioned. So I assumed this was just a 'developer' convention and didn't even think this was something I'd look up in the glossary. As an instrument player (as opposed to a singer or 'vocalist') who has neither conducted or composed anything more than a few 'dittys' I can see how this would be the case where I have never come across the term system. Still that all aside, I think David K and others have got the point I was making. Pip! Pip! James -Original Message- From: lilypond-devel-bounces+james.lowe=datacore@gnu.org on behalf of Graham Percival Sent: Tue 12/10/2010 23:44 To: Carl Sorensen Cc: lilypond-devel@gnu.org Subject: Re: names of vertical spacing dimensions On Tue, Oct 12, 2010 at 04:23:49PM -0600, Carl Sorensen wrote: On 10/12/10 4:20 PM, Wols Lists antli...@youngman.org.uk wrote: For a musician to get that wrong is as seriously incompetent as for a computer guy to refer to a hard disk as ram (I know the man-in-the-street tends to call them both memory). Yes, but some of us who use LilyPond don't qualify as musicians. Yes. In particular, the ONLY PERSON who is actually working as a general documentation editor. Wols: it would be nice if you did at least 1% of the work that James Lowe has done for LilyPond. He has spent a huge amount of time fixing problems in the docs, using tools he didn't know, on aspects of music that he's not familiar, and without complaint about the poor quality of documentation bug reports that he has been resolving. He is not, by any stretch of the imagination, seriously incompetent. Show him some respect. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Graham Percival
Yes, but I see some weaknesses in our docs.
- Glossary: staff should link to system
- Glossary: both staff and system could benefit from images
- Learning: add some link(s) to Glossary: system. Currently we
have none!
gperc...@futoi:~/src/lilypond/Documentation/learning$ git grep
@rgloss{system}
I would recommend adding this to Learning 2 Tutorial. Maybe
somewhere in 2.3 Multiple notes at once; maybe somewhere in
2.5 Final touches. I'll let somebody else think about it in more
detail and produce a patch.
OK, I just pushed these changes. I left out an image
for system, as this is defined wrt the width of the
page, which is not well-defined in the docs (the image
width is less than the page width, and the page width
is variable in html).
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 12/10/10 23:44, Graham Percival wrote: On Tue, Oct 12, 2010 at 04:23:49PM -0600, Carl Sorensen wrote: On 10/12/10 4:20 PM, Wols Lists antli...@youngman.org.uk wrote: For a musician to get that wrong is as seriously incompetent as for a computer guy to refer to a hard disk as ram (I know the man-in-the-street tends to call them both memory). Yes, but some of us who use LilyPond don't qualify as musicians. Yes. In particular, the ONLY PERSON who is actually working as a general documentation editor. Wols: it would be nice if you did at least 1% of the work that James Lowe has done for LilyPond. He has spent a huge amount of time fixing problems in the docs, using tools he didn't know, on aspects of music that he's not familiar, and without complaint about the poor quality of documentation bug reports that he has been resolving. He is not, by any stretch of the imagination, seriously incompetent. Show him some respect. Sorry. I did say it was a mistake I wouldn't expect a musician to make. If James isn't a musician then fair enough. Equally, though, I'm surprised to find non-musicians interested in lilypond (pleased though - the more the merrier - I just didn't expect it). Sorry again, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 12/10/10 23:45, Alexander Kobel wrote: On 2010-10-13 00:27, Wols Lists wrote: Add stave to this. Actually, I would have defined a stave as a line of music, and a system as a group of linked staves played simultaneously. But that all depends on how you understand the word line :-) Stave or staff?! Are these identical? I thought stave is just a wrong singular form of staves, which itself is the correct plural of staff? Merriam-Webster says nothing about these words in a musical context... :-( In English (not necessarily music) the two words have different overtones although they have the same basic meaning. A staff is a long stick used for support when walking. A stave is pretty much the same long stick (although often thicker) used for fighting or for supporting things other than people. So when walking in dangerous territory, you would prefer to use a stave for support rather than a staff because you have a weapon if you need it. Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Tue, Oct 12, 2010 at 04:58:42PM -0600, Carl Sorensen wrote: it is staff and staves, according to the GDP rules: http://lists.gnu.org/archive/html/lilypond-devel/2007-09/msg00240.html Thanks! James, could you send me a patch for the CG? Of course, Neil considered that a US bias (with a smiley): http://lists.gnu.org/archive/html/lilypond-devel/2007-09/msg00245.html Well, our doc policy apologetically specifies US spelling. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/10/10 12:56 PM, Mark Polesky markpole...@yahoo.com wrote: Here's an updated patch set for review: http://codereview.appspot.com/2303044/ It's organized into 5 commits on my local branch: 1) Rename vertical spacing dimensions. 2) Update convert-ly (vertical spacing). 3) Run convert-ly on affected regtests (vert. spacing). 4) Revise regtest texidoc headers (vert.spacing). 5) Update docs in English (vert. spacing). ...but Rietveld meshed them all into one. So, once approved, I'll push it as a set of patches, not just one. Why not push it as one patch? It seems like all of those pieces need to be accomplished in order to have a fully-buildable release (i.e. if the variable names in lilypond don't match the variable names in the docs, make doc will fail. I think it should all be pushed as one patch. 2 questions: 1) The filenames of some of the affected regtests are now incorrectly named. For example, page-spacing-top-title-spacing.ly should probably become page-spacing-top-markup-spacing.ly. What's the protocol for this type of situation? git mv input/regression/page-spacing-top-title-spacing.ly input/regression/page-spacing-top-markup-spacing.ly 2) Should I update the translated docs? If your convert-ly rule can make the changes, go ahead and run convert-ly on the foreign language docs. If your convert-ly rule can't make the changes, then you should modify *the snippets* in the foreign language docs, so they will continue to compile. Don't modify the text in the foreign language docs; the translators will do that. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Mon, Oct 11, 2010 at 6:29 PM, Carl Sorensen c_soren...@byu.edu wrote: On 10/10/10 12:56 PM, Mark Polesky markpole...@yahoo.com wrote: ...but Rietveld meshed them all into one. So, once approved, I'll push it as a set of patches, not just one. Why not push it as one patch? It seems like all of those pieces need to be accomplished in order to have a fully-buildable release (i.e. if the variable names in lilypond don't match the variable names in the docs, make doc will fail. If he has them as separate patches, that might help future debugging efforts if there's any problem with this. I don't think it matters much, but pushing them as separate patches gives us a bit more information in the history, and it certainly doesn't hurt anything. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Here's an updated patch set for review: http://codereview.appspot.com/2303044/ It's organized into 5 commits on my local branch: 1) Rename vertical spacing dimensions. 2) Update convert-ly (vertical spacing). 3) Run convert-ly on affected regtests (vert. spacing). 4) Revise regtest texidoc headers (vert.spacing). 5) Update docs in English (vert. spacing). ...but Rietveld meshed them all into one. So, once approved, I'll push it as a set of patches, not just one. 2 comments: 1) One unintended side-effect was the conversion of page-breaking-between-system-spacing into page-breaking-system-system-spacing. I think that's the right way to go, but I thought I'd mention in case it's an issue for some reason unknown to me. 2) Carl's right: score-markup-spacing it is. 2 questions: 1) The filenames of some of the affected regtests are now incorrectly named. For example, page-spacing-top-title-spacing.ly should probably become page-spacing-top-markup-spacing.ly. What's the protocol for this type of situation? 2) Should I update the translated docs? Thanks! - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
(David, see the note at the end of this post) It's not that I want to split hairs; I want to get the new variable names right the first time. My apologies to any of you who are getting tired with this process. My current (and hopefully final) proposal is now this: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-markup between-title markup-markup after-titlemarkup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system I've realized one subtlety that should help decide the remaining debates. LilyPond has two types of titles, bookTitleMarkup (title, composer, etc.) and scoreTitleMarkup (piece and opus). The elements of bookTitleMarkup will only display if they are entered in a top-level \header block, so they cannot be considered part of a score. The elements of scoreTitleMarkup can be entered in a \header block within a \score block, so they are obviously part of the score. Here's my rationale for the remaining debates: * * * * * * * * * * between-scores-system-spacing only applies to this case: 1) from last system of one score to first system of a new score, with no intervening top-level markup or scoreTitleMarkup. So calling this variable score-score-spacing is misleading because it does not apply when the new score has a scoreTitleMarkup. So now I favor score-system-spacing. * * * * * * * * * * after-title-spacing applies to these cases: 1) from top-level markup to first system of a new score. 2) from bookTitleMarkup to first system of a new score (when scoreTitleMarkup is absent) 3) within a score, from scoreTitleMarkup to first system. IMO, within the proposed naming scheme, the only real choice for after-title-spacing is markup-system-spacing, since markup-score-spacing is misleading since it does not apply to scores with a scoreTitleMarkup. * * * * * * * * * * before-title-spacing applies to these cases: 1) from last system in a score to top-level markup. 2) from last system of one score to scoreTitleMarkup of another score. Within the proposed naming scheme, the 2 choices for before-title-spacing are: system-markup-spacing score-markup-spacing Carl likes score-markup-spacing for at least 2 reasons: 1) the upper attachment point is always the end of a score. 2) system-markup suggests that it should work within a single score, and it doesn't. I've gone back and forth, but now I'm in favor of system-markup-spacing for the following reasons: 1) it complements markup-system-spacing which is easier to remember. 2) I disagree with Carl's #2 above since markup in a variable name only refers to top-level markups (and this will be made clear in the documentation). * * * * * * * * * * If you're okay with the latest proposal, or if you have additional arguments... let me know either way. David, I didn't mean to disregard your last suggestion: spacing markup markup = 3cm spacing score markup = ... It's just that it looks like a much bigger change, and unless someone chimes in with an endorsement and a feasible implementation strategy, I don't realistically see that happening before the next release. But if anyone here can do this, definitely chime in! Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/9/10 9:46 AM, Mark Polesky markpole...@yahoo.com wrote: * * * * * * * * * * before-title-spacing applies to these cases: 1) from last system in a score to top-level markup. 2) from last system of one score to scoreTitleMarkup of another score. Within the proposed naming scheme, the 2 choices for before-title-spacing are: system-markup-spacing score-markup-spacing Carl likes score-markup-spacing for at least 2 reasons: 1) the upper attachment point is always the end of a score. 2) system-markup suggests that it should work within a single score, and it doesn't. I've gone back and forth, but now I'm in favor of system-markup-spacing for the following reasons: 1) it complements markup-system-spacing which is easier to remember. I don't agree with this rationale. markup-system-spacing is chosen because the markup can be either inside the score of which the system is a part, or outside the score. Hence we need to have it be markup-system. In contrast, the markup to which we are spacing with score-markup-spacing is always *outside* the score to which we are referring. Thus, we can (and IMO should) use score-* rather than system-*. I think the asymmetry of these two situations calls for asymmetry in the naming, rather than symmetry in the naming with the documentation making the asymmetry clear. But I won't be an obstructionist here. I've made my argument, and am willing to accept whatever decisions are made on the list. And as the person who is doing the work, Mark's opinions should carry more weight than mine. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/9/10 10:52 AM, Joe Neeman joenee...@gmail.com wrote: On Sat, Oct 9, 2010 at 9:05 AM, Carl Sorensen c_soren...@byu.edu wrote: On 10/9/10 9:46 AM, Mark Polesky markpole...@yahoo.com wrote: * * * * * * * * * * before-title-spacing applies to these cases: 1) from last system in a score to top-level markup. 2) from last system of one score to scoreTitleMarkup of another score. Within the proposed naming scheme, the 2 choices for before-title-spacing are: system-markup-spacing score-markup-spacing Carl likes score-markup-spacing for at least 2 reasons: 1) the upper attachment point is always the end of a score. 2) system-markup suggests that it should work within a single score, and it doesn't. I've gone back and forth, but now I'm in favor of system-markup-spacing for the following reasons: 1) it complements markup-system-spacing which is easier to remember. I don't agree with this rationale. markup-system-spacing is chosen because the markup can be either inside the score of which the system is a part Really? How does that happen? If the markup is a bookTitleMarkup or a top-level markup it's outside of the score. If it's a scoreTitleMarkup, it's inside of the score. At least, this is the way that Mark identified it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Sat, Oct 09, 2010 at 05:50:49PM +0100, Trevor Daniels wrote: Mark Polesky wrote Saturday, October 09, 2010 4:46 PM It's not that I want to split hairs; I want to get the new variable names right the first time. My apologies to any of you who are getting tired with this process. %%% in Mark-style, read to the bottom before commenting. :) This discussion has been quite short (what, one week?), has not made any attempt to consult users or external projects that use or output lilypond input code, etc. We *will* have complaints about this change. If anybody is tired of _this_ process, then Mao help them when GLISS is happening. (that said, GLISS will occur on a separate mailing list, for precisely this reason -- people who want to discuss syntax can do it there, while this list can focus on serious development stuff) I'm afraid I'm no longer following this discussion sufficiently carefully to tender sensible comment, Me too. I think now it would be better to push the changes, fix the documentation, and let us try using it to see if any more tweaks are worth making. +1 This is not going to be the final syntax change for spacing names. David's idea is interesting, and who knows what other possibilities might be suggested if we had a wider consultation. However, that's a task for GLISS 2 in a year or two, not right now. Once you have agreement from Joe and a lack of screams of agony from any other main developers, start pushing stuff. When users complain, I'll tell them to get stuffed [1]. [1] do any other Canadians miss the Royal Canadian Air Farce? Now that I'm in Scotland, I keep on fondly remembering their left-handed immigrant bagpipe technician comedy sketches. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Carl Sorensen wrote: Does before-title-spacing apply at the top of the first page, or only between scores? before-title-spacing does *not* apply at the top of the first page, even when print-first-page-number is #t (to force a header). Does between-scores-system-spacing apply only to the case where there are two scores without a markup between? AFAICT, yes. Do we consider a header as part of a score or not? AFAICT, no. If we don't consider the markup to be part of a score, I like the term score-score-spacing. To me it says it controls the spacing between the last system of the first score and the first system of the next score. If that meaning is right, let's keep the name. If that meaning is wrong, let's change the name. I believe that the meaning is correct, so your vote is to keep score-score-spacing; that's fine by me. Also, if system-markup-spacing only applies to the distance between the last system of the first score and a markup that comes after the score, then it should be score-markup-spacing, IMO. If it applies to the spacing between a system *in a score* and a markup *in the same score*, then it should be system-markup-spacing. system-markup-spacing (a.k.a before-title-spacing) does not apply to a system and markup in the same score, so your vote is for score-markup-spacing; that's fine by me. However, by extension of this logic, and to be consistent, we should then change after-title-spacing to markup-score-spacing, as opposed to markup-system-spacing. This leaves: CURRENT NAME PROPOSED NAME - top-system top-system (no change) top-title top-markup between-title markup-markup after-titlemarkup-score between-system system-system before-title score-markup bottom-system system-bottom between-scores-system score-score I'm fine with these changes, but now I'm confused by something else. After playing around with a bunch of settings, it seems that headers and footers are neither markups nor scores, yet they influence spacing, and there are no variables like after-header-spacing or before-footer-spacing. What variable can I use to set the 'padding between the last system and the footer? Or do I just use bottom-system-spacing, and then the program automatically moves the last system up to prevent colliding with the footer? By the way, the annotate-spacing output is not very helpful here. No, that's too kind; annotate-spacing is so unhelpful it's essentially broken. When I have more time, maybe I'll submit a bug report. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
(Carl et al.: please read at least the last paragraph!) Xavier Scheuer wrote: The previous names were quite easy to understand (although it was a bit difficult due to the large number of such variables) but I don't catch at first sight the meaning of the new proposed ones... Well, in the new docs I would certainly mention the general format: item1-item2-spacing I would also mention that the use of the word markup in these variable names only refers to top-level markups and titles. Would knowing this in advance make you feel differently or do you still not like the proposed names? In the first post of this thread, I explained my own confusion with things like after-title-spacing, which I would expect to control the spacing after titles. But this is doubly misleading. It does not control the spacing after titles that are followed by markups or other titles, yet it *does* control the spacing after some markups that are *not* titles. In contrast to this confusion, the variable always controls the spacing between a markup and a score*, whether the markup is a title or a top-level markup. Thus the name markup-score-spacing is both more informative and less misleading. *um, see the last paragraph... And even if you don't use top-level markups yourself, the spacing variable is designed to work with them, and the variable name should reflect this as clearly as possible. And that's just one example. There are plenty of other confusing things in the current list. Other examples: top-system-spacing controls the spacing *above* the top system, yet bottom-system-spacing controls the spacing *below* the bottom system. before-title-spacing does not control the spacing before titles at the top, nor does it control the spacing before titles preceded by a top-level markup. I (and several others) feel that a consistent format is preferable for future users, and worth the hassle for us current users. Okay, now I see something possibly sub-optimal. By changing after-title-spacing to markup-score-spacing, it could confuse users due to the fact that the title is presumably *part* of the score, no? So if the title is technically considered part of the score, than this is not the distance between markup and score, but rather between markup and system (which reverts to my original proposal of markup-system-spacing). So now I prefer after-title-spacing--markup-system-spacing and before-title-spacing--score-markup-spacing. Carl, what do you think? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky markpole...@yahoo.com writes: (Carl et al.: please read at least the last paragraph!) Xavier Scheuer wrote: The previous names were quite easy to understand (although it was a bit difficult due to the large number of such variables) but I don't catch at first sight the meaning of the new proposed ones... Well, in the new docs I would certainly mention the general format: item1-item2-spacing I would also mention that the use of the word markup in these variable names only refers to top-level markups and titles. Would knowing this in advance make you feel differently or do you still not like the proposed names? They sound systematic enough to obliterate them. Namely use an interface like spacing markup markup = 3cm spacing score markup = ... In other words: I like the systematics better than the resulting identifiers. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 2010-10-06 17:46, Mark Polesky wrote: I also think the name 'space is misleading; I propose 'default-distance. Opinions? I can't see why 'space should be misleading, but that might just be that I'm accustomed to it by now. It's shorter, but anything other is okay as well. (Of course, this requires an understanding of the connections 'padding vs. 'space and 'stretchability vs. 'minimum-distance.) But should it be 'default-distance or 'optimal-distance? Default to me (non-native speaker) implies that it's the value proposed by the system, which can be overridden by the user. I think optimal fits better in the sense that it's the user-given value which the layout algorithms aims to achieve, but does not always succeed to reach. In this sense, 'stretchability is a deeper feature most users hopefully don't have to care about too much; what you want to tweak is 'space. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
IIUC, making all of these changes should be done in 5 steps: 1) rename the variables in the code files 2) change 'space to 'default-distance* in the code files 3) write rules for convert-ly 4) update affected regtests (?) 5) update the docs *or Alexander's optimal-distance (still open to debate) Does these 5 steps sound right? If so, I'm probably able to do #1 and #4, and definitely able to do #5. If I tried to do #2 and #3, I'm pretty sure they would take me way too long and I'd probably mess them up anyway. I *think* I've taken care of #1. Here's a patch: http://codereview.appspot.com/2303044 Please double-check this to see if I've missed anything (more than likely, since C++ is largely foreign to me). Once this patch is approved, maybe Joe can then change 'space to 'default-distance*, and we can go from there. *or Alexander's optimal-distance Thanks! - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky markpole...@yahoo.com writes: IIUC, making all of these changes should be done in 5 steps: 1) rename the variables in the code files 2) change 'space to 'default-distance* in the code files 3) write rules for convert-ly 4) update affected regtests (?) 5) update the docs *or Alexander's optimal-distance (still open to debate) I'd rather pick base-distance. After all, if the distance were optimal (or default), it would seem strange that the end result differed. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/7/10 1:44 AM, Alexander Kobel n...@a-kobel.de wrote: On 2010-10-06 17:46, Mark Polesky wrote: I also think the name 'space is misleading; I propose 'default-distance. Opinions? I can't see why 'space should be misleading, but that might just be that I'm accustomed to it by now. It's shorter, but anything other is okay as well. (Of course, this requires an understanding of the connections 'padding vs. 'space and 'stretchability vs. 'minimum-distance.) But should it be 'default-distance or 'optimal-distance? Default to me (non-native speaker) implies that it's the value proposed by the system, which can be overridden by the user. I think optimal fits better in the sense that it's the user-given value which the layout algorithms aims to achieve, but does not always succeed to reach. I think I'd prefer desired-distance to optimal-distance. optimal distance is what the algorithms actually end up with, as a tradeoff between desired distance and the amount of stuff on a page. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 2010-10-07 15:53, Carl Sorensen wrote: I like base-; it's shorter to type, and it still carries the right connotation. +1. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/7/10 7:51 AM, Valentin Villenave valen...@villenave.net wrote: On Thu, Oct 7, 2010 at 3:41 PM, Carl Sorensen c_soren...@byu.edu wrote: I think I'd prefer desired-distance to optimal-distance. optimal distance is what the algorithms actually end up with, as a tradeoff between desired distance and the amount of stuff on a page. How about requested- rather than desired-? requested- or base- (like David suggested). I like base-; it's shorter to type, and it still carries the right connotation. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Thu, Oct 7, 2010 at 3:41 PM, Carl Sorensen c_soren...@byu.edu wrote: I think I'd prefer desired-distance to optimal-distance. optimal distance is what the algorithms actually end up with, as a tradeoff between desired distance and the amount of stuff on a page. How about requested- rather than desired-? (OK, this post is hardly worth $0.02 :-) Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Carl Sorensen c_soren...@byu.edu writes: On 10/7/10 7:51 AM, Valentin Villenave valen...@villenave.net wrote: On Thu, Oct 7, 2010 at 3:41 PM, Carl Sorensen c_soren...@byu.edu wrote: I think I'd prefer desired-distance to optimal-distance. optimal distance is what the algorithms actually end up with, as a tradeoff between desired distance and the amount of stuff on a page. How about requested- rather than desired-? requested- or base- (like David suggested). I like base-; it's shorter to type, and it still carries the right connotation. It is also consistent with the naming of the baseline-skip property. It would be more so if that were named base-lineskip (as I thought it were). Since that is actually a reminiscence of the TeX spacing trio \baselineskip, \lineskiplimit, \lineskip, this hyphenation would have made more sense to me. However, looking at the program code of TeX, I find the Pascal constant name constituents baseline_skip, line_skip and line_skip_limit. Quite in line with the hyphenation of Lilypond's property names. Bah. I still find base-distance a nice name and somewhat mnemonically related to baseline-skip. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Enough votes are in for 'base-distance (and you can add my vote as well), so I think that settles it. But I still need people to comment on 1) the patch: http://codereview.appspot.com/2303044 and 2) the approach: http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00095.html Two more questions... 1) Pardon my ignorance, but do we ever run convert-ly on the regtests? 2) I've changed between-scores-system-spacing to score-score-spacing, but now I'm thinking score-system-spacing might be slightly clearer. Though if we make that change, we might want to change before-title-spacing to score-markup-spacing for consistency (instead of system-markup-spacing). Or is this a bad idea? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On Thu, Oct 07, 2010 at 07:59:25AM -0700, Mark Polesky wrote: 1) Pardon my ignorance, but do we ever run convert-ly on the regtests? I'd consider that as part of 1288. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/7/10 8:59 AM, Mark Polesky markpole...@yahoo.com wrote: Enough votes are in for 'base-distance (and you can add my vote as well), so I think that settles it. But I still need people to comment on 1) the patch: http://codereview.appspot.com/2303044 The patch looks fine to me. and 2) the approach: http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00095.html The approach seems fine to me, except that you shouldn't push a patch that changes the property names without changing the docs and the regtests at the same time. Otherwise, you break compiling while you're waiting. As far as convert-ly rules go, a regex wizard could probably write a rule that would handle everything properly, considering the possibility that each of the spacing variables can be defined partially (i.e. define space, but not padding or minimum-distance). But trying to figure out how to substitute base-distance for space automatically would seem to be a real problem, since the word space can show up lots of places besides as an argument to *-spacing. Given that the new spacing code has only been in development releases, I think I'd create a NOT_SMART rule, and change the regtests manually. Two more questions... 1) Pardon my ignorance, but do we ever run convert-ly on the regtests? Personally, when I make a change in syntax, I grep for all occurences of that syntax and change them manually. But that's because every change I've made is NOT_SMART. 2) I've changed between-scores-system-spacing to score-score-spacing, but now I'm thinking score-system-spacing might be slightly clearer. Though if we make that change, we might want to change before-title-spacing to score-markup-spacing for consistency (instead of system-markup-spacing). Or is this a bad idea? Does before-title-spacing apply at the top of the first page, or only between scores? Does between-scores-system-spacing apply only to the case where there are two scores without a markup between? Do we consider a header as part of a score or not? If we don't consider the markup to be part of a score, I like the term score-score-spacing. To me it says it controls the spacing between the last system of the first score and the first system of the next score. If that meaning is write, let's keep the name. If that meaning is wrong, let's change the name. Also, if system-markup-spacing only applies to the distance between the last system of the first score and a markup that comes after the score, then it should be score-markup-spacing, IMO. If it applies to the spacing between a system *in a score* and a markup *in the same score*, then it should be system-markup-spacing. Thanks, Carl - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
I also think the name 'space is misleading; I propose 'default-distance. Opinions? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
On 10/6/10 9:46 AM, Mark Polesky markpole...@yahoo.com wrote: I also think the name 'space is misleading; I propose 'default-distance. Opinions? So then we'd have, for each item-item-spacing entry default-distance -- the non-stretched distance between the upper item reference point and the lower item reference point. minimum-distance -- the minimum distance between the upper item reference point and the lower item reference point padding -- the minimum amount of whitespace between the bottom of the upper item and the the top of the lower item stretchability -- a parameter that affects how much the separation between the items will be adjusted in order to accommodate the page layout. That sounds good to me. Thanks, Carl P.S. It seems to me that at one point Joe mentioned there was a different default for stretchability for tension and compression. If that's the case, should we have a 'stretchability and a 'compressibility? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky wrote Wednesday, October 06, 2010 4:46 PM I also think the name 'space is misleading; I propose 'default-distance. Opinions? I'd be happy with that change too. Mark Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: names of vertical spacing dimensions
Mark Polesky wrote Monday, October 04, 2010 11:14 PM Usually when I propose things like this, they're shot down pretty fast, but here goes anyway. It took me a while to mentally connect the names of the vertical spacing variables with their specific domains. For example, I think it's counterintuitive that 'after-title-spacing does *not* affect the spacing after a title when it's followed by another title or markup. The appropriate one for that is 'between-title-spacing. Also, some confusion arises before getting used to the fact that markups are also referred to as title. [snip] Regardless, I prefer the consistency and predictability of the proposed names. Comments appreciated, thanks! Looks a good suggestion to me, but discussion is better deferred until GLISS is launched. Don't lose it! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
