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.
I worry about font matching / performance on Mac OS X now..
AntwortenLöschenWhy, did you have any issues with these recently?
AntwortenLöschenIgnoring the lengthy font collection, would there be any benefits to continue using fontconfig or do the new solutions have feature parity?
AntwortenLöschenStarks, libass will continue to use fontconfig on Linux, but in a different way. The new solution is actually superior, since I can properly sort and match fonts against the full name.
AntwortenLöschen