Open Bug 676068 Opened 9 years ago Updated 11 months ago

Arabic fonts broken on LG phones

Categories

(Core :: Graphics, defect, major)

ARM
Android
defect
Not set
major

Tracking

()

Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: kbrosnan, Unassigned)

References

()

Details

(Keywords: mobile)

Attachments

(2 files)

Reporting this on behalf of the user on the support forums. Arabic text is not correctly joined. Need Martijn to follow up with screenshot, font startup list and if possible the specific fonts from the system folders.
Component: General → Graphics
Product: Fennec → Core
QA Contact: general → thebes
This is a screenshot of trunk Fennec on the LG Optimus Black (Android 2.2) on the http://www.bbc.co.uk/arabic/ site.
List of fonts installed on the LG Optimus Black: clockopia droid sans droid sans arabic droid sans fallback droid sans hebrew droid sans mono droid serif droidsansthai sjjunglego sjlover sjmyheart sjplayful tdballerina tddisplay

I got this from the script at: http://www.kantjils.nl/moz/list_of_fonts.htm

Let know if you need more info.
I don't know how to get the font startup list or the specific fonts from the system folders.
I'm also getting this on  http://www.islamway.com http://alwatan.kuwait.tt/ and http://kooora.com/
I'm pretty sure I see it on all sites with arabic text.
blassey on irc:
<blassey>	mw22: I'm assuming daggett is going to want the actual font file from your phone
adb pull /system/font/<font name>.ttf
Ok, it turns out it is in system/fonts/.
I tried adb pull DroidSansArabic.ttf , but I get permission denied, presumably because the phone I use is not rooted.
Ok, here is DroidSansArabic.ttf on my LG Optimus Black phone. Let me know, if you need more fonts.

It turns out I had to adb pull /system/fonts/DroidSansArabic.ttf from a regular command shell, not from the msys command shell (which screwed things up for me).
The problem here is that LG Optimus ships with what looks like a
non-standard version of DroidSansArabic.ttf.  They've stripped the
GSUB/GPOS OpenType layout tables which prevents HarfBuzz from shaping
Arabic correctly on these devices.  In place of these they've included
glyphs for Arabic Presentation Forms, U+FB50-FDFF, U+FE70-FEFF:

http://www.unicode.org/charts/PDF/UFB50.pdf

These are separate codepoints from the normal Arabic range
(U+600-6FF), with a separate code point for each form of letters in
the Arabic alphabet (i.e. isolated, initial, medial, final).  Webkit
has code for doing presentational ligature formation (i.e.
transforming sequences of Arabic codepoints to the appropriate
presentational forms) but we removed this code long ago (ask Stuart,
he removed it).

I think the solution is to look for OpenType layout tables and ignore
the font for Arabic if it doesn't support them, with the assumption
that DroidSansFallback.ttf will have proper GSUB/GPOS tables and support for Arabic.  But to do this we'll need to confirm that the fallback font hasn't been hacked up similarly.

Details:

Samsung Epic Froyo
HTC Desire HD (2.3)

DroidSansArabic.ttf (size: 35908 bytes)
has GSUB/GPOS tables
no Arabic presentation forms

LG Optimus

DroidSansArabic.ttf (size: 233456 bytes)
no GSUB/GPOS tables
has Arabic presentation forms
John asked me for all the fonts on my LG Optimus Black.
I posted them here: http://people.mozilla.org/~mwargers/fonts/LGOptimusBlackFonts/
The zip file is for quick downloading of all the files at once.
Drat and double drat.  They've also neutered DroidFallback, it also lacks GSUB/GPOS tables.  Argh and double argh.  Maybe we should ship with a sensible fallback font for these situations (the real DroidArabic is 36K).  The Hebrew and Thai fonts still retain their GSUB/GPOS tables.
Huh, so I'm in contact with bbc because that the bold text on page doesn't join properly, but it sounds like this is a different problem.
(In reply to [:Cww] from comment #10)
> Huh, so I'm in contact with bbc because that the bold text on page doesn't
> join properly, but it sounds like this is a different problem.

Yes. That's bug 674335, which relates to a specific webfont the BBC Arabic site is using. The bug here is an issue with the locally-installed fonts on the LG device.
Hi,

Thanks for looking into this. I am the original user that reported this problem.  What is going to be the resolution to this?  Is the decision going to be to ship a fallback font?

Thanks
Anyone there? :)
Hi,

I have a Samsung S with Android 2.2

- Build-in browser have same problem of broken Arabic script (No shaping & No bidi)
- Firefox 9 works well 

Mozilla/5.0 (Android; Linux armv7l; rv:9.0)
Gecko/20111216 Firefox/9.0 Fennec/9.0

Could I help in this with testing or any file you need from my phone?
I guess the suggestion in comment 9 from John Daggett is a solution. You might ping him on irc, once he's back from vacation. Or Jonathan Kew might have an answer.
(In reply to John Daggett (:jtd) (Away 23 Dec - 4 Jan) from comment #9)
> Drat and double drat.  They've also neutered DroidFallback, it also lacks
> GSUB/GPOS tables.  Argh and double argh.  Maybe we should ship with a
> sensible fallback font for these situations (the real DroidArabic is 36K). 
> The Hebrew and Thai fonts still retain their GSUB/GPOS tables.

John, can we detect that and offer to download a non-broken font? This kinda sorta fits in with bug 619521.
Perhaps we should check for the presence of the OpenType tables needed to support Arabic (and Indic scripts, etc), and mask out the corresponding ranges from the cmap if the layout tables are missing. This would be analogous to the check we do for AAT tables on Mac OS X.

This would mean that in a case where the font has been emasculated by removal of the GSUB/GPOS tables, we'd detect this as a lack of adequate font support for the characters in question, and a download-on-demand mechanism (or whatever) could kick in. As things stand, the initial problem here is that the device *does* have a font that appears to "support" the Arabic characters, so we don't even try to look further.
Bug 745780 should enable rendering Arabic on devices like this, by using the presentation-form codepoints supported in their Droid Sans Arabic font.
Depends on: 745780
Keywords: mobile
Jonathan, are we planning to use the Arabic fallback shaping implemented on HarfBuzz trunk?
blocking-fennec1.0: --- → ?
(In reply to Ehsan Akhgari [:ehsan] from comment #20)
> Jonathan, are we planning to use the Arabic fallback shaping implemented on
> HarfBuzz trunk?

Er, see the previous comment?  Bug 745780 is the harfbuzz update which includes these changes.
(In reply to John Daggett (:jtd) from comment #21)
> (In reply to Ehsan Akhgari [:ehsan] from comment #20)
> > Jonathan, are we planning to use the Arabic fallback shaping implemented on
> > HarfBuzz trunk?
> 
> Er, see the previous comment?  Bug 745780 is the harfbuzz update which
> includes these changes.

Right, which is why I asked this question.  I'm not sure if there's going to be some work on our side to use the fallback shaping.  If there is not, we should call this fixed perhaps?
I believe this is fixed for the case where Droid Sans Arabic has been stripped of OpenType tables, but would like to have that confirmed by someone with such a device.

Martijn, could you try a current nightly build on your LG Optimus and let us know whether Arabic now shapes OK, particularly on sites that are *not* providing their own webfonts?

Ehsan, note that for devices where the Droid Sans Arabic font *does* have a GSUB table, but that table is incorrect, we'll need to do something more to make the fallback path take over. I believe you have such a device, as discussed in bug 706888 comment 14. I'll follow up there with a possible way forward.
(In reply to Jonathan Kew (:jfkthame) from comment #23)

> Ehsan, note that for devices where the Droid Sans Arabic font *does* have a
> GSUB table, but that table is incorrect, we'll need to do something more to
> make the fallback path take over. I believe you have such a device, as
> discussed in bug 706888 comment 14. I'll follow up there with a possible way
> forward.

Not sure what you have in mind but I think this should be a mobile-only fix, I think we should avoid font-specific fixups like this wherever possible.
(In reply to Jonathan Kew (:jfkthame) from comment #23)
> Martijn, could you try a current nightly build on your LG Optimus and let us
> know whether Arabic now shapes OK, particularly on sites that are *not*
> providing their own webfonts?

That phone went to the Mountain View office, Tony knows who has it now.
blocking-fennec1.0: ? → -
You need to log in before you can comment on or make changes to this bug.