SVG and PDF rendering are both handled by Thumbor on Wikimedia sites. Font dependencies are managed through Puppet in rOPUP modules/mediawiki/manifests/packages/fonts.pp. This file also controls the fonts available on Proton (pdf creator), MediaWiki, and Graphoid (to be undeployed in T242855).

The list of installed fonts at https://noc.wikimedia.org/conf/fc-list is handled separately at rOMWC fc-list. As far as I can tell, that doesn't actually affect what fonts are available, but it should be kept up to date.

All fonts have to be in a Debian package. If they aren't in the Debian repos, then a package needs to be created. Fonts also have to be under a compatible free license.
Librsvg uses Pango for text rendering, so fonts will have to be compatible with the version of Pango packaged in the version of Debian we are running. In the (bullseye) future, that means no BDF/PCF bitmap fonts. It should pick up fonts once they are installed.
Ghostscript uses it's on font rendering stack, but should also find a properly-installed font in /usr/share/fonts. Both tools support TrueType fonts, which is the most common distribution format.
I don't know anything about Proton and PDF creation, but I would expect that it works with fontconfig and can autodetect new fonts.

Phabricator is the correct place to request font changes. I'm not sure what the best project tags would be. The font installation request tickets seem to appear most often in WMF-General-or-Unknown or Wikimedia-SVG-rendering. Thumbor or Proton may also be relevant, but PDF-Rendering is not (it deals with client-side CSS). It'll ultimately come down to SRE to update/merge the Puppet config and deploy it.

So...requests for new fonts

• should be on Phabricator
• should tag Operations and Wikimedia-SVG-rendering or Wikimedia-General-or-Unknown
• must be freely-licensed
• should be in the TTF format
• should be in the Debian repositories, or easily packaged into a deb

I can't speak to SVG rendering, but PDF rendering at Wikimedia is actually a separate system backed by a service called Proton. All requests related to PDF rendering should be filed as Phabricator tasks and tagged with Proton and #product-infrastructure-team-backlog.

@jbond: If this is a task to work on in the foreseeable future (because "medium" priority instead of "low"), any idea when to expect someone to take a look?

@Aklapper I think SRE are only tagged on this ticket in case there are any puppet changes to be made, reading the ticket im not sure there is so not sure if it makes sense to have sre tagged. As such im not the one who would be working on this and therefore can't really give an answer on priority. however i do notice that the request was made by yourself and a response given https://phabricator.wikimedia.org/T228591#6221461, has that response answered your request or are there still some specifics required.

@jbond: Prioritizing a task as "medium" priority but not being able to give an answer on priority confuses me - how does that go together? I guess I wonder why this (and many other tickets) were not set to "low" priority which feels more realistic given the limited resources and creates less expectations.

In T228591#7023681, @Aklapper wrote:

@jbond: Prioritizing a task as "medium" priority but not being able to give an answer on priority confuses me - how does that go together? I guess I wonder why this (and many other tickets) were not set to "low" priority which feels more realistic given the limited resources and creates less expectations.

While on SRE clinic duty one has to make a judgment call about the relative priority of a specific task. There are many tasks created which are not in the specific area of expertises the person who happens to be on clinic duty that week. Therefore things do get miss classified however the expectation is that the correct teams or interested will be tagged on the ticket and they can make a more informed opinion about the relative priority.

Further selecting the priority is something one has to make with AFAIK no documentation, guidance or process (would love to be corrected on this and will update the sre documentation appropriately).

To clarify: Based on T280718, fc-list will directly relate to what fonts are available to Thumbor when thumbnailing PDFs without embedded fonts and SVGs.

Due to the specifics of the current Puppet configuration, that list will be similar to what is available to the MediaWiki appservers. When Thumbor and MediaWiki are running on the same Debian version, the lists should be the same.

fc-list will not relate to Proton PDF rendering ("Download as PDF" links) or what fonts are available in various parts of WM Cloud Services.

Trying to collect some bits and pieces from T280718 (thanks akosiaris and AntiCompositeNumber):

• PDF creation (!, from articles/pages/etc) happens in Proton
• PDF file thumbnails, bitmap image file thumbnails, and SVG file thumbnails: Thumbor . Font packages would be listed at: https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/mediawiki/manifests/packages/fonts.pp (as Thumbor uses the same definitions as MediaWiki) Looks like Thumbor font packages get defined in https://phabricator.wikimedia.org/diffusion/THMBREXT/browse/master/.pipeline/blubber.yaml$31 per T280718#8920312
• Webfonts / ULS: Assuming this is covered by "MediaWiki" mentioned in T280718#7031428, font packages would be listed at: https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/mediawiki/manifests/packages/fonts.pp
• Things differ between Debian versions (e.g. Thumbor servers could run an older version of Debian than MediaWiki appservers)
• https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikisource/Wikisource_Export for that tool's fonts
• Things might change in a k8s world

I don't see a clear action for SRE so I'm removing the tag. Please add us back when needed.

Quoting T335271#8813221:

https://noc.wikimedia.org/conf/fc-list is going to become increasingly out of date and thus not useful pretty soon