328940 - If first character is existing on current font and second or more characters are not so, we fail to render the text

Status: RESOLVED FIXED

(Core :: Graphics, defect, P1)

Description

[Qiu Yingbo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 POTU(1.1) Firefox Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060228 Firefox/1.6a1 ID:2006022822

Chinese font can be render correctly in most cases. But a little text of this page  can't be displayed..

I'll attach the screenshot of wrong and right.

Reproducible: Always

Steps to Reproduce:
1. make sure your mechine have pre-install chinese font.
2. open the URL. http://team.eyou.com/node/485
3. look the middle area of the left-sidebar

Comment 1

[Qiu Yingbo]

Attachment: screenshot of the bug. notice content in the RED AREA!

Comment 2

[Qiu Yingbo]

Attachment: the same area in MS IE

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that the summary may be wrong. But I'm not sure.

I think that we may fail to select font in following time:

1. the text is specified the font-family and the specified font doesn't have the glyphs after second characters.
2. the first character is 'neutral' character from all scripts. e.g, ' ', '('...

I want to try to fix this. But this bug may be in |gfxWindowsTextRun::MeasureOrDrawUniscribe| that is changin in bug 327184. I cannot try until fixed it.

Comment 4

[Jean-Marc Desperrier]

I found a similar problem with thai on the page http://www.osdev.co.th/.

See a gif capture here :
https://bugzilla.mozilla.org/attachment.cgi?id=214675&action=view

The interesting part is that page shows that the problem disappears if the FX windows is resized so that the part of the line with the problem is wrapped to another line. Capture showing that :
https://bugzilla.mozilla.org/attachment.cgi?id=214676&action=view

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Simple testcase

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv1.0

This is simple. We are checking that the glyph of first character is contains in current font. But we should check all characters.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv1.1

Sorry, changing the indent.

Comment 8

[Stuart Parmenter]

i don't think it is that simple.  i think we want to try and render all the clusters until we can't render one and then go back through the previous fonts in order to keep proper font selection going.

Comment 9

[Stuart Parmenter]

that said, we may still want to take this patch until we can do a better fix. i'll test this out in a bit.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #9)
> that said, we may still want to take this patch until we can do a better fix.
> i'll test this out in a bit.

Yeah, I don't have enough knowledge for gfx, so I don't know the better fix. But this bug is serious for non-alphabet users. We should suppress this in early time even if my patch is not best.

Comment 11

[Stuart Parmenter]

Comment on attachment 215038 [details] [diff] [review]
Patch rv1.1

lets get this in for now.  Please add a comment above it that says something like:
"XXX We want to only use a new font for the glyphs that we are unable to render and use the current font for the rest."

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I cannot create the new patch and check-in to tree until return to Japan.
Can you do it instead of me? (of course, if you have much time.)

Comment 13

[Stuart Parmenter]

will do

Comment 14

[Jean-Marc Desperrier]

About plans to enhance this in the future : 
"We want to only use a new font for the glyphs that we are unable to render
and use the current font for the rest" seems to me exactly like what we should *not* do, in order to avoid the "letters cut out of the newspaper" style.

ScriptItemize will at least help avoid that by ensuring we select a font for a whole word and not just a letter. 

But ideally, we should go back and reconsider the characters earlier in the ligne. If the fall-back font can display them too, then we should use the fall-back font for them, and keep using the fall back font for all it can display in the rest of the line.

It's when meeting a character the fall-back font can not display (or for a block with formatting that changes font selection), that we should revert to the normal font selection algorithm.

BTW about the current approach, there seem to be some performance issues with systematically using ScriptItemize / ScriptTextOut. See this for a description :
http://groups.google.com/group/microsoft.public.win32.programmer.gdi/msg/98dd86a2e2b66a93

Comment 15

[Masatoshi Kimura [:emk]]

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

Comment 16

[Stuart Parmenter]

Comment on attachment 215038 [details] [diff] [review]
Patch rv1.1

checked in

Comment 17

[pal-moz]

seems to be fixed.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1 ID:2006033115 [cairo]

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you, stuart.

I'll restart my work tommorow, and I have an idea for better fix, but I'm trying to simplify the code. I'll mark to fixed this bug after I confrimed it, and I'll file a new bug for better fix, thanks.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

O.K. I confrimed, this is fixed on trunk. Thanks, Stuart.
I filed bug 332649. I'll work on better fix in bug 332649.