Bug 92586 – Arabic web fonts (@font-face) not rendering

• Component: CSS
• Status: NEW

[Samy]

Hello,

Custom fonts via the @font-face property don't show on Arabic text. I have tested the same declaration on macs and pcs and it rendered fine. But on mobile devices running Android or iOS the font is loaded but not applied.

 A sample text can be found at http://jehazy.com/web font 

Thank you.

[Samy]

sorry the URL is
http://jehazy.com/webfont/

Also a radar was filed at apple with the id #12033060

[daegyu]

Hi Samy,

I have tried this at LG Android phone browser and iOS, but it looks fine.
Could you tell more information?

Thanks in advance.

[Mostafa Hajizadeh]

Created attachment 168916 [details]
Mobile Safari in iOS 5 renders text with Gezza, system’s default font for Arabic, ignoring attached web font

[Mostafa Hajizadeh]

Created attachment 168918 [details]
Browser in Android 4.1 renders text with Droid Arabic, ignoring web font

[Mostafa Hajizadeh]

Created attachment 168919 [details]
Chrome for Android in version 1 also ignores web font

[Mostafa Hajizadeh]

Created attachment 168920 [details]
Chrome beta for Android using text with attached web font

[Mostafa Hajizadeh]

Hi,

I added a few screenshot about this bug: these show that Mobile Safari, Android’s Browser, and Chrome for Android ignore attached web font for Arabic texts and use the only Arabic font available on the device. You can compare the fonts with the attachment for Chrome beta for Android, which shows the actual font attached. This screenshots are taken from my weblog, http://sarkeshtype.ir/, which uses attached web font. Any Arabic page with @font-face can show the bug. You can compare the font on mobile with the one you see on the desktop.

Mobile Safari didn’t have this bug before iOS 5. Android’s Browser didn’t have this in Android 2.2, but had it in Android 3.0; I’m not sure about Android 2.3. Chrome for Android used to work fine in beta version; this bug appeared in version 1.

Please let me know if anybody need more information about this.

[Behdad Esfahbod]

bashi, do you have any ideas?

[Kenichi Ishibashi]

Looks like the font is invalid. I converted the woff to ttf and used showttf to check the font. The checksum is wrong.

version='OTTO', numtables=13, searchRange=128 entrySel=3 rangeshift=80
File Checksum =b1c01782 (should be 0xb1b0afba), diff=fff09838
CFF  checksum=81335a58 actual=81335a58 diff=0 offset=220 len=145384
FFTM checksum=47423ff1 actual=47423ff1 diff=0 offset=145604 len=28
GDEF checksum=10ce0eee actual=10ce0eee diff=0 offset=145632 len=128
GPOS checksum=58d4538c actual=58d4538c diff=0 offset=145760 len=744
GSUB checksum=2bf81da8 actual=2bf81da8 diff=0 offset=146504 len=1462
OS/2 checksum=8d945c48 actual=8d945c48 diff=0 offset=147968 len=86
cmap checksum=0879d546 actual=0879d546 diff=0 offset=148056 len=634
head checksum=03a66163 actual=87611ebd diff=84c77fde offset=148692 len=54
hhea checksum=120c0779 actual=120c0779 diff=0 offset=148748 len=36
hmtx checksum=5c674ba5 actual=5c674ba5 diff=0 offset=148784 len=1444
maxp checksum=01695000 actual=01695000 diff=0 offset=150228 len=6
name checksum=3eba1c4b actual=3eba1c4b diff=0 offset=150236 len=3465
post checksum=fd150064 actual=fd150064 diff=0 offset=153704 len=32

Chrome uses OTS, opentype sanitizer, to prevent loading such invalid webfonts. We won't allow to load the font.

[Mostafa Hajizadeh]

Sorry to waste your time on the checksums! Fixed the checksum issue and uploaded changes. The new mitra.woff file should be good now. 

The problem still exists.

[Eric Seidel (no email)]

Am I understanding correctly, that this works fine in Chrome Beta, just not the built-in Android browser?

[Mostafa Hajizadeh]

Eric, Chrome beta didn’t have this bug, but Chrome version 1 had.

None of the three browsers (Mobile Safari, Android’s built-in Browser, and Chrome for Android) had the bug about a year ago or so. They all introduced it in their later versions.

[Eric Seidel (no email)]

I can confirm that it looks right on Chrome on my Mac, but wrong on Chrome on my Nexus S.

I believe we use OTS even on Desktop chrome, so that shouldn't be the issue here.

[Mostafa Hajizadeh]

Sure. As I said, I fixed the checksum issue.

[John Mellor]

Although there are some seemingly related bugs like http://crbug.com/138257 and http://crbug.com/137206 this particular bug probably isn't due to Text Autosizing (bug 84186) since it affects Android Browser which doesn't use that technique (unlike Mobile Safari and Chrome for Android, which do use Text Autosizing).

[Mostafa Hajizadeh]

Someone has this idea (http://stackoverflow.com/a/4361653/165293) that the web font gets lost during the shaping, and hence suggests using Representation Form characters to skip over the shaping phase.

Seems like a strange idea to me, but somebody has done this and it seems to be working. Here’s the blog post:

http://ixdc.net/blog/2011/01/12/arabic-web-fonts-on-ios-resolved/

And here’s the sample page which works in iOS:

http://ixdc.net/blog/wp-content/uploads/2011/01/ios/

Could this be true? I haven’t played with the idea much yet, but thought it might help in tracking down the bug and shared it here.

[Behdad Esfahbod]

Really weird.  When I view http://ixdc.net/blog/wp-content/uploads/2011/01/ios/ from Chrome on Nexus 7 (Android 4.2.2), I see some of the lines using the webfont and some using the system font.  The pattern is consistent when I refresh or resize the page.

[Mostafa Hajizadeh]

The latest update on Chrome for Android fixes the bug. It was released a few days ago and has version number 26.0.1410.58.

I’m not sure about this. Maybe the bug is fixed in WebKit and we should expect later updates of Safari to work fine too?