Issue 1080: Regression: bar lines in double bar are positioned too close together
My first patch was way too trivial and didn't cover all cases
(obviously, I made some errors while testing), so please ignore it.
Now, I have created a patch which
1) restores the former width of the double bar line
2) works properly with the segno sign
For further clarification: I changed the definition of the
double bar line in lily/bar-line.cc to center the segno sign
in respect to the double bar and the double span bar.
I misunderstood the arguments of the stencil.add_at_edge function,
so the distance between the double bar lines got corrupted. Sorry.
IMHO, the double bar fits fine with the segno sign the way it is,
we don't need a narrower double bar in combination with the segno sign.
I hope that I cleaned up the mess I introduced with the segno stuff.
Thanks,
Marc
From 936dd7d3c0794d950a1046e76d5ce273014fcc7b Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Fri, 14 May 2010 08:21:03 +0200
Subject: [PATCH] Issue 1080: corrected spacing in double bar lines
---
lily/bar-line.cc | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lily/bar-line.cc b/lily/bar-line.cc
index d3f21e5..2ace231 100644
--- a/lily/bar-line.cc
+++ b/lily/bar-line.cc
@@ -199,15 +199,15 @@ Bar_line::compound_barline (Grob *me, string str, Real h,
m.add_at_edge (X_AXIS, RIGHT, thin, 0);
m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
*/
- m.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
- m.add_at_edge (X_AXIS, RIGHT, thin, thinkern / 2);
+ m.add_at_edge (X_AXIS, LEFT, thin, thinkern);
+ m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
}
else if (str.find ("S") != NPOS || str == "|._.|")
{
// Handle all varsegno stuff
Stencil segno;
- segno.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
- segno.add_at_edge (X_AXIS, RIGHT, thin, thinkern / 2);
+ segno.add_at_edge (X_AXIS, LEFT, thin, thinkern);
+ segno.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
segno.add_stencil (Font_interface::get_default_font (me)->find_by_name
("scripts.varsegno"));
if (str == "S")
@@ -219,7 +219,7 @@ Bar_line::compound_barline (Grob *me, string str, Real h,
m.add_at_edge (X_AXIS, RIGHT, thick, 0);
m.add_at_edge (X_AXIS, RIGHT, thin, kern);
m.add_at_edge (X_AXIS, RIGHT, colon, kern);
- m.add_at_edge (X_AXIS, LEFT, segno, thinkern);
+ m.add_at_edge (X_AXIS, RIGHT, segno, thinkern);
}
else if (str == ":|S" || str == ":|S.")
{
@@ -244,7 +244,7 @@ Bar_line::compound_barline (Grob *me, string str, Real h,
Real segno_width = segno.extent (X_AXIS).length ();
m.add_at_edge (X_AXIS, LEFT, thick, 0);
m.add_at_edge (X_AXIS, LEFT, thin, kern);
- m.add_at_edge (X_AXIS, RIGHT, thick, segno_width + 2 * thinkern);
+ m.add_at_edge (X_AXIS, RIGHT, thick, segno_width + 2 * thinkern); //
+ 2 * thinkern
m.add_at_edge (X_AXIS, RIGHT, thin, kern);
}
// end varsegno block
--
1.5.4.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
How to engrave text or a note below/within the keysignature as Drone Indicator?
Hello World, I often work with drone-instruments like bagpipes which need to know how to tune their drones. In my handwritten notation I included the Drone indicator below the keysig as simple text "A" or "A/E" because the absolute notename does not matter. How do I do that in Lilypond? Or do you have any other ideas where a "Drone Signature" could be placed? Either as Notes or as Text. Nils ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't hardcode a limited set of markup signatures. (issue969046)
Looks good! http://codereview.appspot.com/969046/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: MODULE_GC_KLUDGE conditional compilation blocks
On 15/05/10 22:42, Patrick McCarty wrote: On Sat, May 15, 2010 at 2:22 PM, Graham Percival wrote: On Sat, May 15, 2010 at 10:02 PM, Ian Hulin wrote: As I understand it, these are to get round problems with Guile pre V1.8,7, which we no longer support. Is it now safe to delete this code? According to configure.in, we only require guile 1.8.2 or higher. Should that be bumped? I think Ian is referring to Guile< 1.8 (so Guile 1.6 and earlier). Is that right, Ian? Just checked the e-mail from Han-Wen. My bad - the kludge is to support Guile 1.6. We've been compiling the code unconditionally up to now, though, because MODULE_GC_KLUDGE is defined in ly_module.hh. Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Neil Puttock: > On 15 May 2010 14:37, Karl Hammar wrote: > > git-pull > > wget http://codereview.appspot.com/download/issue931041_1.diff > > patch -p1 < issue931041_1.diff --dry-run > > patch -p1 < issue931041_1.diff > > make > log 2>&1; make test-redo >> log 2>&1 > > I very rarely use `make test-redo'. The difference between test-redo and check is small: $ grep -A 6 ^test-redo: GNUmakefile test-redo: for a in `cat $(RESULT_DIR)/changed.txt` ; do \ echo removing $$a* ; \ rm -f $$a* ;\ done $(MAKE) check $ grep RESULT_DIR GNUmakefile | head -1 RESULT_DIR=$(top-build-dir)/out/test-results $ cat out/test-results/changed.txt; echo # missing final newline input/regression/out-test//test-output-distance input/regression/out-test//rest-collision-beam-note input/regression/out-test//tree $ Does it matter, if not, why is in the contributor manual ? > I basically do what Carl outlined in the other thread: > > make test-baseline > > git apply issue931041_1.diff > > make check The contributor manual says (3.6.3.1): * Initial test: make [-jX] make test-baseline make [-jX CPU_COUNT=X] check * Edit/compile/test cycle: _## edit source files, then..._ make clean_## only if needed (see below)_ make [-jX]_## only if needed (see below)_ make test-redo_## redo files differing from baseline_ make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_ * Reset: make test-clean It has an "make check" after the test-baseline which you don't have, is it redundant? git-apply and patch -p1 produces the same result, so that is not the cause of our different output: $ cd .. $ cp -a lilypond/ lilypond.b $ cd lilypond.b/ $ git-apply -v issue931041_1.diff Applied patch lily/bar-line.cc cleanly. Applied patch lily/include/bar-line.hh cleanly. Applied patch lily/include/note-spacing.hh cleanly. Applied patch lily/include/paper-column.hh cleanly. Applied patch lily/multi-measure-rest.cc cleanly. Applied patch lily/note-spacing.cc cleanly. Applied patch lily/paper-column.cc cleanly. Applied patch scm/define-grob-properties.scm cleanly. Applied patch scm/define-grobs.scm cleanly. $ cd ../lilypond $ patch -p1 < issue931041_1.diff patching file lily/bar-line.cc patching file lily/include/bar-line.hh patching file lily/include/note-spacing.hh patching file lily/include/paper-column.hh patching file lily/multi-measure-rest.cc patching file lily/note-spacing.cc patching file lily/paper-column.cc patching file scm/define-grob-properties.scm patching file scm/define-grobs.scm $ cd .. $ diff -Naur lilypond* $ > > Also, it would be much easier to look throuht the patch if it did not > > contain so many whitespace changes. In the first 100lines, I see: > > Why would you want to look at the bare diff? Isn't the diff a complete statement of what you want to change? Also you *did* cite the diff. > The whole point of > uploading the patchset to Rietveld is to make it easier to see the > changes in each file. Well, it might help someone else, but not me -- I have mail and git. Putting things on web sites and getting things from them makes it take more time. *** If I take it from the beginning: $ git-log | head -1 commit 22d889f4d27469864c31db81445e9de49774ae23 $ git-status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # issue1195044_1_2.diff # issue1195044_1_3.diff # issue931041_1.diff # log nothing added to commit but untracked files present (use "git add" to track) $ make clean > /dev/null 2>/dev/null $ make > log 2>&1 $ make test-baseline > log1 2>&1 Processing ./snippet-map-1678077630 ... Processing 41/lily-67666737 Failed files: () $ make check > log2 2>&1 Processing ./snippet-map-1678077630 ... Processing 90/lily-015675ea Failed files: () $ patch -p1 < issue931041_1.diff $ make > log3 2>&1 $ make test-redo > log4 2>&1 Processing ./snippet-map--1837524129 ... Failed files: () $ fgrep ' $ # above file attached $ make check > log5 2>&1 Processing ./snippet-map-170730255 ... Failed files: () $ # the same output is produced $ ls -1 input/regression/out-test/multi-measure-rest-multi-staff-center* input/regression/out-test/multi-measure-rest-multi-staff-center-1.eps input/regression/out-test/multi-measure-rest-multi-staff-center-1.signature input/regression/out-test/multi-measure-rest-multi-staff-center-systems.count input/regression/out-test/multi-measure-rest-multi-staff-center-systems.tex input/regression/out-test/multi-measure-rest-multi-staff-center-systems.texi input/regression/out-test/multi-measure-rest-multi-staff-center.eps input/regression/out-test/multi-measure-rest-multi-staff-center.log input/regression/out-test/multi-measure-rest-multi-staff-center.ly input/regression/out-test/multi-measure-rest-multi-staff-center.profi
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
On 16 May 2010 14:35, Karl Hammar wrote: > Does it matter, if not, why is in the contributor manual ? I think the instructions were lifted directly from the old (2.10) docs, so there may well have been changes to the test suite since they were written. TBH, when I started doing regression test checks, I bumbled along until I found something which worked. The important point is this comment: ## redo files differing from baseline If you haven't done `make check' after applying a patch, then the only files which will be retested will be the ones showing up in the initial test. I think the point of `make test-redo' is to speed up the process when working on a patch, since it only rebuilds the snippets which have changed. > It has an "make check" after the test-baseline which you don't have, is > it redundant? I've never followed that step; it seems like complete waste of time. > git-apply and patch -p1 produces the same result, so that is not the > cause of our different output: Correct. > Isn't the diff a complete statement of what you want to change? > Also you *did* cite the diff. Yes, but it was easier for me to pluck the relevant parts out than link to the individual files on Rietveld. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
On Sun, May 16, 2010 at 2:35 PM, Karl Hammar wrote: > Neil Puttock: >> > Also, it would be much easier to look throuht the patch if it did not >> > contain so many whitespace changes. In the first 100lines, I see: >> >> Why would you want to look at the bare diff? > > Isn't the diff a complete statement of what you want to change? > Also you *did* cite the diff. Yes. One of these days, we'll pin down our C++ whitespace desires, update/create a tool to do this automatically, finish merging any old patches, then run it on all our sources to get rid of this stupid problem once and for all. Sadly, we don't have the developer resources to do this now. If anybody thinks that the first couple of items on the above list are already done, I don't want to hear about it. Running fixcc.py on the /lily/ dir produces a diff that's over 100 kb; refering to this as having our desires "pinned down" is silly. > $ fgrep ' style="border-style: none; max-width: 500px;"> That can *sigh* be ignored. This particular regtest changes every time we compile stuff. In particular, I recognize the attached output as being one of the two "regular" outputs from that file. Yes, an unreliable regtest is pretty bad, but "fortunately" there's "only" one of them. Interested people can read about it here: http://code.google.com/p/lilypond/issues/detail?id=1031 > What can I say? FWIW, everything looks in order. Of course, not having much to do on the programming side of things "it's worth" isn't much in this case. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Hello, On 16 May 2010, at 16:02, Neil Puttock wrote: On 16 May 2010 14:35, Karl Hammar wrote: Does it matter, if not, why is in the contributor manual ? I think the instructions were lifted directly from the old (2.10) docs, so there may well have been changes to the test suite since they were written. TBH, when I started doing regression test checks, I bumbled along until I found something which worked. Does that mean we need to change/edit remove something from the CG? If so, let me know and I can make a patch. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
On Sun, May 16, 2010 at 4:02 PM, Neil Puttock wrote: > On 16 May 2010 14:35, Karl Hammar wrote: > >> Does it matter, if not, why is in the contributor manual ? > > I think the instructions were lifted directly from the old (2.10) > docs, so there may well have been changes to the test suite since they > were written. Actually, I think they date from much earlier than 2.10. Alternately, they might have come from "make help", which (if anything) is probably even more out of date. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
On Sun, May 16, 2010 at 4:06 PM, James Lowe wrote: > Hello, > > Does that mean we need to change/edit remove something from the CG? Yes, but not from you. People who know enough about regtests that could fix that text can change this themselves. Going through a third party would only show things down, and besides, you have enough work to do on the user doc side of things. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
On Sun, May 16, 2010 at 4:06 PM, Graham Percival wrote: > If anybody thinks that the first couple of items on the above list are > already done, I don't want to hear about it. Running fixcc.py on the > /lily/ dir produces a diff that's over 100 kb; refering to this as > having our desires "pinned down" is silly. Oops, I meant to update this once it forgot. The diff from fixcc.py is 724 K. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
On 16 May 2010 16:12, Graham Percival wrote: > Oops, I meant to update this once it forgot. > The diff from fixcc.py is 724 K. Is that with emacs 23 installed? I seem to recall there was a wide variation in indentation between 22 and 23. There are many things still wrong with fixcc.py, but it does tend to work for the majority of .cc files since I updated it. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: newSpacingSection in the middle of a measure
On 16 May 2010 05:58, Mark Polesky wrote:
> Is \newSpacingSection only supposed to be used at the
> beginning of measures? If I use it in the middle of a
> measure, I get a huge gap that I can't seem to remove.
Probably, since it creates a new SpacingSpanner which must have a
NonMusicalPaperColumn for its left bound item.
As a workaround you could insert an empty barline and override the
spacing alist:
\version "2.13.22"
\layout {
ragged-right = ##f
}
\relative c'' {
c4 c c c |
c4
\bar ""
\once \override Staff.BarLine #'(space-alist next-note) = #'(fixed-space . 0)
\newSpacingSection
c4 c
\bar ""
\once \override Staff.BarLine #'(space-alist next-note) = #'(fixed-space . 0)
\newSpacingSection c |
c4 c c c |
}
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
On Sun, May 16, 2010 at 4:20 PM, Neil Puttock wrote: > On 16 May 2010 16:12, Graham Percival wrote: > >> Oops, I meant to update this once it forgot. >> The diff from fixcc.py is 724 K. > > Is that with emacs 23 installed? I seem to recall there was a wide > variation in indentation between 22 and 23. oh, good point. It was with emacs 22.2.1. Well, that's something else to do if we ever decide to standardize on a format -- make fixcc.py check the emacs version and barf if it's not 23. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1080: Regression: bar lines in double bar are positioned too close together
On 16 May 2010 09:35, Marc Hohl wrote: > Now, I have created a patch which > 1) restores the former width of the double bar line > 2) works properly with the segno sign \bar ".S|:" is swapped round. Is this what you want? Cheers, Neil <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] python LilyLib: error and warning as functions, program_name and _version as variables
Okay to submit? http://codereview.appspot.com/1240042 This adds error and warning as functions in lilylib.py, as well as program_name and program_version as variables These were originally defined in lilypond-book.py, but make more sense in the library, which can be used by other python applications as well (e.g. musicxml2ly) Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1080: Regression: bar lines in double bar are positioned too close together
Neil Puttock schrieb:
On 16 May 2010 09:35, Marc Hohl wrote:
Now, I have created a patch which
1) restores the former width of the double bar line
2) works properly with the segno sign
\bar ".S|:" is swapped round. Is this what you want?
Of course not - thanks for the hint!
See the attached patch - I hope everything is fine now.
Thanks,
Marc
From 6c91d16ab775f9bdf4d5c63f8cc4a147889a9075 Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Fri, 14 May 2010 08:21:03 +0200
Subject: [PATCH] Issue 1080: corrected spacing in double bar lines
---
lily/bar-line.cc |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lily/bar-line.cc b/lily/bar-line.cc
index d3f21e5..a7f9024 100644
--- a/lily/bar-line.cc
+++ b/lily/bar-line.cc
@@ -199,15 +199,15 @@ Bar_line::compound_barline (Grob *me, string str, Real h,
m.add_at_edge (X_AXIS, RIGHT, thin, 0);
m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
*/
- m.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
- m.add_at_edge (X_AXIS, RIGHT, thin, thinkern / 2);
+ m.add_at_edge (X_AXIS, LEFT, thin, thinkern);
+ m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
}
else if (str.find ("S") != NPOS || str == "|._.|")
{
// Handle all varsegno stuff
Stencil segno;
- segno.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
- segno.add_at_edge (X_AXIS, RIGHT, thin, thinkern / 2);
+ segno.add_at_edge (X_AXIS, LEFT, thin, thinkern);
+ segno.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
segno.add_stencil (Font_interface::get_default_font (me)->find_by_name
("scripts.varsegno"));
if (str == "S")
--
1.5.4.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 915 Multi-measure rests dependent on prefatory matter in other staves
Karl Hammar: > Neil Puttock: ... > > I basically do what Carl outlined in the other thread: > > > > make test-baseline > > > > git apply issue931041_1.diff > > > > make check > > The contributor manual says (3.6.3.1): > >* Initial test: > > make [-jX] > make test-baseline > make [-jX CPU_COUNT=X] check > >* Edit/compile/test cycle: > > _## edit source files, then..._ > > make clean_## only if needed (see below)_ > make [-jX]_## only if needed (see below)_ > make test-redo_## redo files differing from > baseline_ > make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_ > >* Reset: > > make test-clean After yet another run: make clean > /dev/null patch -p1 < issue931041_1.diff make > log 2>&1 make check > log 2>&1 I get the "expected" output (i.e. Neil's output). Regards, /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
contributors manual
>From the debacle with "Issue 915" I have learned that . "make test-redo" does not catch regression due to program changes . rest-collision-beam-note.ly changes is more or less expected . section 8 "Regression tests" is related to section 3.6.3.1 Does "make check" after test-baseline serve any purpose ? What is the purpose for "test-redo", is it there to test changes in the regression test files themselves, and only that ? Regards, /Karl Hammar ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1080: Regression: bar lines in double bar are positioned too close together
On 16 May 2010 19:24, Marc Hohl wrote: > See the attached patch - I hope everything is fine now. Thanks, applied. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributors manual
On Sun, May 16, 2010 at 09:55:09PM +0200, Karl Hammar wrote: >From the debacle with "Issue 915" I have learned that > > . section 8 "Regression tests" is related to section 3.6.3.1 Yes, it's unfortunate that we don't at least have a link from chapter 8 to 3.6.3. It could also be useful to have such a link from somewhere in chapter 9. A patch for the chapter 8 issue would be applied quickly (assuming it still compiles). It might be good to add a subsection. A larger question is whether we should keep "3.6 Post-installation options". In the first place, the word "options" implies (to me) something akin to configuration options, not "a list of possible commands" (which is the meaning used here). Second, it might be easier to find relevant material if we just kept 3.6.1 Installing from a local build, and moved the doc-material to the Doc chapter, and the regrest material to the Regression chapter. > . rest-collision-beam-note.ly changes is more or less expected This is just due to a Critical bug, which will be fixed before 2.14 is out. This might not occur for another couple of months, but it's not a permenant thing. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributors manual
Graham Percival wrote: > A larger question is whether we should keep "3.6 > Post-installation options". In the first place, the word > "options" implies (to me) something akin to configuration > options, not "a list of possible commands" (which is the > meaning used here). How about restructuring the nodes like this (note that I renamed some node names here): 3. Compiling LilyPond 3.1 Overview of compiling 3.2 Requirements 3.3 Getting the source code 3.4 Configuring make 3.5 Compiling 3.6 Installing and testing 3.6.1 Installing from a local build 3.6.2 Testing 3.7 Generating documentation 3.7.1 Documentation editor's edit/compile cycle 3.7.2 Building documentation 3.7.3 Saving time with CPU_COUNT 3.7.4 Installing documentation 3.7.5 Building documentation without compiling 3.8 Problems etc. > Second, it might be easier to find relevant material if we > just kept 3.6.1 Installing from a local build, and moved > the doc-material to the Doc chapter, and the regrest > material to the Regression chapter. I don't think we should burden the Doc chapter with the business of building docs. I see the Doc chapter as being accessible to contributors who won't be compiling. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] hopefully fix #1036
Hello,
This fixes translated bigpages by making
- single-word targets to be lowercased
- anchors match targets
- unneeded anchors be removed, sort of
It brings back the policy of having anchors in English from original
nodenames, thanks to translationof strings which were previously been
ignored.
The patch also contains an absurdity, namely fixing an $id which is
then discarded. More refinements would come because I'm not sure if
this breaks untranslated nodes or something. Anyway, big pages are
perfectly usable now and sectioned HTML docs I've looked at keep
working.
I've had fun diving into Perl but please not more fun for a while :-)
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
From fc7ae6e36f796f5832f35055308015311340ce9a Mon Sep 17 00:00:00 2001
From: Francisco Vila
Date: Mon, 17 May 2010 02:41:46 +0200
Subject: [PATCH] Doc-build: fix targets and anchors for xrefs.
---
Documentation/lilypond-texi2html.init | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/lilypond-texi2html.init b/Documentation/lilypond-texi2html.init
index 3438478..02aefa6 100644
--- a/Documentation/lilypond-texi2html.init
+++ b/Documentation/lilypond-texi2html.init
@@ -657,10 +657,13 @@ sub lc_last($)
{
my $href = shift;
my @hrefsplit = split('/', $href);
- # change the last portion (the filename), if it exists
+ # change the last portion (the filename), if it exists;
+ # if it is a plain filename with no path, change the string as a whole
if ($#hrefsplit > 0) {
@hrefsplit[$#hrefsplit] = lc( @hrefsplit[$#hrefsplit] );
$href = join("/", @hrefsplit);
+ } else {
+$href = lc($href);
}
return $href;
}
@@ -934,9 +937,9 @@ sub lilypond_element_target_name($$$)
if ($target eq lc_last($id)) {
$id = "";
} else {
-$id = substr($id, 0, - 2); # remove the "-1"
+$id =~ s/-1$//i; # remove any trailing "-1"
}
- return ($id, $target);
+ return ($target, $target);
}
@@ -1107,7 +1110,7 @@ sub lilypond_external_href($$$)
sub remove_unneeded_anchor($)
{
- my $ref = shift;
+ my $href = shift;
my @hrefsplit = split("/", $href);
for ($i = 0; $i < @hrefsplit; $i++) {
$item = @hrefsplit[$i];
--
1.7.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
