Re: [Lilypond-auto] Issue 680 in lilypond: clusters collapse when applied to repeated chords

[lilypond]

Comment #15 on issue 680 by address@hidden: clusters collapse when applied to  
repeated chords
https://code.google.com/p/lilypond/issues/detail?id=680

Ok, reran the pixel comparisons.  The following are significantly different  
so far:
backend-excercise-1.png: 9999 differences
cluster-1.png: 9999 differences
cluster-break-1.png: 9999 differences
cluster-cross-staff-1.png: 9999 differences
cluster-style-1.png: 9999 differences
line-arrows-1.png: 9999 differences

And here is the bad thing: cluster-style-1.png and some others do not look  
good _by_ _design_.  The outline of the cluster is kept within the bounding  
box of the surrounding polygon, and since the polygon has one rather sharp  
peak, this means that the blot with which it is drawn is _seriously_  
retracted from the unrounded peak, to the degree where its original pitch  
becomes undiscernible.

Now lookup.cc states in its comments
 * NOTE: Limitations (b) and (c) arise from the fact that round edges
 * are made by moulding sharp edges to round ones rather than adding
 * to a core filled polygon.  For details of these two different
 * approaches, see the thread upon the ledger lines patch that started
 * on March 25, 2002 on the devel mailing list.  The below version of
 * round_filled_polygon () sticks to the moulding model, which the
 * majority of the list participants finally voted for.  This,
 * however, results in the above limitations and a much increased
 * complexity of the algorithm, since it has to compute a shrinked
 * polygon -- which is not trivial define precisely and unambigously.
 * With the other approach, one simply could move a circle of size
 * blotdiameter along all edges of the polygon (which is what the
 * postscript routine in the backend effectively does, but on the
 * shrinked polygon). --jr

And I am sort of afraid that the decision for the cluster drawing might  
have been tainted by the cluster drawing not sticking to its definition.   
So the question is whether it might be advisable to reduce the magic "do  
not retract any further" threshold for spiky polygon corners from its  
current ad-hoc value of 3 blot diameters (meaning that it sets in when  
corners become smaller than 20 degree which then cause the lines to the  
corner to exceed the bounding polygon in return for getting the ink closer  
to the sharp corner).

However, even when using the (rectangular) staircased clusters, the chosen  
padding is just too small for comfort.  It would seem that the cluster code  
relied too much on the previous buggy behavior (apparently the flag code  
drew clock-wise to avoid extra padding and the cluster code  
counterclockwise getting extra padding sometimes but not always) and would  
now warrant more overall padding.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings