librsvg issueshttps://gitlab.gnome.org/GNOME/librsvg/-/issues2020-08-19T16:57:15Zhttps://gitlab.gnome.org/GNOME/librsvg/-/issues/76[BZ#698272] Fonts not properly rendered2020-08-19T16:57:15ZBugzilla[BZ#698272] Fonts not properly rendered## Submitted by ps@..@...cz
**[Link to original bug (#698272)](https://bugzilla.gnome.org/show_bug.cgi?id=698272)**
## Description
>>>
When generating svg files by doxygen and convert those files later to pdf via rsvg-convert I get ...## Submitted by ps@..@...cz
**[Link to original bug (#698272)](https://bugzilla.gnome.org/show_bug.cgi?id=698272)**
## Description
>>>
When generating svg files by doxygen and convert those files later to pdf via rsvg-convert I get default helvetica fonts rasterized.
Attached is example of svg input and pdf output of rsvg-convert and output of inkscape conversion from command line to show the difference.
Is it possible to fix it?
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/75[BZ#696165] audacity.svg miss the red color for small sizes2021-10-21T23:50:48ZBugzilla[BZ#696165] audacity.svg miss the red color for small sizes## Submitted by Benjamin Drung
**[Link to original bug (#696165)](https://bugzilla.gnome.org/show_bug.cgi?id=696165)**
## Description
>>>
audacity.svg miss the red color for small sizes. Open audacity.svg with rsvg-view-3 and zoom o...## Submitted by Benjamin Drung
**[Link to original bug (#696165)](https://bugzilla.gnome.org/show_bug.cgi?id=696165)**
## Description
>>>
audacity.svg miss the red color for small sizes. Open audacity.svg with rsvg-view-3 and zoom out. The red will go away at a specific point.
I initially filed the bug under Ubuntu (with screenshots attached): https://launchpad.net/bugs/1157471
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/74[BZ#695162] Style element ignored if no type attribute is specified2018-01-16T17:37:41ZBugzilla[BZ#695162] Style element ignored if no type attribute is specified## Submitted by Craig Barnes
**[Link to original bug (#695162)](https://bugzilla.gnome.org/show_bug.cgi?id=695162)**
## Description
>>>
I just noticed that if I remove type="text/css" from a style element in an SVG file, eog fails t...## Submitted by Craig Barnes
**[Link to original bug (#695162)](https://bugzilla.gnome.org/show_bug.cgi?id=695162)**
## Description
>>>
I just noticed that if I remove type="text/css" from a style element in an SVG file, eog fails to apply the styles it contains.
This doesn't seem to comply with the SVG spec at http://www.w3.org/TR/SVG/styling.html#StyleElementTypeAttribute:
"If a ‘type’ is not provided, the value of ‘contentStyleType’ on the ‘svg’ element shall be used, which in turn defaults to "text/css" [RFC2046]."
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/73[BZ#694649] test_dimensions: assertion failed (fixture->width == dimension.wi...2021-10-21T23:47:54ZBugzilla[BZ#694649] test_dimensions: assertion failed (fixture->width == dimension.width): (45 == 47)## Submitted by Martin Pitt
**[Link to original bug (#694649)](https://bugzilla.gnome.org/show_bug.cgi?id=694649)**
## Description
>>>
A lot of librsvg's checks currently fail in jhbuild. The one with most info is
/dimensions/100% ...## Submitted by Martin Pitt
**[Link to original bug (#694649)](https://bugzilla.gnome.org/show_bug.cgi?id=694649)**
## Description
>>>
A lot of librsvg's checks currently fail in jhbuild. The one with most info is
/dimensions/100% width and height: **
ERROR:dimensions.c:34:test_dimensions: assertion failed (fixture->width == dimension.width): (45 == 47)
/bin/bash: line 5: 76981 Aborted (core dumped) ${dir}$tst
FAIL: dimensions
but there are plenty which fail before, too. See [1] for the full log.
This doesn't seem to be because of the limited test environment (xvfb only), I can reproduce the same on my workstation's jhbuild with just "jhbuild buildone --check librsvg".
[1] https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-librsvg/60/artifact/librsvg.log
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/72[BZ#692425] License description is unclear2019-10-15T21:52:33ZBugzilla[BZ#692425] License description is unclear## Submitted by Petteri Aimonen
**[Link to original bug (#692425)](https://bugzilla.gnome.org/show_bug.cgi?id=692425)**
## Description
>>>
Some places of the RSVG website claim the license is GPL, while the source code says LGPL:
ht...## Submitted by Petteri Aimonen
**[Link to original bug (#692425)](https://bugzilla.gnome.org/show_bug.cgi?id=692425)**
## Description
>>>
Some places of the RSVG website claim the license is GPL, while the source code says LGPL:
http://developer.gnome.org/rsvg/2.36/
http://git.gnome.org/browse/librsvg/tree/rsvg-base.c
I grepped through the source code, and it appears that the headers of most files specify LGPL. Only some tests claim GPL.
Furthermore, the license in the documentation seems to have been changed without any kind of announcement by this commit on 2010-06-22:
http://git.gnome.org/browse/librsvg/commit/doc?id=14f3d4cef8d13e073108a5359524118099b2ac9b
So I would like a clarification on the current license of librsvg. Is it:
1) Library itself LGPL, tests and documentation GPL.
2) Library completely GPL after 2010-06-22, LGPL before it.
3) Something else?
Personally I would much prefer LGPL for the library proper. Otherwise I may have to fork an old version for use with our GPL-incompatible program.
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/71[BZ#691714] Incorrect rendering of SVG files2020-09-04T16:50:47ZBugzilla[BZ#691714] Incorrect rendering of SVG files## Submitted by Piotr Praczyk
**[Link to original bug (#691714)](https://bugzilla.gnome.org/show_bug.cgi?id=691714)**
## Description
>>>
Created attachment 233443
sample file causing problems
The text present in the file appears/di...## Submitted by Piotr Praczyk
**[Link to original bug (#691714)](https://bugzilla.gnome.org/show_bug.cgi?id=691714)**
## Description
>>>
Created attachment 233443
sample file causing problems
The text present in the file appears/disappears when zoomin in/out.
The text positioning is incorrect (see the integral sign intersecting the string "ATLAS")
**Attachment 233443**, "sample file causing problems":
![plot5.svg](/uploads/afcb87eb02935558aae5aeea6970c2d8/plot5.svg)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/70[BZ#689832] Simple SVG file rendered incorrectly2018-09-21T17:36:59ZBugzilla[BZ#689832] Simple SVG file rendered incorrectly## Submitted by Lubos Dolezel
**[Link to original bug (#689832)](https://bugzilla.gnome.org/show_bug.cgi?id=689832)**
## Description
>>>
Created attachment 230953
Problematic SVG file
I have a very simple SVG file that is rendered ...## Submitted by Lubos Dolezel
**[Link to original bug (#689832)](https://bugzilla.gnome.org/show_bug.cgi?id=689832)**
## Description
>>>
Created attachment 230953
Problematic SVG file
I have a very simple SVG file that is rendered incorrectly in all applications that use librsvg internally. In other apps (such as Inkscape or even Internet Explorer), the image shows up just fine.
I found out that if I break the topmost element group in Inkscape, it works even under librsvg. But that's not a solution...
**Attachment 230953**, "Problematic SVG file":
![Button_Single_Normal.svg](/uploads/304bb1ca9b0a7d92dd86c35cdf1b9574/Button_Single_Normal.svg)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/67[BZ#686346] [patch] Finish the implementation of "load policies"2020-06-30T23:16:22ZBugzilla[BZ#686346] [patch] Finish the implementation of "load policies"## Submitted by Tim Starling
**[Link to original bug (#686346)](https://bugzilla.gnome.org/show_bug.cgi?id=686346)**
## Description
>>>
Created attachment 226707
The patch
In January, I discussed with Christian the idea of a --no-e...## Submitted by Tim Starling
**[Link to original bug (#686346)](https://bugzilla.gnome.org/show_bug.cgi?id=686346)**
## Description
>>>
Created attachment 226707
The patch
In January, I discussed with Christian the idea of a --no-external-files flag to rsvg-convert to support the processing of untrusted files, for example on web servers. I promised to submit a patch, but never did. A week after our conversation, Christian committed some initial work on the concept, in a2e869cb700c13804056820fd4afa215e551b9c5 .
The attached patch aims to complete that work, following on from Christian's start. I added --no-external-files and --load-policy=<policy> command-line options to rsvg-convert, and introduced two additional load policies in addition to the "all permissive" one that Christian introduced.
The patch is generated by git format-patch, for use with git am.
~~**Patch 226707**~~, "The patch":
[0001-Completed-the-implementation-of-load-policies.patch](/uploads/6f840463f96b4295603cd87f1c1a2c0a/0001-Completed-the-implementation-of-load-policies.patch)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/66[BZ#684624] [rsvg-convert] Linked images aren't being rendered2019-03-01T19:22:17ZBugzilla[BZ#684624] [rsvg-convert] Linked images aren't being rendered## Submitted by Sam Phillips
**[Link to original bug (#684624)](https://bugzilla.gnome.org/show_bug.cgi?id=684624)**
## Description
>>>
Created attachment 224979
A minimal test file I created. Image is random internet test image.
I...## Submitted by Sam Phillips
**[Link to original bug (#684624)](https://bugzilla.gnome.org/show_bug.cgi?id=684624)**
## Description
>>>
Created attachment 224979
A minimal test file I created. Image is random internet test image.
I cannot get a linked image to render using rsvg-convert despite rendering correctly in a browser and in Inkscape. I have tried file:// and http:// but neither work.
On further testing I realised that rsvg-convert isn't rendering examples created by Inkscape either.
However, embedding an image works.
I have only tested this on a Mac: (OSX 10.8.2). rsvg-convert version 2.36.3
~~**Attachment 224979**~~, "A minimal test file I created. Image is random internet test image.":
![test.svg](/uploads/e3af45a24008a6529e434528050e00a0/test.svg)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/65[BZ#682040] [librsvg][port of w3c test suite] rsvg fail in a lot of case to c...2021-10-21T23:46:07ZBugzilla[BZ#682040] [librsvg][port of w3c test suite] rsvg fail in a lot of case to convert correctly to png## Submitted by bastien roucaries
**[Link to original bug (#682040)](https://bugzilla.gnome.org/show_bug.cgi?id=682040)**
## Description
>>>
the test case joined* here** adapted (quick and dirty) from inskape testcase and including...## Submitted by bastien roucaries
**[Link to original bug (#682040)](https://bugzilla.gnome.org/show_bug.cgi?id=682040)**
## Description
>>>
the test case joined* here** adapted (quick and dirty) from inskape testcase and including w3c svg 1.1 test case fail in a lot of case.
Please fix it
output of test case on file output.tar.xz
i have only run under amd64 please try on sparc (for alignement issue and strange fpu) and on other arch
Thanks
* for using do:
g++ tester.cpp -o tester
python runtests.py
** aka http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684971
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/64[BZ#681127] There is no difference between different DPIs2019-03-01T19:16:17ZBugzilla[BZ#681127] There is no difference between different DPIs## Submitted by Manuel Kaufmann
**[Link to original bug (#681127)](https://bugzilla.gnome.org/show_bug.cgi?id=681127)**
## Description
>>>
Created attachment 220225
Test case
Hello,
I've been working on a Sugar Activity that uses ...## Submitted by Manuel Kaufmann
**[Link to original bug (#681127)](https://bugzilla.gnome.org/show_bug.cgi?id=681127)**
## Description
>>>
Created attachment 220225
Test case
Hello,
I've been working on a Sugar Activity that uses Rsvg and Cairo to show an SVG image on the screen and I worked with different DPIs (my desktop that uses 75 DPI and the OLPC XO that uses 133 / 200), so I tried to set the DPI of the image (and set the default dpi for every image) but I found that it doesn't take effect.
I'm uploading a test case that loads a svg image and show it twice inside a Cairo context using 75 and 300 as DPI and there is no difference in sizes.
Am I doing something wrong here?
Thanks,
**Attachment 220225**, "Test case":
[rsvg_dpi.py](/uploads/b0251113f01e76813568f8e384a8773f/rsvg_dpi.py)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/63[BZ#680359] svg width/height:100% leads to empty screen2021-10-21T23:47:18ZBugzilla[BZ#680359] svg width/height:100% leads to empty screen## Submitted by Ralf Stephan
**[Link to original bug (#680359)](https://bugzilla.gnome.org/show_bug.cgi?id=680359)**
## Description
>>>
Created attachment 219372
example svg
In the attached SVG, changing the top line <svg...width="...## Submitted by Ralf Stephan
**[Link to original bug (#680359)](https://bugzilla.gnome.org/show_bug.cgi?id=680359)**
## Description
>>>
Created attachment 219372
example svg
In the attached SVG, changing the top line <svg...width="1000" height="600"> to ... width="100%" height="100%"> makes everything disappear, contrary to Firefox.
**Attachment 219372**, "example svg":
![out.svg](/uploads/257f706c297b425322680401960ca2ee/out.svg)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/62[BZ#674155] svg image not displayed correctly2018-02-02T15:56:53ZBugzilla[BZ#674155] svg image not displayed correctly## Submitted by Matthew
**[Link to original bug (#674155)](https://bugzilla.gnome.org/show_bug.cgi?id=674155)**
## Description
>>>
Created attachment 212095
svg file that doesn't display properly
The attached image file displays in...## Submitted by Matthew
**[Link to original bug (#674155)](https://bugzilla.gnome.org/show_bug.cgi?id=674155)**
## Description
>>>
Created attachment 212095
svg file that doesn't display properly
The attached image file displays in an odd and inconsistent manner when opened with eye of gnome. When zooming in and out the background colour(the blue ocean) fades in and out, and when scrolling from side to side quickly, one can get the ocean to disappear.
I didn't create this file myself, I just downloaded it from here (http://familypedia.wikia.com/wiki/File:Globe.svg). I'm not sure whether the svg file is badly formed, but it opens fine in Google Chrome. It also opens fine in 2.3.0, so I'm pretty sure it's not malformed.
I have no idea if any of this is relevant, but here is my system:
Ubuntu 11.10
eog 3.2.1
ATI Radeon HD 4200
GL_RENDERER = ATI Mobility Radeon HD 4200 Series
GL_VERSION = 3.3.11005 Compatibility Profile Context
GL_VENDOR = ATI Technologies Inc.
**Attachment 212095**, "svg file that doesn't display properly":
![Globe.svg](/uploads/87ceb0da8699436c1e7ca9644758cc64/Globe.svg)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/61[BZ#671214] Crash while loading svg image as pixbuf2018-06-01T23:42:30ZBugzilla[BZ#671214] Crash while loading svg image as pixbuf## Submitted by Giovanni Campagna
**[Link to original bug (#671214)](https://bugzilla.gnome.org/show_bug.cgi?id=671214)**
## Description
>>>
I've been seeing random crashes in gnome-shell recently. The coredump shows a double free i...## Submitted by Giovanni Campagna
**[Link to original bug (#671214)](https://bugzilla.gnome.org/show_bug.cgi?id=671214)**
## Description
>>>
I've been seeing random crashes in gnome-shell recently. The coredump shows a double free in a RsvgNode of type STOP - the node itself (and its container, and up recursively) is valid, but the children ptrarray contains a garbage pdata member, which causes a crash.
Memory is aligned correctly for the GPtrArray itself, but all the other members are 0, which makes me think of a double free on the structure, rather than a bug in glib.
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/60[BZ#670398] Patch for chained fractions in path data2018-01-16T15:53:52ZBugzilla[BZ#670398] Patch for chained fractions in path data## Submitted by Paul Dicker
**[Link to original bug (#670398)](https://bugzilla.gnome.org/show_bug.cgi?id=670398)**
## Description
>>>
Some images like example.svg in the attachment don't render correctly.
this happens if two number...## Submitted by Paul Dicker
**[Link to original bug (#670398)](https://bugzilla.gnome.org/show_bug.cgi?id=670398)**
## Description
>>>
Some images like example.svg in the attachment don't render correctly.
this happens if two numbers look like this:
-1.23.45 (first number is -1.23, the second is 0.45)
Changing two lines in rsvg-path.c remedies this.
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/59[BZ#667133] Fix valgrind warnings for Rsvg{Linear,Radial}Gradient2018-12-14T00:56:02ZBugzilla[BZ#667133] Fix valgrind warnings for Rsvg{Linear,Radial}Gradient## Submitted by Xan Lopez
**[Link to original bug (#667133)](https://bugzilla.gnome.org/show_bug.cgi?id=667133)**
## Description
>>>
Created attachment 204450
rsvgvalgrind.diff
I'm getting tons of warnings like this:
==21586== Con...## Submitted by Xan Lopez
**[Link to original bug (#667133)](https://bugzilla.gnome.org/show_bug.cgi?id=667133)**
## Description
>>>
Created attachment 204450
rsvgvalgrind.diff
I'm getting tons of warnings like this:
==21586== Conditional jump or move depends on uninitialised value(s)
==21586== at 0xEAE0CAD: rsvg_radial_gradient_set_atts (rsvg-paint-server.c:326)
==21586== by 0xEB04966: rsvg_node_set_atts (rsvg-base.c:1901)
==21586== by 0xEB01256: rsvg_standard_element_start (rsvg-base.c:273)
==21586== by 0xEB01DF5: rsvg_start_element (rsvg-base.c:617)
==21586== by 0x399D44230B: xmlParseStartTag (parser.c:8285)
==21586== by 0x399D44ABD7: xmlParseTryOrFinish (parser.c:10968)
==21586== by 0x399D44B7AE: xmlParseChunk (parser.c:11739)
==21586== by 0xEB02EA9: rsvg_handle_write_impl (rsvg-base.c:1077)
==21586== by 0xEB03FC9: rsvg_handle_write (rsvg-base.c:1636)
==21586== by 0x4027EEA: gdk_pixbuf__svg_image_load_increment (io-svg.c:135)
==21586== by 0x41C2601: _gdk_pixbuf_generic_image_load (gdk-pixbuf-io.c:1002)
==21586== by 0x41C29C4: gdk_pixbuf_new_from_file (gdk-pixbuf-io.c:1103)
==21586== by 0x6832E4D: pattern_value_parse (gtkstyleproperty.c:1007)
==21586== by 0x6835A17: _gtk_style_property_parse_value (gtkstyleproperty.c:2377)
==21586== by 0x66CC5E4: parse_declaration (gtkcssprovider.c:2294)
==21586== by 0x66CC8D9: parse_declarations (gtkcssprovider.c:2384)
==21586== by 0x66CCA11: parse_ruleset (gtkcssprovider.c:2416)
==21586== by 0x66CCB34: parse_statement (gtkcssprovider.c:2445)
==21586== by 0x66CCBB1: parse_stylesheet (gtkcssprovider.c:2461)
==21586== by 0x66CCDE4: gtk_css_provider_load_internal (gtkcssprovider.c:2554)
==21586== by 0x66CB254: parse_import (gtkcssprovider.c:1737)
==21586== by 0x66CB875: parse_at_keyword (gtkcssprovider.c:1924)
==21586== by 0x66CCB26: parse_statement (gtkcssprovider.c:2443)
==21586== by 0x66CCBB1: parse_stylesheet (gtkcssprovider.c:2461)
==21586== by 0x66CCDE4: gtk_css_provider_load_internal (gtkcssprovider.c:2554)
==21586== by 0x66CD109: gtk_css_provider_load_from_file (gtkcssprovider.c:2646)
==21586== by 0x66CD1F2: gtk_css_provider_load_from_path (gtkcssprovider.c:2673)
==21586== by 0x66CD53B: gtk_css_provider_get_named (gtkcssprovider.c:3175)
==21586== by 0x6814F6D: settings_update_theme (gtksettings.c:2835)
==21586== by 0x6811913: settings_init_style (gtksettings.c:1519)
The code (I think) seems alright, since the hasfoo values are actually initialized, but perhaps valgrind is confused because of the way the bits are being packed? In any case the attached patch fixes the warnings, comments welcome.
**Patch 204450**, "rsvgvalgrind.diff":
[rsvgvalgrind.diff](/uploads/5ca3ffeaf70b7c52f87498697c2455ad/rsvgvalgrind.diff)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/58[BZ#666666] use fallback resolution from the cairo context2021-10-22T00:04:58ZBugzilla[BZ#666666] use fallback resolution from the cairo context## Submitted by Christian Persch
**[Link to original bug (#666666)](https://bugzilla.gnome.org/show_bug.cgi?id=666666)**
## Description
>>>
Since the DPI is only used during rendering, rsvg should use the fallback resolution from th...## Submitted by Christian Persch
**[Link to original bug (#666666)](https://bugzilla.gnome.org/show_bug.cgi?id=666666)**
## Description
>>>
Since the DPI is only used during rendering, rsvg should use the fallback resolution from the passed cairo_t's target, if set, instead of its own default DPI setting. That also makes it easier to use the same handle with different targets, e.g. rendering on screen, and printing, without having to re-set the DPI inbetween.
rsvg_handle_set_dpi[_x_y] and the rsvg_set_default_dpi[_x_y] should be deprecated, and the internal default be -1 meaning to consult the cairo target.
Also need to make sure to set the fallback resolution on the surfaces rsvg creates internally during rendering.
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/56[BZ#666477] <tspan> x attribute not supported for explicit character positioning2018-01-16T17:47:11ZBugzilla[BZ#666477] <tspan> x attribute not supported for explicit character positioning## Submitted by Brion Vibber
**[Link to original bug (#666477)](https://bugzilla.gnome.org/show_bug.cgi?id=666477)**
## Description
>>>
Created attachment 203817
Sample SVG file: X-axis year labels run together, Y-axis labels are mi...## Submitted by Brion Vibber
**[Link to original bug (#666477)](https://bugzilla.gnome.org/show_bug.cgi?id=666477)**
## Description
>>>
Created attachment 203817
Sample SVG file: X-axis year labels run together, Y-axis labels are mispositioned
Downstream Wikipedia bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=33245
The attached file uses <tspan>'s 'x' attribute to specify explicit positions for each character in text labels on the graph. We use librsvg to rasterize PNG versions of SVGs on Wikipedia; currently deployed version (also tested 2.34.2 locally) doesn't appear to support this attribute and so lays the text out itself at what turn out to be incorrect positions.
Looks like the file is using a (possibly obscure) feature to lay out the
various characters at very specific locations:
http://www.w3.org/TR/SVG/text.html#TSpanElementXAttribute
which librsvg apparently doesn't support.
Example bit:
<tspan
x="0 9.1193962 18.238792 27.358189 55.543907 64.663307 73.7827
82.902092 111.10436 120.22376 129.32661 138.446 166.64827 175.76767 184.88707
194.00645 222.19218 231.31158 240.43097 249.55037 277.75262 286.87204 295.99142
305.09427 333.29654 342.41595 351.53534 360.65472 388.85699 397.95984 407.07925
416.19864 444.51675 453.63617 462.75555 471.87497 500.15961 509.27899 518.39838
527.51776 555.70349 564.82288 573.94232 583.06171"
y="0"
id="tspan48"
style="font-size:16.55062866px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Arial;-inkscape-font-specification:ArialMT">19801983198619891992199519982001200420072010</tspan>
**Attachment 203817**, "Sample SVG file: X-axis year labels run together, Y-axis labels are mispositioned":
![Human-Development-Index-Trends-2011.svg](/uploads/0ece5e26c44a8e697f5f651028ac9437/Human-Development-Index-Trends-2011.svg)
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/50[BZ#645201] SVG - Spaces in url() or rgba() break value2018-06-14T19:03:11ZBugzilla[BZ#645201] SVG - Spaces in url() or rgba() break value## Submitted by bez..@..com
**[Link to original bug (#645201)](https://bugzilla.gnome.org/show_bug.cgi?id=645201)**
## Description
>>>
In SVG images, use of white space between the brackets of a url() or rgba() attribute causes the ...## Submitted by bez..@..com
**[Link to original bug (#645201)](https://bugzilla.gnome.org/show_bug.cgi?id=645201)**
## Description
>>>
In SVG images, use of white space between the brackets of a url() or rgba() attribute causes the attribute to be ignored.
For example when using:
... style="fill: url( #test ); stroke: rgba( 255, 0, 0, .5 )" ...
neither attribute is applied. Any white space between the brackets triggers this bug.
>>>https://gitlab.gnome.org/GNOME/librsvg/-/issues/49[BZ#644624] no support for textPath element2018-10-24T19:30:49ZBugzilla[BZ#644624] no support for textPath element## Submitted by Pepijn Schmitz
**[Link to original bug (#644624)](https://bugzilla.gnome.org/show_bug.cgi?id=644624)**
## Description
>>>
Created attachment 183272
The SVG file in question
eog fails to render the curved text in the...## Submitted by Pepijn Schmitz
**[Link to original bug (#644624)](https://bugzilla.gnome.org/show_bug.cgi?id=644624)**
## Description
>>>
Created attachment 183272
The SVG file in question
eog fails to render the curved text in the Sinterklaas poem I created using Inkscape. It contains text curved along a spiral path, which displays and prints correctly in Inkscape itself. Inkscape saved it as an SVG file, but in the thumbnail displayed by Nautilus the curved text is not displayed, and when I open the file in eog, the curved text is completely missing as well. I will attach the file in question.
See also Ubuntu [bug 693778](https://bugzilla.gnome.org/show_bug.cgi?id=693778): https://bugs.launchpad.net/ubuntu/+source/eog/+bug/693778
**Attachment 183272**, "The SVG file in question":
![Gedicht_Anne_2010.svg](/uploads/7650f9e3ca6db7369e6d204d65cb9c16/Gedicht_Anne_2010.svg)
>>>