Closed Bug 426042 Opened 16 years ago Closed 16 years ago

[Trunk] Camino can't render Japanese Fonts correctly

Categories

(Camino Graveyard :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: suishouen, Unassigned)

Details

Attachments

(5 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9pre) Gecko/2008033001 Camino/2.0a1pre (like Firefox/3.0pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9pre) Gecko/2008033001 Camino/2.0a1pre (like Firefox/3.0pre)

Camino can't render Japanese Fonts correctly.
Screenshot and test case coming soon.

Reproducible: Always
Attached image Screenshot
Attached file Test Case for Trunk
Attached file Test Case for Branch (obsolete) —
What is the problem, exactly ?
On trunk you have to use 
font-family: 'Hiragino Mincho Pro'
and
font-family: 'Hiragino Kaku Gothic Pro'
(and 'Hiragino Maru Gothic Pro' for rounded gothic)

without the W3, which points to a font-face ('normal' font-weight), not a family.

And for backwards compatibility with Gecko 1.8, you can do 
font-family: 'Hiragino Kaku Gothic Pro', 'ヒラギノ角ゴ Pro W3', sans-serif;
Attached file test case per comment 4 (obsolete) —
Here is a test case as described in comment 4, Gecko trunk only.
uploaded the wrong file... sorry for the spam
Attachment #312596 - Attachment is obsolete: true
Comment on attachment 312589 [details]
Test Case for Branch

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<!--<link rel="stylesheet" href="./tx.css" type="text/css" media="all">-->

<style type="text/css">
html[lang] {font-size:100%; color:#222; background:#fefefe;}
body {font: 1em/normal sans-serif;margin:1em 5%;}

div[class] {float:left; width 6em; padding:.2em; border: 1px dotted #000; margin: 0 3%;}
div[class] div {margin: 0 0 1em; font-size:24px;}
</style>
<title>test</title>
</head>
<div>
<div style="font-family: Osaka ;">
あいうえお<br>
かきくけこ<br>
さしすせそ<br>
たちつてと<br>
</div>
<br>
<div style="font-family: 'ヒラギノ明朝 Pro W3' ; ">
あいうえお<br>
かきくけこ<br>
さしすせそ<br>
たちつてと<br>
</div>
<br>
<div style="font-family: 'ヒラギノ角ゴ Pro W3' ;">
あいうえお<br>
かきくけこ<br>
さしすせそ<br>
たちつてと<br>
</div>
<br>
<div style="font-family: 'ヒラギノ丸ゴ Pro W3' ;">
あいうえお<br>
かきくけこ<br>
さしすせそ<br>
たちつてと<br>
</div>

</body>
</html>
Attached file Test Case for Branch
I've mistaken.
sorry for the spam.
Attachment #312589 - Attachment is obsolete: true
(In reply to comment #4)
> What is the problem, exactly ?

Spacing between characters rendered by Trunk is very different than Branch.
Rendering Osaka Fonts is significant difference.
(In reply to comment #10)
> Spacing between characters rendered by Trunk is very different than Branch.

Yes, the text system is completely different on trunk, but being different doesn't make it wrong. The summary of this bug says that it can't render them correctly--what exactly is incorrect?

And does Minefield display differently for you?
(In reply to comment #11)
> And does Minefield display differently for you?

Latest Minefield displays the same as Camino trunk does.
And it is different than branch.
Branch is the same as Safari 3.1.
The spacing is slightly different between Gecko 1.9 and Gecko 1.8 - for the better, I think, I hope ! Gecko 1.8 text-rendering isn't exactly good in the modern typographical world of OS X, and it tends to smash down fonts, especially East-Asian ones.

With the Hiragino fonts, there is no difference between Gecko 1.9 and Safari
As far as the Osaka font is concerned, there is a difference with Safari. Safari always uses the monospaced one (Osaka-mono, Osaka−等幅), where as Gecko makes a difference.
If you paste you text snippet in Textedit, rtf format, and select Osaka - regular, and paste a second time, and select 0saka - regular-mono, you'll see that Gecko renders it exactly the same as TextEdit.

Also, there are differences in line-height handling and font fallback between Safari/WebKit and Gecko 1.9, depending on lang group. Those are (filed) bugs in WebKit.
Thanks, philippe.
Now, I know.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Resolution: WONTFIX → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: