2

[REVISED]

My custom icon font is not rendering in Mobile Safari on iOS 5. I've confirmed that the problem must be with my CSS.

The font works fine on iOS 6 and on desktop versions of Safari, Chrome, Firefox, and IE9 when using the corresponding eot and woff formats generated by http://www.fontsquirrel.com

@font-face

I'm currently using the following simplified @font-face declaration (SASS):

@font-face
  font-family: 'Boundless'
  src: asset-url('boundless.ttf', font) format('truetype')
  font-weight: normal
  font-style: normal

The following HTML works (it renders the desired icon character in Mobile Safari on iOS 5.1:

<h1>&#xf0000;</h1>

However, I see a <?> glyph if I try to render it in the way that Font-Awesome does:

SASS

i.bicon-biology:before
  font-family: "Boundless"
  content: "\f0000"

HTML

<h1><i class="bicon-biology"></i></h1>

Yet Font-Awesome icons render fine on the site.

Does anyone know what might be causing this issue?

I should also add that I tried all the recommendations made here: @font-face not embedding on mobile Safari (iPhone/iPad) and none worked. This includes adding the smiley-face hack, making sure my font urls are absolute, and trying svg fonts (which shouldn't be neccessary for iOS 5 anyway).

Community
  • 1
  • 1
Adam Fraser
  • 6,255
  • 10
  • 42
  • 54
  • Just curious, why do you use such a far-out range of characters, rather than something you can see on the keyboard? – daveyfaherty Oct 10 '12 at 16:39
  • 1
    The range in question is deemed the "private use area" (PUA) of utf-8, so it's intended for this sort of thing. It gives me that warm and tingly feeling of doing the right thing semantically. One positive outcome is that screen readers won't try to read off the icons as characters. – Adam Fraser Oct 10 '12 at 20:17
  • Ah, that makes a lot of sense. I'd been wondering about this practice for a few days. Thanks for your answer. – daveyfaherty Oct 11 '12 at 08:28

1 Answers1

4

Mobile Safari apparently just doesn't like the utf-8 addresses I was using (/0f0000-/0f001e).

I edited the font to move the characters to the same positions that Font-Awesome uses (/00f000...), and presto, it works!

I also checked whether adding/removing 0's padding the left made a difference, and it works either way. There's just something about the other address range. :\

AGAIN: This is only an issue when the codes are used in pseudo element content. As you see above, &#xf0000; (and &#x0f0000;) rendered just fine when it was directly in the HTML.

Adam Fraser
  • 6,255
  • 10
  • 42
  • 54