Also see T280829.

And I posted the current version at /T210960#7015971 the other day, by request, as it happened like twice before within in a couple years.

In T280718#7023966, @akosiaris wrote:

in 8 years says to me that this isn't something sustainable to keep around.

I didn't find 3 times in 8 years thaat much but yes.

It's already 3.5 years out of date, if anything relies on it, it's relying on very old data.

People wanted this for T210960 and similar linked tasks.

@akosiaris
I think it is important to define "safe fonts" that are available to librsvg for commons (and also for SVGChecker see T280722), how it is done might not be so important (at least for me).

That is currently done on https://meta.wikimedia.org/wiki/SVG_fonts or with https://commons.wikimedia.org/wiki/MediaWiki:CommonsSvgChecker.js#L-734

But it is important to know which fonts works and which not, using not available Micorosft-fonts is a common mistake (by newbies) why svg-files render wrong (e.g. text is over another text).

I don't care if you publish fc-list or not, but I think that's the lowest limit what is needed to be done, at least I don't know anything easier that provides the necessary informations. If it is easier to publish it on phabricator.wikimedia.org it is ok for me.

Basically a font that wont be available any more in 5 years might should not be used, since SVGs get sometimes re-rendered (e.g. ?action=purge).

So best practice would imho be to first announce it well ahead (at least months), before removing a "safe font".

So fonts should not get outdated, otherwise many files will break. => So updating should not be necessary! (But sadly it is necessary, because fonts get changed/removed.)

@Dzahn
Thanks for your information!

Meanwhile old ticket T79424 from 2011 has been reopened so I created https://gerrit.wikimedia.org/r/681766

conf/fc-list has useful information, and there have been several requests for updated information on MW fonts.

It was clear the list was out of date, and many man hours have been lost in making SVG files whose purpose is to test the validity of the fc-list.

conf/fc-list is an output file, so it should not be under source control. Instead, the file should be generated from sources rather than maintained by humans.

conf/fc-list (or some other endpoint) should be an accurate reflection of the available fonts on the image scalers. That list should be generated after the font packages are loaded. I do not care exactly how the list is made.

If noc.wikimedia.org has the same fonts as the image scalers, then have a chron job create the list every Sunday at 2 AM.

Alternatively, have https://noc.wikimedia.org/conf/fc-list or similar endpoint generate the font list on demand.

If noc.wikimedia.org does not have the same font list, then provide an endpoint on the scalers that returns the fontlist. The endpoint could be something that the servers will cache. From a testing standpoint, there might be an endpoint on each server. Then we could discover if the fonts on the scalers are different from the fonts on toolforge. Maybe add a Special: command. Or add the request to the MW API. Commons SVG Checker has a wired in list of fonts; maybe it could query for the current font list each time it is called.

Access to an up-to-date font list is important, but how that list is obtained is not. The current method of maintaining that list does not keep it up to date.

From a user perspective, having something like fc-list is useful. rOPUP modules/mediawiki/manifests/packages/fonts.pp is the list of font packages that are installed. That's enough for some uses, but it won't really tell you exactly what fonts are available unless you're already familiar with Debian font packaging.

I 've gone through the various tasks (T280829, T79424, T210960 and T180923, let me know if I have missed others) and I 'd like to add the following points.

• It's clear to me that the information itself is useful.
• It's also clear to me that it's at times out of date (no surprise there), causing people to lose time and try to reason about problems that aren't even there. It's clearly quite annoying (T180923#3837751, T79424#7025316, T210960#5351015 and probably others).
• It's also obvious that the file is being generated manually and thus is subject to the idiosyncracies of the terminal/session the generating user (I think UnJamoNovel,은 자모 노벨:style=Regular in T210960#7015971 is a result of such a thing, correct me if I am wrong)
• There can also be some weird artifacts in that list (e.g. T210960#7021779) and I have no idea where they come from.

What's not clear to me yet is which cases we are trying to cover here. To give you an idea:

• PDF creation happens on a different system (proton) than mediawiki. In fact it's a docker container, you can fetch it using docker and the information at https://docker-registry.wikimedia.org/wikimedia/mediawiki-services-chromium-render/tags/ and run fc-list on your own on it.
• Image resizing happens on thumbor, a different system. The output of fc-list on such a host returns an output that has a unified diff of 572 lines compared to a mediawiki host. The actual diff is probably half of that due to how unified diff works, but the point is that they differ and quite possibly a lot.
• And then there is the big one, mediawiki itself. It's at times running on different versions of the operating system and I honestly don't know if fonts differ between versions, I guess at times they do. But even during the times where we run only 1 version of the operating system, a manually curated fc-list page is going to be outdated.
• Toolforge seems to also have similar patterns and there is no guarantee that systems there will ever be in-synced with systems running in production.
• And we might very well have more systems in the the future.

So, do we try to cover all of the above? Or just a subset?

Needless to say, having somewhere the output of all of the above systems isn't particularly easy. It isn't just a periodic job that can be run on a single host and the output served somewhere. That possibly explains why the manually curated fc-list output solution has survived up to now.

We could run one systemd timer on a random (canary) appserver and let it write the output to a local file.

Then we could use rsync::quickdatacopy and another timer on mwmaint* to pull that file over to where noc.wikimedia.org is hosted.

This would give an always current version of the file on actual MW appservers (not the same as mw* or deploy* necessarily, where deployers can already look themselves).

In T280718#7030090, @Dzahn wrote:

We could run one systemd timer on a random (canary) appserver and let it write the output to a local file.

Then we could use rsync::quickdatacopy and another timer on mwmaint* to pull that file over to where noc.wikimedia.org is hosted.

This would give an always current version of the file on actual MW appservers (not the same as mw* or deploy* necessarily, where deployers can already look themselves).

That wouldn't cover though PDF generation and image scaling systems. I guess what I am asking is "Do we want to cover those too?" Cause a yes complicates matters.

I (and presumably most of those seeking the font list) want the font list that is on the image scalers; that is, the list of fonts used for converting SVG files to PNG bitmaps. I'm not interested in font lists used in generating PDF files; PDF files can flow their text, so they do not have the same constraints as SVG 1.1 files (which has no flowed text). PDF files also allow subsequent font substitution; that is not possible after an SVG file has been converted to PNG. I could see some PDF users being particular about PDF CJK font choices, but that is not an immediate concern to me.

SVG files will specify a font-family. If that font family is not available, then the resulting rendering will often be poor. The graphic artist may have selected a serif font, but the SVG render may not know about that font and may substitute a san-serif font. That leads to frustration: the image looks right on the artist's local computer, but it looks wrong on Commons.

Many graphic artists are particular about the font appearance, and some are so particular that they will convert text to curves. That bloats the file, and it makes translation difficult: the curves must be removed, and then replaced with the translated text. It is better if those artists can find an acceptable font on Commons so they do not convert to curves.

So the quick fix is informing those designers of available fonts on the Commons image scalers (Thumbor? Buster?).

In T280718#7023966, @akosiaris wrote:

[...] I propose we remove that file from mediawik-config repo altogether. It's already 3.5 years out of date, if anything relies on it, it's relying on very old data.

Some WMcommons-SVG-editors call phab a "black hole".
librsvg 2.40.X is over 4 years out of date (newer version exist) and 3,5 years depreciated end-of-life (announced that it would have been the last 2.40 version, which was deprecated effectively immediately.). And it is still used for rendering SVG by Wikimedia, see T193352 . I think (almost) no-one would propose to remove the (outdated) svg-renderer from commons (without replacement e.g. another library or client-side rendering). Even if some problematic SVGs get blocked during upload T279238, a outdated librsvg might be still a security issue since old svgs with such content sill exist.

@akosiaris Thanks for gone through the various tasks.

PDF-fonts are imho unimportant (at least I did not run in a PDF-font-issue on Wikimedia, but I'm more on SVGS)

• for PDFs it is more common to embed fonts
• the JPEG-preview of PDFs is generally awefull (so a different font is not the main issue) that you generally do not use the thumbnails of PDFs in Articles, see e.g. thumbnail at Commons:File_types#PDF
• PDFs are often out of scope (i.e. undesired/banned)

I do not know fonts that well, font-version are imho unimportant,

• however it might be an issue if different version contain different number of characters, maybe Problems like T281027 might occur. (I don't know if that can be the case.)
• T253600 shows the difference in rendering between Liberation1 and Liberation2

That SVG checker (runs on Toolforge?) has different fonts is a problem, it makes bug-fixing more difficult. However for such cases there exist a test-svg-file, which is a workaround, but not a perfect solution (This excessive usage leads to T42174 ).

If I compare 21uploads at Test.pdf with ~17.000uploads at Test.svg, I think rendering of pdf is of negligible issue on commons.

In T280718#7031176, @JoKalliauer wrote:

In T280718#7023966, @akosiaris wrote:

[...] I propose we remove that file from mediawik-config repo altogether. It's already 3.5 years out of date, if anything relies on it, it's relying on very old data.

Some WMcommons-SVG-editors call phab a "black hole".
librsvg 2.40.X is over 4 years out of date (newer version exist) and 3,5 years depreciated end-of-life (announced that it would have been the last 2.40 version, which was deprecated effectively immediately.). And it is still used for rendering SVG by Wikimedia, see T193352 . I think (almost) no-one would propose to remove the (outdated) svg-renderer from commons (without replacement e.g. another library or client-side rendering). Even if some problematic SVGs get blocked during upload T279238, a outdated librsvg might be still a security issue since old svgs with such content sill exist.

This isn't the task for complaining about librsvg.

---

@akosiaris Thanks for gone through the various tasks.

PDF-fonts are imho unimportant (at least I did not run in a PDF-font-issue on Wikimedia, but I'm more on SVGS)

• for PDFs it is more common to embed fonts
• the JPEG-preview of PDFs is generally awefull (so a different font is not the main issue) that you generally do not use the thumbnails of PDFs in Articles, see e.g. thumbnail at Commons:File_types#PDF
• PDFs are often out of scope (i.e. undesired/banned)

PDF files uploaded to Wikimedia sites are handled by Thumbor like every other file. The Proton PDF rendering previously referred to is the "Download as PDF" links on articles.

I do not know fonts that well, font-version are imho unimportant,

• however it might be an issue if different version contain different number of characters, maybe Problems like T281027 might occur. (I don't know if that can be the case.)
• T253600 shows the difference in rendering between Liberation1 and Liberation2

That SVG checker (runs on Toolforge?) has different fonts is a problem, it makes bug-fixing more difficult. However for such cases there exist a test-svg-file, which is a workaround, but not a perfect solution (This excessive usage leads to T42174 ).

The font packages for production MediaWiki and Thumbor servers are defined in rOPUP modules/mediawiki/manifests/packages/fonts.pp. Font packages on the Toolforge grid are defined (intermixed with other packages) in rOPUP modules/profile/manifests/toolforge/grid/exec_environ.pp. I don't see any explicit font installations for the Toolforge k8s containers, nor would I really expect any. They're tuned for running webservices and try to install the minimum number of packages possible. If exact parity with production was desired for svgcheck, I would advise running it in Cloud VPS instead of Toolforge.

In T280718#7030081, @akosiaris wrote:

[...]

• PDF creation happens on a different system (proton) than mediawiki. In fact it's a docker container, you can fetch it using docker and the information at https://docker-registry.wikimedia.org/wikimedia/mediawiki-services-chromium-render/tags/ and run fc-list on your own on it.

Proton deals with rendering PDFs of articles, and article content almost never has a specified font (other than font-family:sans-serif). Accordingly, concerns about Proton font family availability are not very common, and probably don't need an engineered solution. For the record, Proton font packages are defined in rMSCR .pipeline/blubber.yaml.

• Image resizing happens on thumbor, a different system. The output of fc-list on such a host returns an output that has a unified diff of 572 lines compared to a mediawiki host. The actual diff is probably half of that due to how unified diff works, but the point is that they differ and quite possibly a lot.
• And then there is the big one, mediawiki itself. It's at times running on different versions of the operating system and I honestly don't know if fonts differ between versions, I guess at times they do. But even during the times where we run only 1 version of the operating system, a manually curated fc-list page is going to be outdated.

Thumbor uses the same font definitions as production MediaWiki (rOPUP modules/role/manifests/thumbor/mediawiki.pp:11), so the only real differences between available fonts should be the package differences in Debian Stretch (oldstable, all Thumbor servers right now) and Buster (stable, all MediaWiki appservers). A difference between Debian versions would be expected, because some of the font packages we use have been updated to include more fonts. https://packages.debian.org/stretch/fonts-noto-cjk vs https://packages.debian.org/buster/fonts-noto-cjk is one example.

• Toolforge seems to also have similar patterns and there is no guarantee that systems there will ever be in-synced with systems running in production.
• And we might very well have more systems in the the future.

So, do we try to cover all of the above? Or just a subset?

Needless to say, having somewhere the output of all of the above systems isn't particularly easy. It isn't just a periodic job that can be run on a single host and the output served somewhere. That possibly explains why the manually curated fc-list output solution has survived up to now.

Having a list of fonts available on Thumbor servers is likely the best user-perspective outcome, since most font questions/comments/complaints relate to image rendering. It's worth noting that the eventual T233196: Migrate thumbor to Kubernetes may impact whatever solution is devised.

Reading the answers (thanks!!!) I understand that

Having a list of fonts available on Thumbor servers is likely the best user-perspective outcome, since most font questions/comments/complaints relate to image rendering.

is the best path forward, as it's a rather smaller and thus more tractable problem. There's a couple of minor complicating factor like the buster migration and the kubernetes migration (that one will actually make things easier) but those are down the road. Let me see what I can do about that.

Change 682685 had a related patch set uploaded (by Dzahn; author: Dzahn):

[operations/puppet@production] thumbor: add a timer that writes the output of fc-list to /srv

https://gerrit.wikimedia.org/r/682685

An updated fc-list has been deployed: https://noc.wikimedia.org/conf/highlight.php?file=fc-list

It was identical on a random appserver and a thumbor server I compared it to.

@Dzahn the list is not complete yet. For example, FreeMono and FreeSerif are not in your list but they do work as shown in this file.

Here is a list of Arabic fonts provided by @Ebrahim

Please note that FreeMono and FreeSerif have otf extension.

@4nn1l2 :
FreeMono fallback to DejaVu Sans Mono
FreeSerif falback to DejaVu Serif
see https://upload.wikimedia.org/wikipedia/commons/thumb/archive/b/bd/20210505084110%21Test.svg/1200px-Test.svg.png (The red DejaVu is imho identical to the green FreeMono/FreeSerif)

<?xml version="1.0" encoding="UTF-8"?>
<svg width="450.31" height="38" xmlns="http://www.w3.org/2000/svg">
 <g transform="translate(-676.32 -291.32)" font-family="Noto Sans" font-size="18">
  <text x="977" y="305" fill="#008000">FreeMono</text>
  <text x="977" y="305" fill="#f00">DejaVu Sans Mono</text>
  <text x="977" y="325" fill="#008000">FreeSerif</text>
  <text x="977" y="325" fill="#f00">DejaVu Serif</text>
 </g>
 <g transform="translate(-676.32 -291.32)" font-size="18" text-anchor="end">
  <text x="967" y="305" fill="#008000" font-family="FreeMono">من مشتعل عشق علی‌ام، چه کنم؟</text>
  <text x="967" y="305" fill="#f00" font-family="DejaVu Sans Mono">من مشتعل عشق علی‌ام، چه کنم؟</text>
  <text x="967" y="325" fill="#008000" font-family="FreeSerif">من مشتعل عشق علی‌ام، چه کنم؟</text>
  <text x="967" y="325" fill="#f00" font-family="DejaVu Serif">من مشتعل عشق علی‌ام، چه کنم؟</text>
 </g>
</svg>

To check font-ability:

• Purge the rendering server-side using ?action=purge: https://commons.wikimedia.org/wiki/File:MediaWiki_SVG_Arabic_fonts.svg?action=purge
• Purge your cache: e.g. press strg&Shift&R (at the same time), more infos see https://commons.wikimedia.org/wiki/Help:Purge
• check your font against length-sorted-font-lists: sans, serif, mono

@JoKalliauer That is correct. Thanks

In T280718#7060805, @4nn1l2 wrote:

@Dzahn the list is not complete yet.

The command used to create that list was fc-list :fontformat=TrueType , nothing was manual. So the only thing missing would be fonts that are not TrueType. Let me know if you want us to remove that limitation to "true type only".

Change 682685 merged by Dzahn:

[operations/puppet@production] thumbor: add a timer that writes the output of fc-list to a file

https://gerrit.wikimedia.org/r/682685

Mentioned in SAL (#wikimedia-operations) [2021-05-05T17:59:16Z] <mutante> adding a systemd timer to all thumbor servers that writes output of fc-list command into /srv/fc-list/fc-list (T280718)

On thumbor servers we now have this: example thumbor1002:

[thumbor1002:/srv/fc-list] $ systemctl list-timers | grep fc
Thu 2021-05-06 17:59:38 UTC  23h left      Wed 2021-05-05 17:59:38 UTC  2min 46s ago fc-list-dump.timer                                    fc-list-dump.service

[thumbor1002:/srv/fc-list] $ systemctl status fc-list-dump.timer
● fc-list-dump.timer - Periodic execution of fc-list-dump.service
   Loaded: loaded (/lib/systemd/system/fc-list-dump.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Wed 2021-05-05 17:59:31 UTC; 3min 8s ago

May 05 17:59:31 thumbor1002 systemd[1]: Started Periodic execution of fc-list-dump.service.

[thumbor1002:/srv/fc-list] $ systemctl status fc-list-dump.service
● fc-list-dump.service - Write the output of the fc-list command to a file
   Loaded: loaded (/lib/systemd/system/fc-list-dump.service; static; vendor preset: enabled)
   Active: inactive (dead) since Wed 2021-05-05 17:59:38 UTC; 3min 23s ago
  Process: 40108 ExecStart=/usr/local/bin/fc-list-dump.sh (code=exited, status=0/SUCCESS)
 Main PID: 40108 (code=exited, status=0/SUCCESS)

[thumbor1002:/srv/fc-list] $ ls
total 52K
4.0K drwxr-xr-x 2 root root 4.0K May  5 17:59 .
4.0K drwxr-xr-x 7 root root 4.0K May  5 17:59 ..
 44K -rw-r--r-- 1 root root  44K May  5 17:59 fc-list
   0 -rw-r--r-- 1 root root    0 May  5 17:59 fc-list.err

[thumbor1002:/srv/fc-list] $ cat /usr/local/bin/fc-list-dump.sh
#!/bin/bash
//usr/bin/fc-list :fontformat=TrueType | /usr/bin/sort 1> /srv/fc-list/fc-list 2> /srv/fc-list/fc-list.err



[thumbor1002:/srv/fc-list] $ tail fc-list
/usr/share/fonts/truetype/unfonts-extra/UnTaza.ttf: UnTaza,은 타자:style=Regular
/usr/share/fonts/truetype/unfonts-extra/UnVada.ttf: UnVada,은 바다:style=Regular

Change 685914 had a related patch set uploaded (by Dzahn; author: Dzahn):

[operations/puppet@production] thumbor/mwmaint: add periodic job to pull fc-list file

https://gerrit.wikimedia.org/r/685914

An update:

The first docker images of Thumbor are around. While it will be a while before they are compatible enough to be deemed capable to be a good replacement for the old and unmaintained Thumbor infrastructure, the fc-list command can already be run in them. Here's a
an example (it assumes you have docker available)

$ docker run --rm -it --entrypoint fc-list -- docker-registry.wikimedia.org/wikimedia/operations-software-thumbor-plugins:2022-10-11-135003-production :fontformat=TrueType
/usr/share/fonts/truetype/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold
/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold
/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book

The list of image tags (aka versions) is available at: https://docker-registry.wikimedia.org/wikimedia/operations-software-thumbor-plugins/tags/

Change 685914 abandoned by Dzahn:

[operations/puppet@production] thumbor/mwmaint: add periodic job to pull fc-list file

Reason:

per comments above

https://gerrit.wikimedia.org/r/685914

Could someone update https://noc.wikimedia.org/conf/fc-list

It got requested at T65236#8862999 (and at T228591#8876182 )

And according to meta:SVG fonts it seems to be outdated.

Looks like Thumbor font packages now also get defined somewhere else: https://phabricator.wikimedia.org/diffusion/THMBREXT/browse/master/.pipeline/blubber.yaml$31