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

[Jean-Baptiste Kempf]

On 22 Jul, Salah-Eddin Shaban wrote :
> 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.

I guess you answered your question then :)

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

Well, let's hope it will work out.

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

Oh yes. But our libass modules requires fontconfig and it's the biggest
part where people complain about VLC on the web, because of the font
cache building.

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

I thought GDI and Uniscribe allowed to have query of codepages (not
codepoints) for fonts.

> 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

Agreed.

> 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

Don't worry about Mac, for now :)

> QCoreTextFontDatabase::fallbacksForFamily does exactly that, and does
> not require actually creating a custom database, so we can use it
> here.

Qt is usually a good example to follow.

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

Well, not all Android versions have the same fonts IIRC.
So I don't see how we can avoid creating a very simple DB.

> 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++ :(

Don't worry about Mac/iOS, we have clever guys on those platforms.

With my kindest regards,

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