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.
sorry the URL is http://jehazy.com/webfont/ Also a radar was filed at apple with the id #12033060
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.
Created attachment 168916 [details] Mobile Safari in iOS 5 renders text with Gezza, system’s default font for Arabic, ignoring attached web font
Created attachment 168918 [details] Browser in Android 4.1 renders text with Droid Arabic, ignoring web font
Created attachment 168919 [details] Chrome for Android in version 1 also ignores web font
Created attachment 168920 [details] Chrome beta for Android using text with attached web font
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.
bashi, do you have any ideas?
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.
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.
Am I understanding correctly, that this works fine in Chrome Beta, just not the built-in Android browser?
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.
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.
Sure. As I said, I fixed the checksum issue.
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).
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.
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.
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?