[vlc-devel] [PATCH 0/9] freetype: use HarfBuzz for text shaping

[Salah-Eddin Shaban]

Hello,

Well, that took a while!

Remi recommended we keep the shaping code out of freetype.c so it's now in text_layout.c along with everything related to text layout.

Another version of the code was tested on a few other languages and no one reported any errors:

http://lists.freedesktop.org/archives/harfbuzz/2015-March/004758.html

A note about text direction:

Early on I faced a problem where some characters like hyphens, quotation marks, and parentheses kept appearing incorrectly. Here's an example:

https://drive.google.com/open?id=0B36ioujDBJZscUlDS1FabDNZbHc

You see the text is rendered with two parentheses facing the same way, one of them is an opening parenthesis at the beginning of the text when it should actually be a closing parenthesis at the end. If you look at the raw characters before shaping (upper left) you'll see that the problem is with the text itself. There are indeed 2 opening parentheses and one of them is at the beginning of the text. It turned out to be a common thing in subtitle files where those who create the files work around the limitations of RTL support by re-ordering characters so they would show correctly when rendered with a paragraph base direction of LTR, like this:

https://drive.google.com/open?id=0B36ioujDBJZsN25pYkNkTDVaMms

Here the first parenthesis at index 0 is identified as an LTR opening parenthesis and left alone, and the second as an RTL one and mirrored, and the end result appears correct.

I kept thinking it was a rendering problem because the text was appearing correctly in the text editor. But then it turned out the editor too was using an LTR paragraph base direction. Were it not for this issue, it would have made sense to set the default text direction to Auto. But it seems to me most people expect it to be LTR.

Things that remain to be done, which I would love to do if circumstances allow it:

font fallback:

As far as I understand things now, there's some sort of a circular dependency here. For shaping to work we need a font, and to know which font to select we need to know the final glyphs, which can only be known after shaping. I'm currently trying to figure it out.

optimizations:

Again, as far as I understand things, when shaping with HarfBuzz FT_Load_Glyph is called twice for each glyph, the extra call is during the shaping stage to get glyph metrics, and FT_Load_Glyph seems to be a bit of a performance bottleneck. Libass replaces the default HarfBuzz FT functions to use a glyph metrics cache, and I think we can use the same libass functions here with little modification. Libass also uses a glyph bitmaps cache and we can do the same here.

Salah-Eddin Shaban (9):
  freetype: update configure.ac and Makefile.am to use HarfBuzz
  freetype: remove layout code from freetype.c
  freetype: remove remaining layout code from freetype.c
  freetype: update freetype.c
  freetype: new file: freetype.h
  freetype: new file: text_layout.h
  freetype: new file: text_layout.c
  freetype: text_layout.c: new shaping functions
  freetype: text_layout.c: new layout functions

 configure.ac                        |   17 +-
 modules/text_renderer/Makefile.am   |    7 +-
 modules/text_renderer/freetype.c    |  751 ++-------------------
 modules/text_renderer/freetype.h    |   72 ++
 modules/text_renderer/text_layout.c | 1273 +++++++++++++++++++++++++++++++++++
 modules/text_renderer/text_layout.h |   55 ++
 6 files changed, 1492 insertions(+), 683 deletions(-)
 create mode 100644 modules/text_renderer/freetype.h
 create mode 100644 modules/text_renderer/text_layout.c
 create mode 100644 modules/text_renderer/text_layout.h

-- 
1.9.1