Re: Fixes heights and pure heights of stems. (issue 4898044)

[mtsolo]

I see what you mean about flags, and I think there are two ways to go
with it.

1)  Reinstate stem-begin-position and stem-end-position in this patch
(trivial: would take 10 minutes).

2)  Create a Flag grob (less trivial, I'd say two hours of work to
create the grob in define-grobs.scm, get it made in a new finalize
method for the stem engraver, copy and paste all of the flag stuff in
stem.cc into a new flag.cc, create an X-offset and Y-offset callback for
flags, and rewrite any .ly material that makes references to flags - the
docs is another story).

I like #2 for the same reason that I'd be against conflating stem
tremolos into stems.  Flags, like stem tremolos, are unique entities
that are appended to stems in certain conditions.

Cheers,
MS


http://codereview.appspot.com/4898044/diff/8002/lily/dot-column.cc
File lily/dot-column.cc (right):

http://codereview.appspot.com/4898044/diff/8002/lily/dot-column.cc#newcode140
lily/dot-column.cc:140: + stem->extent (stem, Y_AXIS)[get_grob_direction
(stem)];
On 2011/08/15 21:57:43, hanwenn wrote:
> this looks like a dimension error. what if staffspace != 1.0?

You're right - the multiplier needs to go around both elements.  Fixed
in a new patchset.

http://codereview.appspot.com/4898044/diff/8002/lily/note-spacing.cc
File lily/note-spacing.cc (right):

http://codereview.appspot.com/4898044/diff/8002/lily/note-spacing.cc#newcode276
lily/note-spacing.cc:276: stem_posns[d] = stem->pure_height (stem, 0,
INT_MAX);
On 2011/08/15 21:57:43, hanwenn wrote:
> again, height is in ss, while posns are relative to 0.5*ss

Thanks for spotting this - fixed.

http://codereview.appspot.com/4898044/diff/8002/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/4898044/diff/8002/lily/stem.cc#newcode160
lily/stem.cc:160: me->set_property ("Y-extent", ly_interval2scm
(height));
On 2011/08/15 21:57:43, hanwenn wrote:
> why don't you a callback directly on Y-extent?

I think that a call to set_property needs to be done here irrespective
of the implementation (the same was true of the old function, it was
just a different property (stem-end-position)).

http://codereview.appspot.com/4898044/