Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

[k-ohara5a5a]

Joe disallowed buildings of zero width in his skylines for reasons given
only as "avoiding numerical inaccuracies".  Could be something like
depending on the +/- sign of 0.0, or depending on advancement through
loops when we increment by a building width.

It seems a bit better, for consistency, to allow zero-width buildings,
so that point-stencils get their requested space around them as
requested by the padding settings.

Best, of course, would be to find and repair the code that cannot handle
zero-widths.  We do not yet have the choice between "a bit better" and
"best", merely "a bit better" or nothing.


https://codereview.appspot.com/7310075/diff/12001/lily/separation-item.cc
File lily/separation-item.cc (right):

https://codereview.appspot.com/7310075/diff/12001/lily/separation-item.cc#newcode156
lily/separation-item.cc:156: // If these two uses of inf combine, leave
the empty extent.
On 2013/02/16 08:05:23, dak wrote:
> The description is inaccurate ...

Comments do not say what the code does; they explain its desired effect.
This code combines extents with extra-spacings, avoiding inf - inf.  The
comment describes the case that could give inf - inf for which we depend
on particular behavior.

https://codereview.appspot.com/7310075/diff/12001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/7310075/diff/12001/scm/define-grobs.scm#newcode1951
scm/define-grobs.scm:1951: (Y-extent . ,(ly:make-unpure-pure-container
#f small-empty-interval))
Better to have commented magic numbers here, in the Grob definition,
where they can be understood.

% Empty for purposes of positioning grobs, but
% extra-spacing-height makes it non-empty for note-spacing
Y-extent = #'(+0.01 . -0.01)

Giving two similar magic number pairs a name is not worth the
complication (make-unpure-pure-container) required.

https://codereview.appspot.com/7310075/