Qiu Yingbo Reporter
	Description • 19 years ago

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

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 3 • 19 years ago

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.

	Jean-Marc Desperrier
	Comment 4 • 19 years ago

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

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 6 • 19 years ago

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

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 7 • 19 years ago

Sorry, changing the indent.

	Stuart Parmenter
	Comment 8 • 19 years ago

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.

	Stuart Parmenter
	Comment 9 • 19 years ago

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.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 10 • 19 years ago

(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.

	Stuart Parmenter
	Comment 11 • 19 years ago

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."

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 12 • 19 years ago

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.)

	Stuart Parmenter
	Comment 13 • 19 years ago

will do

	Jean-Marc Desperrier
	Comment 14 • 19 years ago

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

	Masatoshi Kimura [:emk]
	Comment 15 • 19 years ago

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

	Stuart Parmenter
	Comment 16 • 19 years ago

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

checked in

	pal-moz
	Comment 17 • 19 years ago

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]

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 18 • 19 years ago

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.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 19 • 19 years ago

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