[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tied accidentals in chords still taking up space
From: |
Joe Neeman |
Subject: |
Re: Tied accidentals in chords still taking up space |
Date: |
Fri, 27 Mar 2009 13:51:41 -0700 |
On Fri, 2009-03-27 at 15:04 -0400, Chris Snyder wrote:
> Joe Neeman wrote:
> > On Thu, 2009-03-26 at 10:26 -0400, Chris Snyder wrote:
> >> Joe Neeman wrote:
> > It's not necessary to announce every grob (for example, of the three
> > copies of every breakable grob, only the middle-of-line copy gets
> > announced). The code for creating these non-announced grobs is in
> > Item::copy_breakable_items. In particular, you need the
> > get_root_system(original_grob)->typeset_grob(cloned_grob) line to give
> > your clone a layout_.
>
> That makes sense - when does this announce need to happen? Right now, I
> have it checking accidentals during calculate_positioning_done to see if
> they have layouts, and announcing them if not. Is this acceptable?
I think you should do it as soon as you clone() the accidental (in
Accidental_placement::add_accidental perhaps?).
> > This is a bit tricky. To do this properly, you might need to add a
> > Note_head::get_accidental function that has the logic for finding the
> > right accidental (you could create a new property,
> > "break-reminder-accidental-grob", for the new copy). Then you'd need to
> > change every place that does get_object("accidental-grob") to use the
> > new function; there aren't very many such places. It should be safe to
> > just pick one copy if you want to put this off until later.
>
> How about making the accidental-grob property point to a callback? I'm
> not sure if it's better or not, but I figured I'd consider the
> possibilities.
That would be better, yes. You can determine which accidental is the
right one using the same logic as Accidental::print. Note that this
logic is only valid after the line-breaking has taken place, so you
should note that in the documentation in scm/define-grob-properties.scm.
> I've gotten to the point where the spacing is being calculated
> correctly. However, it's not printing the correct accidentals - after a
> line break, there's a space where the accidentals should be, then
> accidentals printed over the noteheads. I've confirmed that the
> misplaced accidentals are the copies that aren't supposed to be printed,
> and the correct accidentals are not being printed.
In Accidental::print, are the correct accidentals committing suicide?
You might need to change the logic there.
I can't think why the accidentals would be printed over the noteheads,
though. You might get a clue if you check the value of
ape->grobs_[j]->relative_coordinate(common[X_AXIS], X_AXIS) after
accidental-placement.cc:397.
Joe
- Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space), Chris Snyder, 2009/03/26
- Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space), Joe Neeman, 2009/03/26
- Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space), Han-Wen Nienhuys, 2009/03/28
- Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space), Han-Wen Nienhuys, 2009/03/29
- Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space), Han-Wen Nienhuys, 2009/03/29
- Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space), Joe Neeman, 2009/03/29
- Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space), Han-Wen Nienhuys, 2009/03/29