212595 - bad text rendering if korean and english is mixed.

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX: Gtk, defect)

Description

[Eungkyu Song]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1

if korean font and english font are different, (fontconfig's setting) text
rendering is bad. it is fixed when i uncheck "Allow documents to use other
fonts" in option. when this option is disabled, mozilla use same font in korean
and english.

(see my screenshot)

Reproducible: Always

Steps to Reproduce:
1.set Korean font Serif -> serif, Sans-serif -> sans-serif, Monospace ->
monospcae (fontconfig)
2.check "Allow documents to use other fonts"
3.see the given url

Actual Results:  
good randering

Expected Results:  
bad randering (see my screenshot)

Comment 1

[Eungkyu Song]

Attachment: bad font-rendering

mozilla use bitstream-vera sans font to render english, and
gulim (Korean MS-Windows's default korean font) font to render korean.
(i configure this in /etc/fonts.conf)

but rendering is not good.

Comment 2

[Eungkyu Song]

Attachment: good rendering

when i uncheck "Allow documents to use other fonts" in Preferences -> Appreance
-> Fonts. mozilla use gulim to render english and korean font. rendering result
is good.

Comment 3

[Eungkyu Song]

this is my /etc/fonts.conf's serif, sans-serif, monospace setting.
(small modification with debian's default setting)

	<alias>
		<family>serif</family>
		<prefer>
			<family>Bitstream Vera Serif</family>
			<family>Times New Roman</family>
			<family>Nimbus Roman No9 L</family>
			<family>Luxi Serif</family>
			<family>Times</family>
			<family>Kochi Mincho</family>
			<family>AR PL SungtiL GB</family>
			<family>AR PL Mingti2L Big5</family>
			<family>Batang</family>			
		</prefer>
	</alias>
	<alias>
		<family>sans-serif</family>
		<prefer>
			<family>Bitstream Vera Sans</family>
			<family>Verdana</family>
			<family>Nimbus Sans L</family>
			<family>Luxi Sans</family>
			<family>Arial</family>
			<family>Helvetica</family>
			<family>Kochi Gothic</family>
			<family>AR PL KaitiM GB</family>
			<family>AR PL KaitiM Big5</family>
			<family>Gulim</family>
			<family>SimSun</family>
		</prefer>
	</alias>
	<alias>
		<family>monospace</family>
		<prefer>
			<family>Bitstream Vera Sans Mono</family>
			<family>Andale Mono</family>
			<family>Courier New</family>
			<family>Luxi Mono</family>
			<family>Nimbus Mono L</family>
			<family>Kochi Gothic</family>
			<family>AR PL KaitiM GB</family>
			<family>GulimChe</family>
		</prefer>
	</alias>

Comment 4

[Eungkyu Song]

Attachment: rendering while dragging

if i drag bad-rendering-text, it render well.
and, it is not only in html renderer, but also in mozilla itself.
(see the tab name in mozilla firebird)

Comment 5

[Eungkyu Song]

I think this bug belong to "XP Apps: GUI features" component.
This mis-rendering appears not only html rendering screen but also mozilla's
basic UI screen.

see the last screenshot "rendering while dragging"

may i reassign this bug?

Comment 6

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

Definitely NOT an apps bug.  If it happened only in the tabs it could be a
toolkit bug, but since it happens in web pages, it should stay in layout.

Comment 7

[Eungkyu Song]

I examined this problem and made a sample html.

If text start with Korean charactor, rendering problem seems to occur.

Not only html, whole browser has the problem. I selected "Bitstream Vera Sans"
for "Application font" through "gnome-font-properties". If web page's title
start with Korean, same problem occur in "Tab's title", "History list in Go
menu", and "History sidebar (Ctrl-H)" in mozilla firebird, NOT "title of window"
which is rendered by window manager using gtk2 (metacity)"

If I select the mis-rendered text (for html) or move mouse over the text (for
browser), mozilla re-render correctly. However if I push "reload" (for html) or
move window (for browser), mozilla mis-render it again.

I'll attach this html and rendering result.
These will help you.

ps) can you reproduce this problem?

Comment 8

[Eungkyu Song]

Attachment: sample html

Comment 9

[Eungkyu Song]

Attachment: sampl html rendering result

sample rendering result plus "tab title", "history sidebar", and
gnome-font-properties setting screen.

Comment 10

[Eungkyu Song]

Please confirm this bug.
This bug is my only big complain about mozilla/firebird.
Please tell me what is not clear.

Comment 11

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

->Gfx:Gtk (Xft).

It would have been much clearer if you had pointed out that the problem was in
the first line of text in the black bar at the bottom of the page.  It's not
easy to spot given the whole screenshot.

Comment 12

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

->Gfx:Gtk(xft) really

Comment 13

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

Also note that this might be an Xft or Xrender bug rather than a Mozilla bug,
although I'm not sure.

Comment 14

[Eungkyu Song]

Ok, this bug is related xft + fontconfig (+ freetype?). (and may be not a
mozilla's bug)
But, I reported it to mozilla bugzilla because only mozilla have such behaviour.
Many applications (include gnome2) use xft + fontconfig font system with Xrender
extension but there is no problem. I'm sorry that there need too many time to
dive source code. I'm new to mozilla source code and it's not easy.

First, I think problem occurred estimating width of space charactor. If a chunk
of text start with korean charactor, space charactor is renderred too wide and
later charactors are renderred abnormally.

this is the problem.

Second, if some condition (moving mouse cursor over text or dragging text)
occurred to bad randerred text and text are renderred temporary, temporary
renderred result is good. (there may exist two kind of rendering method)

I know these debugging works are painful.
I also attempt to investigate this problem. But i have not much time.

Mozilla is the greatest browser :)

Comment 15

[Eungkyu Song]

recently, i found that this bug is reported to xfree86 bugzilla and corrected.
http://bugs.xfree86.org/show_bug.cgi?id=649

thanx.

Comment 16

[Isaac Hwak Han]

Closing bug as WFM per comment 15, because it's not mozilla bug.