This task should fall to SVG authors rather than a tool automatically injecting font references. It is far better for SVG authors to choose generic fonts and leave plenty of room for varied font metrics. Another option is to have the SVG list several fallback fonts that end in a generic font. I do not see the intent of SVG to display the exact font. The obvious route for such a display (the glyph element) has been removed from SVG 2.0 and is not supported in most current browsers.

Most browsers support webfonts, so an SVG file could display the same font on every agent / browser that supports @font-face src:. For example, accessing https://fonts.googleapis.com/css?family=Noto+Sans+Egyptian+Hieroglyphs provides access to CSS that will download a font of hieroglyphs.

Such files cannot be uploaded to Commons. They are blocked for an xml-stylesheet or @import referring to an external URL. We do not want Google and others tracking users, but the src could point to the font on a WMF server.

Allowing xml-stylesheet and @import when they point to whitelisted domains (such as upload.wikimedia.org) would allow client-side rendering to use the exact fonts.

MediaWiki could read the SVG, collect all the font information, and then prefix an XML stylesheet or add font face rules to the SVG, but such effort should not be needed for most SVG files. Most SVG files do not need special fonts. Insisting SVG use particular fonts is usually counterproductive.

I would close this as won't fix because I doubt WMF wants to serve fonts to the world. I want SVG to have text elements, but if the author absolutely wants the appearance of a particular font, the simple fix is to convert the text to curves.

+1 for @Glrx's answer to close; if you want exact PDF-like font rendering, convert it to curves and use parallel hidden text elements if you need the SVG to be indexed in full-text search data. If you want exact rendering and have big walls of text, perhaps you want a PDF file...?

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?

Is there any way of showing a pdf as part of a wiki? I guess not.

Not sure what "showing" means. You can upload PDF files and there is viewer software for it (also within MediaWiki).

May exact font selection be necessary for correct display? Yes.

@Vollbracht: Then you are using the wrong file format. :) See previous comments: "if you want exact PDF-like font rendering, convert it to curves". In any case, Wikimedia wikis host numerous fonts already. Wikimedia wikis will not and cannot (legally) host every existing font on this planet.

"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?

@Aklapper Thanks for your fast reaction!

In T134407#8601374, @Vollbracht wrote:

What fonts are hosted by WM?

See T228591#7088077; for bitmap thumbnails of SVG files see also T280718#7031428

If we can, we have the possibility of exact pdf-like rendering of these very fonts. Haven't we?

No, as "client-side" means that rendering entirely depends on the font rendering stack of your operating system.
On Linux that's usually Pango, Cairo, Harfbuzz these days (and different software versions may expose different bugs or features), on other systems that's other stuff.
Plus you may have a different version of a font itself installed than someone else.
Plus likely more.

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.

But that for I wouldn't need something like "/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf" but something like "https://commons.wikimedia.org/fonts/truetype/dejavu/DejaVuSansMono.ttf" e.g.

In most cases, SVG should use generic fonts and be designed to work with substituted fonts.

Allowing @font-face rules may allow the SVG agent to use the given font, but it also allows tracking and even malicious fonts.

Even with the specified font, SVG will not render precisely. PostScript, TTF, and OTF fonts do not scale linearly. A layout may look great at one size but odd when scaled just a little larger. That's why the graphic designer should be careful when laying out text.

So why not allow referencing wikimedia provided fonts only?

See the previous comment.

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

And the necessity of care is no argument against a solution with specifying WMF provided fonts in case of need. And the possibility of scaling not necessarily implies linear scaling in all cases. Once more see https://commons.wikimedia.org/wiki/File:ATQuellenNoLnk.svg for example.

First, @font-face with src should not be used in the vast majority of SVG files. Most SVG files need only basic fonts that can be fulfilled with the sans-serif or serif generic fonts. Even if a graphic designer has a favorite font, graphics uploaded to Commons should use fallback fonts.

Many applications do not emit conforming SVG, so one cannot expect reasonable performance from those applications. Adobe and Apple tend to put a PostScript font name into the font-family attribute (something like TimesRoman-Bold) rather than the conventional notion of a font family with broken out attributes for font-weight, font-style, and font-stretch.

There are some rare circumstances where @font-face can make sense. I suspect very few systems have installed a font for the ancient Siddham script. It would make sense to use a web font there, but one can also just tell users to download a suitable font. If one wants to look at Siddham script, then it makes sense to have the font on one's system. Web fonts have a private cache.

The file https://commons.wikimedia.org/wiki/File:ATQuellenNoLnk.svg is a mystery to me. It does not seem to need any special fonts (aleph null and ܦܫܝܛܬܐ and Greek are present). On my system, the SVG displays with Times New Roman because the font specification is font-family="Open Sans". If the specification were font-family="Open Sans, sans-serif", then it would display with a sans-serif font on my machine. Nothing in the file seems to need more than a generic Unicode font.

The file has embedded the font named Serif embedded and used that for @media (min-width: 60em) text. Such a rule is not supported in SVG 1.1 (CSS 2.0), so Commons does not support the file. Nor is it handled by WMF's rasterizer. The @media rule may cause SVG Translate to refuse to translate a file (SVG Translate will refuse to translate because there are id selectors). Furthermore, the embedded font is done with glyph elements. SVG 2.0 has abandoned glyph, and most modern browsers have already dropped support for it.

All text elements state a class such as TextForce, TextShape, TextAlt, or TextPosition. TextShape is hidden on Commons but visible on my machine (which understands @media better). There are also some translateY() games.

Overall, the SVG file is using a lot of arcane mechanisms, but it does not need to use a web font. So I do not understand why you point it out.

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.

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.

If we agree on allowing for WMF font sources that won' t be more complicated as filtering xlink:href. By now all hrefs to not in-file targets are blocked. We should allow for WMF site targets instead anyhow.

This sounds like questions for a support forum. This ticket has gotten quite off-topic.

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?

Because this request is about client-side SVG rendering. You are welcome to specify fonts. See T134407#7669379 and T134407#8584155.

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.