Feature summary:

It will be fantastic if Wikimedia Commons (and maybe local wikis also) can be used as a repository of open licensed fonts in .ttf/.otf format. Both as webfonts for the use of individual wikis and as media file rendered and shown as .png/.svg files on wiki pages demand along the text.

Use case(s):

• Currently in Persian Wikipedia we write historical scripts of cuneiforms where local font isn't expected to locally installed using glyphs actually extracted from an actual font, using this we can either use the original font as a web font or provide a render of the glyph on demand and choosing between the two options when the render is smaller than the shipping the whole font or other considerations.
• Allowing local wiki to use free web fonts where they need, maybe site wide (which may is covered by ULS) but also maybe for specific part of the page, take this just as an example that poets in Persian can have dedicated font, we actually reference non-free local fonts which can't be uploaded to Commons but there should be some other uses.
• Use of icons from font icons and emoji fonts, we have a big library of icons extracted or available in one font but uploaded separately as SVG/PNG, see https://commons.wikimedia.org/wiki/Category:Noto_fonts and it's subcategories, a high number of glyphs just dumped from fonts, and https://commons.wikimedia.org/wiki/Emoji the usage of those Emoji files across Wikimedia is high last time I checked using simple queries from labs replication.
• Tables like https://en.wiktionary.org/wiki/Appendix:Unicode/Ancient_Greek_Musical_Notation can use font rendered at MediaWiki instead of glyphs uploaded separately
• In future if we can have a way to generate graphics using Lua modules like https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2015/Miscellaneous#Collaborative_way_to_generate_SVG/PNG_graphs_using_Lua_modules and https://www.mediawiki.org/wiki/Extension:Monstranto , a repository of fonts can be very useful for generating custom graphics there.

Benefits:

• Being able to create an archive of open fonts in Wikimedia Commons, something like https://openfontlibrary.org https://en.wikipedia.org/wiki/Font_Library but with collaborative Wiki tools for filling meta data and archiving the different versions
• One thing can be handled better using fonts instead of upload each individual SVG for glyphs is to be able to control variation axes of a font for a better result, open https://fonts.google.com/noto/specimen/Noto+Emoji/tester and move the weight axis, users can choose variation configuration of fonts on Wiki and considering this we can't simply dump any font into individual SVG files as there is infinite of combination in an variable font which being able to call fonts directly opens that way. For example see https://commons.wikimedia.org/wiki/Category:Noto_Serif_Armenian even though it has dumped a free font into individual glyphs it doesn't have all possible configurations of the variable font thus isn't that good way to archive the fonts and its glyphs. It's actually not possible to upload all the glyphs a font can provide as SVG files as they can have infinite representation given different variable axes (say like weight of a font, from Regular to Bold, but as it's variable axes each point between 400/Regular and 700/Regular is also a part of a font, but fonts actually provide different results with infinite number of combination of axes) which a support in MediaWiki makes all of them accessible using parameters we can provide at time of calling the renderer using wiki syntax. If variable fonts and its different possible axes is a new thing to you, have a look at [https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg this] or https://fonts.google.com/variablefonts#axis-definitions , or simply change https://fonts.google.com/noto/specimen/Noto+Sans/tester the two sliders/axes in this page.
• Reduction of number of files of that glyphs that are just dumped from actual fonts, again see https://commons.wikimedia.org/wiki/Category:Noto_fonts and it's subcategories, many of those weren't needed if Commons could use the actual fonts.
• This feature can be designed as a generalized version of https://www.mediawiki.org/wiki/Extension:FontAwesome also. As we don't have that extension we've uploaded each individual font glyph separately https://commons.wikimedia.org/wiki/Category:Font_Awesome which if we can have this feature that shouldn't be needed.
• This potentially can be considered as an alternative for WikiHiero also, some additional logics can be handled by some Lua code

Back in 2011 where T20692 and T27220 are closed we didn't have support for .stl 3d objects either also but I think this type of request can feel more familiar now.

I was thinking about this for sometime and even created an personal MediaWiki extension to test the idea, technical wise this isn't more complicated than STL for example as not much is needed in frontend JavaScript stuff (at least from the beginning) but the backend rasterizer can use the following for a MediaWiki's ImageHandler (creating image thumbnail of a font, very similar to the way .svg, .tiff and .pdf are handled):

• pango-view to use as the rasterizer (already installed at least in tools-login.wmflabs servers) with this https://mail.gnome.org/archives/gtk-i18n-list/2010-June/msg00000.html it can render only using an individual font. You can already invoke FONTCONFIG_PATH=. pango-view --text 'test' --no-display --output out.png (or .svg) in wmflabs servers.
• fc-query (also already installed on wmflabs so shouldn't be unfamiliar, a use like fc-query <.ttf file> --format=%{fullname}) to retrieve metadata of each individual font to be shown in Common's metadata section
• Optional: https://github.com/khaledhosny/ots for sanitation of file being uploaded (used in Chrome and Firefox also). Decades ago fonts used to trig weakness of non hardened software, nowadays with existence extensively fuzzed software libraries that isn't a concern. We already have .ttf fonts embedded in PDF files which are allowed in Commons and this can be considered as a non wrapped in PDF version of that.

License wise https://commons.wikimedia.org/wiki/Template:OFL and https://commons.wikimedia.org/wiki/Template:Apache are most popular free fonts licenses already accepted in Wikimedia Commons.

We perhaps can start just with .otf/.ttf file format and provide .woff and woff2 on the fly sometime later the same way we transcode video files somewhere more temporal.

We already have hacky ways to upload fonts, both to embed them in PDF files and upload PDFs in Commons which is already possible, as PDF files actually embed fonts in themselves, and to encode them into base64 text and put them in interface CSS files but the proposal here is to have fonts in more proper way so we can organize them using established tools we already have here such as categories and galleries. There are even software that inspect individual fonts like [https://github.com/khaledhosny/ots OTS], used by both Chrome and Firefox to make sure individual fonts can't impose any danger for end users, on any case this isn't worse than JS scripting capabilities of SVG which we've managed to overcome over the years.

Fonts also provide metadata akin to images EXIF in themselves, it's called the naming table https://learn.microsoft.com/en-us/typography/opentype/spec/name and they usually provide information like the original name of the font, author, date of creation and the copyright, among many other font related strings, and this can be parsed using software like fontconfig (the fc-query command), already installed in Wikimedia servers.

And even better than a .png output, a SVG output can be generated pango-view --text aksljdkalsjdlkasjd --no-display --output a.svg --font="Sans 2000" && svgo -p 0 a.svg (instead of svgo a small script can remove mantissa part of paths which because of the applied scale don't matter anymore), similar to the way .svg is provided by math extension but we can default to that here.

Or to put it differently, this is a request for a different <math>, minus math layout but with custom fonts. And multifont is out of scope here as many uses will be single font or even single character like https://en.wiktionary.org/wiki/Appendix:Unicode/Ancient_Greek_Musical_Notation but maybe we can address multifont drawing in a separate API where we have a drawing API I suggested in 2015 https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2015/Miscellaneous#Collaborative_way_to_generate_SVG/PNG_graphs_using_Lua_modules T66460 using fonts uploaded this way first.