Is that good? Or bad? Or what should happen instead? :)

My take is it is bad. The fc-list should be an accurate reflection of the fonts available to librsvg. I think that problem was raised in another librsvg ticket.

I'm also a bit leery of how font matching works on Unix and other operating systems. The first field appears to be the font file name, but a file name may not correspond exactly to a "font-family". Chrome, Edge, and Firefox has subtle differences with font-family lookup on Windows. I could see a "Droid Sans Georgian" font file belonging to the font-family "Droid Sans" with code points for the Georgian script. The font matcher may load the file name, but the matching algorithm may never consider the file name as a font-family token. It may use the file if a user asks for "Droid Sans" and wants to paint Georgian script code points. For another example, "Book" is a font-weight, so to use "Gentium Book Basic", one might have to say the font-family is "Gentium" or "Gentium Basic" and specify a font-weight of 300. If the font-matcher does not do font-weight matching well, it may be that no "Book" weight font can be accessed.

The summary is the fc-list misleads users. The list may not be an accurate accounting of the available fonts. The list may have been generated on a machine that has different fonts that the production servers. The list may be accurate, but it may not give the user information about how to get librsvg to use that particular font. The list may be accurate, but the font's configuration or metadata may make it unmatchable. The list may be accurate, but librsvg may not use font-config in a way that allows finding the match.

This ticket is similar T180923, which complained about fc-list and unknown fallbacks.

I'm not a font wonk, but one can look at the OpenType format to see what names are embedded in an OpenType file (and independent of the filename that holds the bits)

There is a name table.

https://docs.microsoft.com/en-us/typography/opentype/spec/name

scroll down to the Name IDs section (about 2/3 down the page). It lists the NameIDs used in the font and their meaning. At the bottom of the list is the rather ominous:

"Note that while both Apple and Microsoft support the same set of name strings, the interpretations may be somewhat different. But since name strings are stored by platform, encoding and language (placing separate strings for both Apple and MS platforms), this should not present a problem."

That suggests that some fonts might not use the Unicode platform but rather Apple or Microsoft-specific platforms.

For example uses, see

https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp

That shows the variety of font matching that may take place.

NameID 1 (Font Family name)

NameID 2 (Font Subfamily name) has the Regular, Bold, and Italic distinctions.

NameID 4 (Full font name) is roughly the typical font file name.

NameID 16 (Typographic Family name). If not present, use NameID 2.

NameID 17 (Typographic Subfamily name). If not present, use NameID 2. Adds the CSS notion of font-stretch but strings may be arbitrary.

NameID 21 WWS font family

NameID 22 WWS font subfamily

NameID 25 shows how complicated the world is.

Which names are used for font matching and how they are used depends on the font matcher:

"The key information for this table for Microsoft platforms relates to the use of name IDs 1, 2, 4, 16 and 17. Note that some newer applications will use name IDs 16 and 17, while some legacy applications require name IDs 1 and 2 and also assume certain limitations on these values (see descriptions of name IDs 1 and 2 above). Fonts should include all of these strings for the broadest application compatibility. To better understand how to set values for these name IDs, some examples of name usage, weight class and style flags have been created."

Names may not be obvious. Here is an example that is used:

Minion Pro Semibold:
Name ID 1: Minion Pro SmBd
Name ID 2: Regular
Name ID 16: Minion Pro
Name ID 17: Semibold

Assume a font matcher might list its fonts using NameID 1. Then it reports this font as "Minion Pro SmBd". What if it does font matching based on NameID 16 and 17. The user would have to request font-family "Minion Pro" with some font-weight for semibold. There seem to be many opportunities to reject a match even if other NameIDs are consulted. A request for "Minion Pro SmBd" with semibold weight might be rejected because it is not a regular weight. A request for "Minion Pro" with regular weight might be rejected because semibold was not specified.

There's a lot to sort out.

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

In T210960#5350704, @Aklapper wrote:

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

Why is master/fc-list subject to editing or under source control? I thought WMF is using fontconfig(3). The fc-list of fonts should be generated by fc-list(1) during the build. Manual updates would explain why the fc-list has or had fonts that were not available to librsvg.

See apparent manual updates at T184664. That report also suggests the font lists are different on the image scalers. That would also explain why fonts were not available. Are the available fonts now uniform across all servers of every class?

The fc-list file should be available for reading. It was, for example, used for the known-fonts list in Commons:Commons SVG Checker.

Or am I off base and master/fc-list is used for regression against the output of fc-list?

Configuration for fontconfig is the XML file /etc/fonts/fonts.config that points to the font directories, sets default fonts, and sets aliases.

.see
https://www.freebsd.org/cgi/man.cgi?query=fontconfig&sektion=3&apropos=0&manpath=XFree86+4.5.0
https://linux.die.net/man/1/fc-list

Right, my previous comment was wrong. Thanks for that! The fc-list is a just a dump "for your interest" and does not need to get patched.

@Dzahn Could you please provide us with an updated list for https://noc.wikimedia.org/conf/fc-list like you did here and probably here. Thanks

@4nn1l2 Sure, no problem. Here you go:

This is [mw2300:~] $ fc-list :fontformat=TrueType from mw2300 on buster:

@Dzahn : Thanks

@Dzahn : I noticed some encoding-Problems:

• 575: Ani,অনি Dvf should be Ani,অনি Dvf
• 148: Mitra Mono,\\u09ae\\u09bf\\u09a4\\u09cd\\u09b0 should be Mitra Mono,মিত্র
• 294: Mukti Narrow,মুক্তি should be Mukti Narrow, মুক্তি পাতনা

@all :
If I check https://commons.wikimedia.org/wiki/File:Mediawikis_Font-install-problems.svg

• David CLM still work (but is not in the fc-list)
• ori1Uni does not work (but is in the fc-list), and should work for latin according to https://meta.wikimedia.org/wiki/SVG_fonts

so something is still strange.

Sorry, I don't know anything about the cause of the encoding problems. I was merely a messenger pasting the list of installed fonts by request.

edit: also see T280721#7022037 (checked all the prod servers)

but if this is about a difference between font packages in production and on toolforge then see T218828

Also see T280718