275951 - View source force Japanese encoding even meta tag and chosen from menu tell otherwise

Status: RESOLVED INCOMPLETE

(Core Graveyard :: GFX: Mac, defect)

Description

[Janus]

When viewing source the page always rendered as a Japanese encoded page.  I
don't know precisely which one but the those are Japanese characters in place of
non English characters.

Even the page specified otherwise in meta tag or I chose correct encoding in
view menu, it still does not help.

It happens on both Firefox 1.0 and Camino 0.8.2.  I confirm that Camino 0.8.1
does not have this problem.

Btw, in gmail and yahoo mail web page, part of the contents in emails are
sometime rendered as Japanese while the rest are rendered correctly.  I don't
know whether this is related but it also appear since Camino 0.8.2. Switching
encoding does not help as well.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Not a layout issue; sending to intl.  Note that this also worksforme with a
current trunk Mozilla build, so it sounds like an issue in the UI of the apps in
question (Mozilla explicitly passes the page charset to view source).

Comment 2

[Simon Montagu :smontagu]

If Chinese appears as Japanese, it is more likely a font issue than an encoding
issue. I think Layout: Fonts and Text was the right place for this.

Boris, when you say it works for you, what do you mean exactly?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I mean that the text in the page and the text in viewsource (the part of the
source that's actually rendered as text, in other words) use identical-looking
characters over here.

Comment 4

[Simon Montagu :smontagu]

(In reply to comment #2)
> I think Layout: Fonts and Text was the right place for this.

or maybe GFX:Mac. It may well be dependent on bug 159809.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not sure why I was added to the CC list :-) but FWIW, in Camino 2005012508
(v0.8+) NB I see the same thing as comment 3.  

Under Camino 0.8.2, it looks like the *page* was being displayed in a Japanese font.

However, both the characters and the fonts used in the *view source* are
identical in 0.8.2 and the 0.8+ NB.  Moreover, the characters in the mouseover
and img name attributes of the source match the (graphic) characters of the
buttons (again both Camino branch and trunk).

So for Camino this appears to be worksforme also, unless there's some preference
difference in play.  My CJK fonts are set to the current Moz-Mac defaults.

Comment 6

[Janus]

Attachment: My prefs.js file

Honestly, I have never looked inside gecko's source code deeply.  However, this
is my prefs.js file and I didn't use a .css file for styling.  I hope this help
showing the source of the problem.  Thanks for all you guys' and gals' effort.

Comment 7

[Jungshik Shin]

I can't reproduce the problem (Mac OS 10.3.7 with Korean at the top followed by
English). Both FF 1.0 and Camino 0.8.2 work just fine. (I can read Chinese
characters and understand most of the stuff in the page :-))

I changed the font setting for zh-TW and zh-HK to match yours and it just worked
fine. I don't have DFStd so that I left alone monospace font, but I set serif
and sans-serif to LiHei Pro(儷黑 Pro) and LiSong Pro(儷宋 Pro)

Comment 8

[Jungshik Shin]

It's DFSongStd you specified for monospace that is causing this problem.
DFSongStd is a Windows truetype font distributed by HKSAR.[1] It's very likely
that it doesn't have any Mac platform cmap(PID=1). Currently, Mac GFX can't
recognize the true repertoire of a truetype font without Mac platform cmap
(Safari has no problem) because it still relies on old rendering APIs. This is
related to (if not a dupe of) bug 254585. 

[1] http://glyph.iso10646hk.net/chinese/download_001.html (go all the way down
and there's a download link)

Comment 9

[Jungshik Shin]

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

Comment 10

[Janus]

Thanks a lot, Mr. Shin.