Open Bug 1679746 Opened 3 years ago Updated 2 years ago

Incorrect rendering or joining of kurdish (ckb) texts from specific websites which their content is kurdish(ckb) texts.

Categories

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

Firefox 83
defect

Tracking

()

Webcompat Priority P3
Tracking Status
firefox83 --- affected
firefox84 --- affected
firefox85 --- affected
firefox86 --- affected

People

(Reporter: jwtiyar, Unassigned)

References

Details

Attachments

(4 files)

Attached image atachment-1-Firefox.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:83.0) Gecko/20100101 Firefox/83.0
Firefox for Android

Steps to reproduce:

Opening websites which their content is in kurdish (ckb) language is not rendered correctly as atachment 1.

Actual results:

The texts will not join each other will show up as one letter text.

Expected results:

Should show up like in Atachments 2 and 3 in both safari and microsoft edge.

Attached image atachment-2-Edge.png
Attached image Atachment-3-Safari.png

Hi jwtiyar,

Thanks for your report.

I was able to reproduce the text rendering of Comment #1 on Mac OSX 10.15 using Firefox Nightly 86.0a1 (2020-12-16), Release 83, Release 84 and Beta 85.0b2.

I'll add this ticket to the Core - Layout: Text and Fonts product in the hope someone from their team can take a look at this and investigate.

Regards,
Virginia

Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Text and Fonts
Ever confirmed: true
Product: Firefox → Core

The issue here arises because the commonvoice site specifies the font as, for example, h1 { var(--strong-font-family); }, where the custom property is defined as --strong-font-family: "Zilla Slab",Georgia,Utopia,Charter,serif;

The serif generic family, in Arabic script, maps to the Al Bayan font in the default Firefox prefs.

However, while Al Bayan works fine for the Arabic language, it doesn't support some of the extended Arabic script characters used in Kurdish, such as ڕ‎, ۆ and ێ. So while most of the text appears in Al Bayan, these letters fall back to Geeza Pro (which has more a complete character repertoire), and the required cursive joining does not operate across font-run boundaries. (Even if the correct shaped forms were used, the glyphs still wouldn't join properly or look correct in context.)

A possible fix for the commonvoice site would be to add Geeza Pro to the --strong-font-family list, ahead of the final serif generic, so that for Arabic script on macOS, it will be used in preference to Al Bayan.

We could also consider changing the default font.name-list.serif.ar pref on macOS to a font that has more complete coverage of the extended Arabic script, though simply changing it to Geeza Pro would mean we lose the "serif" / "sans-serif" stylistic distinction.

Yes correct the problem is with some special characters which are not available in arabic.
I did some workround and now kurdish characters shows up coreectly but i lost icons of some buttons in some websites like Pontoon in nightly version but stable version shows them correctly.

Severity: -- → S3
Priority: -- → P3

This appears to also be affecting https://www.iq.undp.org/content/iraq/ku/home.html as well (as reported at https://webcompat.com/issues/89849).

The site specifies Noto Sans Arabic (as a webfont), which both Firefox and Chrome end up using (mixed with DevaVu Sans). But they are rendering differently:

@font-face { font-family: "Noto Sans Arabic"; src: url("https://fonts.gstatic.com/s/notosansarabic/v10/nwpCtLGrOAZMl5nJ_wfgRg3DrWFZWsnVBJ_sS6tlqHHFlj4wv4o.woff2") format("woff2"), url("https://fonts.gstatic.com/s/notosansarabic/v10/nwpxtLGrOAZMl5nJ_wfgRg3DrWFZWsnVBJ_sS6tlqHHFlhQ5l3sQWIHPqzCfyGyvuA.woff") format("woff"); font-style: normal; font-weight: 100 900; font-stretch: 100%; font-display: swap; unicode-range: U+600-6FF, U+200C-200E, U+2010-2011, U+204F, U+2E41, U+FB50-FDFF, U+FE80-FEFC, U+0-FF, U+131, U+152-153, U+2BB-2BC, U+2C6, U+2DA, U+2DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; }

@jfkthame, is this the same issue? If so, do we know what the interop issue is, and if there is a better webfont/workaround the site could be using?

Flags: needinfo?(jfkthame)

Basically the same issue, yes -- the font they're specifying doesn't support all the characters being used in the text, so fallback happens (on a per-character basis) and shaping/joining fails.

FWIW the rendering I see on macOS in both Chrome and Safari is also fairly broken, although the exact details of the breakage varies. On Windows, Chrome/Edge do somewhat better because they pick Segoe UI for the fallback glyphs, which stylistically is a fairly good match to Noto Sans Arabic, although it's still possible to see issues if you know what to look for.

The issue is less obvious in Chrome (or Edge) because they apply basic Arabic joining rules across font-run boundaries, which we don't currently do. However, even in Windows/Chrome, if you increase the font-size e.g. of the word "عێراق" at the top-right of the page, you can see that (a) there's a "crack" between the initial letter and the next, which happens because they're coming from different fonts and don't quite join nicely; and (b) the two dots under the second letter are square, whereas those above the final ق are round, which is a stylistic mismatch between Noto and Segoe UI. So in short, although it's less glaringly bad, the typography is still broken.

Not sure what's a "better" webfont choice offhand -- it doesn't look like Google Fonts supports the full Kurdish character set in their "Arabic" faces, at least from the ones I checked.

Flags: needinfo?(jfkthame)

Alright, thanks. Then I'll close that webcompat issue as a dupe of this one, as we don't have any obvious workaround.

I think Open Sans fonts would render all characters.

Webcompat Priority: --- → ?

Setting as a webcompat P3 as this seems to be inactionable except on a site-by-site basis, since using different fonts could break differently on different browsers, from what I gather. As such I think this is a case where standards work would benefit us more before we try to engineer anything in Gecko. In the meantime, we could try to recommend Open Sans or another font to sites we know are broken, or perhaps do so ourselves in a site-specific intervention.

Webcompat Priority: ? → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: