992100 - Improper rendering of Indic scripts on some Samsung devices, due to bad DroidSansFallback font

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Chandrakant Dhutadmal]

Attachment: Firefox for Android Dev Issue.png

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

1. Visit mr.m.wikipedia.org on a mobile having adroid OS 4.3.
2. See that many words in text on the page are not rendering properly.


Actual results:

There are many words which are broken up. There is no consistency in the issues in rendering of issues. Eg. Using of a Halant (्) is working properly in one word साम्राज्याच्या and is giving problem in other words such as आपल्या. Issues are found in words using ्, ू, ि, ो, ु, etc.


Expected results:

All the words with these characters should render correctly.

Comment 1

[Chandrakant Dhutadmal]

Attachment: Incorrrect and Correc Word Examples

Comment 2

[Teodora Vermesan (:TeoVermesan)]

What version of Firefox and device are you using? I cannot reproduce this on a Samsung Galaxy Nexus (Android 4.3) on Firefox for Android 31.0a1 (2014-04-03).
Can you reproduce on your device using Firefox Nightly for Android http://nightly.mozilla.org/?

Comment 3

[Chandrakant Dhutadmal]

Hi Teodora. I am using Firefox version 28.0.1 on Samsung Galaxy S4. Model Number- GT-I9500., Android version 4.3, Kernel 3.4.5-1984169.

I also installed Firefox Nightly on my mobile and the results are same. Marathi language words do not get rendered properly.

Comment 4

[Jonathan Kew [:jfkthame]]

This looks as though it is probably related to the particular Devanagari font being used, which is not consistent across devices but depends what the vendor has chosen to install; it may also depend on the channel or market through which the device was purchased. Some manufacturers customize the fonts for different markets.

Could you copy the font files from /system/fonts on the problem device, and attach here as a zip file or similar archive? This will allow us to examine the fonts actually being used.

Comment 5

[Chandrakant Dhutadmal]

I dont think the issue lies with the font. The same page when opened with the default browser and google chrome version 34.0.1847.114 renders the text properly.

How do i copy the font from my Samsung s4 device ? I cant find a way to that easily.

Comment 6

[Jonathan Kew [:jfkthame]]

If you have a computer with the android sdk tools installed, you should be able to use adb for this. With your device connected, you can do something like

  mkdir fonts-from-android
  cd fonts-from-android
  adb pull /system/fonts/

to "pull" everything from the device's /system/fonts/ into a directory on your computer; then zip that into an archive and attach to this bug.

(If you first need to install the android sdk, details will depend on your computer platform, but there are plenty of instructions available online.)

Comment 7

[Chandrakant Dhutadmal]

Attachment: SamsungDevanagariFile.zip

I am not sure if i can copy the Android 4.3 Devnagari font and send as attachment with this Bug.? Are there any copyright/ Patent voilations while doing this ?

Comment 8

[Jonathan Kew [:jfkthame]]

Generally, I'd expect the standard Android fonts should be freely redistributable, though it's possible that a specific vendor might add proprietary fonts of their own; different license terms might apply to those.

Comment 9

[Jonathan Kew [:jfkthame]]

On looking more closely at your screenshot, what I notice is that something strange is happening with font sizes. Certain characters seem to be rendered slightly smaller than the surrounding text -- and when this happens in a context where reordering or glyph combinations are required, the rendering breaks because we can't shape text across a font-size change; the two fragments are processed separately.

So the question here becomes why certain parts of the text are appearing with a different font-size.

Comment 10

[Chandrakant Dhutadmal]

The point which i mentioned in my earlier comment remains. If other web browsers on the same device can render the same text properly , with the same font, i think we need to check algorithms for rendering on firefox browser.

By the way, i wanted to understand whether rendering text on web browser is a function of some component in Android OS or web browser?.

Comment 11

[Chandrakant Dhutadmal]

The same bug applies for Hindi language also, as Hindi is written in Devnagari script.

Comment 12

[Chandrakant Dhutadmal]

Releasing Localized versios of Firefox for Android (Even for that matter English version) is going to be a problematic situation as Users will not accept this issue. 

I also dont know if there is anyone who is ready to taking up for fixing. :)

Comment 13

[Gen Kanai [:gen]]

Apologies, added Jane by mistake.

Comment 14

[MS Zaman]

Attachment: bangla_ligatures_firefox.png

Comment 15

[MS Zaman]

Attachment: bangla_ligatures_chrome.png

Comment 16

[MS Zaman]

Attachment: bangla_ligatures.html

Comment 17

[MS Zaman]

A very similar bug exists for the same Firefox version (v28.0.1) on my Samsung Galaxy Note 2 (model SGH-T889V) running Android 4.3, Kernel 3.0.31-2158736. In my case, the affected language is Bengali/Bangla. Although most ligatures render fine, any which involves a leading ?, ? or ? gets broken; see the attachment bangla_ligatures_firefox.png for an example (bordered in red). Chrome (v34.0.1847.114), Dolphin Broswer (v11.0.0) and Opera (v20.0.1396.73172) render the same text correctly; see the attachment bangla_ligatures_chrome.png for correct behaviour (bordered in green). The attached bangla_conjuctions.html can be opened with a browser to verify the behaviour; alternately, visit http://bn.m.wikipedia.org/wiki/ and look for ligatures with dotted circles.

Apologies if the addition of the attachments created spam for the followers.

Comment 18

[MS Zaman]

Correction:
... render fine, any which involves a leading দ, ব or শ gets broken; see ...

Comment 19

[Jonathan Kew [:jfkthame]]

AFAICS, the problem here is specific to certain devices, though I don't know why. I'm still unable to reproduce the issue, either for Devanagari or Bengali, on the devices I have available (Nexus 10 tablet, HTC Desire HD phone). I tried using a copy of the SamsungDevanagari font from comment 7, but it renders correctly in my testing on these devices.

I wonder if this is somehow related to font-size inflation, given that the issue happens when certain characters are rendered with a different size from the rest of the text. (This is the same in both the Devanagari and Bengali examples shown, which seems to confirm that they're really the same underlying problem.)

If you go to Settings / Display / Text Size and set it to the smallest option ("Tiny"), does this make any difference?

Comment 20

[Chandrakant Dhutadmal]

Perfect. Jonathan could figure out the solution. Making the font size as "Small" solves the problem. Thanks all.

Comment 21

[Jonathan Kew [:jfkthame]]

Well...that doesn't solve the problem, but it provides a workaround to avoid it.

So I think this is some kind of bug with the "font-inflation" feature; it's getting applied inconsistently to certain characters, and the inconsistent size then breaks the text shaping. But I still don't know (a) why it's happening at all, or (b) why it seems to happen only on certain devices.

Moving this to Layout:Text, as that's where font inflation is implemented, and cc'ing dbaron, who I believe knows much more about that.

Comment 22

[MS Zaman]

For my device (SGH-T889V), the font size change makes no difference; the ligatures are still broken at both "Tiny" and "Small", which is strange because Jonathan's rationale seems to make sense (at least on the surface, but I am utterly unfamiliar with Firefox's architecture, so what do I know :P).

Given that none of the other browsers (e.g., Chrome, Opera, Dolphin) show this problem on the same system, I would (as a generic guess) venture that the problem arises from some rendering activity for which Firefox relies on the underlying system, but (for example) Chrome does not. Since both my and Chandrakant's devices are from the Samsung Galaxy line, the custom TouchWiz UI on Samsung devices may be related to the problem.

Note: The stock Samsung browser (which looks like it's based on Chrome) does not have this problem either.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It could also be a function of the size of the device, since the size is an input to the font inflation code.

That said, we should never have different font inflation for text whose parent is the same element -- is that what you think is happening here?

Comment 24

[Jonathan Kew [:jfkthame]]

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #23)
> It could also be a function of the size of the device, since the size is an
> input to the font inflation code.
> 
> That said, we should never have different font inflation for text whose
> parent is the same element -- is that what you think is happening here?

That's one interpretation of what the screenshots appear to show: e.g. in the first (complete) line of text in attachment 8401698 [details], there are two instances of word-initial प (devanagari "pa") that are slightly smaller than the rest of the characters, and therefore their associated vowel marks do not combine properly because there is no shaping across the font-size boundary.

At the second occurrence on that line, the same letter appears again later in the word, and in that case it has the proper size.

At this point, I really have no idea why any kind of text-run/style boundary is occurring here. I don't know for sure whether this is in fact connected to font-inflation or not, but comment 20 seemed to indicate it is a possibility; on the other hand, comment 22 suggests otherwise, as the "Tiny" setting ought to suppress any inflation, AIUI.

Comment 25

[MS Zaman]

Attachment: bangla_ligatures_v2.html

Confirming Jonathan's observation that the problem characters are only problematic if they are the leading characters in the "word"; see bangla_ligatures_v2.html and bangla_ligatures_v2_firefox.png.

Comment 26

[MS Zaman]

Attachment: bangla_ligatures_v2_firefox.png

This is how my Firefox for Android displays bangla_ligatures_v2.html.

Comment 27

[Jonathan Kew [:jfkthame]]

The behavior here is really puzzling. In attachment 8411133 [details], we can clearly see the size discrepancies in many of the examples, including ones where there's no actual dotted-circle or otherwise obviously "broken" rendering.

E.g. compare the first entries on the second and third rows, দক and কদ (character sequences <U+09A6, U+0995> vs <U+0995, U+09A6>). On row 2, the first letter দ is visibly smaller; but with the reversed character pair on row 3, the problem doesn't occur.

The problem seems to be limited to certain letters that consistently exhibit the bug, while others that AFAICT should behave identically don't have any issues. It's normally a single, run-initial letter, but in column 2 we can see that when there's a following া (U+09BE, vowel sign aa), this is also reduced in size, so the problem affects a two-character sequence.

MS Zaman, could you provide a list of all the font files on your device, as shown by

  adb shell ls -l /system/fonts

(assuming you have a computer with the android sdk tools installed).

Comment 28

[MS Zaman]

Attachment: List of System Fonts

Here's the requested listing. I ran the command on a terminal emulator on the device, since I don't have ADB installed (and didn't want to bother), but I assume the outputs should be the same.

Comment 29

[Jonathan Kew [:jfkthame]]

Thanks. OK, I'm suspicious of the DroidSansFallback.ttf font listed there - it doesn't correspond to standard versions I've seen, and I wonder if Samsung has customized it in some bizarre way that's leading to problems here. Could you pull a copy of it from the device (sorry, that may require ADB - or perhaps you have other tools that can do it?) and attach it here (zipped, to reduce size).

Chandrakant Dhutadmal, same question for you: could you please provide a copy of the DroidSansFallback.ttf font from your device? Or if you can confirm it's exactly the same size as MS Zaman's version (as shown in the "ls -l" listing), I think we could assume it's the same version.

Comment 30

[Brad Lassey [:blassey] (use needinfo?)]

We plan on shipping Indic locales in 31, so this would seem to be important to track for that release

Comment 31

[Jonathan Kew [:jfkthame]]

Do we have an engineer with access to an affected device who could do more in-depth investigation (running builds under a debugger and/or with added logging, etc) to try and get to the bottom of this? I'm guessing in the dark at this point...

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Maybe Kip can help; not sure if he has the device in question already.

It might be helpful to have steps to reproduce that are usable by somebody who doesn't speak the language.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(That said, most font inflation bugs are reproducable on desktop if you set the necessary prefs; that's generally easier than debugging on a device.)

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, wait, the dotted circles in the screenshots are pretty obvious, so never mind about the language issue.

Comment 35

[Jeff Beatty [:gueroJeff]]

(In reply to Jonathan Kew (:jfkthame) from comment #31)
> Do we have an engineer with access to an affected device who could do more
> in-depth investigation (running builds under a debugger and/or with added
> logging, etc) to try and get to the bottom of this? I'm guessing in the dark
> at this point...

I can verify the bug on my Samsung Galaxy S4 running Android 4.3 running Fennec 29. I don't have dev experience with Android, but am willing to help.

Comment 36

[Jonathan Kew [:jfkthame]]

(In reply to Jeff Beatty [:gueroJeff] from comment #35)

> I can verify the bug on my Samsung Galaxy S4 running Android 4.3 running
> Fennec 29. I don't have dev experience with Android, but am willing to help.

Thanks. As a first step, could you pull the contents of the /system/fonts folder and upload somewhere for me to have a look and see if there's anything fishy there? I expect an archive of the entire folder will be too big for a bugzilla attachment; maybe put it on people.m.o or something?

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Jonathan Kew (:jfkthame) from comment #21)
> Well...that doesn't solve the problem, but it provides a workaround to avoid
> it.
> 
> So I think this is some kind of bug with the "font-inflation" feature; it's
> getting applied inconsistently to certain characters, and the inconsistent
> size then breaks the text shaping. But I still don't know (a) why it's
> happening at all, or (b) why it seems to happen only on certain devices.
> 
> Moving this to Layout:Text, as that's where font inflation is implemented,
> and cc'ing dbaron, who I believe knows much more about that.

A few other questions, actually:

Did you observe the characters being split into different text runs?  Because I believe we'll use a single font inflation for an entire text run.  And are the characters in separate frames?  (I have no idea how they'd get in different text runs if they're in the same frame, unless we're somehow hitting the bidi splitting -- but even then I'd expect them to have the same font inflation.)

One thing that font inflation might trigger is different sorts of fractional font sizes than we see without it -- could that be an issue?

Comment 38

[Jeff Beatty [:gueroJeff]]

Fonts: http://people.mozilla.org/~jbeatty/fonts-from-android.zip
Screenshot: https://www.dropbox.com/s/mvn4pzd3kraw9f7/Screenshot_2014-04-24-14-06-50.png

1) Yes, I believe so
2) I believe they're in the same frame. The screenshot may be more informative on that.
3) I think if the font inflation is applied to an entire text run, I suppose that would become an issue.

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Those questions were for Jonathan; text runs and frames are objects in our code.

Comment 40

[Jonathan Kew [:jfkthame]]

OK, thanks to Jeff's font archive, I know what's happening here. It doesn't have anything to do with font inflation after all. (OK, I'm a bit puzzled by comment 20, assuming my font-related diagnosis is correct, but perhaps that's a mistaken report.)

The basic problem here is that Samsung is shipping a version of DroidSansFallback.ttf that includes an apparently-random scattering of a few characters from various Indic scripts, but not full character repertoires. See attached screenshot, showing the partial Devanagari and Bengali ranges it includes, among others. (Actually, judging by the letters that are present, I suspect they may be aiming to include just the glyphs needed for one particular use-case -- perhaps for rendering country names in a system settings app or something like that.)

So when we go to render a word like राज्य (to take a random example from Jeff's screenshot), which is the character sequence < र ा ज ् य >, and a suitable Devanagari font has not explicitly been specified in CSS, we're finding DroidSansFallback (through global font fallback) for the first letter, र. This font also supports the following ा and ज. But then we hit the halant ् U+094D, which is not present in DroidSansFallback, and so now font fallback finds the Samsung Devanagari font instead, and we continue to use this for the remainder of the word.

And that results in a font boundary (and an apparent size change, because the scaling of the glyphs in the two fonts is different, even though it looks like Samsung just copied the same outlines - stylistically, the designs match). And Indic shaping doesn't work across font-run boundaries.

(When a word starts with a letter that isn't supported in DroidSansFallback, we find the "proper" Indic font via fallback, and then continue to use it for the whole word, and all is well.)

IMO, this is really a Samsung bug: they're shipping a system font with a bizarre, fragmentary character repertoire in various complex scripts, which is a sure recipe for brokenness. But that's no comfort to users stuck with such a device.

I think we can work around the issue by adding a hack to "deprecate" the DroidSansFallback font, such that it is used only as a last resort if no other available font supports the character in question, instead of treating it as an equally good candidate for system fallback as any other. Then Indic text with unspecified font will end up using the "real" Indic fonts instead of the risk that it'll pick a few characters from DroidSansFallback, where available, and others from the "real" font.

I'll try to work up a patch for this, so that people can test on the affected devices.

Cancelling the various needinfo? flags here, as I think we have enough information to make progress now.

Comment 41

[:kip (Kearwood Gilbert)]

I have reproduced this issue on OSX 10.9.2 and FF 29 (No font inflation), using this file:

https://bug992100.bugzilla.mozilla.org/attachment.cgi?id=8409578

Safari rendered the text correctly; however, FF 29 displayed the dotted circles.  This seems to indicate a problem with incomplete combining marks.

Comment 42

[Jonathan Kew [:jfkthame]]

Attachment: partial Devanagari and Bengali character repertoire in Samsung's DroidSansFallback

Screenshot of FontForge showing the problematic font, with extremely partial support for the Indic-script Unicode ranges.

Comment 43

[Jonathan Kew [:jfkthame]]

(In reply to :kip (Kearwood Gilbert) from comment #41)
> I have reproduced this issue on OSX 10.9.2 and FF 29 (No font inflation),
> using this file:
> 
> https://bug992100.bugzilla.mozilla.org/attachment.cgi?id=8409578
> 
> Safari rendered the text correctly; however, FF 29 displayed the dotted
> circles.  This seems to indicate a problem with incomplete combining marks.

That's an unrelated issue, actually - it's a problem with the Core Text shaping of the Bengali font on OS X.

Comment 44

[Jeff Beatty [:gueroJeff]]

(In reply to Jonathan Kew (:jfkthame) from comment #40)
> OK, thanks to Jeff's font archive, I know what's happening here. It doesn't
> have anything to do with font inflation after all. (OK, I'm a bit puzzled by
> comment 20, assuming my font-related diagnosis is correct, but perhaps
> that's a mistaken report.)
> 
> The basic problem here is that Samsung is shipping a version of
> DroidSansFallback.ttf that includes an apparently-random scattering of a few
> characters from various Indic scripts, but not full character repertoires.
> See attached screenshot, showing the partial Devanagari and Bengali ranges
> it includes, among others. (Actually, judging by the letters that are
> present, I suspect they may be aiming to include just the glyphs needed for
> one particular use-case -- perhaps for rendering country names in a system
> settings app or something like that.)
> 
> So when we go to render a word like राज्य (to take a random example from
> Jeff's screenshot), which is the character sequence < र ा ज ् य >, and a
> suitable Devanagari font has not explicitly been specified in CSS, we're
> finding DroidSansFallback (through global font fallback) for the first
> letter, र. This font also supports the following ा and ज. But then we hit
> the halant ् U+094D, which is not present in DroidSansFallback, and so now
> font fallback finds the Samsung Devanagari font instead, and we continue to
> use this for the remainder of the word.
> 
> And that results in a font boundary (and an apparent size change, because
> the scaling of the glyphs in the two fonts is different, even though it
> looks like Samsung just copied the same outlines - stylistically, the
> designs match). And Indic shaping doesn't work across font-run boundaries.
> 
> (When a word starts with a letter that isn't supported in DroidSansFallback,
> we find the "proper" Indic font via fallback, and then continue to use it
> for the whole word, and all is well.)
> 
> IMO, this is really a Samsung bug: they're shipping a system font with a
> bizarre, fragmentary character repertoire in various complex scripts, which
> is a sure recipe for brokenness. But that's no comfort to users stuck with
> such a device.
> 
> I think we can work around the issue by adding a hack to "deprecate" the
> DroidSansFallback font, such that it is used only as a last resort if no
> other available font supports the character in question, instead of treating
> it as an equally good candidate for system fallback as any other. Then Indic
> text with unspecified font will end up using the "real" Indic fonts instead
> of the risk that it'll pick a few characters from DroidSansFallback, where
> available, and others from the "real" font.
> 
> I'll try to work up a patch for this, so that people can test on the
> affected devices.
> 
> Cancelling the various needinfo? flags here, as I think we have enough
> information to make progress now.

Thank you for investigating this and working up a workaround patch. I'm happy to help test, when the patch becomes available.

Comment 45

[Chandrakant Dhutadmal]

Even i am ready to help testing the patch. Plz let me know if anythings needs to be tested on Android 4.3

Comment 46

[Jonathan Kew [:jfkthame]]

I've created a build that includes a patch intended to fix this issue, though as I don't have an affected Samsung device, I have not been able to test it personally.

Jeff, Chandrakant: if you could install the build from

  http://people.mozilla.org/~jkew/fennec-bug-992100.apk

and let me know whether it does in fact resolve the problem, that would be really helpful - thanks.

(This package will install the app with the name "Fennec jkew", so it will not overwrite your existing version of Firefox or Nightly, and can simply be uninstalled again after you've tested it.)

Comment 47

[Jonathan Kew [:jfkthame]]

Attachment: mask out complex-script codepoints in fonts that lack the necessary layout tables.

(untested) patch intended to avoid inappropriate use of Samsung's hacked version of Droid Sans Fallback for some characters in Indic scripts that require complex shaping behavior for proper rendering.

Comment 48

[Chandrakant Dhutadmal]

@Jonathan- I tested the issue with the "fennec jkew" on android 4.3 where there was a problem. Good news is that the patch works fine. All the reoprted word breaks have disappeared in this patch.

If more tests are to be conducted, Plz feel free to inform me.

Comment 49

[Jeff Beatty [:gueroJeff]]

@Jonathan -- Looks great to me! Thank you for spending time on this :-)

Comment 50

[MS Zaman]

Third confirmation: both my test pages and http://bn.m.wikipedia.org/wiki/ look great on the patched Fennec. Three cheers for Jonathan!

(Now here's hoping it makes it to the release version soon.)

Comment 51

[Jonathan Kew [:jfkthame]]

Thanks for testing, all of you. Given the positive results, I'll ask Roc to review this and hope to get it landed soon.

Comment 52

[Jonathan Kew [:jfkthame]]

Tryserver run with this patch https://tbpl.mozilla.org/?tree=Try&rev=7bfe14829f5d

The reftest oranges here are expected, because the check for layout tables in the font prevents use of the "fallback" font in these testcases, as already happens on OS X. We'll just need to update the test manifest accordingly.

Comment 53

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8412717 [details] [diff] [review]
mask out complex-script codepoints in fonts that lack the necessary layout tables.

Review of attachment 8412717 [details] [diff] [review]:
-----------------------------------------------------------------

This is OK, but I think we should do this for all platforms. This affects downloaded fonts (right?) so we should have consistent behavior across platforms.

Comment 54

[Jonathan Kew [:jfkthame]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #53)

> This is OK, but I think we should do this for all platforms. This affects
> downloaded fonts (right?) 

Right...

> so we should have consistent behavior across
> platforms.

That'd be OK, I think (see the TODO comment left in the code by bug 755730), but let's do it as a separate bug, given that it will change behavior more widely, and could possibly break some sites if they're (ab)using fonts that rely on complex-script codepoints but don't have proper layout tables. (E.g. once upon a time, pdf.js would've been affected, but I believe they've fixed that.)

So I'd like to land this as-is to work around the specific Samsung brokenness, and then file a followup to extend the behavior across all platforms.

Comment 55

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/767f7423863b

Comment 56

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/767f7423863b

Comment 57

[Jonathan Kew [:jfkthame]]

Comment on attachment 8412717 [details] [diff] [review]
mask out complex-script codepoints in fonts that lack the necessary layout tables.

Requesting approval for mozilla-31, as I understand we're intending to ship some Indian locales, but this bug means Indian scripts will be broken on some common devices.


[Approval Request Comment]
Bug caused by (feature/regressing bug #): bad fonts on Samsung android 4.3 devices

User impact if declined: broken rendering of major Indian languages

Testing completed (on m-c, etc.): fix confirmed using tryserver builds (comments 48-50), landed on m-c without problems

Risk to taking this patch (and alternatives if risky): low risk - just extends existing code to ignore bad fonts from OS X to android; no effect on other platforms

String or IDL/UUID changes made by this patch: none

Comment 58

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/2569162305c8

Comment 60

[Chandrakant Dhutadmal]

Attachment: Issue with Devnagari word "Eye lash Ra"

This issue remains unsolved for one more word in Marathi language. This word called "Eye Lash Ra" is formed with combination of ऱ ् य ा (U+0931  U+094D U+092F U+093E). The Expected and actual results are shown in the screenshot attached with another comment.

Comment 61

[Jonathan Kew [:jfkthame]]

(In reply to Chandrakant Dhutadmal from comment #60)
> Created attachment 8424411 [details]
> Issue with Devnagari word "Eye lash Ra"
> 
> This issue remains unsolved for one more word in Marathi language. This word
> called "Eye Lash Ra" is formed with combination of ऱ ् य ा (U+0931  U+094D
> U+092F U+093E). The Expected and actual results are shown in the screenshot
> attached with another comment.

This is a bug in the SamsungDevanagari font included on these devices. It supports eyelash-Ra only using the older Unicode sequence U+0930 U+094D U+200D (note the use of RA rather than RRA as the consonant here, and the zero-width joiner to prevent the formation of Reph).

See http://www.unicode.org/versions/Unicode6.2.0/ch09.pdf for details. The preferred sequence for eyelash-Ra is indeed U+0931 U+094F (rule R5), but the older sequence is also mentioned "for compatibility with The Unicode Standard, Version 2.0" (see rule R5a). Unfortunately, Samsung's font only supports that older sequence.

So this is a Samsung bug, and the workaround is to use the old spelling for eyelash-Ra. Or to avoid using the SamsungDevanagari font - but there's not much a user with such a device can do about it, short of rooting the phone and replacing the preinstalled font with a better one.

Comment 62

[Biraj Karmakar [:biraj]]

Attachment: tmp_2014_05_28_23.09.411118564905.png

Till this problem happens for bengali

Comment 63

[Jonathan Kew [:jfkthame]]

(In reply to Biraj Karmakar [:biraj] from comment #62)
> Created attachment 8430189 [details]
> tmp_2014_05_28_23.09.411118564905.png
> 
> Till this problem happens for bengali

What version of Firefox is that?

Comment 64

[MS Zaman]

Just pointing out that the issue posted in comment 62 looks to be the same as what this bug started out with. The Samsung fallback font only has the (Bengali) characters necessary to write বাংলাদেশ (which is U+09AC U+09BE U+0982 U+09B2 U+09BE U+09A6 U+09C7 U+09B6), and whenever a word starts with one (or more) of these characters, followed by something else, we get the broken behaviour. U+09C7 in this list (ে) seems to be an exception: it does not produce the dotted circle when following one of these characters, but shows up on the right of the preceding character instead of the left (see the 8th column in https://bug992100.bugzilla.mozilla.org/attachment.cgi?id=8409576, for example).

Comment 65

[Biraj Karmakar [:biraj]]

Version : 29.0.1

Comment 66

[Jonathan Kew [:jfkthame]]

(In reply to Biraj Karmakar [:biraj] from comment #65)
> Version : 29.0.1

This is expected, then. As indicated by the status flags in this bug, the fix (or workaround for Samsung's messed-up fonts, really) has been applied for version 31 and later. You should be able to test it by installing the current Aurora release.

Comment 67

[Biraj Karmakar [:biraj]]

(In reply to Jonathan Kew (:jfkthame) from comment #66)
> (In reply to Biraj Karmakar [:biraj] from comment #65)
> > Version : 29.0.1
> 
> This is expected, then. As indicated by the status flags in this bug, the
> fix (or workaround for Samsung's messed-up fonts, really) has been applied
> for version 31 and later. You should be able to test it by installing the
> current Aurora release.

It has been solved. I have checked in 31.0a2