103002 - [Composer] The Japanese characters looks like "Cut-off" when first typing in Composer

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Yuying Long]

Build: 10-03 branch build on Mac OS X-Ja

Steps to repro:
1. Launch browser and Open Composer.
2. Switch to Japanese IME "kotoeri" and start type some Japanese characters.

Result:
1. You will find the top of characters have been "cut-off" - see followed screen
shot 1.  
2. If you resize the Composer window, then the characters will display
completely - see followed screen shot 2.
3. Press delete key to delete the character, then you will see there is leftover
pixels of the top of characters - see screen shot 3.
4. If you resize the Composer window again, the leftover pixels will gone.

Note:
1. If you copy/paste a Japanese string from other place(e.g. web site), you will
not see the problem.
2. Not reproducible on Mac9.1-Ja or other windows systems.
3. We had almost same problem(bug 96928) on linux before.

Comment 1

[Yuying Long]

Attachment: 1. when new start typing Japanese characters

Comment 2

[Yuying Long]

Attachment: 2. no "cut-off" After Composer window be resized

Comment 3

[Yuying Long]

Attachment: 3. leftover pixels after deleted those characters

Comment 4

[rbs]

As the opening Note #3 said, the same problem (bug 96928) on linux was fixed as 
a consequence of landing font changes in bug 99010.

So it might help to hook the proper GetTextDimensions() on the Mac sooner 
rather than later.

Comment 5

[Roy Yokoyama]

over to nhotta (Mac issue).  

Comment 6

[nhottanscp]

rbs, I am not familiar with your last change for GetTextDimensions. Could you
explain what is wrong in the current Macintosh implementation? Are you
suggesting to do it differently for MacOSX?

http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsRenderingContextMac.cpp#1297

1296 NS_IMETHODIMP
1297 nsRenderingContextMac::GetTextDimensions(const char* aString, PRUint32 aLength,
1298 nsTextDimensions& aDimensions)
1299 {
1300 if (mGS->mFontMetrics) {
1301 mGS->mFontMetrics->GetMaxAscent(aDimensions.ascent);
1302 mGS->mFontMetrics->GetMaxDescent(aDimensions.descent);
1303 }
1304 return GetWidth(aString, aLength, aDimensions.width);
1305 }
1306 1307 NS_IMETHODIMP
1308 nsRenderingContextMac::GetTextDimensions(const PRUnichar* aString, PRUint32
aLength,
1309 nsTextDimensions& aDimensions, PRInt32* aFontID)
1310 {
1311 //XXX temporary - bug 96609
1312 //XXX need to have nsUnicodeRenderingToolkit::GetTextDimensions()
1313 if (mGS->mFontMetrics) {
1314 mGS->mFontMetrics->GetMaxAscent(aDimensions.ascent);
1315 mGS->mFontMetrics->GetMaxDescent(aDimensions.descent);
1316 }
1317 return GetWidth(aString, aLength, aDimensions.width, aFontID);
1318 }
1319 

Comment 7

[nhottanscp]

cc to rbs, I posted questions but forgot to cc him.

Comment 8

[rbs]

GetTextDimensions(const char* aString, ...) is fine. What needs to be updated is
GetTextDimensions(const PRUnichar* aString, ...). The problem is that due to the 
so-called font-switching, several fonts can be used to render a Unicode string. 
What need to be done is to return the max ascent (resp. max descent) amongst the 
ascents (resp. descents) of the fonts involved to render the string. See
bug 96609 and bug 100868. ftang and others know what it is all about, so you 
might want to have a chat with them. It is needed for all the variants of Mac 
(not just Mac OS X -- there wasn't a way in bugzilla to say that it is a general 
Mac XXX problem).

Comment 9

[Frank Tang]

nhotta, I am fixing this, see bug 100868. The fix there should solve this issue. 
reassign this bug to me. 

Comment 10

[Frank Tang]

fixed and check in.

Comment 11

[Yuying Long]

Fixed verified on 11-16 trunk build.