Thank you for this proposal! It has my support.

I've been thinking about this request. Adding more fonts seems like it must be a good idea, but many of the fonts above raise questions. Do we need Fira Sans, Linux Biolinum, Cardo, Junicode, Vollkorn, or Avocado? That a font is free is a requirement for Commons, but that does not mean that every free font should be loaded onto Commons. So I'm left to ponder the meaning of "Missing fonts".

There are some popular fonts that might be reasonable to have. Century Schoolbook, Bookman, and Chancery are popular. OK, we may be missing the light versions of those fonts, but that raises some questions. Can librsvg understand a request for a light font? If someone states font-weight:300, will librsvg select the appropriate light font? I do not want the user specifying font-family:Century Schoolbook L. And why is the font file "...-L-Regular"? Furthermore, how often do graphics artists specify a light version of a font? Normal and bold are used often, but ultra light, light, heavy, black. and poster are uncommon.

Yes, it would also be good to have condensed versions of fonts, but I suspect the support there is even less than font weights. I've specified conensed fonts when trying to squeeze a label into a tight place, but such efforts often come to grief when a different font is substituted. One cannot rely on condensed (or expanded) fonts being available.

That raises a more important issue: font support will vary by platform. That Commons has a particular font does not mean that my machine also has that font. Everybody sees the same librsvg PNG, but directly displaying the SVG uses a different agent with different fonts. Graphic artists can take time choosing their favorite font on Commons, but that effort is wasted when the SVG is displayed elsewhere. I want WMF to serve some SVG files directly rather than first converting them to PNG. SVG files can have hyperlinks, tooltips, and animation, but those features are lost in the PNG conversion. When SVG files are served, the fonts will vary depending the user's agent.

Having SVG files work on several user agents means the images must work with the generic fonts serif, sans-serif, and monospaced. There should be at least substitution support for the common Arial, Courier, Helvetica, and Times New Roman fonts. If the font requirement is more demanding than that, then embedded fonts or convert to curves would be the way to go.

Even if one goes to the trouble of supplying Windows, Apple, and Linux font families, there is no guarantee that the font will display as desired. Chrome, Firefox, and Edge use different methods to resolve fonts.

More CJK fonts may be in order, but I do not know the field. I understand that some Unicode codepoints are drawn differently, but for monolingual images, the graphics artist just chooses an appropriate Chinese, Japanese, or Korean font to get the right shapes. If we are missing CJK fonts, then it could be worthwhile to add them. That also goes for other scripts.

Strangely, I think this ticket should be closed as won't fix. It's neat that Vollkorn has Regular, Medium, Semibold, Bold, Extrabold, and Black weights, but I'm not going to start using that font family in any illustrations; I do not have the font on my machine, and I have little reason to install it. Same for Fira Sans. I like Century Schoolbook as a font, but I'm not going to use that wide-character font in SVG diagrams; I'd rather use a narrower font with a larger x-height. We should have much more specific reasons for adding a particular font. And in the end, serving SVG files would make the font selection on Commons irrelevant.

@Glrx

Thanks for your opinion. You are very exprienced in fonts (attributes,W3C,systemLanguage,...) and I really value your opinion.

My proposal does not mean, we should install all mentioned fonts, but there might be a few of them which are commonly used (f.e. Bitstream Vera Sans).

The official SVG-fonts-page on meta https://meta.wikimedia.org/wiki/SVG_fonts#Example_rendering contains an image with several not installed fonts: https://commons.wikimedia.org/wiki/File:Meta_SVG_fonts.svg

@Glrx : Do you think any/none of the fonts above should be installed?
If you say none, then close it as won't fix, otherwise we should discuss which fonts to install.

WMF won't serve SVGs directely: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs . I think there might be securityissues, which are too difficult for too few emploies.

Looking at Meta SVG fonts.svg suggests:

Century Schoolbook L
DejaVu Sans Condensed
DejaVu Sans Light
DejaVu Serif Condensed
Nimbus Sans L
Nimbus Sans L Condensed

and several other fonts are installed or at least have acceptable substitutions. For example, the condensed fonts are denser than their normal stretches. Are there any fonts that would fill some gap in coverage? None of the images show missing characters, but the images also do not test many characters. Advice from non-European language users would be good. The Indian languages translation project suggests that Commons has at least reasonable support for those languages.

What listed fonts should we add and why?

I was pleased to see your 2019 Wishlist Survey request. Once again, you made a fabulous request. I am a bit perplexed by some comments and the decision to archive. There is significant browser support for SVG, and the SVG size issue is not a "fairly elaborate architectural consideration". The architecture for images does need to change (an img element is not an adequate container for SVG; width, height, and viewBox attributes within the SVG file are problematic). The security issue may be significant, but that's not an area where I have expertise. An evil person might, for example, insert a malicious link in an SVG file, so if anchor elements are passed, there may need to be a whitelist scan of the SVG. A language switch is easy to handle, but there should be a debate about whether to serve l10n or i18n files, and the outcome of that debate could be a radical architectural change.

I do not see serving SVG issue as an impossibiity but rather Community Tech wanting something more focused, less open ended, and more in line with its skill set. I also think that Community Tech is not charged with developing MediaWiki (something needed to serve SVG), but rather its skills are server-side tools. From a priority standpoint, rendering SVG files as PNGs covers most of WMF's needs, so there is little reason to change. Users are not zooming thumbnails, so the PNGs are adequate. There are few animated SVGs, so that is not a motivator. (Many agents dropped support of SMIL animation,; CSS animation may have good coverage; JavaScript animation would be a no-no.) Buggy SVG rendering is an issue, but it is not a big one because few files are affected and there are workarounds. There needs to be a big benefit to drive a change to serve SVG directly, or some developer needs to be inspired and just do it.

Dear JoKalliauer, I can not support your counter-proposal for new fonts. It doesn't do justice to all the benefits of the request for adding Fira Sans, which is based on it's excellent characteristics for usage on the Internet and the fact is has a really large character set including text figures and small caps. We need Fira Sans for it's readability when used in images that are shown as thumbs.

@OSeveno : Change the proposal as you like

I'm trying to understand the task description but don't unerstand why there are licenses listed between lists. Or what the list is ordered by (maybe licenses?). Or why there's after "SIL Open Font License" two links to Fira Sans fonts, while they are listed again as a bullet point.
Could someone please fix the task description?

If anyone feels like proposing a patch in Gerrit and if the proposed fonts are available as Debian packages: The files to edit are https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/mediawiki/manifests/packages/fonts.pp and https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/fc-list