Comment 47 for bug 560795

(In reply to comment #44)
> (In reply to comment #43)
> > (In reply to comment #42)
> > > (In reply to comment #41)
> > > > (In reply to comment #40)
> > > > > (In reply to comment #38)
> > > > > > (In reply to comment #35)
> > > > > >
> > > > > > > I’ve updated the page with an explanation and with a screenshot of the expected result.
> > > > > >
> > > > > > Thanks - that's a good starting point for creating some LayoutTests later.
> > > > >
> > > > > Right now HarfBuzzRun doesn't hold language and doesn't set language on the buffer.
> > > > >
> > > > > This *is* a Webkit bug.
> > > >
> > > > Ok, then I’m very curious what’s going on in Chromium. Is there any other part of the program that can do something with Opentype features? Because the effects shown in the testpage can’t be replicated but with locl.
> > >
> > > Yes, as you identified yourself, it applies locl, just not the right one. And to make it apply the right one a fix in webkit is needed. I'm not quite sure what you are talking about.
> >
> > I’m sorry, I probably haven’t understood well the part of HarfBuzzRun "doesn't hold language and doesn't set language on the buffer".
> > I understood it in a way that HB isn’t responsible for the locl feature effects we see.
>
> HarfBuzz applies 'locl'. It needs to be told the text language. When it's not, it uses default language.
>
> HarfBuzzRun is a Webkit abstraction around HarfBuzz shaper. It's part of the glue code connecting Webkit HarfBuzz. As such, it must collect the correct language from other Webkit layers and pass it to HarfBuzz. It's not doing that right now.
>
> > I’m confused. But nevermind, I’m sure you’re doing the right thing.
>
> Yes, I believe the issue is clear now.

And I too understand it now. Thank you!