[Webkit-unassigned] [Bug 92098] [GTK] Bring Harfbuzz-ng support to Gtk

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=92098





--- Comment #6 from Kenichi Ishibashi <bashi at chromium.org>  2012-10-30 19:08:43 PST ---
Adding behdad.
(In reply to comment #5)
> (In reply to comment #4)
> 
> > I see this with the latest harfbuzz release (0.9.5).
> 
> The issue seems to be with the platform harfbuzz code. Instead of splitting complex text into runs and choosing a font appropriately, the behavior I see is that the text uses the default font. For each character of the complex text that is not in the default font we are falling back to FontCache::getFontDataForCharacters. In the end harfbuzz is not combining those glyphs properly, because they are fallback glyphs.
> 
> I guess we should be choosing the appropriate fallback font earlier in the process.
> 
> bashi, do you think you can give more information about how this works for Chromium with the HarfbuzzNG path?

(In reply to comment #5)
> (In reply to comment #4)
> 
> > I see this with the latest harfbuzz release (0.9.5).
> 
> The issue seems to be with the platform harfbuzz code. Instead of splitting complex text into runs and choosing a font appropriately, the behavior I see is that the text uses the default font. For each character of the complex text that is not in the default font we are falling back to FontCache::getFontDataForCharacters. In the end harfbuzz is not combining those glyphs properly, because they are fallback glyphs.
> 
> I guess we should be choosing the appropriate fallback font earlier in the process.
> 
> bashi, do you think you can give more information about how this works for Chromium with the HarfbuzzNG path?

Are you trying to use HarfBuzzShaper on GTK? If so, HarfBuzzShaper::collectHarfBuzzRuns() doesn't select fonts properly?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.