Re: Looks for prebroken pieces of dead items in the pure relevant function. (issue 18090043)

[k-ohara5a5a]

This looks correct.

It includes a pointer to the potential Clef in every single measure in
'pure-relevant-grobs', but the user of that list checks whether the Clef
would be visible.

The output with annotate-spacing=##t looks correct.  The bar numbers are
still tentatively placed against the top staff-line, but now that
placement puts them only 0.5 staff-space above the upper limit of the
system extent.

Adding Clefs to the space reservation can the system height because of
the system skylines during the line-breaking stage are two
potentially-misaligned boxes: begin_of_line_extent and
rest_of_line_extent.  These boxes align at the top of the system, so the
staff-lines are conceptually discontinuous.  In the example in the
issue, while Clefs were ignored, the bar number sat fully above the
system, taking 2.25 staff-spaces additional height rather than the
proper 0.5

If anyone put lots of treble-clef staves in a system, and decreased the
minimum-distance between staves, he will see over-full pages before this
patch.

I do not understand the Todo: comment; nothing should have been suicided
at this stage.  What is the life cycle of a Clef and the copies made for
line-breaking possibilities?  Is the never-printed original Clef /ever/
is_live(), or just its broken copies?


https://codereview.appspot.com/18090043/diff/20001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

https://codereview.appspot.com/18090043/diff/20001/lily/axis-group-interface.cc#newcode227
lily/axis-group-interface.cc:227: extract_grob_set (me,
"pure-relevant-grobs", elts);
The use of pure-relevant grobs here...

https://codereview.appspot.com/18090043/diff/20001/lily/axis-group-interface.cc#newcode283
lily/axis-group-interface.cc:283: if (g->pure_is_visible (start,
visibility_end))
tests each Clef to see if it would be printed on the tentative line.

https://codereview.appspot.com/18090043/