Re: [Lilypond-auto] Issue 3255 in lilypond: \with-dimensions doesn't work with zero extension

[lilypond]

Comment #14 on issue 3255 by address@hidden: \with-dimensions  
doesn't work with zero extension
http://code.google.com/p/lilypond/issues/detail?id=3255

I partly agree to the previous comments, and partly not.

I think the situation is like follows:
before Mike's skylines, we used extents for all positioning stuff.  Back  
then, XY-extent had at least two meanings:
- it described grob dimensions, which were necessary to calculate offsets  
needed to align grobs to each other,
- it was the grob's outline, used for checking collisions.
These two tasks are similar but subtly different.

After merging skyline patch, more and more grobs (all of them?) use  
skylines to check for collisions.  This is generally a correct approach,  
and i think that we want to continue moving in that direction.  However,  
it's not clear what we should use extents for, and that needs  
consideration; the resulting API will be probably significantly different  
than the old one.

My first thought was that we should ditch extents, but that doesn't make  
sense: after all, we need to store grob dimensions somewhere (instead of  
calculating them from the skylines every time we need them).  In other  
words, first meaning described above remains valid.  Now, when we want to  
use something like \with-dimensions, what we want to change are not extents  
- we want to change grob outlines, and that will /result/ in different  
extents.  In other words, i think that extents should be derived from  
outlines, in a way similar to how X-offset is derived from self-alignment-X  
(if you want to change how a grob is aligned, you usually don't override  
X-offset - you override alignment, and that results in changed offset).

What i think should be made more prominent (and probably change its meaning  
a bit) is padding.  For example, if we wanted to ensure that there'd be a  
lot of space around dynamics, before 2.17 we could override extents like  
this:

{
  \override DynamicText #'X-extent = #'(-2 . 3)
  \override DynamicText #'Y-extent = #'(-2 . 3)
  c'\f d'\p e'\f f'
}

After skyline patch these overrides don't work like that, because  
collisions no longer are calculated from extents.  What about using padding  
for that purpose?  I imagine that it would work very similarly to  
skyline-horizontal-padding - in fact, the only difference would be that  
setting padding would have effect regardless of whether the grob used  
skylines or not.

#(ly:set-option 'debug-skylines #t)
{
  e'1 \mp
  \override DynamicText #'skyline-horizontal-padding = #0.5
  e'1 \mp
}

Of course, negative padding should be allowed and it would mean that a grob  
can overlap with other grobs.  Setting padding to -inf should do the same  
as  \with-dimensions #'(0 . 0) #'(0 . 0) did before skylines.

I think that using this padding-based approach will avoid problems that  
David outlined in comment #10.

The bottom line: i think that we should move away from using extents for  
spacing objects, and use them only for aligning and  
similar "logical", "one-dimensional" tasks (spacing in general is a 2D  
task, even if we move along one axis). I think we should  
develop "skylinish" ways of solving our spacing problems instead of going  
back to extents.

--
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