Re: Sets TabVoice Stem height to ##f (issue 6303065)

[mtsolo]

On 2012/06/11 07:10:48, dak wrote:
> On 2012/06/11 05:34:23, MikeSol wrote:

> > This shows a case where stem height cannot be determined by stem
stencil
> > presence.  The first version of the patch works under the assumption
that
> > information about height cannot be gleaned from the stencil and must
be made
> > explicit through overrides.  I think that, even though this requires
> redundancy
> > (specifying no stencil and an empty height), if LilyPond treats
cases where
> > there is no stencil and a non-empty height (like
beam-stem-stemlet.ly), then
> the
> > method in the first patch set is better.

> What do you mean with "treats cases"?  That it implements some useful
behavior
> based on the exact given height?  Or merely that it catches the case?

> Personally, I consider it an accident waiting to happen if downing the
stencil
> is not enough to suppress its consideration.

> _Iff_ there is a situation where it is really required to have a
non-zero
> height, then setting the stencil to ##f is the wrong measure: it
should be a
> point-stencil instead.

So when stencil is #f for stems, the height should always be empty?  In
this case, patch set 2 was the correct approach, and the fact that it
failed regtests reveals a hidden bug in the handling of beamed rests
under tuplets.

If you think this is the best way to tackle it, then I'll do that.
It'll likely mean a larger patch as it'll unearth some bugs that didn't
surface with the stem work in 2.15.

http://codereview.appspot.com/6303065/