2

We have an internal application that includes a bunch of custom fonticons. The application only works on the latest version of chrome, so we don't need to worry about compatibility issues. In our sass, we have:

@font-face {
  font-family: 'fonticons';
  src: url('../assets/fonts/fonticons.eot?5066');
  src: url('../assets/fonts/fonticons.eot?5066#iefix') format('embedded-opentype'),
  url('../assets/fonts/fonticons.woff2?5066') format('woff2'),
  url('../assets/fonts/fonticons.woff?5066') format('woff'),
  url('../assets/fonts/fonticons.ttf?5066') format('truetype'),
  url('../assets/fonts/fonticons.svg?5066#fonticons') format('svg');
  font-weight: normal;
  font-style: normal;
}

This seems like overkill. I would like to avoid using and creating unnecessary font files. And the following appears to work just as well:

@font-face {
  font-family: 'fonticons';
  src: url('../assets/fonts/fonticons.woff2?5066') format('woff2');
  font-weight: normal;
  font-style: normal;
}

If I do this, then I can remove the woff, eot, and ttf files, making the build process simpler and faster. Generating the fonts is not currently automated and that is my goal here. I have two questions:

  1. Is there any reason not to do this?
  2. Which version of the fonts should I keep? woff, woff2, ttf, eot?
Andrew Eisenberg
  • 28,387
  • 9
  • 92
  • 148
  • 1
    Modern answer based on it being the end of 2016: WOFF, possibly with WOFF2 if you need to serve the font piece-wise or the brotli compression that WOFF2 uses for your particular font makes enough of a difference over the deflate compression that WOFF uses. All the other formats are either obsolete, or plain not for web content, as per the above-linked SO question. – Mike 'Pomax' Kamermans Nov 22 '16 at 19:07
  • 1
    Nice! Thanks. This is a duplicate question. – Andrew Eisenberg Nov 22 '16 at 19:08

0 Answers0