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

[Jean-Baptiste Kempf]

On 18 Apr, Salah-Eddin Shaban wrote :
> Well, that took a while!

No, it did not. Considering the difficulty, it did not take 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.

Yes, it's a good idea, because so far, the freetype code does too much.
And sometimes we might want a different renderer.

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

That's a cool trivia information :)

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

Do we need a font to do the shaping?

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

OK. First, let's make things right. Then let's make them fast :)

> 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

I do not think this split is correct, tbh.

You cannot delete code, and then add it in a separate commit.
Each commit should compile and work.
Either we apply all togethere,  or we apply per logical group.

Anyway, thanks a lot for this awesome work.

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