1150394 - Arabic characters height is different when rendered inside B2G and desktop browsers

Status: RESOLVED DUPLICATE of bug 1150449

(Core :: Layout: Text and Fonts, defect)

Description

[Oleg Zasypkin [:azasypkin]]

Attachment: rtl-box-quads.html

To reproduce the issue please use attached test case in desktop Firefox and in B2G browser (I used latest mozilla-central flame-kk PVT build). 

To measure container height (div) I use "div.getBoxQuads()[0].p3.y - div.getBoxQuads()[0].p1.y", for actual text height it's "div.childNodes[0].getBoxQuads()[0].p3.y - div.childNodes[0].getBoxQuads()[0].p1.y". Height of Arabic chars is B2G is significantly different from what we see in Desktop.

Currently in gaia we have several Arabic characters bugs that may be caused by this issue (eg. see bug 1140977, bug 1133137, bug 1148626).

Comment 1

[Oleg Zasypkin [:azasypkin]]

Asking for v2.2 blocking status as at least one of referenced bugs was v2.2+ (fixed with ugly line-height and negative margin workaround) and the rest are nice to have in v2.2.

Comment 2

[Julien Wajsberg [:julienw]]

Tamara also had to workaround this, adding her in Cc so that she can add a pointer.

Comment 3

[Jonathan Kew [:jfkthame]]

It's not clear to me that this is a bug. Comparing this example in desktop Firefox and B2G is rather meaningless: all it's showing is that two different platforms are using different fonts, and those different fonts have different line height requirements.

You'll also see different heights if you compare desktop Firefox on different platforms; this is to be expected, because different fonts are available and used.

Similar problems are likely to arise with other scripts, too. Many Indic and SE Asian scripts have some characters that will project higher and/or lower than is typical for Latin text, and elements that have a fixed height that was designed for Latin text will run into such clipping issues.

ISTM that page/app designs need to be flexible enough to allow for font ascent/descent/lineheight metrics that differ significantly across various scripts.

Comment 4

[Julien Wajsberg [:julienw]]

> ISTM that page/app designs need to be flexible enough to allow for font
> ascent/descent/lineheight metrics that differ significantly across various scripts.

Not that easy, especially we can't use "overflow: visible" because we usually want an ellipsis for long text. (and if I'm not wrong "overflow-x: hidden; overflow-y: visible" show the scrollbars).

What's surprising on the examples is that the text does not look to take that much space. Do you think the font's intrinsic measurements could bewrong?

Comment 5

[Julien Wajsberg [:julienw]]

The fonts we use in Firefox OS are at [1]. But I can't find the arabic font here.

[1] https://github.com/mozilla-b2g/moztt

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> The fonts we use in Firefox OS are at [1]. But I can't find the arabic font
> here.
> 
> [1] https://github.com/mozilla-b2g/moztt

AndroidFonts/DroidNaskh there is Arabic.

(Although partners could presumably choose to ship different fonts, throwing an additional variable into the mix.)

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Julien Wajsberg [:julienw] from comment #4)
> > ISTM that page/app designs need to be flexible enough to allow for font
> > ascent/descent/lineheight metrics that differ significantly across various scripts.
> 
> Not that easy, especially we can't use "overflow: visible" because we
> usually want an ellipsis for long text. (and if I'm not wrong "overflow-x:
> hidden; overflow-y: visible" show the scrollbars).
> 
> What's surprising on the examples is that the text does not look to take
> that much space. Do you think the font's intrinsic measurements could
> bewrong?

Arabic has certain glyphs that are considerably taller or deeper than the bulk of the text (as well as diacritics that may be added above or below the text), so the font needs to allow space for these.

Adding characters such as "أ ي" to the example text here may help to show why the font requires the height that it does.

Comment 8

[Jonathan Kew [:jfkthame]]

One thing that might help here would be to replace the Droid Arabic Naskh font we've currently got in moztt (as one of the "inherited from Android" fonts) with Google's Noto Naskh Arabic, which looks like it is designed somewhat more compactly in the vertical direction. This should reduce the line height needed to ensure Arabic text displays without clipping.

Ideally, though, we'd get feedback from Arabic script users regarding their preferred font design. To my eye, the Noto font looks acceptable, but I'm not the target user here!

Comment 9

[Jonathan Kew [:jfkthame]]

I've filed bug 1150449 to propose changing the Arabic font as per comment 8. This may not entirely resolve the problems, but would probably help at least to some extent.

Comment 10

[Oleg Zasypkin [:azasypkin]]

Okay, in bug 1133137 we found out that the real issue was absence of "DroidNaskhUI-Regular.ttf" font in PVT full image (bug 1133137 comment 15) and moztt fonts (bug 1133137 comment 23).

With "DroidNaskhUI-Regular.ttf" Arabic char height is almost the same as English one. Regarding DroidNaskh ---> NotoNaskh migration, if we decide to do it, we'll probably need "NotoNaskhArabicUI-Regular.ttf" as well as "NotoNaskhArabic-Regular.ttf", though I don't know how these fonts are interrelated.