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

[dak]

On 2012/06/11 07:24:33, MikeSol wrote:
> On 2012/06/11 07:10:48, dak wrote:

> > 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.

Not necessarily a hidden bug, but rather a hidden expectation.  If
LilyPond will, when setting the stencil to #f for some reason of its
own, accompany this with consistent height data, then the behavior might
be consistent and not exhibit problems.

Passing information with that sort of secret contract, however, is a bad
idea when users and/or other programmers are expected to be able to
unstencil grobs.  In that case, passing information in the height (or
otherwise manipulating it) without taking the nonexistence of the
stencil into consideration is a rather bad idea.

> 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.

As I said: these may not necessarily bugs but rather larvae: things that
are rather certain to grow into bugs under reasonably natural
conditions.

I think it would be worth the trouble to get rid of them.  In case we
have code that relies on passing information through the Y-height of a
stencil even when the stencil has been set to #f by the user, this will
require finding a different solution.

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