Re: Please fix: japanese doc compilation
Hello John, John Mandereau gmail.com> wrote: > I'm sorry for the delay, and unfortunately I am still quite busy. Don't mind it. I know you have your own life. > Repeating "make web" until it succeeds hides the fact it's currently not > possible to build the Texinfo manuals in Japanese as Werner pointed out; > I'll make it possible to enable building Japanese documentation in HTML only > this week-end, so that "make web" goes on working. Of course, it is up to > you to judge whether the translation is in a good shape for inclusion in the > official documentation; I generally think making translations available > earliest makes proofreading them by other people easier and speeds it up > (except I couldn't reply as quickly as I'd like lately). I'm sure. Perhaps, we should not include Japanese translation in the source codes until Texinfo supports Japanese. However, I want to make my translation available in the web. I believe my translation will help Japanese users to understand LilyPond more easily and is needed as the material for proofreading as you think. Thanks, Sawada, Yoshiki ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Graham asked me to take this patch on as part of my FrogMeister duties, so
here goes.
Chris,
Can you make a brief regression test that shows why this patch is desirable?
Joe seems to feel like it's unnecessary, because you can set the
span-arpeggio style by setting Score.Arpeggio #'stencil.
Anybody on devel,
If we use Joe's approach, there would be one type of Arpeggio for the whole
score, at least at any music moment. Is there a reason why somebody would
want to have different arpeggio stencils for different staffs? If so, then
I think Chris's solution is better than Joe's. If not, then I think we
ought to change the predefined arpeggio commands to work on Score.
Han-Wen,
You expressed concern about Chris's initial approach:
You should use get_property("stencil") unless you're doing something
special. Still better is to use a callback in the spanner which
copies the stencil from its children.
Chris replied:
I originally tried get_property, but the result was that the spanned
arpeggio copied the exact stencil from the child arpeggio, resulting in
only part of the spanned arpeggio being drawn. It appears to me that
get_property causes the stencil callback to be executed (using the data
from the child arpeggio), while get_property_data got a reference the
callback, allowing it to be run later. I looked for documentation or
mailing list posts to figure out what was going on, but couldn't find
anything that explained to me the difference between the two functions.
Looking at the code in grob-property.cc, it appears to me that my
analysis is correct, but I wouldn't be surprised if I'm oversimplifying
things or just plain wrong.
The second option you gave does not appear to me to be possible without
changing the way that spanned arpeggios are constructed. Unless I'm
mistaken, spanned arpeggios are not aware of their children - the
Span_arpeggio_engraver steals the stems and side-support-elements from
the children and feeds them to the spanned arpeggio. It seems to me that
the strategy I implemented (stealing the stencil property from a child
and feeding it to the spanned arpeggio) fits this pattern.
I did realize that the ly_symbol2scm call was not needed. I've attached
a new patch that does not include it.
And the new patch is:
---
lily/span-arpeggio-engraver.cc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lily/span-arpeggio-engraver.cc b/lily/span-arpeggio-engraver.cc
index 07958a8..9b5f0d6 100644
--- a/lily/span-arpeggio-engraver.cc
+++ b/lily/span-arpeggio-engraver.cc
@@ -61,6 +61,7 @@ Span_arpeggio_engraver::process_acknowledged ()
{
span_arpeggio_ = make_item ("Arpeggio", SCM_EOL);
span_arpeggio_->set_property ("cross-staff", SCM_BOOL_T);
+ span_arpeggio_->set_property ("stencil",
arpeggios_[0]->get_property_data ("stencil"));
}
}
--
1.5.6.3
Han-Wen, do you have any objections to the new patch?
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Carl D. Sorensen wrote: > Can you make a brief regression test that shows why this patch is desirable? > Joe seems to feel like it's unnecessary, because you can set the > span-arpeggio style by setting Score.Arpeggio #'stencil. Well, I put together a regression test, but it's not exactly "brief" (I demonstrated all of the approaches). The files are here: http://temp.mvpsoft.com/ly/arpeggios/ There are four tests: arpeggio-1.png: Using standard \arpeggioXx commands (without the patch) [*] arpeggio-2.png: Joe's idea arpeggio-3.png: Joe's idea extended to actually modifying the \arpeggioXx commands [*] arpeggio-new.png: the first test again with my patch applied. The starred versions were rendered flawlessly. Joe's way, however, required some non-intuitive \revert commands, as \arpeggioXx had no effect after the \override Score.Arpeggio commands, even if they were in different staves. Explanation of desired output: First chord: Connected, normal Second chord: Connected, bracket Third chord: Unconnected, top bracket, bottom normal Fourth chord: Unconnected, top slur, bottom arrow-up > Is there a reason why somebody would want to have different arpeggio > stencils for different staffs? If not, then I think we ought to change > the predefined arpeggio commands to work on Score. Two possibilities: organ music (which I engrave a lot of) could require such a situation; even more likely is in orchestral music, where there are often a lot of independent parts. Those possibilities, plus the possibility that existing scores could be broken, suggests to me that modifying the \arpeggioXx commands is the least desirable approach. Given the minimal invasiveness of my patch, it seems to me that even the slight possibility of someone needing this functionality should support its inclusion. My patch also makes LilyPond handle connected arpeggios in an intuitive way (to me, at least), negating the need to add caveats in the documentation. I understand, however, the reason for your thoroughness in evaluating patches, and I appreciate the excellent-quality code that results. Thanks for your time. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
On Wed, Jan 21, 2009 at 9:51 PM, John Mandereau wrote: > Repeating "make web" until it succeeds hides the fact it's currently not > possible to build the Texinfo manuals in Japanese as Werner pointed out; > I'll make it possible to enable building Japanese documentation in HTML only > this week-end, so that "make web" goes on working. Of course, it is up to > you to judge whether the translation is in a good shape for inclusion in the > official documentation; I generally think making translations available > earliest makes proofreading them by other people easier and speeds it up > (except I couldn't reply as quickly as I'd like lately). Can you make it so doc and web take a different set of languages? For the tarball distribution, I still want to build the PDFs. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
References in Contributor's Guide
Graham,
I made two mistakes in my recent work on the Contributors Guide.
1) I included an @ref{} reference to the CG, and it wasn't valid. Does
@ref{} work for the CG?
2) I didn't find out that I'd made the mistake, because I did make web from
Documentation/user, which doesn't rebuild the CG. Is there a way to rebuild
the CG and check cross references without rebuilding the entire
(multi-language) documentation tree?
Jan, I'm sorry about the broken reference. As you can see here, I thought I
had checked it out, only to find out I hadn't. Thanks for fixing my
mistake.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
Han-Wen Nienhuys gmail.com> writes: > > I'll make it possible to enable building Japanese documentation in HTML only > > this week-end, so that "make web" goes on working. Of course, it is up to > > you to judge whether the translation is in a good shape for inclusion in the > > official documentation; I generally think making translations available > > earliest makes proofreading them by other people easier and speeds it up > > (except I couldn't reply as quickly as I'd like lately). > > Can you make it so doc and web take a different set of languages? For > the tarball distribution, I still want to build the PDFs. I took the latest source code by "git". Therefore, I can revert it. But, I do not have the privilege. Revert it, John, please. Thanks, Sawada, Yoshiki ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
On Thu, 2009-01-22 at 08:06 -0700, Carl D. Sorensen wrote: > Graham asked me to take this patch on as part of my FrogMeister duties, so > here goes. > > Chris, > > Can you make a brief regression test that shows why this patch is desirable? > Joe seems to feel like it's unnecessary, because you can set the > span-arpeggio style by setting Score.Arpeggio #'stencil. > > > Anybody on devel, > > If we use Joe's approach, there would be one type of Arpeggio for the whole > score, at least at any music moment. Is there a reason why somebody would > want to have different arpeggio stencils for different staffs? If so, then > I think Chris's solution is better than Joe's. If not, then I think we > ought to change the predefined arpeggio commands to work on Score. My approach can work at the same granularity as \set connectArpeggios. That is, if the Span_arpeggio_engraver is at the PianoStaff level (which it is by default) then you can override PianoStaff.Arpeggio #'stencil to affect only the Arpeggios in that PianoStaff. I should probably explain my objection to the original approach: every time we set a user-overrideable variable in an engraver, we make it impossible for the user to set that variable directly. What's more, there is no indication in the automatically-generated docs that the user's override would be ignored. Maybe it's a contrived example, but if someone does \override Voice.Arpeggio #'stencil = #foo \override PianoStaff.Arpeggio #'stencil = #bar then they might wonder why the spanned arpeggio has a "foo" stencil even though it is created in the PianoStaff context. I think Han-Wen's approach is the "real" solution, but it's also a bit more work. You could create a new SpanArpeggio grob that gets Arpeggios as children and has, as default properties, callbacks that check the children. You need to decide what happens, though (this is also an admittedly pretty negligible problem with Chris's original patch) if two "child" arpeggios have different stencils: what happens to the span arpeggio? Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
automatic setting of `currentBarNumber'
Writing to lilypond-user, I got no reply, thus I'm sending it again to
lilypond-devel.
Werner
==
The following problem:
\score {
\relative {
c1 | c1 | c1 | c1 |% Bars 1-4
}
\score {
\relative {
c1 | c1 | c1 | c1 |% Bars 5-8
}
I know how to manually set `currentBarNumber' in the second \score
block:
\set Score.currentBarNumber = #5
However, I want to have this set automatically; for example, if I
later decide to insert two bars into the first \score block, the
starting bar number for the second \score block should be updated
accordingly.
It's rather straightforward to store the value of `currentBarNumber'
in a Scheme variable (the number `10' is just a dummy value):
#(define lastBarNumber 10)
\score {
\relative {
c1 | d1 | e1 | f1 |
\applyContext
#(lambda (x)
(set! lastBarNumber (ly:context-property x 'currentBarNumber)))
}
However, I wasn't able to make lilypond use the computed value. I
tried both `\set' and `\applyContext' (using
`ly:context-set-property!') without success.
Please advise.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
