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

[Salah-Eddin Shaban]

On 4/18/15, Jean-Baptiste Kempf <jb at videolan.org> wrote:
> 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?


When shaping with HarfBuzz, yes. FriBidi can perform simple shaping
that does not require a font file. For example, turning Arabic
characters (which are stored in text files in their isolated forms)
into their initial/medial/terminal forms, as well as mirroring and
simple ligatures. The screenshots show an example of shaping with
FriBidi, mirroring here is performed by changing code points. When
shaping with harfbuzz it's the glyph indices of the characters within
the selected font file that get changed. As a matter of fact, when
shaping with HarfBuzz we lose track of code points altogether. And I
think it's the same with other shaping libraries, like Microsoft's
Uniscribe.


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


Sorry I didn't know that. I'm learning as I go.
You know I was trying for years to do anything worthwhile in
programming but it had always been toy projects and Hello Worlds and
the like. It's VLC which snapped me out of it :) and for that I'm
really grateful.

Last Internet outage here lasted about 3 weeks I think. Even now DSL
connections are down, but on mobile networks the Internet is working
again. Not always but it's better than nothing. When the Internet came
back I was almost done, so I decided to be quick about it.

I tried first to send everything as a single commit, but the mailing
list would not accept it for some reason. It was not a connectivity
issue on my side, the email was sent and I could see it in GMail, but
it would not show up on the list. The patch was about 80 KBs or
something so I thought maybe it was a size limit issue. That's why I
broke it into smaller commits, no larger than 20 KBs. I was really
worried some parts would show up and others would not and then I might
lose Internet access again and that would be embarrassing lol.

I'm not sure how much of the patch can be split into commits that
actually compile and run. The bulk of it would probably still have to
remain as a single commit. That was actually the difficult part. I had
to work a long time before I could compile and test for the first
time.


> Anyway, thanks a lot for this awesome work.
>
> --
> Jean-Baptiste Kempf
> http://www.jbkempf.com/ - +33 672 704 734
> Sent from my Electronic Device
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>