Synopsis: Thai writing system has 4 levels of displays TOP -------- ABOVE -------- BASE -------- BELOW U+0E0E (®) and U+0E0F (¯) both are BASE-level char, which will be displayed in BASE-level area. BUT both also has long 'tail' that goes into BELOW-level area. If in the same dispaly cell, there's BELOW-level char co-existed. (e.g. ¯ + Ù ) BELOW-level char, which normally displayed at the BELOW-level area, should be slightly moved down -- in order to avoid overlie/overlapping the tail of U+0E0E/U+0E0F. ---- Test case: let C = { ® | ¯ } or { U+0E0E | U+0E0F } (BASE-level chars w/ tail) B = { Ø | Ù | Ú } or { U+0E38 | U+0E39 | U+0E3A } (BELOW-level chars) C + B e.g. ® + Ø --> ¯Ø ¯ + Ú --> ¯Ú ---- Expected result: B should not overlied/overlapped the tail of C. B should be vertically slightly moved down from normal position. B should be explicitly displayed, easy to read/know that the char is there. ---- What really happens: (with Mozilla 1.0 RC 2 on win/solaris) B overlied/overlapped the tail of C. this result it is very hard to figure out, if B is exist or not. (B will be lost into the tail of C) ---- FYI, Thai Character Do Chada Unicode: U+0E0E TIS-620: 0xAE Thai Character To Patak Unicode: U+0E0F TIS-620: 0xAF Thai Character Sara U Unicode: U+0E38 TIS-620: 0xD8 Thai Character Sara UU Unicode: U+0E39 TIS-620: 0xD9 Thai Character Phinthu Unicode: U+0E3A TIS-620: 0xDA

Confirm base on reporter's comment, and I checked U+0E0E and U+0E0F in Composer html source, it really showing very low (although I don't know what are they should be).

from the case, B should be placed below C, as said, NOT overlapped.

assign to shanjian for now cc ftang

Over to new bugzilla component "Complex Text Layout" ...

Displaying those characters in proper level is the expected by the user. It affects readability of the webpages a lot.

The text only contain the problematic clusters. If the little diacritics below the base consonants can't be distinguished from the base consonant, then there's still a problem.

The text only contain the problematic clusters. If the little diacritics below the base consonants can't be distinguished from the base consonant, then there's still a problem.

However, shaping seem to works on Windows (XP). This screenshot is taken from Firefox 1.0 on Windows XP. It looks correctly.

shanjian is no longer working on mozilla for 2 years and these bugs are still here. Mark them won't fix. If you want to reopen it, find a good owner first.

Mass Reassign Please excuse the spam

Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all the spam is his fault feel free to tar and feather him

Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam

Apparently, this bug has been fixed since Pango enabling.

It looks correctly on the lastest trunk build. Tested with Mac OS X 10.5.2 with Minefield 3.0b4pre build 2008022104.

need confirmation from Windows, and we can close this i think.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3) Gecko/2008021416 Firefox/3.0b3 on Ubuntu 8.04 Alpha 6 display https://bugzilla.mozilla.org/attachment.cgi?id=175113

under same environment (Ubuntu 8.04 Alpha 6), Ephiphany displays the test case correctly (see this attachment), while Firefox 3 beta 3 displays it incorrectly (see attachment 309363 [details]). same behavior from Firefox 3 trunk ?

fixed HTML tag in earlier test case (attachment 175113 [details])

Screenshot of the latest test case (https://bugzilla.mozilla.org/attachment.cgi?id=309367) in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031304 Minefield/3.0b5pre on Ubuntu 7.10 The glyphs are displayed correctly. Note that font settings are: Proportional: Serif Serif: Norasi Sans-serif: Loma Monospace: Tlwg Typist If Tahoma or Arial Unicode MS (Windows fonts) are selected as default fonts, the glyphs will appear overlapped. Testings in other GNOME applications yield same results.

I have tested Firefox 3 Beta4 (Windows XP sp2) with https://bugzilla.mozilla.org/attachment.cgi?id=309367. The result is Firefox display incorrect, font still overlap each other. Anyway, IE6 is display like this too.

(In reply to comment #17) > under same environment (Ubuntu 8.04 Alpha 6), > Ephiphany displays the test case correctly (see this attachment), > while Firefox 3 beta 3 displays it incorrectly (see attachment 309363 [details]). > > same behavior from Firefox 3 trunk ? Trunk works fine for me (Debian unstable).

(In reply to comment #19) > If Tahoma or Arial Unicode MS (Windows fonts) are selected as default fonts, > the glyphs will appear overlapped. Testings in other GNOME applications yield > same results. (In reply to comment #20) > I have tested Firefox 3 Beta4 (Windows XP sp2) with > https://bugzilla.mozilla.org/attachment.cgi?id=309367. The result is Firefox > display incorrect, font still overlap each other. > > Anyway, IE6 is display like this too. I think both cases are font-dependent. Tahoma appears to lack PUA glyphs for lower variants of the below marks. And with its lack of Thai OpenType features, nothing can help it for this case, then. For comment #20, I think you may choose a better font which works on normal apps to test.

Test again on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008031317 Firefox/3.0b4 with various fonts: Tahoma, Norasi, Waree, Loma, and Tlwg Typist. (Tahoma is installed addtionally as it is not in Ubuntu repo) No problem at all with Norasi, Waree, Loma, and Tlwg Typist. With Tahoma, the last character (ฐ) looks good, but not the first two (ฏฎ). as Theppitak stated, this is a font-dependent issue.

Can we close this as "Won't Fix" ? (or "Works For Me"?)

modification of testcase in attachment 309367 [details] + more fonts

font-dependent issue. won't fix.