GSoc 2011 Wrap-up

Complex text layout

With this year's GSoC, libass gained solid complex text layout support, with help of the FriBidi and HarfBuzz-ng libraries. In practice that means Arabic, Hebrew, Devanagari and many other scripts that are non-trivial to render display correctly (and without side effects or bugs). Additionally, for latin text,  ligatures, combining marks and language-specific features should work as expected. Vertical CJK text layout is also improved, now it can use proper vertical glyphs variants, if available. The work on complex text layout progressed quickly, and shortly after the midterms most text rendered without major problems.

A real-life example of Arabic subtitles.

New font handling code (without fontconfig)

Since there was quite a lot of time left in GSoC, I started focusing on a completely different problem: font matching. libass used fontconfig for that, but fontconfig is a pain on Windows. Moreover, the font sorter/matcher of fontconfig isn't very suitable for libass, since it does not match names the way Windows, and therefore VSFilter does.

I completely ripped out fontconfig and replaced it by my own font sorting/matching code. Various backends can provide font meta information to the font sorter. Currently, three such backends exist:

• FreeType backend, mostly useful for embedded fonts
• fontconfig backend, to access system fonts on Unix
• Windows GDI backend, to access system fonts on Windows

In the end, in practice the most important advantage is that there's no hard dependency on fontconfig anymore. Even without any additional platform-specific backend, libass can now render embedded Matroska subtitles correctly, as the long as the required fonts are attached. The Windows GDI backend gets rid of the fontconfig cache building, which bothers many users.

What's cooking

Performance Improvements to the Windows GDI font backend.

The GDI interface is very bad and awkward to use for collecting font metadata. The new DirectWrite API is much more sane and I'll likely implement a backend for this. It is supported on Windows Vista and up.

I have half-finished SSE2-accelerated versions of the blur filters (\be, \blur) lying around, these should be  completed.

Rendering quality will be improved with an internal compositor. Especially if alpha transparency is in use, results are less than optimal at the moment.

System fonts without fontconfig

I've uploaded a new version of my win32 VLC test build. This new download includes an experimental Windows GDI font collector (patch), so system fonts can be used now! The interface for that (FontProvider) is now publicly exposed in the libass library as well.

Not actually that horrible.

GDI is a bad API for what I need to do, so there are some limitations. I can't get all "full names" for a font, only the localized or often English name. More importantly, fonts are accessed with the GetFontData call that buffers them into memory. This can be quite slow, especially for big CJK fonts or Unicode fonts like "Arial Unicode MS".

Still, for most purposes, this should work fine.

Download the test build

VLC win32 test build

I've built VLC for Windows against the latest code of the fonts branch, and of course with the FriBidi and HarfBuzz support from mainline. This means:

• Arabic and Hebrew text works correctly (but no HarfBuzz support)
• OpenType shaping works
• The annoying "Building font cache" message is gone

However, currently only embedded fonts are supported. Usually most fonts are embedded in Matroska files, so this often is not a big issue.

Download the test build

Update: Download replaced by a new build with HarfBuzz support.

--disable-fontconfig

With the latest commits to the fonts branch, I can say with some excitement that libass does reasonably work without fontconfig now. Embedded fonts work perfectly, and so does the fallback font (if specified).

Next stop: a public interface for providing information about system fonts.

Font handling: it's hard!

So far libass uses FontConfig for collecting font metadata and matching fonts. However, fontconfig isn't ideal for matching fonts in the way the ASS/SSA formats need it. These formats primarily use the "full name" for matching the font, that is, a name including style, such as "Arial Bold Italic". FontConfig does not match against this name at all, and there are various hacks in libass to work around that (badly).

If you dig deeper into it, you'll find out that font naming is a big and complicated mess. Let's sum up the facts:

• Various different names exist, such as family name, full name, PostScript name, subfamily name, etc.
• Most of these can be localized
• Different platforms (such as Windows or Mac) can have individual names

So there's no such thing as a single name for a font at all! Gladly we don't really need to support all of these names (family name and full name seems to be good enough).

As a first step to get away from the FontConfig dependency I've implemented my own font sorter and matcher that is optimized for the needs of ASS/SSA. I've also begun to work on an interface (FontProvider) that allows various font sources (such as Windows DirectWrite or container-embedded fonts) to plug into libass. At the moment, this already allows libass to work without fontconfig when only embedded fonts are needed.

There are still some problems to solve with this new code, but in the meantime, it will live in the fonts branch, until it is ready for general consumption.