127661 - (ctl-align-justify) [CTL-Thai] non-base char is incorrecly positioned (out of display cell) when align=justify

Status: RESOLVED WORKSFORME

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

Description

[Atsawin Chaowanakritsanakul]

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.

Comment 1

[Olivier Cahagne]

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

Comment 2

[Aaron Kaluszka]

WFM 2002022203/WinXP

Comment 3

[Atsawin Chaowanakritsanakul]

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.

Comment 4

[Arthit Suriyawongkul]

this may be a duplicate of bug #117484

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

Comment 5

[Atsawin Chaowanakritsanakul]

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.

Comment 6

[Arthit Suriyawongkul]

Attachment: test case

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

Comment 7

[Arthit Suriyawongkul]

Attachment: Screenshot #1 - test case rendered by Mozilla 0.9.8

(Mozilla 0.9.9 made the same result)

Comment 8

[Arthit Suriyawongkul]

Attachment: Screenshot #2 -- test case rendered by IE 6.0

(correctly rendered)

Comment 9

[Arthit Suriyawongkul]

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

Comment 10

[Arthit Suriyawongkul]

character width problem?

Comment 11

[Arthit Suriyawongkul]

this bug is really occurs.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Roy Yokoyama]

assign to layout/font person. Shanjian :)

Comment 14

[Frank Tang]

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

Comment 15

[Arthit Suriyawongkul]

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

probably for every html tag with align= attribute

Comment 16

[Arthit Suriyawongkul]

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

view in build 20020803

Comment 17

[Shanjian Li]

accept

Comment 18

[Roland Mainz]

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

Comment 19

[Theppitak Karoonboonyanan]

Attachment: Screnshot of the test case with mozilla 1.5b (--enable-ctl) on Linux.

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.

Comment 20

[Theppitak Karoonboonyanan]

Attachment: Another screen shot which shows more cases.

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

Comment 21

[Jungshik Shin]

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   

Comment 22

[Jungshik Shin]

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. 

Comment 23

[Atsawin Chaowanakritsanakul]

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.

Comment 24

[Samphan Raruenrom]

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.

Comment 25

[Frank Tang]

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. 

Comment 26

[Travis Chase]

Mass Reassign Please excuse the spam

Comment 27

[Travis Chase]

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

Comment 28

[Travis Chase]

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

Comment 29

[Simon Montagu :smontagu]

Does this bug still occur in trunk builds?

Comment 30

[Theppitak Karoonboonyanan]

Attachment: Screenshot for the test case with trunk build

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

Comment 31

[Keng Susumpow]

Attachment: Mac OS X 10.5.2 Screen shot for test case on Trunk build

Seems the bug has been fixed in Trunk.

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

Comment 32

[Keng Susumpow]

Attachment: Screenshot of rendered test case on Windows XP

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

Comment 33

[Arthit Suriyawongkul]

also works fine on Firefox 3 beta 3 on Linux.

should we mark this as fixed ?

Comment 34

[Arthit Suriyawongkul]

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.