https://codereview.appspot.com/545970043
(needs https://codereview.appspot.com/555760043/)
Compute SVG skyline based on original data
Since stencil data is used as input to formatting decisions, this
will make SVG output more similar to PS/PDF output.
Use bounding box as skylines for markup in svg backend
As there is no routine for determining skylines for utf-8-string
stencils, they normally fall back to the grob's bounding box, which is
fine. However, when there is a mixture of utf-8-string and other types
of stencil (which have associated skyline functions) in a single grob,
the entire grob gets a skyline determined only from the non-utf-8-string
stencils. This sometimes causes the text portion of such mixed grobs
(e.g. metronome marks) to collide with other grobs.
While looping over the stencils, check for utf-8-string and if found,
clear the skylines and break out of the loop. Empty skylines forces a
fallback to the grob's bounding box, which restores the behaviour from
before the patch to improve skyline approximations (issue 2148). This
does not fix the issue that there is no routine for determining skylines
for utf-8-strings when the backend is svg, but it does at least remove
the collisions without changing the behaviour in non-broken situations.
Add a suitable (svg backend) regression test.
Originally reported here.
the tempo marking in the SVG output is both lower, so that it collides with the stem of the A, and also has insufficient space between the equals sign and the preceding quarter note:
\version "2.18.0" \relative c'' { \tempo 4=76 a4 }
Patch counted down please push - don't forget this goes on top of another patch.
(needs https://codereview.appspot.com/555760043/)