[vlc-devel] [RFC PATCH] freetype: font fallback using fontconfig

Jean-Baptiste Kempf jb at videolan.org
Wed Jul 15 08:21:59 CEST 2015

Hello Salah-Eddin,

On 09 Jul, Salah-Eddin Shaban wrote :
> This is one way to implement font fallback using fontconfig. Platforms

Thanks a lot.
That's amazing work, once again.

> that do not use fontconfig will require that we implement a custom
> font database, which should not be very difficult.

Well, Windows GDI+ seems to have one database, but by coderanges, and
not codepoints. Windows DirectWrite should have a complete database.

Android does not have such DB, but has a list of fonts, mostly by name
of script.

OSX and iOS CoreText have the DB too.

The rest (that we care about) all have FC.

> Here I am doing the fallback on the codepoint level, which is the
> method used by Qt and Libass. An alternative method is to try the

If that fast enough?

> A few notes:
> - We can no longer pass NULL for FcConfig to fontconfig functions.
> This is because we are now adding font attachments to the FcConfig,
> and passing NULL causes the default config to be used. This means that
> later instances of the freetype module will use the same FcConfig,
> which will contain stale records about font attachments in previous
> media files.

OK. But is that thread-safe?

> - The way font attachments are processed here might need tweaking.
> Judging from one comment in Libass's source, using the language as a
> criteria in a matching pattern might cause some font attachments to be
> ignored by fontconfig, because they lack certain characters to qualify
> as covering a certain language. If this is indeed the case, we can
> probably have another FcConfig in filter_sys_t devoted solely to font
> attachments. We create this one using FcInitLoadConfig or
> FcConfigCreate so that system fonts will not be included in it. And in
> FontConfig_Select we search that first, without adding the language to
> the matching pattern.
> Application fonts in fontconfig are explained better here:
> http://mces.blogspot.com/2015/05/how-to-use-custom-application-fonts.html

Well, yes, font attachments, notably in MKV/ASS from Anime sources
should be prioritized over the other fonts.

> - I'm not sure if we really need to pass a language to LoadFace. I did
> it at first to avoid calling LoadFace for each codepoint, but that was
> happening anyway when HarfBuzz was disabled, and it was too slow, so I

> had to think of something else. Now each run tries already loaded
> faces first, and only calls LoadFace if none of them has the required
> codepoint. This seems to work very well. So languageFromScript can

This part is a good idea I think.

> probably be removed altogether, along with the language parameter to
> LoadFace. I left them for now to do some more testing. Sometimes
> calling LoadFace without a language causes fontconfig to return a
> different family even when no fallback is required. For example, if
> LoadFace is called with the family "Droid Arabic Naskh", with language
> and codepoint set to 0, it returns DroidSans.ttf. If language is set
> to "ar" it correctly returns DroidNaskh-Regular.ttf. Apparently using
> FcPatternAddWeak instead of FcPatternAddString to add the family has
> something to do with it. This was done so that the language will take
> precedence over the family. Anyway, it can be reverted, in which case
> the font attachments issue mentioned above should be fixed as well.

Yeah, I am not sure we need this language passing to LoadFace.

> - Also in one Libass comment, it is said that fonts in SSA subtitle
> files are sometimes referenced using their full name (family + style).
> I'm not sure whether it's something we too should handle.


> - About creating a custom font database, this should probably be done

The less DB we have to manage, the better we are :)

Jokes aside:
 - Android has no DB whatsoever, that I can see. But everything is in
   /system/fonts and there is DroidSansFallback.ttf there.
   Else, Skia seems to have a very dumb DB for Android
   That should be doable for us too.

 - Unixes will have FC, always. If not, don't care.

 - Windows GDI and Uniscribe should provide:

 - OS X and iOS should have similar code, IIRC.

The other should adapt. :)

> - An alternative to creating a font database for platforms that
> currently use Dummy_Select is to create a "smart" Dummy_Select with a
> hard-coded map of scripts to font files. Something also has to be done
> about fonts that lack neutral characters like parentheses and
> punctuation but that should be trivial.

No platform use Dummy_Select for now.

Btw, if you want, you can expect HB to be in, same as fribidi, tbh.


Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device

More information about the vlc-devel mailing list