LilyIssues / Issues / #1434 SVG backend: xml:space="preserve" is needed forand/or

Google Importer - 2010-12-05

Originally posted by: v.villenave

I'm not sure librsvg is at fault: I've downloaded Eye of GNOME (only to test your hypothesis!), and here are the results I get using the following code:

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="50" xml:space="preserve">
<rect x="0" y="0" width="100%" height="100%" style="fill:blue;" />
<text x="50%" y="50%" fill="orange" font-size="30" text-anchor="middle" > LilyPond</text>
</svg>

Perhaps a more advanced test file is required?

with-preserve.png

without-preserve.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-05

Originally posted by: pnorcks@gmail.com

You're right, something else is causing the bug in librsvg. I'm narrowing it down right now...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-05

Originally posted by: pnorcks@gmail.com

Okay, here's an example:

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="50" xml:space="preserve">
<rect x="0" y="0" width="100%" height="100%" style="fill:blue;" />

<path transform="scale(0.005, -0.005)" d="M0 0" />
<text x="50%" y="50%" fill="orange" font-size="30" text-anchor="middle">LilyPond</text>
</svg>

The transform attribute value is not arbitrary, since the LilyPond SVG output uses that value for scaling down font-glyph path data.

I tested in Eye of Gnome, Gimp, geeqie, and gqview, which all use librsvg.

test.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-05

Originally posted by: pnorcks@gmail.com

To be more accurate, LilyPond uses values that look like this:

transform="translate(84.2198, 18.8442) scale(0.0040, -0.0040)"

But the "translate" part is not necessary to reproduce the bug, and the scaling values are close to the ones from my previous comment.

I should note that only <path> elements immediately before <text> seem to trigger the bug, not <rect> or <polygon> or any other element.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-05

Originally posted by: pnorcks@gmail.com

After further testing, this issue is much more strange than I initially believed.

If I make any further discoveries, I'll link to the relevant GNOME Bugzilla.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-05

Originally posted by: v.villenave

Looks weird indeed.
Please let me know if you prefer someone else to send them a bug report :-)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-06

Originally posted by: pnorcks@gmail.com

I'm having a blast trying to fix the librsvg issues... ;)

Here's a report for one of the problems:
https://bugzilla.gnome.org/show_bug.cgi?id=636661

There are probably more to find, but that will have to wait for another day.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-07

Originally posted by: v.villenave

Wow, I can't believe you even sent them a patch! :-)

What about other SVG rendering engines? Does the "preserve" attribute work appropriately e.g. in Firefox, Inkscape or Karbon?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2010-12-07

Originally posted by: pnorcks@gmail.com

Yes, the "preserve" attribute works correctly everywhere else I've checked: Chromium, Firefox, Inkscape, Opera, Batik Squiggle, etc.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Federico Bruni - 2016-06-08

then moved here:
https://bugzilla.gnome.org/show_bug.cgi?id=636660

unfortunately the patch has been ignored

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Étienne Beaulé - 2017-08-10

xml:space is getting deprecated, and it's getting replaced by the CSS white-space. When trying these properties in Chrome 59.0.3071.115, xml:space had no effect, but white-space's effect was too extreme, shifting all text too far to the right. It will be important to remove the newline at the beginning of each <tspan block.

Last edit: Étienne Beaulé 2017-08-15

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Kastrup - 2017-08-16

How about using   for spaces in positions where they would otherwise be removed? I think that changing characters to something else should be avoided if possible.

Last edit: David Kastrup 2017-08-16

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Étienne Beaulé - 2017-08-16

As it's just another representation of the same character, it has no effect. Tying it in with bug 4678, while changing characters should be avoided, a non-breaking space (U+00A0) was the correct character to use, and the use of U+0020 was in error, creating a bug.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Kastrup - 2017-08-16

As it's just another representation of the same character, it has no effect.

Huh? I thought the whole point of character entities was to avoid interpretation according to XML syntax so I should be surprised if <text>  </text> should have the spaces expressed via character entities removed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- David Kastrup - 2017-08-19
  
  Ok, I tried this. Indeed, no effect. Stripping the spaces is indeed not really a feature of XML syntax: in spite of XML being usually formatted and indented nicely, all spaces are part of the content and thus   makes no difference: it is the text (and tspan) tag itself that takes that content and then normalized spaces.
  
  Ugh. xml:space looks like the originally designed way to deal with that: that it is apparently not well-supported is surprising, to say the least.
  
  So apparently my "I cannot believe things are that broken" hunches are not worth a whole lot: I should leave the field to the people actually working with that stuff.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Étienne Beaulé - 2017-08-18

Issue 1434: Fix text spacing in SVG

This change makes every SVG contain a style tag with the white-space
property set to include all white-space (pre). This will cause all
white-space to be applied, and not be ignored.

As SVG files with -dsvg-woff set already appended a style tag, the
woff-header now only appends their settings, with a new define to close
the style tag.

The main difficulty arising with this change was with the newline
character that appears after each opening tag. To rectify, a boolean
parameter was added to define(s) on whether to insert a newline for
opening tags, and the appropriate value was passed to all uses of the
define(s).

http://codereview.appspot.com/321460043

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Étienne Beaulé - 2017-08-18

Description has changed:

Diff:

assigned_to: Étienne Beaulé

Needs: -->

Type: --> Defect
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-08-18

Patch: new --> review
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-08-18

Passes make, make check and a full make doc.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Description has changed:

Diff:

--- old
+++ new
@@ -1,6 +1,8 @@
-*Originally created by:* *anonymous
+http://codereview.appspot.com/321460043

-*Originally created by:* [pnorcks@gmail.com](http://code.google.com/u/pnorcks@gmail.com/)
+
+
+*Originally created by:* [pnorcks@gmail.com]

 If the value inside &lt;text&gt; or &lt;tspan&gt; has leading or trailing whitespace characters, these whitespace characters are removed by default.&nbsp; This behavior agrees with the SVG/XML recommendations.

Patch: review --> countdown

Anonymous - 2017-08-22

Patch on countdown for August 25th

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-08-25

Patch: countdown --> push
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-08-25

Patch counted down - please push.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-08-26

labels: --> Fixed_2_21.0

status: Started --> Fixed

Patch: push -->
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-08-26

author Étienne Beaulé beauleetienne0@gmail.com
Fri, 18 Aug 2017 03:15:34 +0100 (23:15 -0300)
committer James Lowe pkx166h@gmail.com
Sat, 26 Aug 2017 10:39:07 +0100 (10:39 +0100)
commit 28670249d4116d8828d2632e23617a4a5efd4230

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

SVG backend: xml:space="preserve" is needed forand/or

Issue Tracker for LilyPond

Searches

Help

#1434 SVG backend: xml:space="preserve" is needed forand/or

Related

Discussion