Mac version of Bug #405393. See bug 405393 comment 5. (I haven't confirmed whether this problem was present on Mac with FF2, but I assume it wasn't.)

Mac Fx 2 shows question marks for the testcase. But given the multiple problems with 'special' characters on Mac Gecko 1.8, I'm not sure it is a fair comparison.

Thanks, I'll remove the "regression" keyword, but this is still something we should fix.

Yeah, that's because we essentially did not render Indic script languages in 1.8, and also because there are no suitable fonts available for Malayalam on Mac OS X. ZWNJ did work in other cases on the branch (http://www.unics.uni-hannover.de/nhtcapri/bidirectional-text.html), though. I really have no idea what this bug's testcase is supposed to do given the Malayalam font issue (and the fact it triggers bug 407761 for me on trunk). Can we get a Telugu or Kannada testcase instead? Mozilla doesn't have a langGroup established for either, so I don't know how it might work, but there *are* suitable Mac fonts for Telugu and Kannada: http://web.nickshanks.com/typography/telugu/ and http://web.nickshanks.com/typography/kannada/ so we can actually see glyphs and compare to a reference rendering.

I meant to post this earlier... With the necessary fonts installed, I can view Kannada and Telugu pages: te.wikipedia.org or kn.wikipedia.org correctly, I think. I can't see any missing glyphs boxes or similar in the body text or anything that looks like the screen shots posted in bug 405393. Those two pages also look the same when using Safari 3. ml.wikipedia.org fails for the reasons mentioned in comment 3.

Thanks for comments. (In reply to comment #3) > Yeah, that's because we essentially did not render Indic script languages in > 1.8, and also because there are no suitable fonts available for Malayalam on > Mac OS X. Has anyone tried freefont? http://www.nongnu.org/freefont/ I'll mark this as invalid, as it sound like the glyph boxes were simply due to the lack of a suitable font. If the testcase fails to render even with these fonts installed, then we should reopen.

I don't see any glyph boxes in Malayalam using the AnjaliOldLipi font from http://varamozhi.wikia.com/wiki/Varamozhi. OTOH, the ZW[N]J don't seem to have any effect, for example in attachment 247090 [details]

Reopening then and changing the URL from attachment 291259 [details] to attachment 247090 [details]. Is the ZW[N]J meant to have an effect in all three cases in attachment 247090 [details]? (On Linux with FreeSerif or AnjaliOldLipi, I only see an effect with the first and third comparison; the ZWJ at the end of the second comparison does not have an effect.)

Given that none of these Malayalam fonts are AAT fonts and therefore don't support glyph reordering, is it possible (likely) that the ZW[N]J appearing to have no effect on Mac OS X is simply yet another artifact of no suitable fonts. (No suitable font is not quite the right description, as XenoType sell an AAT Malayalam font; there are just no free/free or shareware fonts available.)

Sorry, didn't mean to re-set the priority.

So do we have any ZW[N]J testcase that is known to work on Mac with appropriate AAT fonts? I don't really understand the examples in http://www.unics.uni-hannover.de/nhtcapri/bidirectional-text.html, though I guess I could sit down and figure them out.

I can reduce those to more understandable ones when I get a bit of time, but they all look correct to me on trunk. For the ZWNJ tests, there are a series of three related words; ignore the first word in every group (it's a singular). The second word is the testword; it has a ZWNJ. Compare that to the third word (in red); if the second word and the third word look identical, we're broken (it's an anti-reftest, so to speak). It's harder for me to explain the ZWJ tests, and the bug he describes in "Markup inside Arabic text" (needing ZWJ to keep words joined across internal style changes) has been fixed. I'm sure I can write some testcases that work, though...in fact, we ought to be able to reftest Arabic letter + ZWJ against the relevant glyph from Arabic Presentation Forms-B codeblock, e.g. <p dir="rtl" lang="ar">ج&zwj;</p> <p dir="rtl" lang="ar">ﺟ</p>

(In reply to comment #11) > It's harder for me to explain the ZWJ tests, and the bug he describes in > "Markup inside Arabic text" (needing ZWJ to keep words joined across internal > style changes) has been fixed. I'm sure I can write some testcases that work, > though...in fact, we ought to be able to reftest Arabic letter + ZWJ against > the relevant glyph from Arabic Presentation Forms-B codeblock That will be great if it works. I tried to write a reftest for the word-joining across span boundaries bug, but it failed even though the differences were imperceptible to the human eye.

I checked in some ZWNJ reftests in layout/reftests/text. Unfortunately the Linux tinderbox has terrible Arabic fonts in which all characters are displayed as isolated forms, so the test is meaningless there.

Here's a WIP of a reftest for ZWJ I came up with on my way to sleep last night. The main problem is that I've not yet come up with a clean way to do two positive (==) tests before doing this (!=) test. I'm having a couple of visible spacing issues when I switch to presentation forms, which perhaps I can work around (at least on the Mac) by swapping words, but that doesn't guarantee it won't also hit comment 12 before all is said and done. Also, does hex vs. decimal entities matter? Software I'm using converts to the latter easily, but not to the former at all; smontagu's ZWNJ tests used the former.

(In reply to comment #14) > Also, does hex vs. decimal entities matter? Software I'm using converts to the > latter easily, but not to the former at all; smontagu's ZWNJ tests used the > former. I think people generally use hex entities because Unicode code points are usually described with hex, but I don't think there is anything _wrong_ with using decimal entities. Better to have a reftest with decimal than no reftest.

From reading http://en.wikipedia.org/wiki/Apple_Advanced_Typography#AAT_for_Indic_scripts and bug 205476 comment 17 and some following comments, it sounds like ATSUI does not have an Indic script engine and doesn't read the GSUB classes necessary for rendering Indic script with OpenType fonts. So we could either mark this invalid, claiming it is a bug in ATSUI or a failure of the OS to provide AAT fonts, or we could consider using Pango one day.

I think this is a WONTFIX. As noted by Karl in comment 16, we use ATSUI for doing glyph selection and layout and ATSUI doesn't support Open Type layout tables. As part of the fix for bug 361986 the mac font code will now explicitly skip over OpenType fonts for Indic text to avoid this situation.

Per comment 17.

We now use harfbuzz IIUC, so this may be WFM.