- **summary**: SVG backend: error in text skylining --> SVG backend: Use
bounding box as skylines for markup
- Description has changed:
Diff:
~~~~
--- old
+++ new
@@ -1,6 +1,28 @@
-*Originally created by:* *anonymous
+https://codereview.appspot.com/582010043
-*Originally created by:*
[fedel...@gmail.com](http://code.google.com/u/100133126505215384215/)
+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.](http://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00213.html)
~~~~
- **assigned_to**: Kevin Barry
- **Needs**: -->
- **Type**: -->
---
** [issues:#3778] SVG backend: Use bounding box as skylines for markup**
**Status:** Started
**Created:** Sun Jan 05, 2014 05:39 AM UTC by Anonymous
**Last Updated:** Tue Apr 28, 2020 07:01 PM UTC
**Owner:** Kevin Barry
**Attachments:**
-
[document.svg](https://sourceforge.net/p/testlilyissues/issues/3778/attachment/document.svg)
(4.4 kB; image/svg+xml)
https://codereview.appspot.com/582010043
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.](http://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00213.html)
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:
~~~~
:::TeX
\version "2.18.0"
\relative c'' {
\tempo 4=76
a4
}
~~~~
---
Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Testlilyissues-auto mailing list
testlilyissues-a...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto