Atsawin Chaowanakritsanakul Reporter
	Description • 23 years ago

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020406

In a cell which use align=justify, Mozilla render upper/lower Thai vowel
incorrectly. They're shifted to the right.

In pictures attached, IE 6.0 render correctly but Mozilla 0.9.8 doesn't.

Reproducible: Always
Steps to Reproduce:
1. Open sample URL provided (http://home.nakhon.net/joke/mozbug1.html)
2. If your system support Thai and you have MS San Serif font installed, you'll
notice incorrectly rendered Thai upper/lower vowel.
3. If your system doesn't support Thai, look at screen capture provided. The IE
one is correct render while Mozilla's is wrong.

Actual Results:  Mozilla shift upper/lower vowel 1 character to the right.

Expected Results:  Correct upper/lower vowel placement. (Compare with IE's
screen capture provided)

Only happen with 'MS San Serif' font (Thai version of this font.) This font is
bitmap font and being phase out by Microsoft. Unfortunately, most user still use
this font. It replacement is 'Microsoft San Serif' which is TTF.

	Olivier Cahagne
	Comment 1 • 23 years ago

I may be wrong because I don't have a Thai system nor do I understand anything
about Thai, but build 200202408 on Win2k renders the same as IE6, and is
different from your 0.9.8 screenshot. The 'accents' render the same as IE6.

I guess I don't have this non-TTF MS San Serif. How does one know about this ?

Just in case, can you try latest nightly build to check ?
Availble here:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip

	Aaron Kaluszka
	Comment 2 • 23 years ago

WFM 2002022203/WinXP

	Atsawin Chaowanakritsanakul Reporter
	Comment 3 • 23 years ago

Test with 2002022503, Win98SE Thai Edition. The rendering's still incorrect.

It's same as 0.9.8. I think these codes wasn't touch for very long time. I've
found this bug several months ago, but at that time, I think it's mis HTML. I
just realized that it's Mozilla's bug.

	Arthit Suriyawongkul
	Comment 4 • 23 years ago

this may be a duplicate of bug #117484

it will occurs only with Thai Character "Tho Thahan" (U+0E17)
in "MS Sans Serif" font.

	Atsawin Chaowanakritsanakul Reporter
	Comment 5 • 23 years ago

Test again with 0.9.9, still incorrect rendering. (Check the sample URL in bug
page.) This bug is *NOT* relate to Thor-Thahan bug (#117484). This involve
ALIGN=JUSTIFY cell in table. However, like #117484, this bug only happened with
Win98's MS Sans Serif font.

	Arthit Suriyawongkul
	Comment 6 • 23 years ago

html document contains
<td align="justify">(Thai text)</td>

	Arthit Suriyawongkul
	Comment 7 • 23 years ago

(Mozilla 0.9.9 made the same result)

	Arthit Suriyawongkul
	Comment 8 • 23 years ago

(correctly rendered)

	Arthit Suriyawongkul
	Comment 9 • 23 years ago

tested with 0.9.9.
this bug is not a duplicated of Bug #117484.
this is a new bug.

	Arthit Suriyawongkul
	Comment 10 • 23 years ago

character width problem?

	Arthit Suriyawongkul
	Comment 11 • 23 years ago

this bug is really occurs.

	Boris Zbarsky [:bzbarsky]
	Comment 12 • 23 years ago

Over to Intl.  I'm seeing this on Linux too.

	Roy Yokoyama
	Comment 13 • 23 years ago

assign to layout/font person. Shanjian :)

	Frank Tang
	Comment 14 • 23 years ago

We know this problem. The problem happen to surrogate ( and we fixed the
surrogate one for window and layout) and also all combining mark, including thai
which heavly use combining mark.
Currently, when we have justify text, we render one character at a time and
incrment the x position for each charcter. We should not do that. We could do
that per text-element but not per unicode. Need to add text-element code into
gfx to address this issue. 
It looks like we need a TextElementBreaker :)

	Arthit Suriyawongkul
	Comment 15 • 22 years ago

this is not only for table's cell,
but also for <div align=justify>.

probably for every html tag with align= attribute

	Arthit Suriyawongkul
	Comment 16 • 22 years ago

another page for testing
http://www.thairath.co.th/itdigest/19_8_2002/itdigest.html
(Thai online newspaper)

view in build 20020803

	Shanjian Li
	Comment 17 • 22 years ago

accept

	Roland Mainz
	Comment 18 • 22 years ago

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

	Theppitak Karoonboonyanan
	Comment 19 • 21 years ago

This bug still exists in Mozilla 1.5b (--enable-ctl on Linux), now with
different behavior.
Please see the attached screenshot which was taken from the test case above.

	Theppitak Karoonboonyanan
	Comment 20 • 21 years ago

To elaborate the case, I took a screenshot from another
web page which has more Thai text at:
http://www.tpschamnong.iirt.net/article/basa_5nt098.html

Notice that there is extra space after every cell that
contains combining character. So, if it's followed by
another combining character, the next one will be
pushed further to the right (and with it, more extra
space).

	Jungshik Shin Assignee
	Comment 21 • 21 years ago

I guess two screenshots were taken with an Xft build, right? Currently, Xft
build can't handle 'justified' text (written in a complex script). Without
'justification, it should work fine. I should have mentioned it in the int'l
release notes. ftang's diagnosis is more or less right. In nsFontMetricsXft
code, we add the value of an element of the 'spacing' array (passed over from
the layout code) to every and each Unicode character (surrogate code points
don't have this problem any more  at least in Gfx:Win, Gfx:GTK including Xft)
instead of each grapheme. 

The cleanest solution is to go all the way to Pango (see bug 214715). Falling
short of that, I've been trying to adapt Pango to the existing code in bug 
215219 (especially bug 205219 comment #17 and bug 205219 comment #18) . The same
problem (applying 'spacing' values per grapheme rather than per Unicode
character) has been holding it down there. I thought I almost solved it, but it
didn't work. B   

	Jungshik Shin Assignee
	Comment 22 • 21 years ago

re comment #1:

On Win2k/XP with any of complex script support package (Thai, Devanagari, Tamil,
etc) installed (in the control panel : language and ? ), Thai rendering should
work. Actually, my expectation was that _justfied_ text rendering would break on
Win 2k/XP the same way as it breaks in Xft build on Linux. I was surprised to
find that it doesn't (For the last couple of minutes, I've been tried to find a
difference between Mozilla's rendering and MS IE's rendering on Win2k. They're
not identical and Mozilla's positioning of vowel signs and tone marks is
slightly off toward the right).  ExTextOutW() on Win32 must be more intelligent
than I thought :-). 

FYI, see also bug 218887 about using  Uniscribe APIs (used by MS IE) on Windows
and bug 121540 about using ATSUI on Mac OS.

re comment #3 : So, it doesn't work on Thai Win98. How about unjustified text?
Does it work? It should work on _Thai_ Win98. 

	Atsawin Chaowanakritsanakul Reporter
	Comment 23 • 21 years ago

To #23, test with 1.4 with Win98SE Thai Edition, the bug still exist. Unjustify
text works correctly. (It always works correctly.)

However, on Win2000, Mozilla render justify/unjustify text correctly.

	Samphan Raruenrom
	Comment 24 • 20 years ago

I've tested the page http://www.tpschamnong.iirt.net/article/basa_5nt098.html
using Firefox 1.0 and Mozilla 1.7.3 on Windows XP. It looks almost correctly but
not. The clusters with two diacritics like «×é ·Õè Á×è are drawn wrong. It looks like
the 2nd diacritics (which are tone marks) is overstriked over the first
diacritics (which are upper vowels). I guess that shaping doesn't work correctly
when rendering justified text.

	Frank Tang
	Comment 25 • 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 26 • 20 years ago

Mass Reassign Please excuse the spam

	Travis Chase
	Comment 27 • 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 28 • 20 years ago

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

	Simon Montagu :smontagu
	Comment 29 • 17 years ago

Does this bug still occur in trunk builds?

	Theppitak Karoonboonyanan
	Comment 30 • 17 years ago

Thanks to the new text layout in trunk, this bug has been fixed.

	Keng Susumpow
	Comment 31 • 17 years ago

Seems the bug has been fixed in Trunk.

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

	Keng Susumpow
	Comment 32 • 17 years ago

Seems this bug has been fixed in Trunk.

Tested on Windows XP SP 2 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030305 Minefield/3.0b4pre

	Arthit Suriyawongkul
	Comment 33 • 17 years ago

also works fine on Firefox 3 beta 3 on Linux.

should we mark this as fixed ?

	Arthit Suriyawongkul
	Comment 34 • 17 years ago

comment #31 confirmed 'fix' on Mac OS X
comment #30, #33 confirmed 'fix' on Linux
comment #32 confirmed 'fix' on Windows XP

Windows 98 (in comment #3) is no longer supported, skip
http://wiki.mozilla.org/Firefox3/Firefox_Requirements#System_Requirements

close as WORKSFORME.