Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1814)

Issue 4605047: Attaches bound info to beam for better normalized-endpoint calculations. (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
8 years ago by MikeSol
Modified:
7 years, 8 months ago
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

Attaches bound info to beam for better normalized-endpoint calculations. Also adds a slight modification to the print function to take into account the width of the last stem.

Patch Set 1 #

Total comments: 3

Patch Set 2 : Removes changing of beam extent and keeps bound-info #

Unified diffs Side-by-side diffs Delta from patch set Stats (+11 lines, -0 lines) Patch
M lily/beam.cc View 1 2 chunks +11 lines, -0 lines 0 comments Download

Messages

Total messages: 9
MikeSol
This, in tandem with the modification to spanner_length, leads to better optical results for feathered ...
8 years ago (2011-06-15 08:03:29 UTC) #1
Graham Percival (old account)
thanks, http://code.google.com/p/lilypond/issues/detail?id=1693
8 years ago (2011-06-15 08:26:22 UTC) #2
Neil Puttock
http://codereview.appspot.com/4605047/diff/1/lily/beam.cc File lily/beam.cc (right): http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode564 lily/beam.cc:564: + last_normal_stem (me)->extent (commonx, X_AXIS).length (); needs parentheses to ...
8 years ago (2011-06-15 21:50:51 UTC) #3
MikeSol
On 2011/06/15 21:50:51, Neil Puttock wrote: > http://codereview.appspot.com/4605047/diff/1/lily/beam.cc > File lily/beam.cc (right): > > http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode564 ...
8 years ago (2011-06-16 07:18:30 UTC) #4
MikeSol
On 2011/06/16 07:18:30, MikeSol wrote: > On 2011/06/15 21:50:51, Neil Puttock wrote: > > http://codereview.appspot.com/4605047/diff/1/lily/beam.cc ...
8 years ago (2011-06-22 13:05:57 UTC) #5
Neil Puttock
On 16 June 2011 08:18, <mtsolo@gmail.com> wrote: > left-bound-info and right-bound-info are calculated at the ...
8 years ago (2011-06-22 21:40:55 UTC) #6
mike_apollinemike.com
On Jun 22, 2011, at 11:40 PM, Neil Puttock wrote: > On 16 June 2011 ...
8 years ago (2011-06-22 21:48:33 UTC) #7
Neil Puttock
On 22 June 2011 22:48, mike@apollinemike.com <mike@apollinemike.com> wrote: > In this present case, I could ...
8 years ago (2011-06-22 22:31:42 UTC) #8
mike_apollinemike.com
8 years ago (2011-06-22 22:43:52 UTC) #9
On Jun 23, 2011, at 12:31 AM, Neil Puttock wrote:

> On 22 June 2011 22:48, mike@apollinemike.com <mike@apollinemike.com> wrote:
> 
>> In this present case, I could see the bound info being calculated via a
callback that fetches the 'quantized position property for the Y values, but the
X values would still need to be calculated by consulting the normal stems à la
lines 559-570.  Were I to place the calculation in a callback, it would require
a code dup of these lines.  To avoid this, I could create a property called
x-positions and change the name of positions to y-positions and quantized
positions to quantized-y-positions.  Then, I'd put lines 559-570 in a separate
callback for the X positions.  Lemme know if this sounds good.
> 
> I think I'd rather you keep the slightly unidiomatic code than rename
> properties (particularly since renaming positions will affect other
> grobs).

Fair 'nuf.  All of this stems from the feature of Beams whereby coordinates are
calculated in terms of X/Y instead of left/right - I think it's the only spanner
that will pose this problem.

Cheers,
MS
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b