vertical spacing: Rename dimensions. (issue2505041)
Reviewers: , Message: Sorry this took so long. I uploaded all 6 commits as separate patch sets so it's easier to review. Patch set 7 combines all the changes into one set. Okay to push? - Mark Description: vertical spacing: Rename dimensions. Please review this at http://codereview.appspot.com/2505041/ Affected files: M Documentation/de/notation/spacing.itely M Documentation/es/notation/spacing.itely M Documentation/fr/notation/spacing.itely M Documentation/notation/spacing.itely A input/regression/page-breaking-markup-padding.ly A input/regression/page-breaking-markup-padding2.ly A input/regression/page-breaking-markup-padding3.ly M input/regression/page-breaking-min-distance.ly D input/regression/page-breaking-title-padding.ly D input/regression/page-breaking-title-padding2.ly D input/regression/page-breaking-title-padding3.ly M input/regression/page-spacing-loose-lines-between.ly M input/regression/page-spacing-loose-lines-header-padding.ly A input/regression/page-spacing-top-markup-spacing.ly M input/regression/page-spacing-top-system-spacing.ly D input/regression/page-spacing-top-title-spacing.ly M input/regression/paper-nested-override.ly M input/regression/stem-length-estimation.ly M input/regression/system-overstrike.ly M lily/constrained-breaking.cc M lily/include/constrained-breaking.hh M lily/page-breaking.cc M lily/page-layout-problem.cc M ly/paper-defaults-init.ly M python/convertrules.py M scm/page.scm M scm/paper-system.scm ___ 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 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: What is the beef with \longa stems?
Laura Conrad lcon...@laymusic.org writes: Valentin == Valentin Villenave valen...@villenave.net writes: Valentin On Sat, Oct 9, 2010 at 7:01 PM, David Kastrup d...@gnu.org wrote: why are longas treated specially? Valentin Though I don't know how to answer that question, I suspect Valentin the answer might help solve Valentin http://code.google.com/p/lilypond/issues/detail?id=826 I suspect not, because the problem with that issue isn't that lilypond itself does something wrong with the longa tail, but because lilypond-book's treatment of the bounding box cuts off the tail. The skyline graphics attached to the issue report would appear to suggest otherwise. -- 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
GUB libgnugetops-1.3.tar.bz2
Hey, Does anybody have libgnugetopts-1.3.tar.bz2 in their download/ dir in GUB? This file is no longer available (it's been deprecated from the freebsd ports)... I discovered this the hard way. I deleted my download/ dir and tried to build GUB from scratch. :| I'm trying to bump gettext to 0.18.1.1, which seems to build fine on freebsd, but fails on mingw. But just in case we can't get gettext sorted out, I'd like to get a copy of this tarball if anybody has it. 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: GUB libgnugetops-1.3.tar.bz2
On Thu, Oct 14, 2010 at 8:15 PM, Graham Percival gra...@percival-music.ca wrote: Hey, Does anybody have libgnugetopts-1.3.tar.bz2 in their download/ dir in GUB? This file is no longer available (it's been deprecated from the freebsd ports)... I discovered this the hard way. I deleted my download/ dir and tried to build GUB from scratch. :| Does http://distfiles.macports.org/libgnugetopt/ help? (Not sure how vanilla this file is, though.) Version 1.2 can still be found online: http://cvsup13.tw.freebsd.org/pub/FreeBSD/distfiles/ http://ftp.olympus.ru/unix/freebsd/distfiles/ HTH, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB libgnugetops-1.3.tar.bz2
On Thu, Oct 14, 2010 at 8:02 PM, Valentin Villenave valen...@villenave.net wrote: On Thu, Oct 14, 2010 at 8:15 PM, Graham Percival gra...@percival-music.ca wrote: Hey, Does anybody have libgnugetopts-1.3.tar.bz2 in their download/ dir in GUB? This file is no longer available (it's been deprecated from the freebsd ports)... I discovered this the hard way. I deleted my download/ dir and tried to build GUB from scratch. :| Does http://distfiles.macports.org/libgnugetopt/ help? (Not sure how vanilla this file is, though.) It's not vanilla. :( They added some autotools stuff, and the default makefile doesn't have an all option. Attempting to compile it manually didn't work out after 10 minutes of poking around, so I'm not optimistic about putting that into GUB. Version 1.2 can still be found online: Yeah, I saw that, but what's the difference between 1.2 and 1.3 ? Is that relevant to the freebsd binaries? I don't have a freebsd box handy to test things on. The best long-term option is to use a later version of gettext. The safest+laziest short-term solution is to get a libgnugetops-1.3.tar.bz2 that somebody downloaded as part of GUB within the past, oh, 6 months? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Build: another hack for translations (fix 1323). (issue2520041)
Reviewers: ,
Description:
Build: another hack for translations (fix 1323).
Please review this at http://codereview.appspot.com/2520041/
Affected files:
M python/auxiliar/postprocess_html.py
Index: python/auxiliar/postprocess_html.py
diff --git a/python/auxiliar/postprocess_html.py
b/python/auxiliar/postprocess_html.py
index
38e325e297835021380fe2ca8b4f349d7feb421d..78978c090fdd71b4085558ce22b3a5e8c9ad2aef
100644
--- a/python/auxiliar/postprocess_html.py
+++ b/python/auxiliar/postprocess_html.py
@@ -347,15 +347,26 @@ def process_html_files (package_name = '',
s = add_header (s, prefix)
# make the return to doc index work with the online website.
if target == 'online':
+if lang_ext == '':
+# normal docs
+add_to_url = ''
+extra_depth = ''
+else:
+# translation
+add_to_url = '.' + lang_ext
+extra_depth = '../'
+old_link = ('href=\../../' + extra_depth +
+'/Documentation/web/manuals' + add_to_url + '.html\')
+devel_link = ('href=\../../../../' + extra_depth +
+'website/development' + add_to_url + '.html\')
+manuals_link = ('href=\../../../../' + extra_depth +
+'website/manuals' + add_to_url + '.html\')
+# the CG is never translated, so don't add lang_ext
if (('Documentation/contributor' in prefix) or
(int (versiontup[1]) % 2)):
-s = s.replace (
-'href=\../..//Documentation/web/manuals.html\',
-'href=\../../../../website/development.html\')
+s = s.replace ( old_link, devel_link )
else:
-s = s.replace (
-'href=\../..//Documentation/web/manuals.html\',
-'href=\../../../../website/manuals.html\')
+s = s.replace ( old_link, manuals_link )
### add footer
if footer_tag_re.search (s) == None:
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
