Overriding @font-face src URL?

26
votes

We are using FontAwesome with Bootstrap. However, when we try to use FA with our custom minifier, it attempts to load the fonts from a relative path, which returns a 404, due to the way the minified URL structure is setup.

So we figured the best way to fix this was to add an additional CSS file to our minify list that would override the @font-face src URLs that FontAwesome's font uses. We basically just copied the @font-face definition from FontAwesome, and specified absolute URL locations.

However, now what happens is our correct URLs load the fonts AND the originally specified URLs from the FontAwesome CSS are attempted (resulting in the same 404 errors as before).

Are we doing something wrong, or is there really no way to override the @font-face src URLs so that 'upstream' definitions are totally ignored?

2
cssfont-awesome
Can you post some code? - David Starkey
Is the web page loading and using the correct fonts? - rvidal
I have discovered the issue and will post it as a separate answer... ultimately it was a typo! Thanks for the feedback, as posting the code (as @DavidStarkey asked) was what ultimately led me to discover the problem! - Mason G. Zhwiti
I take it back, even with the fixed definition of @font-face, it's not working properly. - Mason G. Zhwiti
@rvidal To answer your question, the webpage loads properly, and the Font Awesome glyphs are showing up correctly. So the only issue is just that the browser is making 3 additional requests that it doesn't need to make, each of them resulting in 404s as they don't exist where it's trying to hit. - Mason G. Zhwiti

2 Answers

16
votes

Simple override the font-family of the base CSS class:

.fa {
  font-family: 'FontAwesome2' !important;
}

Then, paste/include and edit the font definition:

@font-face {
  font-family: 'FontAwesome2';
  src: url('//host.domain/yourpath/fontawesome-webfont.eot?v=3.1.0');
  ...
  font-style: normal;
}
3
votes

UPDATE: The "solution" below did not actually work... we did in fact have a typo, but in subsequent testing, this was still not the root cause, and we are still facing the issue.

The solution is to be VERY CAREFUL when overriding the @font-face, making sure to provide all of the same formats used in the original @font-face. Otherwise it appears the browser sees it as a different definition, and will try to download files referenced in both, rather than overriding it.

So here is the definition in FontAwesome's CSS, which is referenced first.

@font-face {
  font-family: 'FontAwesome';
  src: url('../font/fontawesome-webfont.eot?v=3.1.0');
  src: url('../font/fontawesome-webfont.eot?#iefix&v=3.1.0') format('embedded-opentype'), 
    url('../font/fontawesome-webfont.woff?v=3.1.0') format('woff'), 
    url('../font/fontawesome-webfont.ttf?v=3.1.0') format('truetype'), 
    url('../font/fontawesome-webfont.svg#fontawesomeregular?v=3.1.0') format('svg');
  font-weight: normal;
  font-style: normal;
}

And when we tried to override, we accidentally dropped the "format('svg')" definition:

@font-face {
  font-family: 'FontAwesome';
  src: url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.eot?v=3.0.1');
  src: url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.eot?#iefix&v=3.0.1') format('embedded-opentype'),
    url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.woff?v=3.0.1') format('woff'),
    url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.ttf?v=3.0.1') format('truetype');
  font-weight: normal;
  font-style: normal;
}

Once we added the format('truetype') definition, we no longer experienced the additional hits that had resulted in 404s.