I am trying to wait for fonts to load before rendering my web page. One suggest that converting to base64 could be the best solution by this answer. So I converted using fontsquirrel webfont generator(also chose Truetype Hinting: Keep Hinting) and used in my file as
#font-face {
font-family: "Montserrat";
src: url(...) format("woff"), url("montserrat-regular-webfont.ttf") format("truetype");
font-weight: 400;
font-style: normal;
}
But when I check on webpage, the original spacing of the font are removed.
This is before using base64
And this is after using base64
As you can see, spacing are removed, how do I prevent this ?
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.
Related
For some reason the font I'm trying to add won't add itself to my website. I'd rather not do this with an image, so is it possible the font is broken? Would it be possible to fix it with just the otf or ttf?
My code (in case I'm missing something):
#font-face {
font-family: urbanJungle;
src: url('UrbanJungleDEMO.ttf');
}
h1 {
font-family: urbanJungle;
font-size: 100px;
color: #34495e;
}
Additional details: This is in the latest Chrome, other custom fonts work.
In the network console the font is red and it says cancelled.
Live URL: http://codestack.co.uk/website/
The font was from Dafont, no extra processing applied by myself, it's in the same directory as the index page. All the relevant CSS is included.
You should use Font Squirrel font-face generator for this: http://www.fontsquirrel.com/tools/webfont-generator
Different browsers need different font formats, you only provided one. The generator will convert your font to all the formats needed and give you a CSS file too, with no hassles.
You are using only TrueType font, IE support only *.eot fonts. And you are missing a lot informations. It is always better to use font stack instead of using single font, if first font went missing css use immediate next font on the list (called font-stack).
Here is an interesting article about #font-face by Paul Irish : Bulletproof #font-face Syntax
#font-face{
font-family:MyFont;
src:url(../font/MyFont.eot);
src:local('?'),
url(../font/MyFont.woff) format("woff"),
url(../font/MyFont.otf) format("opentype"),
url(../font/MyFont.ttf) format("Truetype"),
url(../font/MyFont.svg#myfont) format("svg");
font-weight: normal;
font-size:normal;
}
body{
font-family: "MyFont", Verdana, sans-serif; /* Font stack */
}
I've been using font squirrel to generate web fonts for a while. Usually the CSS it gives is like this:
#font-face {
font-family: 'sancoale_slsf_norm_regunormRg';
src: url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.eot');
src: url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.eot?#iefix') format('embedded-opentype'),
url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.woff') format('woff'),
url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
But playing around with generating the WOFFs as base64 the outputted CSS changes to:
#font-face {
font-family: 'sancoale_slsf_norm_boldnormBd';
src: url('sancoaleslsfnormbold-webfont.eot');
}
#font-face {
font-family: 'sancoale_slsf_norm_boldnormBd';
src: url(data:application/x-font-woff;charset=utf-8;base64,d09 [BLABLABLA] =) format('woff'),
url('sancoaleslsfnormbold-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
Does anyone know why the #font-face declaration is split? - Just interested really!
Base64 is a binary-to-text encoding scheme that represents binary data in an ASCII string format.
Data URI is just a URI scheme that provides a way to include data in-line.
Basically, you’re converting the font file into a crazy long string of text that you can paste right in your font-face declaration to replace the font file source link.
The Data URI Scheme is:
data:[<mediatype>][;base64],<data>
The Base 64 source in a #font-face looks like:
src: url(data:application/x-font-woff;charset=utf-8;base64,<your base64 font>) format('woff'),
Font Squirrel's generator provides the .eot file as IE support for Base64 began with version 9 (I think).
I've found this method of font-face to have higher deliverability over Paul Irish's bulletproof method.
Fonts.css
In practice, I throw all my base64 encoded fonts (plus weight variations) inside a fonts.css file. This also includes my icon font - which I use IcoMoon's web app to build and get the base64.
Yeah, base64 adds some bulk and it sure isn't pretty, but throwing them all into a central fonts.css file reduces your requests, prevents FOUC, and seems to do a great job of getting around stupid aggressive firewalls that block font file types as default.
I actually wrote a little post on this a while back.
My guess is that this is a workaround for the differing data URI support among internet explorer versions. IE 6-7 have no support, IE 8 only supports some elements and only up to 32KB, and IE9+ supposedly works without issue. More info on Data URI support can be found over at Wikipedia and caniuse. The 'base64 CSS' option at font squirrel uses data URI encoding.
I'm using a custom icon-font using CSS3's #font-face and in older version of Google Chrome, only the unicodes are showing and are not being replace or rendered in my custom font, which shows the glyphs for those unicodes.
Here is the #font-face syntax that I am using:
#font-face{
font-family:'glyphs';
src:url('../fonts/glyphs.eot');
src:url('../fonts/glyphs.eot?#iefix') format('embedded-opentype'),
url('../fonts/glyphs.svg#glyphs') format('svg'),
url('../fonts/glyphs.woff') format('woff'),
url('../fonts/glyphs.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
Any idea why the unicodes are showing and not the symbols that are part of the icon-font?
You're possibly running into unicode-range limitations. As described here you can define in a font-face declaration which Unicode characters are covered. It could very well be that older Chrome versions only replaced Latin characters by default. You should be able to fix this by adding this to your font-face declaration:
unicode-range: U+00-FFFF;
Having said that, it could very well be that you're only having a local issue. Check in your Chrome settings, under Advanced Settings, under Web Content click Customize Fonts, then at the bottom check the current setting for Encoding. Changing its value to "Unicode (UTF-8)" could solve the issue as well.
Try switching the orders of the fonts you are loading. Some browsers, even older version of chrome, load svg fonts in weird / incomplete ways.
Try:
#font-face{
font-family:'glyphs';
src:url('../fonts/glyphs.eot');
src:url('../fonts/glyphs.eot?#iefix') format('embedded-opentype'),
url('../fonts/glyphs.woff') format('woff'),
url('../fonts/glyphs.ttf') format('truetype');
url('../fonts/glyphs.svg#glyphs') format('svg'),
font-weight: normal;
font-style: normal;
}
I may be going out on a limb here, but is it possible that the document displaying the font either a) declares a character encoding other than UTF-8 / UTF-16 (or isn't explicitly declared) or b) the html document is saved in an encoding other than UTF-8 / UTF-16?
A very common problem causing websites to display characters incorrectly is having a different declared character encoding in the HTML than the encoding used to save the HTML document. Also, the use of characters that are part of either of these encodings can create issues.
You should post the HTML code as well for us to answer better. I'm assuming you are using data-icon attribute in HTML. In that case, you should add this code after your font-face css code.
[data-icon]:before {
font-family: 'glyphs';
content: attr(data-icon);
speak: none;
font-weight: normal;
font-variant: normal;
text-transform: none;
line-height: 1;
-webkit-font-smoothing: antialiased;
}
I've had some problems with relative paths, old browsers and font-face declarations in the past: you might want to try with a fixed path (/someFolderInRoot/fonts/glyphs.svg) or a relative path under the css file-path (fonts/glyphs.svg).
Does it all work in a newer version of Chrome and other browsers?
Chrome installs updates automatically for most users, so perhaps you're making the website backwards compatible for a version nobody uses.
I want to download Google web-fonts in all formats and create a combined CSS to use them anywhere without loading them from Google servers.
I already have a php script that downloads the font files. Need only the CSS now.
As you may know the Google web-font API serves a special CSS depending on the browsers user agent.
I have a few questions about it.
Is it true that Google web-fonts get only serve one font as svg for only OS devices, I noticed this while testing a few fonts (with faked user agent). While for others there are multiple #font-face declarations but with font-weight and font-style different. Am I right to assume Google serves the SVG only for the "regular" version of the fonts not "italic, bold, book ..."
Whats the best way to combine them into one CSS, especially in regards to this combined SVG font.
You are right that Google only serves up the font for your specific user-agent. Getting them all is tricky.
You mentioned you have a PHP script for fetching the different font formats, so you may not need these two options, but I'll list them anyway:
Option 1
This article walks through the process of how to download all the different formats:
http://ijotted.blogspot.com/2012/05/download-eot-ttf-woff-formats-of-font.html
In short, you'll need to use user-agent spoofing to grab all the different formats.
Option 2
Another option would be just to grab the TTF version (since that's easy) and then head over to http://www.fontsquirrel.com/tools/webfont-generator to have them convert/generate all the other versions.
If you end up using this option, it may be useful to know that Joe Maller has put together a full download package to grab all of the TTF font files at once (though it might be a bit out of date).
Serving up with CSS
Once you have all the different versions, use a syntax like this for your CSS. This is from FontSpring's Bulletproof Font-Face Syntax.
#font-face {
font-family: 'MyFontFamily';
src: url('myfont-webfont.eot?#iefix') format('embedded-opentype'),
url('myfont-webfont.woff') format('woff'),
url('myfont-webfont.ttf') format('truetype'),
url('myfont-webfont.svg#svgFontName') format('svg');
}
That last line of course depends on whether you have an SVG font file. Which brings us to...
SVG
That first link claims:
While it's true that Google serves the SVG font format on iOS devices running version 4.2 or below, I can confirm that the SVGs are empty or broken. It's therefore true that Google no longer supports devices running iOS versions 4.2 and below. Implies, no SVG font format anymore.
I haven't been able to verify this anywhere else, however I have seen a whole lot of users complaining about SVG issues, fonts not loading... I would be inclined to ignore SVG as an option, and focus on serving up EOT/WOFF/TTF. That seems to be the most solid way of covering your bases.
Update: it appears that fontsquirrel.com can generate an SVG version. So even though Google doesn't provide SVG as a download option, you can still generate it if you really want to.
You can use base64 encoding, but it is about 30% larger than normal files (and I don't know if this url will be parsed every time you write something, so please, check it before you use it).
Or you can download it once and save it in local-browser memory and use it without downloading new version (but you still need to download these files at least one time).
With IE i can't help you. But when you're creating new #font-face rule, you can specify font-weight.
/** #1 **/
#font-face {
font-family: 'Open Sans';
font-style: normal;
font-weight: 600;
src: local('Open Sans Extrabold'),
local('OpenSans-Extrabold'),
url(http://themes.googleusercontent.com/static/fonts/opensans/v6/EInbV5DfGHOiMmvb1Xr-hnhCUOGz7vYGh680lGh-uXM.woff)
format('woff');
}
/** #2 **/
#font-face {
font-family: 'Open Sans';
font-style: italic;
font-weight: 300;
src: local('Open Sans Light Italic'),
local('OpenSansLight-Italic'),
url(http://themes.googleusercontent.com/static/fonts/opensans/v6/PRmiXeptR36kaC0GEAetxh_xHqYgAV9Bl_ZQbYUxnQU.woff)
format('woff');
}
.a {
font-family: 'Open Sans';
font-weight: 300; /** #2 used for <= 500 cos font-weights are 300 and 600 **/
}
.b {
font-family: 'Open Sans';
font-weight: 800; /** #1 used for >= 600 **/
}
Hope it'll help u.
I have generated a #font-face with FontSquirrel, and resulted these (tweaked later) rules:
#font-face {
font-family: 'CabinSketchRoBold';
src: url('cabinsketchro-boldwebfont.eot');
}
#font-face {
font-family: 'CabinSketchRoBold';
src: url('cabinsketchro-boldwebfont.woff') format('woff'),
local('?'), url('cabinsketchro-boldwebfont.ttf') format('truetype'),
url('cabinsketchro-boldwebfont.svg#CabinSketchRoBold') format('svg');
font-weight: normal;
font-style: normal;
}
Style is applied in the css file like this:
h1,h2,h3,h4,h5,h6 {font-weight:normal;font-family:'CabinSketchRoBold',Arial,sans-serif !important; }
Everithing works fine in Chrome, even in InternetExplorer, but in newer versions of Firefox, the font doesn't load. It loads in FF 3.6... o_O
I have another font, Ubuntu, loaded from Google via the JavaScript option, and that one loads ok, even on the headings, after changing
font-family:'CabinSketchRoBold','Ubuntu',Arial,sans-serif !important;
What's wrong with the declarations that makes FF ignore my local font?
EDIT: this is not only on localhost, it happens on the live site too. I have looked at other answers and tried them out, but no luck. WOFF was even base64 encoded, same result.
SOLVED: Seems that the .eot being in a separate declaration (again, FontSquirrel generated) was doing the damage. Moving it with the others solved it. Thanks Boris Zbarsky!
#font-face {
font-family: 'CabinSketchRoBold';
src: url('cabinsketchro-boldwebfont.eot?#') format('eot'),
url('cabinsketchro-boldwebfont.woff') format('woff'),
local('?'), url('cabinsketchro-boldwebfont.ttf') format('truetype'),
url('cabinsketchro-boldwebfont.svg#CabinSketchRoBold') format('svg');
font-weight: normal;
font-style: normal;
}
Your problem is that you are actually defining two separate faces of the "CabinSketchRoBold" font.
The first face is normal weight and uses .eot file for the font data.
The second face is bold weight and uses one of woff, truetype, svg, whichever is available.
Then you're styling text that's normal weight. So the first face is picked. See http://dev.w3.org/csswg/css3-fonts/#font-style-matching for the spec on this.
In particular, following the steps in that spec, in step 4 we end up a single face: the .eot one. But since the browser can't do anything with that font format, this face has no glyphs so in step 5 the browser moves on to the next family name. The other (bold) face in the "CabinSketchRoBold" family is not considered, per spec.
So the upshot is that you should either list font-weight: bold in both your rules or in neither one. Then the .eot and the other options would all be considered as sources for a single font face, not for different faces in the same family.
It looks like Chrome doesn't actually follow the spec here, unfortunately...
The latest versions of Firefox are able to show the font related errors in the tools->web developer->errors console. for example this is the error I give with a custom font:
Error: downloadable font: table 'GSUB': OpenType layout data discarded
You must have this font type for working in IE,Firefox,Chrome
#font-face
{
font-family: 'BHoma';
src: url('/public/font/BHoma.eot?#')format('eot'),
url('/public/font/BHoma.ttf')format('truetype'),
url('/public/font/BHoma.woff')format('woff'),
url('/public/font/BHoma.svg#BHoma')format('svg');
}
but you first must generate your font from this link
http://www.codeandmore.com/2011/06/font-face-kit-generator/