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

[mtsolo]

On 2012/06/11 07:48:34, dak wrote:
> 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.

My compromise solution in the most recent patch set is to use Keith's
idea but to leave a comment so that people know that beam, stencil-less
stems are treated as having a height of 0 at the point of the beam
whereas unbeamed stems are heightless.  The former is the case because
otherwise the beam doesn't know where to go - it seems like a reasonable
exception.

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