161818 - [trunk]text positioning wrong with Japanese fonts.

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[hirata masakazu]

2002080717 trunk for MacOS9.x. and several recent builds.
Open a URL in Japanese.
View Source.
Result: Tags rendered in bold overlap with other non-bold text.

Other symptoms: If you view Mozilla query page with Japanese encodings, when you
type a text in a form, you can see the caret positioning getting off as you type on.
A bit similar to bug 128394.

Comment 1

[hirata masakazu]

http://www.tcp-net.ad.jp/danbo/
displays quite obvious example of this bug.

Comment 2

[Yuying Long]

Could you please attach a screen shot? thanks!

Comment 3

[hirata masakazu]

Attachment: two examples of bold face problem

Here is the screenshots showing the bold face problem. Caret problem could not
be captured by System screen shot, and was not included.

Comment 4

[hirata masakazu]

This may not be specific to non-Western fonts, since zooming text causes similar
bug 161853 with Geneva font.

Comment 5

[Yuying Long]

Hmm, I don't see the display problem in comment #3 on my Mac 9.1-JA.

It probably related with bug 143557.

Comment 6

[Roy Yokoyama]

text layout issue -> shanjian

Comment 7

[chado]

I think this is serious problem for many of Japanese Mac OS users.
Osaka is one of the most common font set for Japanese.
Using Osaka font for Japanese-serif, text slipping is more distinguished. 
(screenshot is following)

In my testcase, using Osaka font for Japanese-serif, several things appeared.
(testcase is following also)

1) "Tags" part of screenshot
   Many tags, which can enclose some text in line, causes this problem.
   i.e. a, acronym, code, em, strike, strong, and so on...
2) "Font specifing" part of screenshot
   When Osaka is specified for style in explicit (means not serif, sans-serif 
   nor un-specified), text slipping will not happen.  
   So, temorary workaround for ones who like to use Osaka is using 
   UserContent.css to specify Osaka font for all text.
3) "series" part of screenshot
   Dotted rectangle, which appears when link text have clicked, shows 
   wrong range from text which actually rendered.
4) "a to z" part of screenshot
   Slipping width is depend on character.  For example, "x" slips much, 
   "z" slips less.
5) there's no part on screenshot
   Zooming 200% or more, slipping will go away.  

There can be something wrong with calculating text-node width for default style.

2002-08-01-08-trunk was good.
2002-08-02-08-trunk and later builds including 
2002-08-09-08-trunk are no good.  
So, any of these checkins might caught this problem:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=
match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=08%2F01%2F2002+
08%3A00%3A00&maxdate=08%2F02%2F2002+08%3A00%3A00&cvsroot=%2Fcvsroot .

I'm seeing this not only in navigator window, but also in view source, 
composer, and chatzilla, at least.  
This looks relating with bug 161250, also bug 161872.

prefering "default styled text layout slipped under some font settings" or some 
as summary.

Sorry for too long posting.

Comment 8

[chado]

Attachment: another screenshot

another screenshot under the Osaka font, size 12 pix.

Comment 9

[chado]

Attachment: testcase

testcase (Osaka font for Japanese encoding required).

Comment 10

[Shanjian Li]

give it to naoki, this is a mac specific problem.

Comment 11

[Yuying Long]

I checked this on 08-12 build, this problem only exists in Mac OS 9 trunk but
not in branch build.

Comment 12

[nhottanscp]

cc to [e-mail]

rbs, you made changes to mac gfx on 8/1, is this related to your changes?

Comment 13

[rbs]

This might be due to the fact that the ATSUI fallback is being use all the time
-- see bug 161481 for details. It has a small patch that you could try to see if
that fixes the problem. The patch is waiting clearance to check-in at the moment.

Comment 14

[nhottanscp]

The patch for bug 161481 was checked in for 1.1 branch.

Yuyin, please try tomorrow's 1.1 branch build.

Comment 15

[chado]

2002-08-14-03-trunk works fine on Mac OS J1-9.0.4.

Comment 16

[chado]

Latest 1.1 branch build 2002-08-14-22-1.1 also works fine on Mac OS J1-9.0.4.

Comment 17

[rbs]

Marking FIXED to get it off the radars.

The fix for bug 161481 is taking care of a number of Mac bugs that happened
after the landing of bug 107146.

Comment 18

[Yuying Long]

Don't see it on 08-16 trunk build(1.1b) / Mac 9.1-JA.

Mark as verified.