Page MenuHomePhabricator

[Epic] SVG client side rendering
Open, LowPublic

Assigned To
None
Authored By
bzimport
Oct 4 2005, 12:31 AM
Tokens
"Like" token, awarded by 4nn1l2."Like" token, awarded by Habitator_terrae."Love" token, awarded by JoKalliauer."Like" token, awarded by ToBeFree."Like" token, awarded by Liuxinyu970226."Love" token, awarded by MichaelSchoenitzer."Heartbreak" token, awarded by sladen."Love" token, awarded by FoXFTW."Like" token, awarded by He7d3r."Like" token, awarded by fbstj."Love" token, awarded by Perhelion."Like" token, awarded by Ricordisamoa.

Description

Please add an option to allow client side SVG rendering.

See Also: T10901: [DO NOT USE] SVG rasterisation and management on Wikimedia sites (tracking)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Considering bunch of Brion's new tasks, how about converting this in fact Tracking-Neverending task either to subproject of Wikimedia-SVG-rendering or project of its own?

Change 182332 abandoned by Ricordisamoa:
[WIP] enable native client-side rendering of SVG images

Reason:
I've rebased the change just in case someone wants to revive it, but I'm abandoning it as it was nothing more than a proof of concept. Ongoing work by Brion at T134482

https://gerrit.wikimedia.org/r/182332

In T5593#78746, @cscott wrote:

Note that the 'lang' option won't work for client-side SVG rendering; see bug 58920.

That's T60920: lang support for SVG images using SystemLanguageAttribute ill-defined and not properly supported in browsers now; just quoting myself to link the bugs properly in phabricator.

If you're intersted in see SVGs here is a script for you.

JoKalliauer claimed this task.

If you're intersted in see SVGs here is a script for you.

Thanks to @Habitator_terrae : there is now an option to allow client side SVG rendering:

Installation

Add following code to https://meta.wikimedia.org/wiki/Special:MyPage/global.js:

//[[:de:Benutzer:Habitator terrae/svgEinbinden]]
mw.loader.load('https://de.wikipedia.org/w/index.php?title=Benutzer:Habitator terrae/svgEinbinden.js&action=raw&ctype=text/javascript');

Finish!

Wasn't this bug about native client-side SVG rendering, without relying on third-party scripts?

@AfroThundr3007730 : The description is "Please add an option to allow client side SVG rendering.", therfore in my opinion this request/task is resolved, but I would agree there should be another new phabricator-Task about "Native client-side SVG rendering, without relying on third-party scripts".

I believe that's what this bug is already doing, judging by the related tasks list, comments, and commits. Changing the title might be more apt than closing (something like "Support native client-side SVG rendering"). Also when considering that its related subtasks are still open, it doesn't make much sense to close at this point.

@AfroThundr3007730 : According to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs supporting native client-side SVG rendering seems to be impossible/stalled within the next years, not even for specific SVGs T208578 .
Anyway if someone whats to render it on client-side (f.e. animated SVGs) it is possible T5593#5234639 .

That's why this is an "Epic" bug (and should track such blocking issues)... nobody said it would be easy (if at all possible) to implement.

Custom user scripts can not be quoted as a "solution" here, as the issue is obviously unfixed in the MediaWiki software itself.

In that case, since this is a long-running epic -- one who's main task has not yet been resolved -- I have reopened it, and also added the other task for tracking.

Seeing https://www.mediawiki.org/wiki/Inline_SVG_use today i was wandering whether there is a phabricator issue for allowing svg direct rendering in Mediawiki core if site administrators choose to allow this. For many intranet sites this would be a very useful feature especially for generated svg that e.g. comes from graphviz or similar tools.

@AfroThundr3007730 : According to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs supporting native client-side SVG rendering seems to be impossible/stalled within the next years, not even for specific SVGs T208578 .
Anyway if someone whats to render it on client-side (f.e. animated SVGs) it is possible T5593#5234639 .

Publishing on WP is publishing for public - not for those installing something special for themselves only!

I suggest general client side SVG rendering for inline SVG in WP and all SVG media smaller than its 500px PNG representation. SVG media should allow links into WP (and interwiki) only. Inline SVG may be limited to templates and links there to WP (and interwiki) only as well.

Advantages:

  • data driven graphics
  • multiple icons from single file
  • graphics transforms (mirrored hieroglyphs for rtl writing e. g.)
  • many many more

I'd really appreciate using a single SVG source file instead of about 100 png icons to write a hiero sentence. Out in the wild most hieros face right. I'd really appreciate a possibility for Wikipedia hieroglyphs to do so as well. Client side svg rendering would do that.

And what about some [[File:ATQuellenNoLnk.svg]]? As you might guess I have an ATQuellen.svg file here having a couple of links pointing to Wikipedia pages. How could I have such links in an svg file uploaded to Wikimedia?

I'd really appreciate using a single SVG source file instead of about 100 png icons to write a hiero sentence. Out in the wild most hieros face right. I'd really appreciate a possibility for Wikipedia hieroglyphs to do so as well. Client side svg rendering would do that.

And what about some [[File:ATQuellenNoLnk.svg]]? As you might guess I have an ATQuellen.svg file here having a couple of links pointing to Wikipedia pages. How could I have such links in an svg file uploaded to Wikimedia?

About hieroglyphs, that's probably T214232: Hieroglyph images should be replaced with SVG versions or unicode font (Noto Sans Egyptian Hieroglyphs)

About links inside SVG images, if SVG are ever embedded as SVG, they won't have hyperlink capabilities, because they'll be served inside <img> tags and not as *inline* SVG.

About hieroglyphs, that's probably T214232: Hieroglyph images should be replaced with SVG versions or unicode font (Noto Sans Egyptian Hieroglyphs)

That's next step after SVG can be handled senibly.

they'll be served inside <img> tags and not as *inline* SVG.

Why? Why not offer both and especially inline SVG for a limited number of paths especially for replacement of annotated images?

SVG inside <img> tags have some restrictions in place that make them safe enough to be enabled on WMF wikis. Inline SVG would expose users to privacy problems or malicious scripts, and I foresee that they will never be allowed.

We don't enter html on Wikipedia. We don't enter img tags there either. Why not integrate a limited subset of SVG tags for inline image capabilities? Why not offer path tags, simple shape tags, use tags, interwiki links and transform tags only? What security flaws could you think of then?

I believe simple Unicode hieroglyphs already display on Windows browsers because Windows has a hieroglyph font.

To make hieroglyphs work in general, WMF just needs to supply the CSS that points to a webfont on a WMF server. (I understand that using Google's CSS is a bad idea because it allows Google tracking. However, I believe WMF may point to a copy of a Google font on a WMF server.)

See https://commons.wikimedia.org/wiki/Help:SVG_guidelines#Background stating

Your browser may or may not have a font for Egyptian hieroglyphs (𓀀𓀐𓀠) or Siddham script (𑖎𑖚𑖕𑖿𑖧𑖲𑖨𑖿𑖎𑖜𑖿𑖧𑖯).

Cartouches and stacking may be a problem, but simple scripts should work. Doing them in Unicode also means that copy/paste work.

Cartouches and stacking may be a problem, but simple scripts should work. Doing them in Unicode also means that copy/paste work.

These simple scripts are the big exception and may be OK for hieratic transcripts. In addition they ignore the fact of default text direction and provide left-to-right hieroglyphic forms only