[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFC Wikimedia re-evaluates svg-renderer #386

Closed
JoKalliauer opened this issue May 18, 2021 · 6 comments
Closed

RFC Wikimedia re-evaluates svg-renderer #386

JoKalliauer opened this issue May 18, 2021 · 6 comments

Comments

@JoKalliauer
Copy link
Contributor

As already discussed on Wikimedias-phabricator, Wikimedia re-evalutes svg-renderer. Not sure if there will be a decision any time in future, or everything will kept as it is. Since I asked at inkscape#4809, as well as at librsvg#729, I also want to ask at the imho most promising candidate, about it's (resvg) personal opinion, what to consider in the re-evaluation.

I made some benchmarks at https://commons.wikimedia.org/wiki/User:JoKalliauer/SVG_test_suites. In which in all categories resvg is the winner (under librsvg/resvg/Inkscape/batik). However all benchmarks are SVG1.1 only, contain hardly CSS, which might favours resvg.

Today (I did not see it earlier) I'm writing a proposal for a discussion for the Wikimedia Hackaton, the technical conference of Wikimedia on 22.05.20 and 23.05.2020 (This weekend!). So it might be likely that within a year Wikimedia gets librsvg >=2.44 or resvg or Inkscape (instead of librsvg 2.40). Maybe argumenting with security-issues ( Common Vulnerabilities and Exposures) of unmaintained libcroco, mentioned by librsvg might help progressing.

Wikimedia has whyever a problem installing Rust. If that issue is not solvable I'm planing to suggest running a container as suggested by librsvg-developer.

I collected all wikimedia-svg-rendering-phabricator-tasks at https://www.mediawiki.org/wiki/User:JoKalliauer/phab/wikimedia-svg-rendering#table . From the currently reported bugs resvg fixes 45 of 51, inkscape fixes 40 of 51 and librsvg 2.50 fixes 28 of 51. This comparison might not be fair since all of them are librsvg 2.40-bugs.

My personal recommendation would be resvg, and a flag for changing the renderer to librsvg. librsvg and Inkscape use cario, so bugs might occour synchronous. And the Wikimedia-Community imho prefers open formats (as svg-files) edited by everyone. But the Community imho do no like program-specific features such as inkscape-files. Inkscape has the goal of providing features over providing svg that can be rendered by browsers (ref).
@RazrFalcon
Copy link
Collaborator

All I can say is that resvg supports the most SVG features compared to Inkscape, Batik and librsvg.
It also should be the fastest, since I'm using tiny-skia/Skia and not Cairo (which is pretty low). But there are still a lot of optimisations left.

However all benchmarks are SVG1.1 only, contain hardly CSS, which might favours resvg.

resvg actually has a pretty decent CSS support. Inkscape and librsvg and not that better.

And I'm not sure that librsvg supports that many if any SVG2 features. Inkscape does some, but I haven't tested them. resvg-test-suite has to be updated first to see actual picture.
SVG2 support in resvg is planed, obviously, but it's limited just by my time.

of unmaintained libcroco, mentioned by librsvg might help progressing.

The latest librsvg doesn't use it anymore. It uses Rust alternative.

Wikimedia has whyever a problem installing Rust.

Not much I can do here.

@JoKalliauer
Copy link
Contributor Author

of unmaintained libcroco, mentioned by librsvg might help progressing.

The latest librsvg doesn't use it anymore. It uses Rust alternative.

I thought about progressing anywhere away from c-librsvg-2.40, mabye to rust-librsvg or to resvg or something else.
As a user almost everything is better than c-librsvg 2.40.

SVG2 support in resvg is planed, obviously, but it's limited just by my time.

SVG2-support might be even undesired, as long as it is not released, because Wikimedia Community imho wants to have uniform renderings, Wikimedia imho does not want e.g. Inkscape-files supporting features that no one can render anymore in 20 years. Wikimedia has the idea of free reuse, so for Wikimedia I would focus on SVG 1.1.

PS: Maybe you want to join the jitsi-meeting tomorrow 15:00 (UTC) or 18:00 (EEST) at the Hackaton about reevaluating Wiki-svg-render . You know more about supported features pros&cons than me, so I would be happy to see you tomorrow.

@RazrFalcon
Copy link
Collaborator

SVG2-support might be even undesired

I'm still not sure how I would be implementing it. SVG has the version attribute, but browsers doesn't care about it and always use SVG2. Which makes testing problematic, because a lot of stuff was changed between SVG1 and SVG2.
Maybe I would have a flag like --force-svg-version=1.1

Maybe you want to join the jitsi-meeting tomorrow

Is it video-only?

@JoKalliauer
Copy link
Contributor Author
JoKalliauer commented May 21, 2021 •
edited
Loading

SVG2-support might be even undesired

I'm still not sure how I would be implementing it. SVG has the version attribute, but browsers doesn't care about it and always use SVG2. Which makes testing problematic, because a lot of stuff was changed between SVG1 and SVG2.
Maybe I would have a flag like --force-svg-version=1.1

I don't know what changed, but I think most people do not care that much about the specs. I think for Wikimedia the differentiation between SVG1.1 and SVG2 won't be necessary. ("Everything" will be better than c-librsvg2.40)

Maybe you want to join the jitsi-meeting tomorrow

Is it video-only?

https://meet.jit.si/WMhack2021-Room1 (currently 2min remaining session)

Sometimes noone speaks, it is a very informal conference, but usually not longer than 1min (so there should be sound). You can even join the room if no one is there.

You can just listen or you can switch on Microphone and or camera, or just type.

@JoKalliauer
Copy link
Contributor Author

FYI The Outcome is:

Wikimedia plans to upgrade Debian (https://phabricator.wikimedia.org/T216815) this summer, which imho depends on one person (which did not join the meeting) who has also other things to do (so when it is actually done is another question) , this summer is imho somehow related to https://en.wikipedia.org/wiki/Debian_version_history#Release_table ,
before that nothing will be changed.

After upgrading debian, WMF there might evaluate renderer. However they will use a packaged version e.g. from https://packages.debian.org/search?keywords=resvg&searchon=names or https://packages.debian.org/search?keywords=librsvg2&searchon=names . It is possible but maybe unlikely that someone from WMF packages a newer version themself. (It somehow depends on the required versions of dependencies.)

So it is kind of stalled for now.

@RazrFalcon
Copy link
Collaborator

Using debian-provided version is a dead end. It will always be way to outdated.

Thanks for the update anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@RazrFalcon @JoKalliauer