Mozilla seems to get the wrong font encoding under certain circumstances. I'm using truetype fonts, and have verified this with "Georgia" and "Lucida Sans Unicode". I noticed that the "middot" entity appears as an uppercase sigma sign. (I attach a test page). Despite the font preferences set to use those fonts with an iso-8859-15 encoding, this always happens. Some investigation turns up that sigma is the corresponding code point for middot in the windows-cp1255 encoding, which is the first one in an alphabetical list of encodings that those truetype fonts support. (but even weirder, I've removed that codepage from the fonts.dir and fonts.scale files, and still the problem occurs.) I've verified with Opera and Encompass that this doesn't seem to be an artefact of my font serving setup. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020320, build 2002032004
Assignee: asa → yokoyama
Component: Browser-General → Internationalization
Keywords: fonts, testcase
QA Contact: doronr → ruixu
cc firstname.lastname@example.org The test case seems work fine with me on RH7.2 when using lucida sans unicode ttf no matter I set the default charset to iso-8859-15 or not.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I should note that the ttf font is being served by the X server: if I try the same thing with the builtin FreeType support then I get the right result. However, I prefer to use X alone for fonts. I have reproduced this problem on another box, a pretty fresh install of debian sid on a powerpc. (I also meant microsoft-cp1255 not windows-cp1255 as i wrote above)
On the advice of the Debian maintainer, I tried a tarball from mozilla.org rather than the Debian Mozilla, and the problem did not occur. Therefore this is starting to look like it might be a Debian-specific bug.
OK, found the issue. It's related to running the libgdkxft hack. "unset LD_PRELOAD" before running Mozilla makes things work just fine, even though I lose the antialiasing.
Assignee: yokoyama → shanjian
reporter, this could be a bug in your x window font setting. do the following xlsfonts |egrep Georgia
I will attach the result of xlsfonts | egrep -i Georgia >fonts.txt As I said above, though, the culprit seems to be the libgdkxft hack. But I guess there must be a few people running this.
reporter, Could you "setenv NS_FONT_DEBUG=3d" and attach the console output here?
Status: NEW → ASSIGNED
Created attachment 77718 [details] font debug output as requested here's the debug output you requested. i'm no expert, obviously, but i did notice this-- from prefs.js: user_pref("font.name.serif.x-western", "microsoft-georgia-iso8859-15"); despite this the last message in the debug seems to indicate iso8859-1 version was loaded...
shanjian is no longer working on mozilla for 2 years and these bugs are still here. Mark them won't fix. If you want to reopen it, find a good owner first.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
Mass Reassign Please excuse the spam
Assignee: shanjian → nobody
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
WONTFIX X core fonts bug
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 9 years ago
Resolution: --- → FIXED
Comment 17 does not indicate that this has actually been fixed. Changing the resolution to match that comment.
Resolution: FIXED → WONTFIX
You need to log in before you can comment on or make changes to this bug.