1680610 - Underline position for Arabic and Hebrew sometimes overlays i'jam and niqqud

Status: UNCONFIRMED

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

Description

[Manish Goregaokar [:manishearth]]

Attachment: testcase.html

Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1155268

Depending on the platform, underlines sometimes overlay Hebrew diacritics and Arabic consonant pointing. This looks particularly bad when combined with text-decoration-skip-ink (which is on by default), since underdot diacritics, underline diacritics like the hebrew patah, and Arabic consonant pointing (i'jam) get mixed up with the actual underline.

I'm getting better behavior on Windows, but it's still not ideal.

Here's an example of a case where this changes the meaning of the word, "Wikipedia" reads as "Wikyyydia" or some such, on Firefox on OSX.

Comment 1

[Manish Goregaokar [:manishearth]]

Attachment: firefox-ubuntu.png

Comment 2

[Manish Goregaokar [:manishearth]]

Attachment: firefox-windows.png

Comment 3

[Manish Goregaokar [:manishearth]]

There's some existing discussion on this from the spec side in https://github.com/w3c/alreq/issues/86 and https://github.com/w3c/alreq/issues/86. Note especially Behnam's comment in https://github.com/w3c/csswg-drafts/issues/1288#issuecomment-297526373 that says that Arabic underlines should be squarely below the dots.

Comment 4

[Jonathan Kew [:jfkthame]]

By default, we use the underline position (and thickness) specified in the font (the "first available" font, I think, if fallback is involved for some of the text).

For these scripts, specifying text-underline-position: under would probably be more appropriate; or text-underline-offset: <length> can be used to set a specific level. But it's hard to see how to design a default behavior that would be "good" in all cases, particularly for mixed-script content.

Comment 5

[Khaled Hosny]

In my case, I think there are two issues with the under-line position:

• The value is taken from the first font (Open Sans in my case) even though the text is rendered by a fallback font. Setting the Arabic font explicitly improves things.
• Firefox clips the underline position to the descender (no idea why), which prevents fonts with tight descender from having underline that does not touch the glyphs even if they wanted to.

Comment 6

[Manish Goregaokar [:manishearth]]

The value is taken from the first font (Open Sans in my case) even though the text is rendered by a fallback font. Setting the Arabic font explicitly improves things.

ooh, that is definitely a bug. Mind checking that in Chrome as well and commenting on the chrome issue too?

Comment 7

[Khaled Hosny]

FWIW, I think this is the code clipping underline position https://searchfox.org/mozilla-central/source/gfx/thebes/gfxFont.cpp#3711-3720

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to Manish Goregaokar [:manishearth] from comment #6)

The value is taken from the first font (Open Sans in my case) even though the text is rendered by a fallback font. Setting the Arabic font explicitly improves things.

ooh, that is definitely a bug.

Is it, though? Suppose the text were part Latin script, which would render with Open Sans, and also included some Arabic letters (all within a single underlined element): would you expect different underline positions under the different fonts, or what?

Comment 9

[Manish Goregaokar [:manishearth]]

Hm, that's a good point. I'm not sure how to square this circle

Comment 10

[Khaled Hosny]

I’d expect the lowest underline position to be used for the whole string, it might look less ideal for the script/font that wants higher underlines, but it would avoid cutting through the text of the ones that require lower underline.