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

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Yuying Long]

Build: 08-24 linux trunk build on RH6.2-Ja

Steps to repro:
1. Launch browser and Open Composer.
2. Turn on the kinput2 and start type some Japanese characters.

Result:
1. You will find the top of characters have been "cut-off" - a screen shot will
be followed.  
    I don't see the same problem on N6.1 RTM build.
2. If you resize the Composer window, then the characters will display completely.

Comment 1

[Yuying Long]

Attachment: Screen shot for the cuf-off characters on the top.

Comment 2

[Roy Yokoyama]

assiging to bstell; ccing yokoyama and shanjian

Comment 3

[kill this account]

Attachment: html test case

Comment 4

[kill this account]

Attachment: image; showing the leftover pixels when a Japanese char is deleted

Comment 5

[kill this account]

in attachment 49255 [details] I copied the Japanese char from attachment 49255 [details] into a
composer window 2 times, cover/uncovered to force a redraw, then deleted one
character.

As can be seen in the image; moz's idea of the size/position does not match the
actual glyph's size/position.

Comment 6

[kill this account]

this is a side effect of bug 91794

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comments made on bug 91794:

------- Additional Comments From [e-mail] 2001-09-13 15:31 -------

>changing from max_bounds.ascent,max_bounds.descent to ascent/descent
>causes clipping of Japanese chars. See bug 96928

I checked the documentation and it is okay to use the ascent/descent in the way 
this bug is doing. I suspect therefore that the regression might perhaps be just 
some side-effects of the fact that an unrelated ASCII font is determining the 
height, instead of the actual J-font being used for the text. If that's the case 
then my patch in bug 99010 makes even more sense. I suggest to wait and try to 
see if my patch caters  for the regression.


------- Additional Comments From David Baron 2001-09-13 15:42 -------

If this did cause bug 96928, then the fix would not be to back it out, but to
fix invalidation code so that it works in this case.  (If bug 96928 was a
side-effect of this fix, then it was merely that this change exposed an existing
bug that would previously have been visible for text with a 'line-height' less
than 'normal' -- one that we should fix anyway.)

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase with 'font-family: "Times New Roman", Times, sans-serif'

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase with 'font-family: sans-serif'

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I see the bug when editing the first of the above testcases but not the second.
 They are displayed on my machine using the same font (which is different from
the one I get if I specify 'serif'), but the line-spacing is noticeably
different (I can see from going Back/Forward between them that the characters
are a pixel lower in the second testcase).

I think this confirms rbs's theory.

Comment 11

[Yuying Long]

The problem occurs in both testcases here on Linux 6.2-Ja system though.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Try replacing "sans-serif" in the second testcase with the name of the Japanese
font that shows up when you view the first testcase.

Comment 13

[kill this account]

David: did you actually test with rbs' patched code?

Comment 14

[kill this account]

rbs: The patches ot bug 99010 have rotted a bit and I cannot get it to 
work on a current build.

Can you verify that your patch for 99010 fixes this?

Thanks

Comment 15

[rbs]

That doesn't surprise me, I have been singing all along how hard it is to keep
up with the trunk. Let me drop new zip files in sync with current trunk so that
you can easily overwrite the current ones.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, I didn't test with rbs's code, but it's clearly the problem he describes
since I can see or not see the problem with a given font depending on the value
of the 'font-family' property that led to the font being selected.

Comment 17

[kill this account]

rbs: thanks

dbaron: I'm just being careful (or pedantic depending on the pejorative one 
wants to use)

Comment 18

[kill this account]

I tried a build with the 99010 patches and it seems to solve this problem.

Comment 19

[kill this account]

Yuying: now that bug 99010 is checked in could you test if this is still
a problem?

thanks

Comment 20

[Yuying Long]

I can not verify it on today's trunk build, cause we have a trunk block bug(with
JA locale) that I can launch browser.

But I still see it on branch build though.

Comment 21

[Yuying Long]

This works fine on 10-01 trunk build.

However, bug 99010 is re-opened right now, don't know if it will be affected
here when there is some new changed over there.

Comment 22

[kill this account]

this was fixed by bug 99010

Comment 23

[Yuying Long]

Marking as verified cause not reproducible on 10-01 linux trunk build.