143557 - overlapping text at certain sizes

Status: RESOLVED WORKSFORME

(Core :: Internationalization, defect)

Description

[Frank Tang]

I saw this with 0509 branch build on macos x

reproduce procedure
1. go to www.google.com
2. click preference
3. select trad chinese or simp chinese. (not sure about japanese or korean)
4. click ok
5. now search any word
expect result:
all the text display correctly
actual result:
the red highlight text overlap with normal text in the search result

This somehow only happen when the the size set to the follow value in the
preference (the default for both chinese is 16) regardless I select Serif or
Sans Serif

size 8,12,13,14,16 are bad
other size, such as size 9,10,11,15,18,20,24 have no problem
when I test the font set to trad chinese is LiGothic Median and Li Sung Light. 

I guess is the GetTextDimension code have some error round up differently with
DrawString when we use bitmap font.

Comment 1

[Frank Tang]

reassign

Comment 2

[Yuying Long]

Attachment: Another overlay test page

This page font size is 2 - one size smaller than the default standard size is
3.

Comment 3

[Frank Tang]

look very bad on mac.

Comment 4

[Frank Tang]

I don't know how to fix this issue. need help from macdev
This currently only happen on trad chinese and simp chinese. I cannot reproduce
this for Korean nor japanese
the problem is in the layout we call GetTextDimension per line break point and
sum the width up together. and when we draw text we draw the whole string.
I put printf on the GetScriptTextWidth and DrawScriptText, it turn out that when
we call GetScriptTextWidth with one Chinese characters (two bytes), it return
12, and when some time it called it with two chinese characters (4 gytes), it
return 24. The sum of that whole string is 
12+12+12+12+12+12+12+25+12+12+25+12+25+25+12+12+12+25+12+12 = 305
but when I call DrawScriptText and call TextWidth with all of them it return 324. 
I think this is a round down error between the fraction and integer. 

I print LMGetFractEnable() , it is 0.
I set CharExtra(0.0f) and SpaceExtra(0.0f).

Could this a bug on MacOSX for QuickDraw with Chinese font ?

Comment 5

[Frank Tang]

this is NOT a regression. We have this bug in n6.2. But when we ship n6.2 Apple
have not ship MacOS X 1.4 with chinese yet. So we didn't hit this problem. IE in
the other hand do not have this problem. 

Comment 6

[Patrick C. Beard]

I'm running 10.1.4 and with a recent daily build, I can't reproduce this on 
my system. Do I have to install additional language support on my Mac? 
Which fonts are you using for the Serif and Sans Serif settings?

Strangely enough, the google preferences won't stick for me, google 
somehow thinks cookies are turned off in all my browsers, and yet they 
aren't off since I can log into  bugzilla and stay logged in.

Comment 7

[Frank Tang]

patrick- have you visit the attachement ?

Comment 8

[Frank Tang]

naoki: I am really out of option for this bug. I think a fresh eye could help. 
Please try to fix it. Thanks

Comment 9

[nhottanscp]

>3. select trad chinese or simp chinese. (not sure about japanese or korean)
chinese only so far, I don't see the problem with Japanese (www.google.co.jp)
and Korean (http://www.google.com/intl/ko/). But Korean and Japanese search
results do not use color unlike the Chinese results.

Comment 10

[nhottanscp]

I have a result of text width using the attached test case (25 Chinese
characters). FractEnable was off (the result was the same even it was on anyway).


::TextWidth                      324
(one call for 25 characters)

::TextWidth                      300
(25 calls for 25 charcters)

::DrawText                       325
(one call for 25 characters)

::DrawText                       325
(25 calls for 25 charcters)


So the current code which is calling ::TextWidth per character and estimates
smaller width than the actually drawn character width. That causes the text overlap.

Comment 11

[Frank Tang]

nhotta, can you hack a stand along app that can show the problem so we can send
ot apple?

Comment 12

[nhottanscp]

standalone test using the same text as the attached HTML


#include <stdio.h>
#include <Carbon.h>

int main()
{

  // 25 Chinese text in GB2312
  unsigned char text[] = 
  "\xC7\xEB\xCA\xE4\xC8\xEB\xCB\xF9\xD0\xE8\xB5\xC4\xD0\xC5\xCF\xA2\
\xA3\xAC\xB5\xE3\xBB\xF7\xA1\xB0\xC8\xB7\xB6\xA8\xA1\xB0\xBD\xF8\
\xD0\xD0\xA1\xA3\xC3\xBB\xD3\xD0\xD7\xA2\xB2\xE1\xA3\xAC\xC7\xEB\
\xCF\xC8";

  ::TextSize(13);
  short font = ::GetScriptVariable(smChinese, smScriptAppFond);
  ::TextFont(font);

  short width1 = ::TextWidth(text, 0, 50);
  short width2 = 0;
  
  for (int i = 0; i < 50; i+=2) {
    width2 += ::TextWidth(text, i, 2);
  }

  printf("Measure Chinese text \(GB2312\) \nusing ::TextWidh, text size 13,
application font for smChinese.\n\n");
  printf("1 TextWidth call for 25 characters: %d\n25 TextWidth calls for 25
characters: %d\n",
          width1, width2);
  
	return 0;
}

Comment 13

[nhottanscp]

There is no width inconsistency by changing TextSize from 13 to 12.

In Mozilla, if I use 15 pixel for Chinese instead of 16 pixel then I don't see
the overlap problem and the text drawn nicer too. 
I wonder why we get 13 point from 16 pixel instead of 12, 72 / 96 * 16 = 12.

Anyway, we can change macprefs.js and set the default value for Chinese to 15
instead of 16.

Comment 14

[nhottanscp]

Attachment: Change default font size for Traditional and Simplifiled Chinese to 15 which let Quickdraw to use 12 point instead of 13.

Comment 15

[nhottanscp]

The patch changed Simplified and Traditional Chinese font size from 16 to 15
pixel for both proportional and fixed. That fixes the problem for the attached
test case and http://www.google.com/intl/zh-CN/, http://www.google.com/intl/zh-TW/.

Yuyin, could you try other Chinse pages and see they are okay with 15 pixel? You
need to change the sizes from 16 to 15 pixel using pref dialog. Please try both
MacOS X and MacOS 9. Let me know if you have questions.

Comment 16

[nhottanscp]

For fixed width, 16 looks better than 15, we don't want to change that.
We need MacOS 9 result for propotional 15 pixel setting.

Comment 17

[Yuying Long]

Yes, on Mac OS X, size 15 for proportional will fix the problem in this bug, but
size 16 is better than 15 when load a fixed width page.

And I couldn't find a good size combination for both proportional and fixed.

On Mac OS 9, seems there is not much difference between size 15 and 16 for
fixed, but size 15 is a little bit better than 16 for proportional.

Comment 18

[Simon Fraser [no longer active]]

The patch to change the default font sizes won't help those users who have
changed their font sizes in the prefs, will it?

Comment 19

[Frank Tang]

>------- Additional Comment #18 From Simon Fraser  2002-06-24 10:51 
>The patch to change the default font sizes won't help those users who have
>changed their font sizes in the prefs, will it?
No, and those users could change their font size again to make it work.
We know this is not a good solution. But that is the best one can got so far.
The root of the problem is really inside QuickDraw. You can try nhotta's program
and see the inconsistent error round down between the whole string and the sum
of substring. It won't be a big deal if the whole string round down char by char. 

Comment 20

[nhottanscp]

Attachment: Change Chinese proportional font size default to 15.

Comment 21

[Frank Tang]

Comment on attachment 89145 [details] [diff] [review]
Change Chinese proportional font size default to 15.

r=ftang simple and safe work around before we can find out fix for complicated
issue deep inside QD and mac gfx.

Comment 22

[Frank Tang]

nhotta, please make screen shot to show the problem on Mac. and show the screen
before and after your work around.

Comment 23

[nhottanscp]

Attachment: screen shot before the fix

Comment 24

[nhottanscp]

Attachment: screen shot after the fix

Comment 25

[Simon Fraser [no longer active]]

Comment on attachment 89145 [details] [diff] [review]
Change Chinese proportional font size default to 15.

sr=sfraser
But we need a bug to stay open, since the problem still exists if the user
changes their font sizes in the prefs.

Comment 26

[nhottanscp]

checked in to the trunk

Comment 27

[nhottanscp]

relnoteRTM, this is not going to 1.0.1 branch

We need to watch if the next MacOS X release produce better Chinese fonts.

Comment 28

[nhottanscp]

I filed a bug in Apple's bug system at bugreport.apple.com.

Problem ID: 2985882 - Chinese text overlapping problem at certain sizes with
Netscape 7.0 PR1 

Comment 29

[HARUNAGA Hirotoshi]

A similar problem happens also with Japanese fonts/OS.

If attachment 83127 [details] is seen using "Heisei-kaku-gothic W5" (Adobe) for
Japanese font(14px), the linked text overlap with previous text at the
time of text zoom 90% and 140%, on 2002071608-trunk/Mac OS J-9.2.

Original report in Bugzilla-jp(Japanese):
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2386

Comment 30

[nhottanscp]

The problem is seen with Chimera.
Simon, have we switched to use ATSUI in Chimera? Or Chinse text is still drawn
by QD?

Comment 31

[Simon Fraser [no longer active]]

Chimera is using QuickDraw text rendering (with the smoothing bit turned on).
But note that Chimera is being built off a branch, so won't pick up trunk changes.

Comment 32

[nhottanscp]

Yes, I know that. I thought if we plan to switch gfx to ATSUI then not much make
sense to workaround the QD specific problem (at least of MacOS X). Do we have a
bug to default gfx to ATSUI?

Comment 33

[Simon Fraser [no longer active]]

The ATSUI bug is bug 121540. The patch in there has bitrotted somewhat.

Now that we have anti-aliased text rendering from QuickDraw, I'm not sure
whether we want to go to ATSUI. ATSUI does render some text better, but is
slower, and needs code written for all the fallback logic. In addition, we're
really abusing the ATSUI API (which is designed for paragraph-level layout). It
really would require some changes in the text layout code (nsTextFrame etc.) to
make proper use of ATSUI.

Comment 34

[Frank Tang]

> It really would require some changes in the text layout code (nsTextFrame
etc.) to make proper use of ATSUI.
I gave this kind of comment to apple to express our difficulty several years
ago. I heard that they have now ATSUI low level which provide closer what we
need. maybe we should look into that kind of thing. Does Apple give more low
level ASTUI (or AAS) api for text rendering in macos x now ?

Comment 35

[Frank Tang]

hum... apple does have low level atsui- but that is not what we need. see 
http://developer.apple.com/technotes/tn/tn2033.html

Comment 36

[Frank Tang]

does the SwapQDTextFlags() call in widget/src/mac/nsToolkit.cpp have any impact
on this bug ?

Comment 37

[nhottanscp]

>I saw this with 0509 branch build on macos x
The original report was filed on 5/10 that is before the quartz rendering was
turned on. But we can try to turn it of and see if related.

Comment 38

[Kim Ahlström]

Additional comments on Japanese pages showing this bug can be found in Bug 185503 (Sorry about the dup).
Something that might be related to this bug is the fact that underlined Korean links have their underline drawn inside the text. This only seem occur with small serif fonts and all sans-serif fonts.
Example of sans-serif: http://kr.dailynews.yahoo.com/headlines/
Example normal and small serif: http://kr.yahoo.com/
Korean pages does not, however, seem to have the overlapping-bug.

Comment 39

[nhottanscp]

remove topembed+
This is really a bug inside MacOS X. Not a mozilla bug.

Comment 40

[Juan José Mata]

EDT triage: this works for me on a trunk build from 2/12/2003 on OX 10.2.4,
minusing topembed nomination.

Comment 41

[Greg K.]

*** Bug 185503 has been marked as a duplicate of this bug. ***

Comment 42

[nhottanscp]

remove nsbeta1+
This is really a bug inside MacOS X. Not a mozilla bug.

Comment 43

[Samir Gehani]

i18n triage team: nsbeta1-

Comment 44

[riscky]

With 10.3.3 with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
&
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040413
Firefox/0.8.0+

Uisng the "overlay test page" both browsers render the page as showen in "screen
shot after the fix"

Can this be closed? 

Comment 45

[HARUNAGA Hirotoshi]

No problem too using Firefox 1.5 on OS 10.3.9.
Marking WFM.
Please reopen if I was wrong.