2006-08-16 19:18:33 Masayuki Shibatani:
It looks Safari uses 'Hiragino Kaku Gothic Pro W6' instead of 'W3' defined in css to render the page.
Attached style.css file doesn't define 'Hiragino Kaku Gothic Pro W6'. (Actually they defined "ヒラギノ角ゴ Pro W3"(Hiragino Kaku Gothic Pro W3. We also see "Hiragino Kaku Gothic Pro" defined in style.css but it doesn't define W3 or W6. I’m not sure it will cause the problem.)
See attached screen shot. I marked red underline to point problematic characters. The blue underline indicates likely problematic.
The actual URL was http://rblog-tech.japan.cnet.com/0061/2006/08/apple_9899.html.
* STEPS TO REPRODUCE
1. Install Leopard 9A241 English primary as Japanese Country Region and Kotoeri as default keyboard.
2. Open attached archive file.
3. Print it as PDF file (The PDF file is also attached.)
4. Select problematic text and copy & pate into TextEdit.
5. Prove the fonts in the text.
Actual: Safari uses different font randomly in Japanese.
Expected: Shouldn't change font randomly and don't use undefined fonts.
2006-08-16 19:24:56 Masayuki Shibatani:
There is no problem on London 8J134.
2006-08-16 20:38:42 Yosuke Kurita:
I'm not sure who's at fault, but WebKit team might be able to pinpoint the cause - <rdar://problem/4672333>. I hope it's not us...
2006-08-19 13:15:48 Julio Gonzalez:
Sending to WebKit for more info.
2006-08-24 18:48:11 Stephanie Lewis:
This is a regression from Safari 2.0.4. Happens in Leopard 9A250.
2006-08-29 10:23:48 Alice Liu:
Safari BRB Reviewed - we need to test with TOT on tiger.
2006-12-21 16:14:38 Darin Adler:
I'm pretty sure this is simply a case where a font doesn't cover all the characters. We then use these AppKit calls:
to find a suitable font. We've long been told that these calls can give different results on different systems, so this might not be a regression at all.
This does not occur on Tiger when running ToT, closing.