librsvg bug

I propose to not fix, as this is proprietary code of an editor without standard. Actual browsers seems also not support this not understandable font-name systematic.

If a majority of editors output using this format (especially if they do so by default), then it's a de facto standard, and the software should at least accept files using it. Standards compliance is great in theory, but in practice if everyone else is ignoring the standard, you generally don't have much choice in the matter (end users don't care that editors aren't spec-compliant, they only care that their files don't display correctly on your site).

Perhelion is right, Wikimedia volunteers shouldn’t spent efforts on compatibility kludges helping Adobe to promulgate their Illustrator and other house products. Better to design a bot fixing such font specification anomalies; it’s this consistent with Wikimedia mission to produce a reusable content, not a kludge envisaged.

Which is why I hedged my bets with "majority of editors". I have no idea how widespread this actually is in editors, nor what proportion of uploaded files are affected (and I also don't know what, if any, threshold the WMF has for supporting such things). Obviously, if the proportion of editors/affected files is suitably low, then running a bot periodically to correct such files is probably the ideal course of action. That being said, it would probably be useful to at least show a warning that a known, unsupported feature is being used in a file, to allow users to understand why their file isn't displaying as they expected.

I agree with Perhelion and would close this bug as won't fix. "DejaVuSans-Bold" is not a font-family, so we should not expect a font matcher to find it; we would expect a substitution. That substitution would not be bold because the user did not specify font-weight:bold. Maybe some font matchers will do better, but we should not expect that result.

Authors should not rely on "Random Name Bold" being a bold font. A font matcher should not have to look at the font-family name and intuit a style and weight if the name includes "Italic" or "Bold" or "Book" or "Heavy" or "Oblique". A font family NAME is supposed to be a family NAME and not a particular font; nothing need be parsed out of an atomic name.

Font matching is a difficult task, so it is best done with a standard library or system calls. My impression is librsvg ultimately relies on fontconfig (fcfontlist(3) and friends). Assuming no mistake in librsvg's use of the library, the bug would be an upstream fontconfig bug. But it's not really a bug.

Some months back I did a font test on Chrome, Edge, and Firefox using the font file names on my Windows machine. I expected the same font matching behavior, but they had slight differences.

"Palatino Linotype Bold Italic" would give the same bold-italic result with or without font-weight:bold;font-style:italic on Edge. On Chrome and Firefox, just the font name would display a normal (non-italic, non-bold) face; with font-weight:bold;font-style:italic it would be a bold-italic face.

"Arial MT Rounded Bold" displayed a substituted normal serif font on Chrome. Edge and Firefox displayed the right thing. (My font directory does not have an "Arial MT Rounded" font file or even an "Arial MT" font file.)

"Arial" with font-weight:900 appeared to find the "Arial Black" font file on all three browsers

"Arial Black" displayed the same with font-weight:200, 400, or 900 on all three browsers.

I don't think anybody can rely on consistent behavior if they stick a font file name in the font-family attribute/property

WebType recognizes the font matching support is weak and recommends a workaround for unusual weight fonts: use a font-weight specific font name with a common (but mismatched) CSS font-weight property:

https://www.webtype.com/info/articles/fonts-weights/

But the more workarounds that are done, the more difficult font matching becomes. The "DejaVuSans-Bold" example isn't trying to inject a light face into an agent that does not understand font-weight:200. "DejaVuSans-Bold" is an ordinary case and should be done the ordinary way.

Stick with what is simple: specify the font-family, the font-style, and the font-weight. Any font matcher with that explicit information has a better shot at a reasonable match. Maybe it will guess wrong for the "DejaVu Sans" family, it should get the style and weight right.

Furthermore, the more specific the font name, the less likely it will be present or have a good match on other user agents. Even if librsvg were hacked to interpret "DejaVuSans-Bold" as "DejaVu Sans" font-weight:bold, that would only change the behavior of librsvg; it would not change other SVG renderers. It would be better to fix the file so it worked in more places rather than fix it here so it only worked here.

If one were to run the Commons SVG Checker on the file, it would complain about the "DejaVuSans-Bold" font family.

AI automatically sticks in an "Arial-BoldMT" font family, but Adobe is wrong and Adobe wants to sell fonts. The Commons SVG Checker will also complain about that font family name.

Perihelion is also right about the standard. If librsvg is to be fixed, then how would it be fixed? Where is the document that says what a font matcher should do when presented with names such as "Arial-BoldMT"? OK, maybe "Arial-BoldMT" can be added to a font-substitution list, but that is just a workaround for a specific site; everybody won't have the same substitution list.

Fix the problem where it is broken, and it's broken somewhere else. Incnis_Mrsi's bot proposal would do that, and it would be a better approach than adding to fontconfig's substitution table. If a file displays the wrong font on Commons, then it will probably display the wrong font elsewhere. The goal should be to fix the file on Commons so it will display elsewhere, too.

Finally, SVG files should use font-family specifications with a CSS fallback list. My machine does not have "DejaVu Sans"; a better font-family specification is "DejaVu Sans, Arial, sans-serif".

@Glrx I agree with you when you say that almost every render system (like web browsers for example) don't render font families spelled like "Arial-boldMT".

But I also think that trying (or possibly fixing) this problem (because it is not really a bug) should fix thousands (or possibly near to one million ?) SVG files that spell font families like this.

I'll put a finer point on it: the suggestion would violate the SVG specification, so it should not be done.

If the file says just font-family="DejaVuSans-Bold", then the font-weight="normal" and font-style="normal" are defaulted by the SVG specification. The SVG file is saying use a normal weight font. That's a conflict, and you want the conflict resolved by overriding the font-weight attribute. That's ignoring the specification.

For a more absurd example, fonts often use their designer's name: e.g., Bodoni, Caslon, and Stone. What if Wilhelm Bold designed the font "Wilhelm Bold". Stripping the "Bold" would be the wrong thing. Messing with the font weight could make things worse. Imagine all the body text changing from normal to bold.

I don't know why the font matching tests I did above came out the way they did, but I can imagine a quasi-consistent story. Edge just passes the font name to the system matcher an lives with the result. It looks like Chrome first strips off "Bold" and "Italic" and passes what is left over to the system matcher (so "Palatino Linotype Bold Italic" becomes "Palatino Linotype") and lives with the result. FireFox seems a bit more clever; it may strip "Bold" and "Italic" and call the system matcher; if the system matcher didn't find an exact match, then it may try to match the original name. (FireFox found and used "Palatino Linotype" but did not find "Arial MT Rounded" so it used "Arial MT Rounded Bold".) The results are not consistent across programs.

It would be far better for Incris_Mrsi's bot to fix the millions of broken SVG files that have "DejaVuSans-Bold" to say "DejaVu Sans" and font-weight="bold". Then every SVG agent that has DejaVu Sans will display the file as the artist intended. I'd even be OK with the bot editing the font-family to "DejaVu Sans" and ignoring the implied font-weight; it's the artist's fault if she didn't specify the right font-weight; that's one of the lessons WebType teaches.

And there's really no harm here. If my system doesn't have the specified font, then it substitutes another font and I get an illustration that I can read. If the artist says "DejaVuSans-Bold" and my user agent substitutes some other font at normal weight, what is the harm? The text is still readable even if it is not bold. The result as it stands now is useable.

If the artist did the right thing with font-style and font-weight, then the result will be an even better match.

I do not have DejaVu Sans on my system, so even if the artist did font-family="DejaVu Sans", the SVG agents on my system will substitute Times New Roman. I get a serif instead of a sans-serif font. If the artist really wanted to display a sans serif font, then she should have specified "DejaVu Sans, sans-serif". And that specification would make her art come out close to right on all systems, not just systems that have "DejaVu Sans" installed. So Incris_Mrsi's bot would do wonders if it included reasonable fallback fonts.