Seen on a recent build. The Arabic character ي is truncated in the tab title so the two bottom dots are not seen. This occurs in both the Arabic and English UI.

Additionally, it is truncated in the omnibox, but moving the cursor causes the text to bounce up and down so it is sometimes seen.

What steps will reproduce the problem? 1. Google "ويكي"

It might be related to Issue 7999.

Screenshot.

I think I understand the issue. The GTK font for Arabic locale is supposed to be: gtk-font-name="ChromeDroidSans,Droid Arabic Kufi,sans-serif, 10".

But, the platform font actually ends up as "Arimo", whose font metrics are too small to fit the glyphs from Droid Arabic Kufi which are used for Arabic characters. It seems that the function FindBestMatchFontFamilyName in platform_font_gtk.cc doesn't handle a font-family list, and returns "Arimo" as the best match for it.

I can think of at least 2 solutions.

(1) Fix platform_font_gtk.cc. But I wonder if that will be unnecessary (on Chrome OS) because of the GTK removal.

(2) Change the GTK font to just "Droid Arabic Kufi". If we do, as shown in the screenshot, the ي in the tab title and wrench menu (in the Ctrl+Shift+N incognito window item) is no longer truncated, although the favicon alignment is weird. Jungshik, do you think it would be okay to do that?

Oshima, does the GTK removal impact the use of platform_font_gtk.cc on Chrome OS? Also, will there be a way to specify the platform font as we currently do in files like locale_settings_cros_ar.xtb (http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/resources/platform_locale_settings/locale_settings_cros_ar.xtb?view=markup)

Daniel, do you know how GTK removal affects fonts?

Background: The Arabic UI should use "ChromeDroidSans,Droid Arabic Kufi,sans-serif, 10" as the platform font, but this gets mangled by FindBestMatchFontFamilyName in platform_font_gtk.cc to "Arimo". Therefore, the font metrics are off and some Arabic characters get truncated in the tab titles and menu.

I'm wondering how best to fix this. Would the GTK removal obsolete the use of PlatformFontGtk? And can we still specify locale-specific fonts like we now do in the gtkrc "files" (IDS_LOCALE_GTKRC in locale_settings_cros_*.xtb files)?

While I haven't heard much about the plans here, I assume that PlatformFontGtk will need to be replaced. Note that it'll still be used for the Linux version of Chrome, though, so it'd be good to fix it in the meantime (assuming that it's not too much work).

http://developer.gnome.org/pango/stable/pango-Fonts.html#pango-font-description-set-family states, "In some uses of PangoFontDescription, it is also possible to use a comma separated list of family names for this field." Perhaps PlatformFontGtk::PlatformFontGtk() should split |family_name| on commas and call FindBestMatchFontFamilyName() for each family until it finds a match (although I'm a bit worried that we'll just end up falling back to a default font -- if it's supported in fontconfig, maybe FindBestMatchFontFamilyName() should take a |strict_match| parameter as well).

I think the reason for specifying both fonts is that Droid Arabic Kufi contains only Arabic characters and ChromeDroidSans only Latin characters. So we actually want to keep both inside of PlatformFontGtk, not find a best match between them.

It seems there is a fundamental limitation that PlatformFontGtk holds on to a single SkTypeface when we would like to use a list of font families as PangoFontDescription allows. It also seems that the SkTypeface is used only for getting font metrics. I think it should be possible to get metrics using Pango (pango_layout_get_pixel_extents), but I guess there is a reason Skia is used (there is a comment that "pango metrics are much more expensive").

Perhaps an intermediate solution is to find the first match within the list as Daniel suggested, and just order our list so that Droid Arabic Kufi comes first, since we know it is the bigger font.

+agl: Do you have any thoughts on using a font family list inside PlatformFontGtk?

What do we do on Windows? Surely we encounter tab titles that span multiple fonts there...

Unfortunately, because PlatformFontGtk is only used for tab titles on Linux it hasn't had as much attention as our other font code. I think ultimately if we're using Pango to render the fonts, we should be using Pango to measure them; we've had other bugs in this area due to Pango doing kerning and Skia not doing it. Otherwise, you should feel free to make SkTypeface etc. as complicated as you need to support multiple fonts, though I think getting this fully correct (especially in the presence of complex scripts and RTL) is pretty hard.

adding xiaomei who is working on BIDI/Complex support for chromeos. Looks like it's only used inside canvas_skia_linux.cc on linux/chromeos, I agree with evan that using pango is better option. Xiaomei, what do you think?

On Windows, Arial's Arabic glyphs are not as tall as Arabic glyphs in Droid Arabic Kufi / Droid Arabic Naskh. The same is true of Arabic glyphs in Segoe UI (the UI font on Windows Vista or later). Windows made a lot of compromises to fit Arabic glyphs in the limited vertical space .

So, in case of Arabic, we don't hit this problem on Windows. In addition if SegoeUI is used as the UI font (we don't have gtkrc-equivalent on Windows and we just use the default OS UI font for most locales, which is SegoeUI. Only for some Indian locales, we specify locale-specific fonts), Windows automatically picks a fallback font for 'major' scripts that work more less with SegoeUI's metric. So, we're ok there.

Anyway, on Windows, only a single UI font can be specified in Chrome's UI because our code on Windows has the same limitation as on Chrome Linux. However, thanks to what I described above, it's mostly ok.

Anyway, I agree with Evan that we should use Pango 'directly' to deal with a list of fonts.

It's absolutely necessary to be able to specify a list of fonts in the UI.

xji, this is the problem I told you about the other day. It looks like specifying multiple fonts doesn't help in our current implementation. (see comment 5 on gtkrc and specifying multiple fonts).

To Matt, does replacing 'ChromeDroidSans' with 'Chrome Droid Sans' lead to any change? It does not look like it does, but just in case, I'm asking.

BTW, for Arabic and other 'tall scripts', our plan is to build UI fonts (separate from 'document/body' fonts) to work better in a restricted vertical space like tab title, ominibox, bookmark bars.

Three changes to try:

1) Put 'Droid Arabic Kufi' before 'Chrome Droid Sans' in gtkrc for Arabic (in IDS_...) 2) Replace 'ChromeDroidSans' with 'Chrome Droid Sans' 3) Replace 'ChromeDroidSans' with 'Droid Sans'

Droid Sans and Chrome Droid Sans have different vertical metrics. The former has larger vertical metrics in head, hhea and OS/2 tables.

Well, I'll try it on Friday.

See also bug 21296

1. 1st attachment shows that "ويكي" has two dots below the left-most character (last character in RTL-sense) clipped in the omnibox candidate list.

2. 2nd attachment shows that "قمر_طبيعي" has two dots below the left-most character (last character in RTL-sense) clipped in the tab title. There's no clipping in the omnibox, but the bottom of the tallest glyph (with the deepest descender) touches the boundary.

3. 3rd attachment shows that "قمر_طبيعي" is not clipped in the tab title tooltip because the tooltip has more vertical space available for 'ink' than the tab strip.

For the original issue reported (tab title), there is some vertical space available for 'ink', but it's not fully used for 'ink'. We have to find out whether that's because we end up using 'Arimo' with smaller vertical metrics (in head, hhea, OS/2 tables)[1] or because we specify some 'padding' below and above that is not available for ink.

If it's the latter, we can consider reducing 'non-drawable' padding in the tab title and making most of the vertical space in tab title available for 'ink. Glen wrote (off-line a few weeks ago) that it'd be good to do so.

[1] We also have to check what vertical metrics Arimo has. THe chance is that Chrome Droid Sans has a lot more tighter vertical metrics than Arimo. In that case, making the tab title use Chrome Droid Sans wouldn't help.

Moving bugs marked as Started but not blockers from R17 to R18. Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.

Bulk move of non-blocking issues from R18 to R19.

Bulk punt: This bug is not a regression or release blocker. If you believe it needs to be in M19, please move it back and tag it with ReleaseBlock-(Beta|Stable) for consideration.

This bug has not been touched in a while. Please re-open (in crbug.com) if you can repro in M20+. Thanks a lot for your help!

Moved to: Issue chromium:200482