Arthit Suriyawongkul Reporter
	Description • 23 years ago

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

	Yuying Long
	Comment 1 • 23 years ago

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).

	Arthit Suriyawongkul
	Comment 2 • 23 years ago

from the case,

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

	Roy Yokoyama
	Comment 3 • 23 years ago

assign to shanjian for now 
cc ftang

	Roland Mainz
	Comment 4 • 22 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 5 • 21 years ago

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

	Samphan Raruenrom
	Comment 6 • 20 years ago

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.

	Samphan Raruenrom
	Comment 7 • 20 years ago

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.

	Samphan Raruenrom
	Comment 8 • 20 years ago

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

	Frank Tang
	Comment 9 • 20 years ago

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. 

	Travis Chase
	Comment 10 • 20 years ago

Mass Reassign Please excuse the spam

	Travis Chase
	Comment 11 • 20 years ago

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

	Travis Chase
	Comment 12 • 20 years ago

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

	Theppitak Karoonboonyanan
	Comment 13 • 17 years ago

Apparently, this bug has been fixed since Pango enabling.

	Keng Susumpow
	Comment 14 • 17 years ago

It looks correctly on the lastest trunk build.

Tested with Mac OS X 10.5.2 with Minefield 3.0b4pre build 2008022104.

	Arthit Suriyawongkul Reporter
	Comment 15 • 17 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 16 • 17 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 17 • 17 years ago

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 ?

	Arthit Suriyawongkul Reporter
	Comment 18 • 17 years ago

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

	Phisit Siprasatthong
	Comment 19 • 17 years ago

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.

	plynoi
	Comment 20 • 17 years ago

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.

	Theppitak Karoonboonyanan
	Comment 21 • 17 years ago

(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).

	Theppitak Karoonboonyanan
	Comment 22 • 17 years ago

(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.

	Arthit Suriyawongkul Reporter
	Comment 23 • 17 years ago

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.

	Arthit Suriyawongkul Reporter
	Comment 24 • 17 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 25 • 17 years ago

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

	Arthit Suriyawongkul Reporter
	Comment 26 • 17 years ago

font-dependent issue. won't fix.