After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 771769 - In a svg file the stylesheet is not used if located in the parent directory
In a svg file the stylesheet is not used if located in the parent directory
Status: RESOLVED OBSOLETE
Product: librsvg
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2016-09-21 13:59 UTC by Pecita
Modified: 2017-12-13 18:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Pecita 2016-09-21 13:59:51 UTC 
Dear developers.

Consider this SVG image that references a stylesheet in its parent directory. The stylesheet is not taken into account while it is if one moves in the image directory. (eog 3.20.4, debian strech)

[e.svg]
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="../stroke.css" charset="utf-8"?><svg xmlns="http://www.w3.org/2000/svg" id="e" viewBox="-600 0 1000 1000">
   <g transform="matrix(1 0 0 -1 0 600)">
      <path d="M 72,42     c 53,20 88,52 88,88"/>
      <path d="M 160,130            a 50,50 0 0 1 -50,50            a 70,70 0 0 1 -70,-70            a 90,90 0 0 1 90,-90"/>
      <path d="M 130,20            a 100,100 0 0 1 60,20"/>
   </g>
</svg>

[stroke.css]
path {
	fill:none;
	stroke:#36c;
	stroke-width:40;
	stroke-linecap:round;
}
Regards,
Philippe
Comment 1 Felix Riemann 2016-09-21 17:31:10 UTC 
I think the librsvg devs have to decide about that as it appears to be on purpose.

The thing is that eog sets the SVG basepath to the path of the SVG.
When loading external resources librsvg (which handles SVGs for eog) makes some security checks. One such check appears to be enforcing that file resources have the basepath as prefix, which means that loading of "../stroke.css" will be denied while "./stroke.css" or "sub/stroke.css" would work.
Comment 2 Pecita 2016-09-23 01:12:49 UTC 
Thank you for this analysis and clear explanation.
Excuse me stress. I do it because the gene is significant. Also, the rfc3987 requires accepting this path.
Q1? The Security check seems to be paranoid delirium: can someone explain?
Q2? Can you change this behavior in the librsvg API call?
Q3? Is it worth opening a librsvg bug? If so, would you do it?
Comment 3 Pecita 2016-09-23 05:57:11 UTC 
I'm sorry, I did not see that the bug was reassigned to librsvg. Q1?, and Q2? are.
Comment 4 Felix Riemann 2016-10-02 10:28:33 UTC 
(In reply to Pecita from comment #2)
> Q2? Can you change this behavior in the librsvg API call?

No, the API only let's me set the base URI.
Comment 5 Pecita 2016-10-04 04:55:40 UTC 
This bug creates a problem of general consistency with other libraries. If for example I imports the svg in FontForge, FF relies on libraries respecting the specification, applies the stylesheet and creates an object that conforms to user expectation, different from eog.
librsvg can not make a such decision alone.
(May be eog could use an other librarie than librsvg?)
Comment 6 GNOME Infrastructure Team 2017-12-13 18:24:21 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/154.