654065 - Wrong glyphs for White Smiling Face and Black Smiling Face

Status: RESOLVED DUPLICATE of bug 560472

(Firefox :: General, defect)

Description

[Julian D. A. Wiseman]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Unicode characters White Smiling Face (#9786) and Black Smiling Face (#9787) are shown with the wrong glyphs in unformatted <p>s.

Example attached.

Reproducible: Always

Comment 1

[Julian D. A. Wiseman]

Attachment: HTML of ☺ and ☻ with various formattings

Comment 2

[Julian D. A. Wiseman]

Attachment: PNG of ☺ and ☻ with various formattings

Comment 3

[Julian D. A. Wiseman]

That HTML test case works fine in Opera 11.01; Safari 5.0.5; and Chrome 11.0.696.57. So the root cause of the problem isn’t necessarily at the level of the operating system. In particular, it isn’t caused by a lack of fonts.

Comment 4

[Thomas Ahlblom]

Works for me with GNU/Linux with a new clean profile:
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Also did a fast test with Wine 1.0.1 and that also worked for me:
Mozilla/5.0 (Windows NT 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Comment 5

[Julian D. A. Wiseman]

Error seen on Firefox 4.0.1 under Mac OS X 10.6.7.

Comment 6

[Jonathan Kew [:jfkthame]]

This is dependent on your installed fonts. Those characters are not supported in the default fonts specified in your Firefox prefs, so we search the fonts available on your system to find one that does support them, and use whatever we find. If the one we find happens to have inappropriate glyphs at those codepoints, that's what you'll see.

FWIW, I don't get this problem on my OS X machine here; the smiling-face characters render nice-looking smiling-face glyphs in all the examples in your testcase.

Comment 7

[Julian D. A. Wiseman]

> This is dependent on your installed fonts.
Ahh. I have a lot of installed fonts. So it is a problem with my machine rather than a general problem. Thank you.

Is it possible to ‘trace’ Firefox to discover which font is causing the problem?

Comment 8

[Jonathan Kew [:jfkthame]]

Unfortunately, I don't think there's an easy way to do this in Firefox at the moment (unless you create a debug build and run it under gdb). That's something I'd really like to have...

However, if you use the Character Viewer palette from the OS X keyboard menu (use the Input Sources tab of the Language & Text system preferences to enable it), you can select the Smiling Face character and then look at the Font Variations to see which of your installed fonts has those rather weird glyphs at these positions.

Comment 9

[Julian D. A. Wiseman]

Thank you. The guilty party is Wewak Wide, with accomplices Wewak Regular and Wewak Narrow.

Comment 10

[Julian D. A. Wiseman]

So removal of Wewak changed the problem without fixing it. Uncey was next to die; which made the black smiles good but not the white. It wasn’t obvious which of several was causing the next problem, so I zapped Isildur High, then Maranallo (alas: quite elegant), then Torcing Away 2000. Finally, all is good. It works!

But why did I need to do this to fix Firefox, when Safari and Opera and Chrome all managed to cope without this font purge?

Comment 11

[Julian D. A. Wiseman]

Maranallo re-added to system, without breaking anything. I’m declaring victory.

Thank you all for identifying the problem. Methinks there is still a bug — works without purge in Chrome, Safari and Opera — but I recognise that the programmers might have a different opinion.

Comment 12

[Jonathan Kew [:jfkthame]]

The browser is doing what it's supposed to do, which is to find a font that can display the characters found in the page, even though the fonts that were actually specified don't support them. If some fonts have incorrect glyphs for certain Unicode characters that's not a browser bug, it's a font bug.

The basic problem is that if there are characters in the text that are not supported by the fonts specified in the page CSS, and also not supported by the preferred default fonts specified in your browser preferences, then the program doesn't really have any good basis for making a choice among whatever fonts happen to be on your system, and the result you get should be considered more-or-less arbitrary.

Having said that, I do have some thoughts about improving/optimizing our font-selection process in ways that might improve the odds here; e.g. favoring certain well-known "system" fonts - even if they're not explicitly specified in the prefs - over whatever random fonts the user happens to have installed. (See bug 560472.) The "real" solution, though, if you want proper control of the fonts used to render text, is to ensure that the stylesheets involved actually specify appropriate fonts for the content concerned.

I'm resolving this as a duplicate of bug 560472, as I think that pretty closely reflects the problem you're experiencing, and how we could improve things.

Comment 13

[Julian D. A. Wiseman]

I concur with the summary given by Jonathan Kew in comment 12, with the marking of duplicate, and with the strategy that would “improve the odds”. Somehow Opera Chrome Safari avoided this problem: surely Firefox can as well.

Thank you again for showing me how to fix it on my machine.