On Nov 27, 2011, at 1:21 AM, Keith OHara wrote:
> On Sat, 26 Nov 2011 14:48:29 -0800, m...@apollinemike.com
> <m...@apollinemike.com> wrote:
>
>> On Nov 26, 2011, at 9:56 PM, Keith OHara wrote:
>>
>>> Mike, Maybe change-clefs should not get the full extra-spacing-height by
>>> default.
>>
>> I could do this if I could call Item::break_visible before line breaking
>> (which would let me know which clefs are change clefs as opposed to
>> beginning-of-line-clefs). However, I remember Neil saying that this was a
>> bad idea, although I don't remember why. Any ideas why this call isn't
>> Kosher?
>>
>
> Oops. I was thinking the smaller change clef was a different "grob", but it
> is not.
>
> 'break_visible' calls break_status_dir() to look up whether an item is
> visible based on the results of line-breaking, so you don't want that. Now I
> see that the clef:calc_glyph_name() does the same.
>
But break_status_dir doesn't seem to be contingent on line breaking (again, I
could be wrong). It actually seems to be the opposite - line breaking can't
happen w/o break_status_dir being called first.
Direction
Item::break_status_dir () const
{
if (original ())
{
Item *i = dynamic_cast<Item *> (original ());
return (i->broken_to_drul_[LEFT] == this) ? LEFT : RIGHT;
}
else
return CENTER;
}
The only function call within this function is to original (), which itself is
a simple getter that just returns a pointer to original_.
broken_to_drul_ is populated with copy_breakable_items (), which itself is
called via discretionary_processing (), which is called first in
System::pre_processing () (before any of the springs and rods calculations take
place). So, by the time any pure height approximation is required, it seems
that the breaking of items into pieces would already be done and that a
function call to Item::break_status_dir would be safe.
> I think all the Clefs that exist before line-breaking should be change clefs,
> with the begin-of-line clefs added afterwards. Probably best if no Clefs use
> the pure-from-neighbor height, certainly not CueClefs.
>
If my logic above holds, then this can be accomplished while preserving one
grob (Clef).
> The distinction between beginning-of-line and middle-of-line spacing is made
> with 'space-alist'. Most of the spacing based on the meaning, rather than
> extent, of symbols is done with that system.
> Actually, your "don't-hang-over-me" rule would fit there nicely as a new type
> in a 'space-alist' to go alongside "minimum-space", "semi-fixed-space" etc.
> It could be "no-overlap-space" and use the extent of the Item and the
> next-note column rather than their skylines.
>
I've toyed around with this idea - it would take me a while to figure out how
to integrate it into Staff_spacing::get_spacing, but it seems completely
appropriate. Perhaps a last 2011 or first 2012 project.
>> Perhaps a stupid question, but why does LilyPond even take ledger lines into
>> account if they have no vertical or horizontal extent? How do they factor
>> into the spacing calculations?
>>
>
> Neighboring note-columns are allowed to tuck under ledger lines, but not
> within the ledger lines. {e'''8 cis'' e''' fis'' }
> The NoteHead has extra-spacing-height to enforce this rule.
>
Ah, all is clear. Note_head::include_ledger_line_height goes to 1 unit away
from the staff. So the extra spacing height for bar lines should be something
like 1.01. I'll give that a shot.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
