Open Bug 642798 Opened 15 years ago Updated 3 years ago

Certain Bengali fonts cause Firefox to hang

Categories

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

x86
macOS
defect

Tracking

()

People

(Reporter: stas, Unassigned)

References

Details

Attachments

(4 files)

I'm not able to visit http://bn.wikipedia.org. Firefox becomes unresponsive, (the CPU usage goes up to 100%) but it never crashes, so I don't have a crash report. This is happening on Firefox 4 RC1 on Mac OS X 10.6.6 with these two fonts installed: * SolaimanLipi for Mac * Rupali for Mac (any of the two will cause Firefox to hang) I got the fonts from: http://ekushey.org/?page/mac_download (http://files.ekushey.org/Unicode_Bangla_on_Mac_OS_X/Unicode_Bangla_Fonts/EK-OSX-Font.dmg.zip) When I remove these fonts, I can visit the page without any problems. All fonts show as squares, though. I think it's a specific glyph or a subset of glyphs that cause the problem. Oddly enough, the following page displays just fine: http://en.wikipedia.org/wiki/Bengali_script
I thought I had a bug on this, but I don't find it. IIRC, we're triggering a hang in OSX itself.
Assignee: smontagu → nobody
Component: Internationalization → Layout: Text
QA Contact: i18n → layout.fonts-and-text
(In reply to comment #0) > I think it's a specific glyph or a subset of glyphs that cause the problem. > Oddly enough, the following page displays just fine: > > http://en.wikipedia.org/wiki/Bengali_script In that case it's probably a specific combination of characters that is causing the hang.
It works on 3.6.*, but not on 4 beta1 on wards (both 32- and 64-bit). Safari Version 5.0.3 (6533.19.4) and Chrome 10.0.648.151 both hang too.
Component: Layout: Text → Internationalization
Component: Internationalization → Layout: Text
Sounds like this is an Apple bug, probably in Core Text. Maybe you can identify the specific character string that's triggering the problem? (E.g. by taking a local copy of the page and removing parts of the text.)
http://utrrs.org/web/lang/bn_IN/font/IndicFontTestCaseCodepoint-Bengali.html and its siblings render fine, but those are not the current version of the testcases. CCing Ankit and Runa on whether there's a status update on that.
I was able to isolate 3 characters that cause the problem. They only trigger the hang when they're written next to each other, without the separating space: ন্ ডোতে That would explain why http://en.wikipedia.org/wiki/Bengali_script works fine -- all characters are spelled out individually there. There might be more of such cases.
Have you validated those two fonts with Fontbook ? Both report serious errors (Solaiman in the name table, don't remember about Rupali). When I had those fonts installed, I noticed that Photoshop CS5 would crash very frequently.
(In reply to comment #6) > I was able to isolate 3 characters that cause the problem. They only trigger > the hang when they're written next to each other, without the separating space: > > ন্ ডোতে Please provide a link to the entire text or the actual text for the above. I suspect there could be an (unnecessary) ZWNJ/ZWJ in there somewhere.
(In reply to comment #7) > Have you validated those two fonts with Fontbook ? > Both report serious errors (Solaiman in the name table, don't remember about > Rupali). Please try with the Lohit-Bengali fonts. If I recall correctly, there were some Unicode related inconsistencies in the fonts from ekushey earlier. I do not know about their current status.
I tried the lohit font, it helped so that the osx Terminal wouldn't crash on a hg diff on bn-BD, but nightly still is still hanging.
Gen, Bengali text does not break at all on Linux unless the text itself has some inherent borking. If one could get an example of the excerpt that contains the erring characters that Stas reported in comment #6, then it may be easier to narrow things down. However, for the record I use the bn-IN language pack and not bn-BD. regards Runa
Attached file HANG YOUR MAC
Test case to hang your mac. Runa, given that we're apparently hanging somewhere in mac-specific or real osx code, it's not surprising that you wouldn't be able to reproduce this on linux.
Here's the process analysis from the activity monitor.
The page here: http://ekushey.org/?page/mac_download clearly states that due to a rendering bug in Mac OS X 10.6, these fonts would not work. Instead I used the SolaimanLipi fonts that they have recommended from: http://onkur.sourceforge.net/ . Bengali pages are displayed without error for Aurora nightly on Mac OS X 10.6.4. Additionally, Lohit Bengali also has massive rendering failure. Unfortunately, I could not check it on 10.6.6. Can you please check if the original bug can be replicated on 10.6.6 with the second set of fonts from: http://onkur.sourceforge.net/ ? HTH
The SolaimanLipi font seems to fix safari, but not Firefox, at least on 10.6.8 for me. It'd be great if someone else could verify, as my machine is a bit funky, in particular when it comes down to fonts.
(In reply to comment #4) > Sounds like this is an Apple bug, probably in Core Text. Jonathan- can you verify if this a Core Text bug? If so, what is the next step?
Looks like an infinite loop in CoreText: 744 gfxMacFont::InitTextRun(gfxContext*, gfxTextRun*, unsigned short const*, unsigned int, unsigned int, int, int) 744 gfxCoreTextShaper::InitTextRun(gfxContext*, gfxTextRun*, unsigned short const*, unsigned int, unsigned int, int) 744 CTLineCreateWithAttributedString 744 TTypesetterAttrString::Initialize() 744 TTypesetter::FinishEncoding(TLine&, unsigned char) const 744 TCombiningEngine::ResolveCombiningMarks() 744 TLine::GetNextUncombinedCharRange(long, bool&) const 735 TRun::GetNextUncombinedCharRange(long, bool&) const 595 TRun::FindNextGlyphIndex(long, long*) const 280 TRun::FindGlyphIndex(long, int) const 235 TRun::FindGlyphIndex(long, int) const 45 TNativeGlyphStorage::GetStringIndices() const 242 TRun::FindNextGlyphIndex(long, long*) const 44 TNativeGlyphStorage::GetAttachmentCount(long) const 29 TNativeGlyphStorage::GetStringIndices() const 94 TRun::GetNextUncombinedCharRange(long, bool&) const 46 TRun::NextGlyph(long, long*) const 9 TRun::NextGlyph(long, long*) const With textrun logging enabled, it's failing handling the testcase string with SolaimanLipi: 1895369920[100115db0]: (textrun-fontmatching) font: [SolaimanLipi-Regular] lang: en-jp script: 4 len: 6 TEXTRUN [ন্ডোতে] ENDTEXTRUN Just trying to dump the log file in Terminal.app hangs!! TextEdit.app displays it as ASCII so it doesn't hang.
The fonts in question are AAT-enabled versions of OpenType fonts. My guess is that these fonts have a bug which is causing the problem in CoreText. Note: this is not a security problem because the sanitizer doesn't allow AAT tables through, so the problematic tables will be stripped before use.
Bug 674857 (marked as a dupe of this) shows an example string where the SolaimanLipi font was consistently hitting this hang. This is a Core Text issue that was filed in radar on 21-Apr-2010 (rdar://7890137), with testcases showing the problem in Safari as well as Firefox. We should re-test on 10.7 to see if the problem has been resolved in the new OS version.
No hangs for me (though I didn't install any fonts from comment 14). Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0a1) Gecko/20110728 Firefox/8.0a1 Bengali font rendering feels blurry to me, but maybe that's just me.
Also no hangs after installing fonts from comment 0.
Ok, with the comment 0 fonts installed there were no hangs, but composite characters, like the ones from the wikipedia example: ক + ি → কি looked wrong - the composite character had "ক" on the left and " ি " on the right, which, it seems, is not the expected rendering and not what happens when these fonts aren't installed.
Ok, to clarify things again: no hangs whatsoever, neither on wikipedia nor while viewing attachment 544837 [details].
Attached image SoleimanLipi screenshot
This screenshot uses SoleimanLipi from http://onkur.sourceforge.net/ (using data: URL with content from attachment 544837 [details]).
(In reply to comment #25) > Created attachment 549492 [details] > SoleimanLipi screenshot The text rendering looks broken from this screenshot and also its not a complete word.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: