[vlc-devel] [RFC PATCH] freetype: using Pango for text layout

[Jean-Baptiste Kempf]

On 21 Jan, Salah-Eddin Shaban wrote :
> So Pango handles that for us, as well as glyph positioning (base glyphs and
> diacritics). Here's a little patch to render diacritics in red and 2
> screenshots for comparison:
> 
> https://docs.google.com/file/d/0B36ioujDBJZsR28ydHBRWjc5Nm8/edit
> https://docs.google.com/file/d/0B36ioujDBJZsNTVLTDVnaFpNSjA/edit
> https://docs.google.com/file/d/0B36ioujDBJZsLXFVWG0xa0pKRVk/edit

Nice.

> The red arrows show an example of glyph substitution: 2 diacritic glyphs
> are replaced with a single glyph by Pango according to OpenType tables. The
> first one is not unreadable, but the second is the official way to render
> this combination of diacritics. The blue arrow shows an example of wrong
> wrapping of RTL text.
> 
> So what do you guys think? Should we go with PangoFT2 or PangoCairo? Same
> module or a separate one?

Unfortunately, none of them will be working for Windows and OSX for VLC.

Longer explanation:
Pango and Pangocairo depend on Glib, and we don't want to ship Glib,
because it is very complex to build and it misbehave a lot on Windows
and OSX, and notably when compiled statically and used in 2 different
modules at the same time. Maybe it's fixed on this particular version,
but it's probably not.

Moreover, our code Freetype code is already a mess.

Why is that?
------------
Well, our Freetype module does a bit too much, and yet, not enough.
It can take HTML-like or raw text, and display it.
And it supports many quirks with teletext and all. Including some
japanese half-glyphs.

Therefore this module parses the HTML/XML, then tries to render it using
freetype.
But that means that modules like QuartzText or DirectWrite, (or any
other) does not support the same set.

Then we add fribidi to have a "almost" RTL support.

Then we have lookup for fonts and so on, using fontconfig or complete
hacks on Android and iOS. And we don't have fallbacks for glyphs...

And we don't render some languages correctly.

And of course, all the options are based on this module...

I cleaned this a bit, and tried to make the FT-specific code less
important, but it's hard and not finished.

Theory
------
In theory, we should have:
 - parsing into text_style_t (common)
 - merging into glyphs (harfbuzz?)
 - asking the OS for the right font for this glyph (including fallbacks)
 - asking the rendering engine to render that (could be Freetype) and
   getting rects back
 - merge everything and add the underlining and striking
 - send the subpicture_t to the vout

And be able to plug the right parts depending on the OS, with
pf_functions :)

Now what?
---------
There are several path of actions, from now on...
1) improve the FT module until it gets to Theory, and probably merge
   harfbuzz library in it.
2) create on API above libass so we can send text_style_t, and not only
   ASS style
3) create a new pango module for Unixes
4) mplayer way: Transform all text into SSA and send to libass

1) Difficult, but more portable and safe, for regressions
2) Should be simpler, but question about merging in libass arises.
   However, libass supports everything, including correct fallback
   (well, almost, still fontconfig on Windows...)
   So this is probably a libass fork
3) Well, less portable, for iOS, Windows and Android.
4) not sure it's the best idea, perf wise...

Here is my general view of it...

With my kindest regards,

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