Re: Close loopholes in note-collision logic (issue4293054)
LGTM http://codereview.appspot.com/4293054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com wrote: > The problem is that Lilypond processes graphical objects before it processes > pagination, making it impossible to know exactly how much space a footnote > will take up when the graphical object is processed. > > One solution to this problem would be to reprocess all top-level markups > with correct footnotes after having done the pagination, then redo the > pagination and see if all the footnotes stay the same. If so, keep the > current configuration. Otherwise, rinse & repeat. This actually seems > kinda sorta doable, although I'd have to do some homework on how these > markups are stored internally and figure out to what extent these internal > representations survive downstream into the pagination phase. > Overall comment: I think we should avoid 2 pass solutions if we can help it. Have you thought of setting a fixed width/height for the number and later filling it in? -- 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
Re: Adds automatic numbering to footnotes. (issue4244064)
On Mar 19, 2011, at 11:01 AM, Han-Wen Nienhuys wrote: > On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com > wrote: >> The problem is that Lilypond processes graphical objects before it processes >> pagination, making it impossible to know exactly how much space a footnote >> will take up when the graphical object is processed. >> >> One solution to this problem would be to reprocess all top-level markups >> with correct footnotes after having done the pagination, then redo the >> pagination and see if all the footnotes stay the same. If so, keep the >> current configuration. Otherwise, rinse & repeat. This actually seems >> kinda sorta doable, although I'd have to do some homework on how these >> markups are stored internally and figure out to what extent these internal >> representations survive downstream into the pagination phase. >> > > Overall comment: I think we should avoid 2 pass solutions if we can > help it. Have you thought of setting a fixed width/height for the > number and later filling it in? That's what I do on line 1862 of define-markup-commands.com. This uses a seed of 0 (line 1861) on the first pass, and then uses the actual value on the second pass (line 1860). The seed of 0 works well for one digit numbers, but breaks down on larger #s. Cheers, Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Sat, Mar 19, 2011 at 12:06 PM, m...@apollinemike.com wrote: >> On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com >> wrote: >>> The problem is that Lilypond processes graphical objects before it processes >>> pagination, making it impossible to know exactly how much space a footnote >>> will take up when the graphical object is processed. >>> >>> One solution to this problem would be to reprocess all top-level markups >>> with correct footnotes after having done the pagination, then redo the >>> pagination and see if all the footnotes stay the same. If so, keep the >>> current configuration. Otherwise, rinse & repeat. This actually seems >>> kinda sorta doable, although I'd have to do some homework on how these >>> markups are stored internally and figure out to what extent these internal >>> representations survive downstream into the pagination phase. >>> >> >> Overall comment: I think we should avoid 2 pass solutions if we can >> help it. Have you thought of setting a fixed width/height for the >> number and later filling it in? > > > That's what I do on line 1862 of define-markup-commands.com. This uses a > seed of 0 (line 1861) on the first pass, and then uses the actual value on > the second pass (line 1860). The seed of 0 works well for one digit numbers, > but breaks down on larger #s. But if you format the number to be flushed with space in a box for 2 digits, you should be fine, right? -- 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
Re: Adds automatic numbering to footnotes. (issue4244064)
On Mar 19, 2011, at 11:58 AM, Han-Wen Nienhuys wrote: > On Sat, Mar 19, 2011 at 12:06 PM, m...@apollinemike.com > wrote: > >>> On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com >>> wrote: The problem is that Lilypond processes graphical objects before it processes pagination, making it impossible to know exactly how much space a footnote will take up when the graphical object is processed. One solution to this problem would be to reprocess all top-level markups with correct footnotes after having done the pagination, then redo the pagination and see if all the footnotes stay the same. If so, keep the current configuration. Otherwise, rinse & repeat. This actually seems kinda sorta doable, although I'd have to do some homework on how these markups are stored internally and figure out to what extent these internal representations survive downstream into the pagination phase. >>> >>> Overall comment: I think we should avoid 2 pass solutions if we can >>> help it. Have you thought of setting a fixed width/height for the >>> number and later filling it in? >> >> >> That's what I do on line 1862 of define-markup-commands.com. This uses a >> seed of 0 (line 1861) on the first pass, and then uses the actual value on >> the second pass (line 1860). The seed of 0 works well for one digit >> numbers, but breaks down on larger #s. > > But if you format the number to be flushed with space in a box for 2 > digits, you should be fine, right? > Doable, but that causes the reverse problem - namely, too much space between the footnote and the next markup in a line for single-digit notes. Given that the majority of notes in most documents will be single-digit, it makes sense (to me) to have a single digit as the seed. One way to avoid a two-pass system is to redo the way that top-level markups are stashed in LilyPond. If LilyPond can re-evaluate these markups after page breaking is calculated, it can scan to see if their vertical extent is the same as the original. If so, keep the page breaking configuration. If not, re-calculate page breaking, taking the new vertical extents into account. Then re-update the footnotes. Do this as a loop until the new extent equal the old extent for every text markup. However, this seems like it'd take a few hundred lines of code to get up and running & should be the object of a new patch. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Sat, Mar 19, 2011 at 1:07 PM, m...@apollinemike.com wrote: > One way to avoid a two-pass system is to redo the way that top-level markups > are stashed in LilyPond. If LilyPond can re-evaluate these markups after > page breaking is calculated, it can scan to see if their vertical extent is > the same as the original. If so, keep the page breaking configuration. If > not, re-calculate page breaking, taking the new vertical extents into > account. Then re-update the footnotes. Do this as a loop until the new > extent equal the old extent for every text markup. You realize that you may end up in an infinite loop for (rare) degenerate cases, right? If anything, you should stop after the 2nd pass. -- 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
Re: Adds automatic numbering to footnotes. (issue4244064)
On Mar 19, 2011, at 12:14 PM, Han-Wen Nienhuys wrote: > On Sat, Mar 19, 2011 at 1:07 PM, m...@apollinemike.com > wrote: > >> One way to avoid a two-pass system is to redo the way that top-level markups >> are stashed in LilyPond. If LilyPond can re-evaluate these markups after >> page breaking is calculated, it can scan to see if their vertical extent is >> the same as the original. If so, keep the page breaking configuration. If >> not, re-calculate page breaking, taking the new vertical extents into >> account. Then re-update the footnotes. Do this as a loop until the new >> extent equal the old extent for every text markup. > > You realize that you may end up in an infinite loop for (rare) > degenerate cases, right? If anything, you should stop after the 2nd > pass. Good point - I can make the # of passes in the loop a variable w/ the default as 2. However, for now, would you agree that the two-pass solution is better than the alternative (too-wide / too-narrow spacing)? Although I don't have much feedback for where this would be useful, the one person who has given this code a spin (Bertrand) and who is pretty invested in all things footnote seems to like this system over a one-pass alternative (I'm not putting words into your mouth, am I, Bertrand?). Cheers, Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Sat, Mar 19, 2011 at 1:20 PM, m...@apollinemike.com wrote: >> You realize that you may end up in an infinite loop for (rare) >> degenerate cases, right? If anything, you should stop after the 2nd >> pass. > > Good point - I can make the # of passes in the loop a variable w/ the default > as 2. > > However, for now, would you agree that the two-pass solution is better than > the alternative (too-wide / too-narrow spacing)? Although I don't have much > feedback for where this would be useful, the one person who has given this > code a spin (Bertrand) and who is pretty invested in all things footnote > seems to like this system over a one-pass alternative (I'm not putting words > into your mouth, am I, Bertrand?). Technically I much prefer the 1 pass solution, although it requires constraints on how the marks are formatted (with padding space for small numbers.) -- 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
Re: Adds automatic numbering to footnotes. (issue4244064)
Am Samstag, 19. März 2011, um 17:27:23 schrieb Han-Wen Nienhuys: > Technically I much prefer the 1 pass solution, although it requires > constraints on how the marks are formatted (with padding space for > small numbers.) But practically as a publisher of critical editions, I not only prefer, but require a solution where both one-digit and two-digit footnotes are spaced properly. 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
[ANNOUNCE] Schikkers-List v0.0.3 -- the Look Less Ikli release
I'm happy to announce Schikkers-List v0.0.3 -- the Look Less Ikli release Although it's mostly useless, be sure to get it while it's hot http://lilypond.org/schikkers-list/download/schikkers-list-0.0.3-4.linux-x86.sh http://lilypond.org/schikkers-list/download/schikkers-list-0.0.3-4.mingw.exe Also check out the new and improved website, and logo http://lilypond.org/schikkers-list/ NEWS * Font scaling has been redone and looks at the display's DPI * All glyphs are drawn in black, for a less debug feel * GUILE-2.0 inside! Fresh with 13 new cross build patches to get it to also... * Run on Windows * --debug option enables grey feta items and debug messages * Templates with lyrics, multiple staffs and multiple voices per staff Using Guile-2.0 and Guile-Gnome and featuring .go-auto-compilation on GNU/Linux and Windows. The first run may be quite slow because of this, the next runs are extra snappy. Also, the first run on Windows may fail, just run a second time. Here are some screen shots http://lilypond.org/schikkers-list/images/ WHAT IS Schikkers List? Schikkers List is a GUI for LilyPond. Although there are several advanced front-ends for editing LilyPond files, graphical as well as text-based, none of them uses LilyPond to do the actual rendering. Schikkers List aims to be a dumb snappy interactive graphical shell and user interface, while outsourcing the smart music layouting to LilyPond. THANK YOU Thanks go out to Nicolas Sceaux and Valentin Villenave for their support and suggestions, to Han-Wen Nienhuys for finding an ugly font scaling bug, to Patrick McCarty for his Guile-2.0 work on LilyPond and to the Guile team, notably wingo and dsmith for their prompt help on irc on my many questions getting Guile-2.0 to cross build and run (esp. for MinGW). Enjoy, Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Sat, Mar 19, 2011 at 11:05:34PM +0100, Reinhold Kainhofer wrote: > Am Samstag, 19. März 2011, um 17:27:23 schrieb Han-Wen Nienhuys: > > Technically I much prefer the 1 pass solution, although it requires > > constraints on how the marks are formatted (with padding space for > > small numbers.) > > But practically as a publisher of critical editions, I not only prefer, but > require a solution where both one-digit and two-digit footnotes are spaced > properly. What about just adding an \override Footnote #'max-number = #99 tweak for now? (default to #9). I agree that another solution would be better in the long run, but for the purpose of keeping patches separate and stuff, would this be an ok stopgap solution? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Gets the beam collision engraver to handle autobeams (issue4287061)
Reviewers: ,
Message:
This is my attempt to get the beam-collision-engraver to handle auto
beams, except...it doesn't work! For some reason, in spite of the fact
that I'm creating AutoBeamStub grobs just fine, the acknowledger in the
beam collision engraver is not picking them up. Can anyone suggest
where the system is broken?
Cheers,
Mike
Description:
Gets the beam collision engraver to handle autobeams
intermediary
Please review this at http://codereview.appspot.com/4287061/
Affected files:
M lily/auto-beam-engraver.cc
M lily/beam-collision-engraver.cc
M scm/define-grobs.scm
Index: lily/auto-beam-engraver.cc
diff --git a/lily/auto-beam-engraver.cc b/lily/auto-beam-engraver.cc
index
dbff4e95a2f8803bfe87fa2b7afd18fe307422e9..e6c9b854060a21d7159c50cbfdd2728c85337487
100644
--- a/lily/auto-beam-engraver.cc
+++ b/lily/auto-beam-engraver.cc
@@ -71,6 +71,7 @@ private:
Moment shortest_mom_;
Spanner *finished_beam_;
vector *stems_;
+ Grob *stub_;
int process_acknowledged_count_;
Moment last_add_mom_;
@@ -147,6 +148,7 @@ Auto_beam_engraver::Auto_beam_engraver ()
forbid_ = 0;
process_acknowledged_count_ = 0;
stems_ = 0;
+ stub_ = 0;
shortest_mom_ = Moment (Rational (1, 4));
finished_beam_ = 0;
finished_grouping_ = 0;
@@ -217,6 +219,7 @@ Auto_beam_engraver::create_beam ()
for (vsize i = 0; i < stems_->size (); i++)
Beam::add_stem (beam, (*stems_)[i]);
+ beam->set_property ("auto-beam-stub", stub_->self_scm ());
announce_grob (beam, (*stems_)[0]->self_scm ());
return beam;
@@ -225,7 +228,7 @@ Auto_beam_engraver::create_beam ()
void
Auto_beam_engraver::begin_beam ()
{
- if (stems_ || grouping_)
+ if (stems_ || grouping_ || stub_)
{
programming_error ("already have autobeam");
return;
@@ -251,6 +254,8 @@ Auto_beam_engraver::junk_beam ()
stems_ = 0;
delete grouping_;
grouping_ = 0;
+ stub_->suicide ();
+ stub_ = 0;
beam_settings_ = SCM_EOL;
shortest_mom_ = Moment (Rational (1, 4));
@@ -274,6 +279,7 @@ Auto_beam_engraver::end_beam ()
delete stems_;
stems_ = 0;
grouping_ = 0;
+ stub_ = 0;
beam_settings_ = SCM_EOL;
}
@@ -416,6 +422,8 @@ Auto_beam_engraver::acknowledge_stem (Grob_info info)
durlog - 2,
Stem::is_invisible (stem));
stems_->push_back (stem);
+ if (stems_->size () == 1)
+stub_ = make_item ("AutoBeamStub", (*stems_)[0]->self_scm ());
last_add_mom_ = now;
extend_mom_ = max (extend_mom_, now) + get_event_length (ev, now);
if (recheck_needed)
@@ -537,6 +545,7 @@ ADD_TRANSLATOR (Auto_beam_engraver,
" @code{stemRightBeamCount}.",
/* create */
+"AutoBeamStub "
"Beam ",
/* read */
Index: lily/beam-collision-engraver.cc
diff --git a/lily/beam-collision-engraver.cc
b/lily/beam-collision-engraver.cc
index
39e614c2a15dea10f3b72f88110959c35dc389a1..04fcea78dbbcdccb28fccd4ac810b0e80e061a49
100644
--- a/lily/beam-collision-engraver.cc
+++ b/lily/beam-collision-engraver.cc
@@ -28,6 +28,7 @@ class Beam_collision_engraver : public Engraver
protected:
vector active_beams_;
vector signaled_beams_;
+ vector signaled_beam_stubs_;
vector end_beams_;
vector covered_grobs_;
vector covered_interior_grobs_;
@@ -35,6 +36,7 @@ protected:
DECLARE_ACKNOWLEDGER (note_head);
DECLARE_ACKNOWLEDGER (accidental);
DECLARE_ACKNOWLEDGER (clef);
+ DECLARE_ACKNOWLEDGER (auto_beam_stub);
DECLARE_ACKNOWLEDGER (key_signature);
DECLARE_ACKNOWLEDGER (time_signature);
DECLARE_ACKNOWLEDGER (beam);
@@ -47,8 +49,15 @@ public:
void
Beam_collision_engraver::stop_translation_timestep ()
{
+ /*
+ Erase all beam stubs that have been suicided.
+ */
+ for (vsize i = signaled_beam_stubs_.size (); i--;)
+if (!signaled_beam_stubs_[i]->is_live ())
+ signaled_beam_stubs_.erase (signaled_beam_stubs_.begin () + i);
+
/*
- First, for all grobs that fall to the left of a beam during
+ For all grobs that fall to the left of a beam during
a timestep (i.e. clefs, time signatures), add these to
the beams that are currently active.
*/
@@ -75,14 +84,25 @@ Beam_collision_engraver::stop_translation_timestep ()
In auto beaming, beams both begin and end during the same timestep.
This means that if there is a beam that is both in signaled_beams_ and
end_beams_, it must either be an auto beam (likely) or a beam that
- has no notes under it (highly unlikely). In either case, we cannot
account
- for the grobs under this beam, and we erase it from signaled beams.
+ has no notes under it (highly unlikely). In either case, we check for
+ a beam stub and assign covered-grobs accordingly.
*/
for (vsize i = 0; i < end_beams_.size (); i++)
for (vsize j = 0; j < signaled_beams_.size (); j++)
if (end_beams_[i] == signaled_beams_[j])
{
- sig
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
On 2011/03/18 11:22:11, Trevor Daniels wrote: LGTM I like this warning text. Much better. Trevor Applying the patch gave the following: /home/colin/lilypond-git/lily/page-layout-problem.cc: In member function 'void Page_layout_problem::solve_rod_spring_problem(bool)': /home/colin/lilypond-git/lily/page-layout-problem.cc:425: warning: conversion to 'Real' from 'vsize' may alter its value /home/colin/lilypond-git/lily/page-layout-problem.cc:427: warning: conversion to 'Real' from 'vsize' may alter its value /home/colin/lilypond-git/lily/page-layout-problem.cc: In static member function 'static scm_unused_struct* Page_layout_problem::get_spacing_spec(Grob*, Grob*, bool, int, int)': /home/colin/lilypond-git/lily/page-layout-problem.cc:861: error: expected ';' before '}' token make[1]: *** [out/page-layout-problem.o] Error 1 make[1]: Leaving directory `/home/colin/lilypond-git/build/lily' make: *** [all] Error 2 colin@Sherlock:~/lilypond-git/build$ http://codereview.appspot.com/4278058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
Reviewers: Trevor Daniels, Colin Campbell,
Message:
On 2011/03/19 23:37:50, Colin Campbell wrote:
error: expected ';'
Oops. I guess you can't teach an old dog to use a new editor.
Fixed, and I hope people do try it, because this method of suppressing
the repeated warnings changes the output. Using this patch, LilyPond
uniformly changes the 'staff-affinity that was giving her trouble,
instead of just changing it when she notices trouble.
Before the patch, LilyPond
Description:
Avoid repeats of 'staff-affinity' warning; change text.
issue 1555
Please review this at http://codereview.appspot.com/4278058/
Affected files:
M lily/page-layout-problem.cc
Index: lily/page-layout-problem.cc
diff --git a/lily/page-layout-problem.cc b/lily/page-layout-problem.cc
index
c9512fcca83a9d6908ae8237a048f47985a1fc98..febfa05bfb03ffda2331b6a7b04fa78557099e51
100644
--- a/lily/page-layout-problem.cc
+++ b/lily/page-layout-problem.cc
@@ -855,8 +855,9 @@ Page_layout_problem::get_spacing_spec (Grob *before,
Grob *after, bool pure, int
Direction after_affinity = to_dir (after->get_maybe_pure_property
("staff-affinity", pure, start, end));
if (after_affinity > before_affinity)
{
- warning (_ ("staff-affinities should only decrease"));
+ warning (_ ("adjacent non-staff lines have incompatible settings
for vertical spacing; changing staff-affinity."));
after_affinity = before_affinity;
+ after->set_property ("staff-affinity", scm_from_int
(after_affinity));
}
if (before_affinity != UP)
return before->get_maybe_pure_property ("nonstaff-nonstaff-spacing",
pure, start, end);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
LGTM. I can't think of a case where updating `after' would cause problems - this seems like a good solution. http://codereview.appspot.com/4278058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
On Sat, Mar 19, 2011 at 7:03 PM, wrote:
> LGTM.
> I can't think of a case where updating `after' would cause problems -
> this seems like a good solution.
It might cause problems if "pure" is true. When the method is called with
"pure," it shouldn't cause any side effects. For a concrete example, this
will mess up if you have
Staff
Lyrics with affinity down
Staff that sometimes disappears
Lyrics with affinity up
Staff
because the staff that sometimes disappears will trigger the warning
_before_ line breaking (with "pure" set to true). This can be fixed by
adding
if (!pure)
{
warning (...);
after_affinity = before_affinity;
}
because there isn't really a need to print out the warning every time the
pure version is called.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
On 2011/03/20 05:46:51, joeneeman wrote: This can be fixed by adding if (!pure) Thanks very much. Just in case anybody wonders, we can safely put the assignment to after_affinity inside the if (!pure) with no change, because that assignment can't change behavior. If after_affinity > before_affinity then we know before_affinity != UP so we will return without ever using after_affinity. http://codereview.appspot.com/4278058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
