Converting and Rendering Web Fonts to Base64 - Keep Original Look

Converting and rendering web fonts to base64 - keep original look

In the Font Squirrel Expert options, make sure to set the 'TrueType Hinting' option to 'Keep Existing'. Either of the other options will cause the TrueType instructions (hints) to be modified, which will in turn affect the rendering of the font.

Alternatively, if you're happy with the rendering of the font directly from GWF, you can just take that file and do the base64 encoding yourself. In OS X or Linux, use the built-in base64 command in Terminal/shell:

$ base64 myfont.ttf > fontbase64.txt

For Windows, you'll need to download a program to encode in base64 (there are several free/Open Source tools available). Copy the contents of that file, then use in your CSS as:

@font-face {
    font-family: 'myfont';
    src: url(data:font/truetype;charset=utf-8;base64,<<copied base64 string>>) format('truetype');
    font-weight: normal;
    font-style: normal;
}

(Note that you may need to make some adjustments to the various @font-face info to match your particular font data; this is just an example template)

Converting webfonts to base64 removes original font line-heights

The issue is with Font Squirrel as they discussed in github. While generating in their http://fontsquirrel.com/tools/webfont-generator, enabling to No Adjustment for Vertical Merics:(in Expert) fixes the issue.

Issues with embedded icon fonts as base64

Apparently, FontSquirrel was not including my glyphs in the resultant base64.
I am unsure if I missed an option, but I solved this by just simply using base64 on WSL(bash) on the ttf font file and replacing the base64.

Can I convert embedded base64 encode font to a font file?

Copy the base64 encoded part and convert it. There are many ways to do that.

Linux

base64 -d base64_encoded_font.txt > font.woff

Mac OS X

openssl base64 -d -in base64_encoded_font.txt -out font.woff

WIndows

Go to http://www.motobit.com/util/base64-decoder-encoder.asp and paste the text. Choose "decode the data from a Base64 string (base64 decoding)" and "export to a binary file".

Why are CSS-inlined (base64-encoded) webfonts rendered with a delay?

(putting this together into an answer so people don't have to read through the endless comments)

Unexpectedly, this is unrelated to the browser, rather it is about how Twitter includes the style sheet.

Basically, a cookie named "goth" determines whether the font style sheet is injected in a blocking or non-blocking way.

In-depth explanation

In the first load (without cookies) of a Twitter page, the font style sheet is asynchronously injected (that is, in a non-blocking way) and a cookie named "goth" is set¹.

In subsequent requests which send the goth cookie, the font style sheet is served in a blocking way, in the form of a <link rel="stylesheet"> in the <head> of the document.

To see this by yourself, follow these simple instructions:

In Chrome, open view-source:https://twitter.com/simevidas
Open the DevTools (F12) -> "Resources" tab -> Cookies -> twitter.com, delete the goth cookie.
Hit reload (F5). As your request headers did not include a goth cookie, the font style sheet (gotham-narrow-v3.css) is not present in the document's head, rather it is in a hidden HTML-encoded JSON string (pic). It will be injected asynchronously via JavaScript later.
Check your cookies in the DevTools Resources tab again -- just reloading the view-source page was enough to set the goth cookie again for me, but in case you don't have the goth cookie just open a Twitter page.
Now with the goth cookie set, reload the view-source page again. You will notice that the font style sheet (gotham-narrow-v3.css) is now included via a <link rel="stylesheet"> inside the document's head (pic). This one is loaded before the first render, as <link>ed CSS style sheets are render-blocking.

And of course, hard-refreshing (Ctrl/Cmd+F5) will still send the cookies and load the font style sheet in the blocking manner.

¹: Initially, I believed this was supposed to be some sort of lazy loading with feature detection, but I've tested it on Firefox 3.5 (which does not support WOFF webfonts) and Firefox 3.0.13 (which does not support webfonts at all) and both are having the goth cookie being set.

As the cookie is actually a session cookie (is discarded once the browser is closed), it is more plausible that the first asynchronous-injection is done to speed up the first render, and subsequent requests assume that the font style sheet is already cached and inserts it in a blocking way to prevent flash-of-unwebfont'ed-content (a more specific form of FOUC which I just made up).

I haven't made it through the minified JS to be sure of that, but feel free to edit this answer or comment if you manage to.

And yes, this is highly localized topic which probably won't help many people, I've just decided to put it all together in a clear and concise answer just so those who are interested in this topic don't have to venture into the endless comments in the question.

stylus.url() base64 encodes woff2 font

Reading through the sourcecode for stylus.url() I found the mimes option. Which I haven't found documented anywhere. I can set which mime types I want to base64 encode by setting that option:

stylus(str)
    .set('filename', __dirname + '/css/test.styl')
    .define('url', stylus.url({
        mimes: {
            '.gif': 'image/gif',
            '.png': 'image/png',
            '.jpg': 'image/jpeg',
            '.jpeg': 'image/jpeg',
            '.svg': 'image/svg+xml'
        }
    }))
    .render(function(err, css){

    });

Converting and Rendering Web Fonts to Base64 - Keep Original Look