Re: [Lilypond-auto] Issue 2148 in lilypond: vertical skylines should use stencil integrals

[lilypond]

Comment #111 on issue 2148 by address@hidden: vertical skylines should  
use stencil integrals
http://code.google.com/p/lilypond/issues/detail?id=2148

> partcombine-force.ly "V1 longer" and "Solo" too close.

This is because the letter "g" is no longer the bottom of the skyline  
everywhere.  "g" is only the bottom of the skyline at a point where there  
is no collision.

I think it is reasonable to leave this - if people want text-on-text  
vertical spacing, they should use a column markup.

> metronome-mark-broken-bound.ly swaps tremolo and dashed spanner.

Curious...this may be because the skylines are so snug that one can now  
comfortably fit under the other, eliminating the need to shift. I'll have  
to study this further.

> figured-bass-extenders-markup.ly creates an unmotivated gap between  
> second and third quarter.

Janek spotted this as well.  I've changed the default slightly to fix this.

> In script-accidental-collision.ly, collision of fermata with natural in  
> second to last measure.

Fixed.

> In figured-bass-implicit.ly, the text "implicit" gets too close to the  
> extender line which needs more vertical room above when it is the top  
> figured bass element.

It seems OK now...

> In tuplet-properties.ly, "no edges" creeps too close to tuplets: maybe  
> skylines need to be padded a bit visually, less with the extremal points  
> and a bit more with retracted parts.

Interesting...this is a good idea.  The thought crossed my mind to do a  
sort of skyline-concave-padding where, for concave skylines (or maybe even  
all skylines), the padding increased linearly as a function of how low the  
skyline was compared to its highest point.  This allows things not to get  
too snug.  I think this can be implemented later down the line.

> In slur-dynamics.ly, "dynamics outside" is no longer true, but since the  
> regtest does not explicitly ask for it, the new resolution looks  
> appropriate.  Maybe the regtest needs redesigning.

Removed the annotation.  Currently, the snug-skyline-maker is aggressive -  
if it can pack things in, it will.  It is not smart enough yet to  
say "avoid collisions with grob X by moving inside but grob Y by moving  
outside."  This type of rule-based collision resolution is used in a  
primitive form for beams.  A project later down the line could be to come  
up with some sort of Collision_resolver class with lots of virtual  
functions that a bunch of different classes inherit from.

> In tuplet-number-outside-staff-priority.ly, the second tuplet number is  
> interleaved so tightly with "tr" that it looks like a mathematical  
> subscript.

I'm not sure how to implement a good fix - there are a few possibilities.   
The one I'm leaning towards most would be extra padding in the style of the  
concave padding I talk about above for the trill glyph, as we don't want  
things dipping too low into it.

> Large vertical offset for pedal dash in pedal-ped.ly.

I don't see a significant change from master on this one - maybe I'm not  
looking in the right spot?  A visual would help.

> In chord-name-entry.ly, measure 22 and 23 have their texts combined  
> illegibly into one line.  In general, text/text would warrant more  
> padding, particularly when at similar height, than text/graphic.

I also don't see the problem here...perhaps it is fixed in a more recent  
patchset?  I'm working directly from the files in input/regression today  
(compiling docs from scratch), so there could also be a problem w/ the  
regest in its native regtest environment.  Keep me posted and thanks to  
both David and Janek for the feedback!