[vlc-devel] [RFC PATCH] freetype: font fallback using fontconfig
jb at videolan.org
Wed Jul 15 08:21:59 CEST 2015
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
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:
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 :)
- 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.
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
More information about the vlc-devel