Page MenuHomePhabricator

CSS class are not inherited to child text/tspan elements in SVG (not general)
Closed, ResolvedPublic

Description

CSS class definitions for text elements are not inherited to the child tspan elements. See first version File:Global_Wind_Power_Cumulative_Capacity.svg (svg ; - 800px-PNG).

This is a long time known bug but I found no report here (also not on GNOME).


Version: unspecified
Severity: normal
See Also:
T68672: SVG style element ignored if no type attribute is specified

Details

Reference
bz66551

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:23 AM
bzimport set Reference to bz66551.
bzimport added a subscriber: Unknown Object (MLST).

named class overruled a general element class

As bug 66672 is present the given example is very unlucky. So I attach a much better example (temporary uploaded here https://upload.wikimedia.org/wikipedia/commons/thumb/archive/b/bd/20140616194801%21Test.svg/120px-Test.svg.png)

So I must differentiate and change the bug.
All text should be green with exception of the first.
What happens are 2 things:

  • named class overruled a general (in this case higher) element class
  • tspan and text elements without coordinate attribute get ignored from a class (so this was at beginning my second faulty conclusion)

Attached:

MW does not look at class, so bug is in librsvg. Not clear that it has been reported there.

Aklapper subscribed.

All text should be green with exception of the first.
What happens are 2 things:

  • named class overruled a general (in this case higher) element class
  • tspan and text elements without coordinate attribute get ignored from a class (so this was at beginning my second faulty conclusion)

Attached:

Cannot reproduce the problem locally anymore in librsvg2-2.44.13-1:

Screenshot from 2019-03-10 19-02-53.png (365×640 px, 46 KB)

AntiCompositeNumber lowered the priority of this task from Medium to Low.Oct 14 2020, 8:37 PM
AntiCompositeNumber moved this task from Backlog to Upstream (librsvg) on the Thumbor board.

Confirming fixed in 2.44.10.

https://commons.wikimedia.org/wiki/File:SVG_CSS_Test.svg

tests several SVG 1.1 (CSS 2) selectors.

The results for librsvg 2.40 are poor. Many selectors that should work in SVG 1.0 do not.

Can somebody test the file in a newer version of librsvg?

@Aklapper thanks.

T68551#6890974 shows that librsvg 2.50 does not handle SVG 1.0 / CSS 1.0 :lang() pseudo selectors. That is not good news for switch translated files.

The rest is very good news.

T68551#6890974 shows that librsvg 2.50 does not handle SVG 1.0 / CSS 1.0 :lang() pseudo selectors. That is not good news for switch translated files.

That's unresolved upstream https://gitlab.gnome.org/GNOME/librsvg/-/issues/649 and I'm afraid I lost track which specific, single issue this Phab task is tracking. :)

JoKalliauer changed the task status from Open to Stalled.Jun 30 2021, 2:56 PM
JoKalliauer moved this task from Backlog to update librsvg on the Wikimedia-SVG-rendering board.

https://gitlab.gnome.org/GNOME/librsvg/-/issues/649 is fixed in librsvg 2.52.2, but as written before I lost track which specific issue this task is about :(

T68551#6890974 shows that librsvg 2.50 does not handle SVG 1.0 / CSS 1.0 :lang() pseudo selectors. That is not good news for switch translated files.

":lang() selector does not match lang attribute from element's parent" in https://gitlab.gnome.org/GNOME/librsvg/-/issues/805 has been fixed in librsvg 2.52.3.

JoKalliauer claimed this task.
JoKalliauer subscribed.
  1. unclear description

As per previous comments by Glrx and Aklapper, this bug-report is (now) unclear to me.
If the problem persists please provide a minimal (not) working example, showing the specific problem.

  1. should be resolved in librsvg2.44

As per Aklapper and AntiCompositeNumber this issue should be fixed in 2.44 and I don't see a striking rendering issue.