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

[Salah-Eddin Shaban]

On 7/15/15, Jean-Baptiste Kempf <jb at videolan.org> wrote:

>> 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?
>

It's the faster of the two methods. LoadFace is usually called only
once or twice for each run. FT_Get_Char_Index is called for each
codepoint, sometimes more than once, but that seems to add only a
little overhead. In the other method the shaping process can be tried
several times and that can slow things a lot.

>> 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?
>

Yes, it's the default FcConfig that is shared process-wide, and we're
no longer using it. However, this may have to change again so that
font attachments are handled in a uniform way on all platforms.

>> - About creating a custom font database, this should probably be done
>
> The less DB we have to manage, the better we are :)
>

I agree :)
It's just that for the time being I can only work on Linux, so the
idea of one method to use on all platforms was attractive.

> 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
>
> https://code.google.com/p/skia/source/browse/trunk/src/ports/SkFontHost_android.cpp?r=9939
>    That should be doable for us too.
>
>  - Unixes will have FC, always. If not, don't care.
>
>  - Windows GDI and Uniscribe should provide:
>    https://src.chromium.org/chrome/trunk/src/ui/gfx/font_fallback_win.cc
>    https://src.chromium.org/chrome/trunk/src/ui/gfx/render_text_win.cc
>
>  - OS X and iOS should have similar code, IIRC.
>

Okay, I have examined the Skia and Chrome code. As far as I can see,
no platform has a database in the sense that one can query for fonts
having certain scripts or certain codepoints, they all provide a list
of fallback fonts to try one by one until missing glyphs are found. In
Windows this is called "Font Linking" and in CoreText "Cascade List".
Qt and Skia do more or less the same thing. DirectWrite does offer
better fallback facilities (IDWriteFontFallbackBuilder and
IDWriteFontFallback::MapCharacters) but they require Windows 8.1 as a
minimum. So I think font linking is what we should use for Windows.

Chrome's GetFallbackFontFamilies in Linux uses FontConfig in this
manner too so that a list of fonts is returned and the same steps are
taken on all platforms, and I think we should do the same as well. On
Mac GetFallbackFontFamilies is not implemented, and CoreText handles
font fallback internally. That works for them since CoreText is used
for rendering and not FreeType. But Qt's
QCoreTextFontDatabase::fallbacksForFamily does exactly that, and does
not require actually creating a custom database, so we can use it
here.

For Android I think we can take the easy way, at least for starters,
and avoid creating a Skia-like database. So we can hard-code the
standard system fonts and the scripts they support. And any list we
return should have DroidSansFallback.ttf as a last resort.

I will try to do the Windows and Android code by the book and
hopefully any errors will require only minor fixes by you. But for
CoreText I'm afraid I can't do even that. I'm not at all familiar with
Mac OS/iOS or with Objective C/C++ :(