439118 - Certain HTML entities (e.g. shapes and arrows) not rendering properly

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Gabriel Mansour]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0

When viewing a page with arrow HTML entities (e.g. ←, →, etc.) or certain shapes (e.g. ♥, ♦, ♣, ♠), the glyphs do not get rendered (or they're "invisible", i.e. there's a gap where it should belong, but it's not there). They used to show up fine in Firefox 2, but in FF3 (up to RC3), they stopped showing up.

I'm using a Mac, but this issue could very likely exist on other platforms as well.

I've tried using both UTF-8 and iso-8859-1 (Latin1) charsets, and the problem still exists in both cases. I'm no expert on this, but I'm assuming this issue probably exists in other (if not all) character sets too.

Here's a list of entities that don't render properly (there could possibly be more; these are just the ones I was able to find). This also applies to the numbered entities, but I'll use the named entities for convenience's sake:
  ↓
  ↔
  ←
  →
  ↑
  ♣
  ♦
  ♥
  ♠
  ≡
  ∩

I would very much appreciate it if you could fix this before the final release of Firefox 3 (and I'm sure all your other users would too), since getting HTML entities to show up right is very important. Thanks.

Reproducible: Always

Steps to Reproduce:
1. Go to a page that contains the any of the character entities listed. (e.g. http://www.cookwood.com/html/extras/entities.html)
2. Scroll down where the above listed entities (or jump to that section using Quick Find)
3. Notice that those entities don't get rendered.
Actual Results:  
The entities are not rendered as the glyphs/symbols they represent. There's a gap where it should belong, but the symbol isn't there.

Expected Results:  
The entities should be rendered as the actual glyphs/symbols they represent.

Comment 1

[Dave Townsend [:mossop]]

Everything on that age displays fine for me.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008061302 Minefield/3.1a1pre ID:2008061302

Comment 2

[Gabriel Mansour]

I'm not sure why it's not showing up properly for me. I've disabled all my installed add-ons to ensure they aren't causing any conflicts, and those entities still aren't showing up. I've included a screen capture of what I'm seeing if that helps.

http://skitch.com/gabriel/pwp8/entities-arrows

Comment 3

[Gabriel Mansour]

So, I tried creating a new user account and then launching Firefox, and the entities seemed to show up fine... so maybe something happened to my Firefox Profile during the upgrade from Firefox2 to Firefox3?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Sounds like the symptoms of a buggy font.  Maybe one of your chosen fonts in preferences is a font that claims to have those characters, but it really has blanks instead?

Comment 5

[Gabriel Mansour]

I'm currently using Helvetica as my default font, and I'm not so sure that's the case, since the symbols show up right when I'm in Safari.

Also, I tried creating a brand-new Firefox profile so I'd be using Firefox's default settings, and then visited the "XHTML entity reference page" <http://www.cookwood.com/html/extras/entities.html>, and they still don't show up, and in that case the default font is Times, so I'm not sure it's a font-specific thing. I've also tried using some other common web fonts as my default (Arial, Trebuchet, Verdana), but that didn't make anything better.


Would there be anything else I might be able to do that could possibly fix this?

Comment 6

[John Daggett (:jtd)]

(In reply to comment #3)
> So, I tried creating a new user account and then launching Firefox, and the
> entities seemed to show up fine... so maybe something happened to my Firefox
> Profile during the upgrade from Firefox2 to Firefox3?

I would dig around in ~/Library/Fonts, most likely there's something funky there if the entities are displaying just fine for a new user account (which will have an empty ~/Library/Fonts).

You can also probably track this down with FontBook.

1. Open FontBook
2. Edit > Special Characters...
3. Set the View dropdown to All Characters
4. Find the character for one of the entities (the Unicode codepoint info displays when you select and hover over a character)
5. Toggle Character Info and Font Variation to show all the fonts that claim to have glyphs for this character

My guess is the bad font will pop out when you do this.

Comment 7

[tamera]

I just installed Firefox 3 on a new Mac, so no old prefs remained. The default font is Times, and this error occurred - I noticed as I use ↑ and ↓ on my site. Changing the default font to Arial fixed it, but this still seems like a Firefox bug and not a font bug, as it seems odd that my fonts would be corrupt on a brand new machine.

Comment 8

[Denis de Bernardy]

Confirming the bug for larr/rarr entities in Camino 2 beta-2, MacOSX 10.5.

Bug occurs with:

- Verdana, Helvetica, Sans-Serif
- Trebuchet MS, Tahoma, Helvetica, Sans-Serif
- Tahoma, Helvetica, Sans-Serif
- Monotype Corsiva, Courier, Monospace
- Georgia, Times, Serif

But not with:

- Times New Roman, Times, Serif
- Courier New, Courier, Monospace
- Arial, Helvetica, Sans-Serif

It's font-related indeed. However, I'd like to highlight that, until I installed Camino 2 beta-2, from Camino 1.6.7, things were rendering fine. So it's probably related to the Gecko engine in FF3/Camino2.

Comment 9

[Hiram]

I too would like to confirm this bug in Firefox 7.0.1. I tested the bug on the URL listed above (http://www.elizabethcastro.com/html/extras/entities.html#shapes) with the fonts listed in Comment #8.

Using the troubled fonts in the list, many of the arrows and shapes do not show up properly; they are just blank spaces. I have also encountered the issue when using Web fonts (on other sites).

HOWEVER, if I change the "font-weight" (via FireBug) from the default 400 to 300, the arrows suddenly become visible (in the default weight, no less).

This leads me to believe that the issue is related to the way the font rendering is being handled, but I am not too sure about how this works.

Comment 10

[Jonathan Kew [:jfkthame]]

Please try the fontinfo addon[1] and check which font is actually being used when these characters appear as blanks (select the blank space, right-click, and choose "Show Fonts in Selection"). It may not be the font specified via CSS or prefs, if the character is not actually supported by those fonts, in which case fallback comes into play.

[1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/

Comment 11

[Hiram]

(In reply to Jonathan Kew (:jfkthame) from comment #10)
> Please try the fontinfo addon[1] and check which font is actually being used

Great suggestion! This really helped to shed some more light on the issue. When the character is not supported by the current font, it resorts to a backup font, however, it doesn’t use the same backup font for all characters.

Let's say, for example, that the page font is "Georgia" (which doesn't support the arrows I mentioned in Comment #9). Firefox will substitute the font for "Symbol" (which supports all the arrows) on one line, and a different font (that DOESN'T support the arrows) on the next line. This still results in alternating rows of visible symbols.

If I change the font-weight to 300 (like I also mentioned in Comment #9), Firefox will still use "Symbol" on one line, but the other lines use "Hiragino Sans GB W3" (which also supports the arrows). My guess is that changing the font-weight forces Firefox to look for a better alternative.

Why doesn't Firefox use "Symbol" for all the arrows? Or why doesn't it substitute the font for another one that is known to support all (or most) Unicode characters (like Arial)?

I'm really confused as to what's going on behind the scenes.

Comment 12

[Peter Magyari (Desktop QA)]

Since this is a very old report and I cannot reproduce the issue myself I'm going to close it for now.

However, if you can still reproduce this, feel free to re-open the report.