New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embed font files as base-64 #294

Closed
davegandy opened this Issue Jun 20, 2012 · 28 comments

Comments

Projects
None yet
@davegandy
Member

davegandy commented Jun 20, 2012

What do folks think about base-64 encoding all of the font files and including them directly in the LESS and CSS? There are apparently implementations that will also work in IE7.
http://venodesigns.net/2010/06/17/you-got-your-base64-in-my-css/
http://stackoverflow.com/questions/1124149/is-embedding-background-image-data-into-css-as-base64-good-or-bad-practice

Advantages:

  • No messing with font path, everything could be implemented in a single css file.
  • Should be no funky cross-domain font loading issues in Firefox and others. Font files will get served in their proper format.

Thoughts?

@nextgenthemes

This comment has been minimized.

nextgenthemes commented Jun 21, 2012

I did not know that this is possible with fonts. I know this for images. Well you save a http request but the actual filesize get a little big bigger for base64. I guess it's a good idea but i know not enough about it to say this is my final opinion.

@kremalicious

This comment has been minimized.

Contributor

kremalicious commented Jun 21, 2012

I would say no. Saving 1 http request but giving users exceptionally more data than they need isn't a good approach. In the current implementation the browser makes 1 http request for the font and downloads 1 font file. If we base64 encode all the font files, users will get the data for all the different font files, not just the one their browser needs. To me, the saving of 1 http request doesn't justify this. And the initial rendering of the page will take longer because it won't start before the bigger CSS file gets downloaded. Currently the page gets rendered fast with the icons coming in afterwards.

The other problem I see is caching. If you include the fonts within the CSS they won't get cached anymore and there're some file size restrictions in place on mobile devices for cached resources, although I'm not sure if this is still valid for newer OS.

Nevertheless, this could be added to a best practice section in the docs because for some larger projects this could improve performance. E.g. when a page loads many more font files, embedding at least the icon font could be a good idea.

@replete

This comment has been minimized.

replete commented Jun 26, 2012

I don't think there is benefit in delivering much more data to everyone, to save just one HTTP request and eliminating easily-solved MIME type font issues.

You can save a request simply by including the fontawesome.css within their main stylesheet, e.g. by a LESS import, or some build-script concatenation.

@nextgenthemes

This comment has been minimized.

nextgenthemes commented Jul 13, 2012

@kremalicious Yes i agree i not taught about that this way all font files would be delivered to everyone. The usual way seems to be better because the browser just picks the font its supports and don't even loads the others.

@yannski

This comment has been minimized.

yannski commented Aug 16, 2012

However, when you host your font on Amazon S3, you have no other choice that base64 encode them (because S3 does not support the correct HTTP header for cross domain font serving). So having an example using base64 could be really nice.

@auxbuss

This comment has been minimized.

auxbuss commented Oct 11, 2012

I'm in favour. It's solved problems on some devices going this route with some other fonts.

@davegandy

This comment has been minimized.

Member

davegandy commented Jan 2, 2013

Yeah, I won't be doing this by default. If folks want to take the font into Font Squirrel, it will Base64 encode the fonts. Not a bad solution if you need it.

@davegandy davegandy closed this Jan 2, 2013

@padde

This comment has been minimized.

padde commented Feb 26, 2013

This would still be useful if you want to keep the fonts in the browser cache with a cache manifest (won't work with standard font files)

@xero

This comment has been minimized.

xero commented Apr 10, 2013

sorry to comment on a closed issue, but im working with font-awesome on the amazon cloud which is messing up font headers for firefox only (weird right?). so i tired the base64 encoding trick and it works like a charm! for thoese who are interested, i uploaded the ttf to the font-squirrel webfont-generator, selected expert mode, set the css to base64 encode, and selected a custom sub-setting with a unicode range of xf000-xf112. bam. works perfectly. but i think the css that font-squirrel sent me is a bit verbose. is there a better way to do it than....

@font-face {
    font-family: 'FontAwesome';
    src: url('../font/fontawesome-webfont-webfont.eot');
}
@font-face {
    font-family: 'FontAwesome';
    src: url(data:application/x-font-woff;charset=utf-8;base64,[BASE64_DATA_GOES_HERE]) format('woff'),
         url('../font/fontawesome-webfont-webfont.ttf') format('truetype');
    font-weight: normal;
    font-style: normal;
}

i really want to combine the two style declorations into one, but im pretty sure the order is important. also the #iefix from the base css is missing. suggestions are welcome.

@padde padde referenced this issue May 11, 2013

Closed

Cache webfonts #9

@matzke

This comment has been minimized.

matzke commented Jul 18, 2013

+1 for base64 (as optional alternative)

I would like to use fontawsome in wicked_pdf (wkhtmltopdf), where i would have to use base64 encoding.

@miere

This comment has been minimized.

miere commented Oct 8, 2013

+1 for base64 (as optional alternative)

@jedibatman

This comment has been minimized.

jedibatman commented Nov 22, 2013

To those interested I have forked the 'font-awesome-rails' gem to include an optional css file that has the font base64 encoded, for your wkhtmltopdf pdf generation needs.

https://github.com/Outcome-Engenuity/font-awesome-rails-base64

Let me know if anyone has any issues with it, or if you would like additional features.

@eduardoinnorway

This comment has been minimized.

eduardoinnorway commented Nov 13, 2014

Fonts is a pain in the ... some times, so a base64 alternative is a big +.
The so called "size increaze monster" is a drop in the air for this case and font. To let the user wait a millisecond more or less to see an icon is a better solution than to show null just because you have no means to mix with the server. So please, pritty please with sugar on top, a base64 alternative.

@antoniobrandao

This comment has been minimized.

antoniobrandao commented Feb 22, 2015

+1

@Spangenhelm

This comment has been minimized.

Spangenhelm commented Feb 23, 2015

+1 Sorry for commenting on a closed issue but having a base64 version is really useful within certains applications like for example TiddlyWiki (a single self-modifying html file that can be used on or offline. my interest for the base64 embedded fonts comes from the fact that i can store all my datas and the app itself within one single html file !)

If it is not too much work for you then we would really appreciate it !
Thank you

@adamwintle

This comment has been minimized.

adamwintle commented Feb 23, 2015

<rant>In mainland China its a real pain because the Chinese government partially blocks some website's HTTP requests. It seems like they block certain files (PDFs, fonts, .ZIP), etc and not just the entire websites. This problem isn't even consistent to one region of China either; in Beijing we can't load web fonts (from what we think is the local ISPs blocking some western web fonts) and in Shenzhen all web fonts load without a problem.</rant>

So yeah, it would be great if a reliable base64 version was included in the official repo instead of using third-party tools. This way its one less HTTP request and its all bundled into a CSS file, which makes the content of the font harder to trace.

@stef-w

This comment has been minimized.

stef-w commented Feb 23, 2015

+1

@nextgenthemes

This comment has been minimized.

nextgenthemes commented Mar 11, 2015

You can always write a script that pulls the current woff from this repo and generates a css with the base64 font in it.

Even If I not use FA any more but +1 from me for having this in the repo. Funny how much learned since 2012.

@wavded

This comment has been minimized.

wavded commented Mar 11, 2015

+1

@tobibeer

This comment has been minimized.

tobibeer commented Sep 15, 2015

I sure wish the base64 string for the woff was part of the distro, because figuring out a tool to do the conversion can be ...difficult.

@stefanct

This comment has been minimized.

stefanct commented Nov 28, 2015

+1 because it would make creating self-contained html files (e.g. with asciidoctor) way easier. i can't remember reading that argument yet...

@morganfeeney

This comment has been minimized.

morganfeeney commented Apr 24, 2016

Wouldn't this also be a good way to avoid issues with screen readers reading out the glyph character? This solution just means an icon is only that.

@tagliala

This comment has been minimized.

Member

tagliala commented Apr 24, 2016

@morganfeeney I may be wrong but this should have no effect on screen readers. Screen reader compatibility should be addressed in the docs here: http://fontawesome.io/accessibility/

@morganfeeney

This comment has been minimized.

morganfeeney commented Apr 24, 2016

What I was getting at is that you wouldn't need to add the markup to hide characters from screen readers. A CSS only solution would just rule it out completely as you wouldn't assign an icon to a character. Would it not?

@tagliala

This comment has been minimized.

Member

tagliala commented Apr 24, 2016

I don't know if embedding fonts as base64 would prevent screen readers to read glyphs. We had a discussion on accessibility at #6133 and nobody mentioned this approach.

Moreover, I'm strongly against this because embedding all formats in the .css file will force the browser to download them all (.eot/.woff//.woff2/.svg), instead of picking the most appropriate one

@ranbuch

This comment has been minimized.

ranbuch commented Sep 8, 2016

+1
I need to convert an SVG with Font-Awesome text to image. To do that I (to my understanding) need to embed inline font into the SVG, otherwise the font-face wouldn't be supported.

@alexbruno

This comment has been minimized.

alexbruno commented Jul 3, 2017

I just published an alternative solution for this problem:

https://www.npmjs.com/package/font-awesome-base64

@svyatik

This comment has been minimized.

svyatik commented Feb 14, 2018

There's one good solution for base64 fonts. You can download them async, separately from your main css file. Then you can save these base64 fonts to localStorage and apply from async JS to every page. This will give you a big boost of website loading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment