Some icons don't render properly

[monemihir]

Hi,

If I use the icons from the ui.html file that comes with the ZIP all icons render properly. But the same icons don't render on my website.

I am developing using .NET MVC 4.

I even tried download the font from www.entypo.com with the same effect. It just shows me random characters instead of actually rendering the icon. If you see the attached image below...the random characters are actually supposed to be the 'download' icon. As you can see the 'trash' icon renders just fine.

Here is my HTML

This happens in all browsers irrespective of versions.

I am also using FontAwesome icons in the same website and they render properly. So I doubt there is an issue in the MIME mapping of the font files.

Please help

Cheers, Mihir

[qrczak]

Maybe there are conflict between entypo and fontAwesome. Try for a while remove fontAwesome css and see what will happen. Maybe the names of the classes was overwritted

[monemihir]

But the CSS files referenced are completely different i.e pages that use Gumby styling do not have reference to the FontAwesome CSS/Font files. They are even stored in a different location. Also the fact that the font IDs are different for Entypo and FontAwesome means that there should be no conflicts...surely??

Here is the directory structure:

-- Content ---- Font -------- Bootstrap ------------ bootstrap font files -------- Entypo ------------ entypo font files -------- FontAwesome ------------ fontawesome font files ---- Css -------- gumby.css/fontawesome.css/bootstrap.css ---- JS ---- Img

[rsadwick]

Did you check your MIME types in IIS to make sure the fonts are being served up? Also check the network tab in Chrome or Fiddler to see if you're getting any 404s on your fonts. Anything?

[richardsweeney]

I had some issues with IIS recently with a site that was accessible both with and without the www. IIS refused to serve the web fonts to the domain without www. 1 okt 2013 kl. 12:48 skrev Ryan Sadwick notifications@github.com:

Did you check your MIME types in IIS to make sure the fonts are being served up? Also check the network tab in Chrome or Fiddler to see if you're getting any 404s on your fonts. Anything?

— Reply to this email directly or view it on GitHub.

[monemihir]

@rsadwick Yes, I do have the MIME types for WOFF, EOT, TTF, SVG set up properly and I know they work because without them even the FontAwesome icons don't work. So the fact that I have the FontAwesome icons working properly means that the MIME mapping should be fine I think

@richardsweeney I am not even at the IIS stage yet. I am running the website through VS2012 Development Server and/or IIS Express. Where are you saying to add the www. ? In the CSS files?

[richardsweeney]

@monemihir I don't really know anything about windows servers, but on a recent project where the client was using ISS we had an issue with an icon font whereby the path to the font files was www.website.com but the site was also accessible via website.com (that is to say, without the www).

When visiting the site without www, the icon font would not show. Presumably IIS thought it was a different domain and was all worried about XSS, so it didn't allow the font to be downloaded.

SO:

The path to the fonts was www.example.com/fonts/somthing.woff

So visiting www.example.com the fonts were delivered

Visiting example.com the fonts were never downloaded

Not sure if this will help you, but it's a handy gotcha to know about!

[rsadwick]

@monemihir: check your Web.config as well:

<staticContent>
     <mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />
</staticContent>

[danhere]

I don't believe it has anything to do with the MIME type. Can you double check that the file in question is UTF-8 and not anything else. You can also attempt to force UTF-8 by putting a snowman in a comment above the icon list. http://unicodesnowmanforyou.com/

[chambaz]

Hey @monemihir, did you have any luck with this? Ensuring your editor is set to UTF-8 when editing the file.

[monemihir]

@rsadwick Yep I already have that in my web.config

@danhere When I check the page info from Firefox/Chrome/IE it does show my that it is being rendered with encoding as UTF-8, so I am not sure why I would need the snowman thingi

@chambaz Unfortunately not yet. The thing is that I am not even touching the files with an editor. I have just done a vanilla download and added the files to my VS2012 project.

I will make a nightly build and deploy at http://mihirmone.dyndns.org/nightly/webextras so you guys can have a play around with it. I removed the icons from the current nightly deploy since I couldn't get them working. So just check tomorrow, I'll do another nightly later today (AEST).

[izeau]

Using your demo I fiddled around with the DOM and modified the “Stable” download button to add the extra classes (namely icon-left and icon-download). It seems you did NOT deploy the font in the right directory, since Gumby tries to load the resource http://mihirmone.dyndns.org/nightly/webextras/Content/font/entypo.woff which is not found on your server. However, http://mihirmone.dyndns.org/nightly/webextras/Content/font/entypo.ttf is present.

On your Bootstrap 3 demo, your WOFF FontAwesome font file isn’t loaded as well, but it falls back to the TTF (which is why you can see the FontAwesome icons).

So this has nothing to do with your encoding, which is fine by the way.

Now, judging by the number of Google results, IIS seems to have an issue with WOFF, sending a 404 HTTP error even when the resource should be found. This is typically fixed by inserting the snippet you gave:

<staticContent>
    <mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />
</staticContent>

Can you triple check? It seems you have an error in your web server configuration here. So you can either fix it, or do a quick’n’dirty hack in Gumby’s CSS to replace the WOFF font by the TTF one.

PS: please note that the WOFF file format has been standardized by the W3C and has now MIME type application/font-woff.

[monemihir]

@izeau @chambaz Can you please check http://webextras.apphb.com. I have confirmed that the font files are now being served up properly. However, the issue still persists.

I have also noticed that only icons who have unicode content specified in the CSS file work. So icons like Note or Mail will work, but icons like Music or Flashlight won't render properly.

PS: sorry I clicked the wrong button which closed the issue, so I have reopened it.

[izeau]

Your gumby.css is broken. Try a new fresh version, or check if your assets pipeline (if you use one) doesn’t break it.

.icon-download.icon-left a:before,
.icon-download.icon-right a:after {
  content: "📥";
  height: inherit
}

Please explain how you solved your WOFF files problem, it might help other! :+1:

[Motifsky]

Not sure if this is related to your font issue, but many of the specific icons your having issues with, e.g. Music and Flashlight seem to overlap with something that happened to me today. I just upgraded to Mavericks this AM and started getting compass compile errors indicating bad ASCII characters I am using CodeKit 1.9 (8348). As we already have the @charset "UTF-8" character set in place and still was receiving the errors. I followed the errors to certain icons in the _entypo.scss file and some other mystery characters in two other files. _grid.scss and _forms.scss.

In the entypo.scss file as each font is mapped like this

$entypo-icon-note: \266a; $entypo-icon-picture: \1f304;

for all of the fonts the start with /1f they displayed on github preview and in sublime text3 as an 'icon' instead of as an alpha numeric code.

When I replaced the icon with the correct code (thank you team gumby for adding the comment with the correct codes!), the compile error went away. For the other two files that were throwing errors in CodeKit... _grid.scss was a line the had nothing but an ending bracket, which I deleted the line and simply retyped a new end bracket. The other was a comment line in _forms.scss, I simply deleted the line. Now the entire compass project compiles without issue.