So why not extend the list of allowed tags by 'svg', 'g' and 'path' at minimum? Even if we 'd add a couple of other tags more we wouldn't increase the risk of security flaws or huge image data chunks in a Wiki article. But we'd be able to visualize a number of facts much more clearly, right away.

As far as I understood this is no boolean value but should default to something like 'partial' in future. (Want it asap!)

We 've had that already. If we have a rule to support client side rendering for small svg only and a small svg is replaced by a big one obviously the svg is not served any longer but its png representation is instead. I'd appreciate a warning at upload in that case.

Solution for second problem: If we provide a single font set (FreeSans and FreeSerif, or Liberation Sans, Liberation Serif and Liberation Mono e.g.) hosted on Wikimedia we can expect svg using these fonts and hence rendering the same on all clients.

In T5593#8708677, @Locke_Cole wrote:

In T5593#8624078, @Locke_Cole wrote:

Not sure where best to bring this up, but would it be possible for this to play nice with "dark mode"? In other words, for objects (like logos for example) that conceivably have a "reverse" variant, there's a way to either let SVG authors specify both and then have it automatically selected based on some setting (perhaps CSS styling in the SVG)? I guess my concern is that if there's any "optimization" done to an SVG it might strip/trim what appears to be redundant data, and I know some of the related tasks contemplate "optimizing" SVG's prior to sending them.

For what it's worth, the method that seems to be correct is to use @media (prefers-color-scheme: dark) within the SVG. To that end, I've started uploading SVG images that support light/dark mode, and if anyone needs them for testing I've created a tracking category on EN here: https://en.wikipedia.org/wiki/Category:SVG_images_that_support_dynamic_color_schemes.

One step at a time! It's great to have such features I couldn't even think of with pixel graphics only. But it's even much better to have a supported svg subset available for usage in wikis at all. Later on we might support svg files that make use of template styles. That would be great and by the way it would solve your problem as well.

In T5593#8702404, @Vollbracht wrote:
Step 4: If fonts are linked (SIL open fonts e.g.) font rendering with not installed fonts can be done without server side processing.

Step 4: If fonts are linked (SIL open fonts e.g.) font rendering with not installed fonts can be done without server side processing.

I suppose it'll be all the same if any image is updated by an other one. There are rules the system will follow and these may be different for small and for big files. In either case all cache content needs to be dropped, no matter whether it's a redirect or a set of raster images and no matter what it's going to be replaced by.
And now back to translations:
I don't get the point! An image is included in a Wiki. If it's deWiki the author will expect it to show an image with German content. Now some Chinese try to translate the page. Let's say they see an image with German content. Either they try to adapt the image and ensure to have it be shown in Chinese or they decide to have their own image. Now let's say they see that image with English or French content. Why should they react different? (except gawking why those Germans obviously have non German image content on their page) But once more: This is no issue to deal with especially as there are few images that should be multi language. In most cases to have one file version per content language will be the better choice anyhow.

In T5593#8664999, @AntiCompositeNumber wrote:

In T5593#8664865, @Glrx wrote:

Translation is a small issue. Most users will not notice. If a French speaker just visits the fr.Wiki, then she will just see the French translations. It only gets weird when she visits the Japanese Wiki and starts seeing illustrations in French or English rather than Japanese. Technically, the issue can be avoided by localizing the SVG for each language wiki -- that's what is done now, but the localization is done just for the PNG and not for the SVG.

I would not call translation a small issue. Wikimedia sites have better language support than most user agents. Relying solely on browser language selection would prevent translation into all languages.

This can be an issue. It needs not. We already ensure that database access doesn't exceed a certain amount. There are technical possibilities to keep huge svg thumbnails from client side rendering. However Only 8 out of 40 svg files I uploded exceeded 10kB. Only one out of 7 raster files I uploaded was smaller than 100kB. In the end it's not about the thumbnails. It's about describing structures and relationships where thumbnails might be about 40 kB but without any value whereat the full scale raster graphics would exceed the size of any sensible vector variant of same quality. So yes we had this argument already and I estimate it rebutted for quite a while.

This answer doesn't amuse me. You got a PM about that. Please reflect given arguments assuming that I did know that this is about client-side SVG rendering and that I did read those posts.

The very svg file I used for an example will not stay the way it is. Next version won't have glyph tags. But the problem is the number of lines and text elements that are hard to position for optimal outline and visibility. So in case of font change it makes a big difference even if a line in a text element is just 10% wider. This is why precisely specifying a font may be crucial in rare cases. So why keep this request declined?

Btw. what do I have to bother about reasonable performance in graphics applications that tend to produce big svg files with low font capabilities? And why should I expect something good or bad from that software? I want to produce Wiki content that looks the same on most browsers as on mine and is lean code and high quality the same time. How that might be produced shouldn't be this topic.

I won't use @font-face with src in the vast majority of SVG files. But it might prove necessary in rare cases. And it's not a matter of "my favorite" font but of a font with reliable glyph sizes e. g. then.

Hey! I answered on that! You cannot argue with tracking or with malicious fonts if every font has to be provided by WMF.

So why not allow referencing wikimedia provided fonts only?

What does my browser do if it's asked to render a page using a font specified by a given source? Shall it ignore @font-face { font-family: 'my-font-family'; src: url('http://my.domain.tld/my/path/file') format('woff2, or whatever'); }? If it would do so (on very few smartphones) my svg still would get rendered and not necessarily with lower quality. That shouldn't hinder me providing best quality in calculable result for all others in case of need.

@Aklapper Thanks for your fast reaction!

"Showing" means presenting within a Wikipedia page besides text, tables and other images. PDF is not meant to be used like this.
What fonts are hosted by WM? We need to be able to specify them exactly. If we can, we have the possibility of exact pdf-like rendering of these very fonts. Haven't we?

Closed too early!
Is there any way of showing a pdf as part of a wiki? I guess not.
Will that happen in future? Less probably than showing svg as part of a wiki.
May exact font selection be necessary for correct display? Yes. See [[commons:File:ATQuellenNoLnk.svg]] for example. There may be better ways to design this matter. But there are graphics out there where texts might flow over or behind other objects or into each other if a client happens to use the wrong font. And still there's an interest in reading these texts as texts.
Fonts need to be used. There's no way of presenting text without.
Fonts need to default to some value. This depends to the OS used. And they need to be provided somewhere.
Yes, if we do not hinder that, Meta or MS might prepare an image allowing for statistics how often or even by what IP it's been presented. For open source distribution providers I rate this chance unrealistic. So why not whitelist only fonts provided there or alternatively host at least one open source standard font that might be used in case of need?

In T134410#8433664, @Glrx wrote:

Perhaps we could allow web fonts that point to Commons.

Yes! Please!

Is any browser capable of showing png but not capable of showing svg out there left?

@Jonathanischoice: Thank you. I fully agree. The only problem left seams to be the fear of security flaws that I still don't understand.

In T208578#4716971, @Glrx wrote:

A better option would always serve small (say less than 20kB) SVG files.
[..]
The better option to just include any small SVG file. No article or file editing ks required. If the SVG file is less than x bytes, then it gets served rather than converted to PNG. There can be some trouble. Somebody might suddently bloat an SVG file to 10 MB, and then all those articles that expected to download a small SVG file suddently choke on a 10 MB monstrosity.

Wouldn't the server access the PNG instead then? Simple rule - simple solution!

What about an other way: What about treating a couple of tags out of SVG set to create html5 content out of Wikimedia code? To enhance the Wiki code syntax would allow small efficient inline SVG being completely save and enhancing capabilities of drawing genealogical trees with lines instead of table borders or of drawing hieroglyphs the way they are on real life samples. Charts could show interrelations with links to corresponding pages. This would be a great deal and an extensible step in Wikimedia development.

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

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?

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

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.

In T5593#5245461, @JoKalliauer wrote:

@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 .

There are several tools to fill a template around. Some care about 8 digit dates. Others don't. I'm bound to one which does. German Literatur template requires a date of publishing which in general is 4 digit year only. So I fill it with 01-01 only to delete that afterwards. That's awkward.

Shouldn't we handle internal links the same way as in wikipedia?
Lets upload svg containing <text>[[Wikipedia]]</text>
Wikimedia Commons should deliver compiled version containing <text><tspan xlink:href="https://de.wikipedia.org/wiki/Wikipedia"><a xlink:href="https://de.wikipedia.org/wiki/Wikipedia">Wikipedia</a></tspan></text> per default and offer source for download in addition.