Page MenuHomePhabricator

installed fonts fallback to DejaVu Sans
Open, Needs TriagePublic

Description

Some fonts fallback to DejaVu Sans, see File:T210960_fonts.svg

SVG:
https://upload.wikimedia.org/wikipedia/commons/0/0a/T210960_fonts.svg

PNG:
https://upload.wikimedia.org/wikipedia/commons/thumb/0/0a/T210960_fonts.svg/4500px-T210960_fonts.svg.png

Following fonts: (from https://noc.wikimedia.org/conf/fc-list )
Droid Sans Armenian:style=Regular
Droid Sans Ethiopic:style=Regular
Droid Sans Fallback:style=Regular
Droid Sans Georgian:style=Regular
Droid Sans Hebrew:style=Regular
Droid Sans Japanese:style=Regular
Droid Sans Mono:style=Regular
Droid Sans:style=Regular
Droid Serif:style=Regular
EB Garamond Initials Fill1:style=Regular
EB Garamond Initials Fill2:style=Regular
EB Garamond Initials:style=Regular
EB Garamond,EB Garamond 08:style=08 Regular,Normal,obyčejné,Standard,Κανονικά,Regular,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
EB Garamond,EB Garamond 12:style=12 Regular,Regular
FontAwesome:style=Regular
FontAwesome:style=Regular
FreeSans:style=Regular,нормален,Normal,obyčejné,Mittel,µεσαία,Normaali,Normál,Medio,Gemiddeld,Odmiana Zwykła,Обычный,Normálne,menengah,прямій,Navadno,vidējs,normalusis,vừa,Arrunta,सामान्य
Gentium Basic:style=Regular
Gentium Book Basic:style=Regular
Gentium:style=Regular
GentiumAlt:style=Regular
IPAexGothic,IPAexゴシック:style=Regular
IPAexMincho,IPAex明朝:style=Regular
Junicode:style=Regular
Lato,Lato Black:style=Black,Regular
Lato,Lato Medium:style=Medium,Regular
Lato:style=Regular

Event Timeline

JoKalliauer updated the task description. (Show Details)Dec 2 2018, 7:40 PM

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

Glrx added a comment.Dec 2 2018, 10:30 PM

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.

Glrx added a comment.Dec 3 2018, 8:31 PM

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.

Glrx added a comment.Jul 20 2019, 2:42 PM

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.