Fontconfig font provider may use non-Windows names

[sr55]

We have a user reporting incorrect font-selection that appears to have the required front on their system.

HandBrake/HandBrake#1615

fc-list | grep 'Ong Do Gia'
/usr/share/fonts/transcoder/utm-fonts/UTM Ong Do Gia.ttf: UTM Ong Do Gia:style=Regular
/usr/share/fonts/transcoder/unicode-fonts/UTM Ong Do Gia.ttf: UTM Ong Do Gia:style=Regular

Results:
[09:26:01] [ass] fontselect: (UTM Ong Do Gia, 700, 0) -> /usr/share/fonts/transcoder/svn-fonts/SVN-Student.ttf, 0, SVN-Student
[09:26:01] [ass] fontselect: (UTM Swiss Condensed, 700, 0) -> /usr/share/fonts/transcoder/unicode-fonts/UTM Swiss CondensedBold.ttf, 0, UTMSwissCondensed-Bold

First one was incorrect, second one was.

Utilising 0.14.0

I'm not convinced this is a bug, but more something funny about the source that's triggering the font choice to go the wrong way. Any suggestions would be appreciated.

[secondsabre]

Just wanted chime in on this that I noticed a similar problem in Handbrake myself, under HandBrake/HandBrake#1954.

Multiple files that I've passed through Handbrake have come back with the incorrect font once burned in (softsubs are fine), and I've noticed the same problem with VLC as well. I know how to play around in ASS files, so I've been picking away at options to try and figure out what the cause is.

For my test case, the ASS file is using the font "Bahnschrift SemiBold Condensed", but VLC and Handbrake (with burn-in) keep rendering it in its basic form, "Bahnschrift". I tried a bunch of stuff inside the ASS files to find the triggers, including:
-changed to a different variation (Bahnschrift SemiBold SemiCondensed)
-removing all styling tags beyond defined styles (italics, etc, thinking that it might be choking on a not-found variation)
-exporting to SSA instead of ASS
-changed to a different font that doesn't have sub-variations (OffensiveBold), and that seemed to bypass the problem (in both programs)

Here are log snips and screencaps from the respective processes.

---

Broken original attempt (Bahnschrift)
Handbrake Log:
[ass] fontselect: (Bahnschrift SemiBold Condensed, 400, 0) -> Bahnschrift, 0, Bahnschrift
MPC screen:

VLC screen:

(as you can see, it's dropping the variations for some reason)

---

Second attempt w/ new font (OffensiveBold)
Handbrake Log:
[ass] fontselect: (OffensiveBold, 400, 0) -> OffensiveBoldBold, 0, OffensiveBoldBold
MPC/VLC screen (both show the same thing)

I do find it a little odd that it seems to be adding an extra 'bold' to the font name during conversion, especially since the font doesn't use a bold variation anywhere in the file but in terms of output it seems to work properly.
Edit: Looks like the font is called "OffensiveBold Bold" in the Windows font folder, so that makes sense. Durp.

---

I can keep on plugging away at this to see if I can nail it down, I've seen similar issues come up from a bunch of different fonts, but others are just fine. Let me know if you need any more info or testing, I'd be happy to help quash this problem any way I can.

[TheOneric]

Not sure if related to your issues, but:

fc-list | grep …

If you're testing font selection, especially with Variants fc-match is a more suitable command. For one you might get false positives/negatives due to filename vs fontname and the variants. On the other hand users (and sysadmins/distro maintainers) can configure aliases for fontconfig. E.g. common preconfigured aliases on Linux+GNU systems include aliasing the proprietary Microsoft fonts Arial,Courier New,Times New Roman,… systemwide to the metrically identical Arimo,Cousine,Tinos,… or the Liberation font family (or for closer visiual similarity Courier New → Courier(the original), though this does not have the same metrics).
Users can also define their own aliases (see man fonts-conf), which might "hide" an installed font. fc-match does take this into account, fc-list does (afaik) not.

[TheOneric]

I was now able to obtain a copy of the SVN Student font (no license info though).
This font is broken and I can't even get fc-match to match SVN-Student,SVN Student or similar.
Having the SVN font present leads to libass selecting this font instead of the proper UTM Ong Do Gia font, soft- and hardsub.
Inspecting the font in fontforge shows why: Among several other warnings about broken fields and differing values is:

Warning: Mac and Windows entries in the name table differ for the PostScript String in the language English (US):
  Mac String: UTMOngDoGia
  Windows String: SVN-Student

Also both have their "UniqueID" set toUTM:Version 1.00.

That being said, e.g. pluma does allow me to select the proper UTM Ong Do Gia and even SVN Student, so it should be possible to have a workaround for these broken fonts.

[abdatta]

I'm having the same issue as @secondsabre I'm using Aegisub to create subs with the font "Bahnschrift Condensed", and while Aegisub shows the font properly, when I open the subs in VLC, they change to the basic "Bahnschrift" font, thus distorting all the text. In my case, I'm using the font for masking kanji signs, so it especially looks bad when it gets distorted. Any possible solutions?

[TheOneric]

I'm having the same issue […] with the font "Bahnschrift Condensed" […], when I open the subs in VLC, they change to the basic "Bahnschrift" font

There are many different Bahnschrift fonts. Which one are you using ?

The orignal issue, as reported in HandBrake, was a broken font, that claimed to be another font in its header – except for the MS-specific part. While it maybe might be a good idea for libass (unlike most other software) to check these headers for font selection in the interest of VSFilter compatibility – this really is problem with the font itself and should be fixed by the font author.
If your Bahnschrift-font-family is shipped as a OpenType variable font, then see #386 .
Or maybe it's another problem altogether, hard to say without knowing the specific font you used.

Any possible solutions?

If it's a broken font, fix the font.
If it's a variable font, until #386 is fixed, you can split the variable font up into separate font files for each width variations you are using.

[abdatta]

Thanks for responding so soon! 😃 Yes, I think it is a variable font, and that's what is causing the issue. I'm sorry I wasn't aware that there are many fonts with the name/variant "Bahnschrift Condensed". Here's a screenshot for when I open the font in windows:

Thanks for letting me know we can split up variable fonts. I'll try finding ways to do so. In case you know some easy way to do it already, I'll be grateful if you share 😄

[TheOneric]

That being said, e.g. pluma does allow me to select the proper UTM Ong Do Gia and even SVN Student, so it should be possible to have a workaround for these broken fonts.

When no system font provider is used, libass actually already uses the Windows platform name to select the inteded UTM Ong Do Gia font if its attached to the media container (or loaded via API as a memory font) — even if SVN Student is also attached. Attached/Memory fonts are the only ones we can fully achieve compatibility with VSFilter for since we parse all fields ourselves. With system fontproviders this is not always possible and e.g. Fontconfig does not distinguish between platform names afaik (though it’s curios GTK’s fontselection based on Fontconfig manages to distinguish them).

Unfortunately, enabling Fontconfig breaks this and instead of the attached font, the system’s copy of SVN Student is selected instead. I believe this is due to our implementation of the Fontconfig provider eagerly registering all fonts on startup and there being no distinction between memory/attached fonts and fonts already registered by the system provider.
Implementing such a distinction as discussed in e.g. #608 (albeit VSFilter doesn't distinguish) or switching Fontconfig away from eagerly loading will likely fix this particular case.
I can't test it, but it’s possible our other font providers (CoreText and the two DirectWrite variants) already do select the attached UTM Ong Do Gia, since they both already switched away from eager loading for unrelated reasons (which didn't really affect Fontconfig).