lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Prevents nested tuplets from colliding. (issue 4808082)


From: address@hidden
Subject: Re: Prevents nested tuplets from colliding. (issue 4808082)
Date: Sat, 17 Sep 2011 12:20:11 +0200

On Sep 6, 2011, at 9:41 AM, address@hidden wrote:

> Mike says this is not yet ready for pushing in comment #11.  We should
> not push while he is away without his confirmation.
> 
> Trevor
> 

Hey all,

I'm pretty sure that the differences I'm noticing come from more accurate 
Y-extents of stems.  However, if these Y-extents are in fact less accurate then 
we're in trouble.  All of my tests have come back reporting them as more 
accurate, but then again, I designed my own tests (like the Y-extent printer I 
sent out to the list back when I was working on stems).  If people could report 
back perceived changes in how new stem Y-extents are effecting layout (good or 
bad), this'd help me evaluate if there are any flaws in the Stem code.  For the 
moment, I don't see any.

I'm comfortable with pushing this version of the patch in its current form 
(after I re-run regtests on it and after I push other stem fixes being tossed 
around - these fixes may have an impact on this patch).  However, if people 
think the gaps between the nested tuplets needs to be controlled via a separate 
property, a new property can be added that controls the distance between nested 
TupletBracket and TupletNumber grobs (currently, there is a 
one-property-fits-all property called "padding").  It may be a good idea, 
however, to get this pushed first and then to work on that later.

> 
> http://codereview.appspot.com/4808082/diff/45009/lily/tuplet-bracket.cc
> File lily/tuplet-bracket.cc (right):
> 
> http://codereview.appspot.com/4808082/diff/45009/lily/tuplet-bracket.cc#newcode285
> lily/tuplet-bracket.cc:285: if (!scm_is_pair (scm_x_span) ||
> !scm_is_pair (scm_positions))
> Should issue programming error if user has specified invalid value for
> 'positions.
> 

Should there also be a programming error if X-positions is incorrectly set?
Also, wouldn't this erroneous setting be blocked with a property check 
(positions is number-pair? in define-grob-properties.scm).

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]