I have mixed feelings about this request.

The fix is simple, so why not?

On the other hand, I do not want to support the Symbol font and its private encodings. In today's environment, I expect UTF-8 files, so the character encoding should be UTF-8 rather than Symbol. I've fixed at least one file encoding. T267487

Significantly, fixing the font on WMF servers does not fix the problem in the rest of the universe. Commons files are supposed to be shared in more places than just WMF wikis. It would be a local fix.

Furthermore, what happens if WMF starts directly serving SVG files? Then we are using the fonts on the user's computer -- not the fonts on WMF servers.

I prefer well designed SVG files. Such files should be relatively insensitive to font metrics. They should use the correct text anchors, and they should have extra space so fonts with slightly larger text metrics will still fit. Leaving extra space also makes translations easier. Well designed SVG files should either use CSS generic fonts or at least fallback to a CSS generic font.

Adobe Illustrator is also quirky. The font-family may encode not only the font family, but also the font-style or the font-weight. I do not want font-substitution tables fixing problems that should be fixed in the SVG source.

The font-family may encode not only the font family, but also the font-style or the font-weight.

Well, I don't think the problem of bad family names is expected to be fixed by my request in the first place...

They should use the correct text anchors, and they should have extra space so fonts with slightly larger text metrics will still fit.

I *think* I mentioned a bit of that when writing the SVG translate guide, but to be frank it's nowhere near visible enough. Anyways, people expect their SVGs to work and expect to be told clearly why when they don't. I do not think we are doing well enough on either of that. Maybe we should set up some SVG-linter like we do for wikitext? Or maybe there is one I am not aware of.

I do not want to support the Symbol font and its private encodings.

Well, the motivation for fixing would probably be minimal as browsers (if they do get served SVGs directly) are expected to do the substitution per web standards not wanting to break things. A lint, though, would be nice.

Untagging CommTech since this is a feature request.

Revisiting.

I would decline this feature request.

XML files often start with the prolog

<?XML version="1.0" encoding="UTF-8"?>

That makes the claim that the file uses UTF-8 character encoding, but the Adobe fonts do not use UTF-8. They use an encoding such as Adobe-Standard-Encoding that puts a dagger at 0xD1 (Unicode Ñ) instead of U+2020 (Unicode †) and the "fi" ligature at 0xAE (Unicode ®) instead of U+FB01 (Unicode fi).

We should not have confusing character encodings.

IIRC, WMF will reject an XML file that claims

<?XML version="1.0" encoding="Adobe-Standard-Encoding">

The Symbol (Adobe-Symbol-Encoding) and Zapf Dingbats (no standard encoding?) fonts are especially problematic because they are often used with fonts that use UTF-8 encoding. The character encoding is then inconsistent within the file.

Files that use non-UTF-8 code points are problem files. It is OK to use an Adobe Standard Encoding font as long as the non-standard codepoints are avoided. If non-standard codepoints are used, then the file may not render correctly on many platforms. That is a problem. We have had at least one phabricator issue where an SVG using an Adobe-Symbol-Encoding font wanted to show a Greek beta, but the font substitution showed something else.

Adobe character encodings are trouble; we should avoid them.