Re: Did VerticalAxisGroup default-staff-staff-spacing stop respecting padding in 2.17.10?

[address@hidden]

On 9 févr. 2013, at 08:47, David Kastrup <address@hidden> wrote:

> "address@hidden" <address@hidden> writes:
> 
>> -  if (b.end_ > b.start_ + EPS)
>> +  if (b.end_ >= b.start_)
> 
> That should be rather "if (b.end_ > b.start_)" to be equivalent.
> However, you are right that for "proper" emptiness, this change would
> seem correct.
> 
> We had some changes recently regarding the representation of \hspace
> that revolved around empty intervals and stuff.  Given how recent this
> was, it would not be surprising if we had some code presenting emptiness
> by a one-point interval, and the original line above seems to be
> catering for that case.  Though without the EPS, it would not appear
> that a point interval can become a non-point interval through shifting
> (after all, once two values are really equal, they can't become
> different when put through the same transform).
> 
> With boxes, including baseline parts does not really make much of a
> difference, so the code could likely get away with treating empty and
> zero-extent as mostly equivalent.
> 
> With skylines, we don't have that luxury.  Stacking a zero-height box
> between skylines now makes a large difference.  And it would appear that
> there is code that is not aware of that difference yet.

This is touching upon some deep-buried inconsistencies in the code base.  For 
example, in define-grob.scm, pure heights for grobs are defined as a point 
(line 2777) rather than an empty interval when they don't exist.  The same 
problem exists in Grob::pure_height.  Stuff like this is finally coming to the 
surface in these corner cases.  I had a bit of time this morning so I've been 
working on a solution, but it may be difficult as certain spacing conventions 
are built on these assumptions. I'll post my results whenever I get something 
that works.

Cheers,
MS