For example, in this #fontface declaration that I found here, the CSS has a format('truetype') indicating that it's a .tff. But in my program, with and without doesn't make a difference.
font-face {
font-family: 'DroidSerif';
src: url('DroidSerif-Bold-webfont.ttf') format('truetype');
font-weight: bold;
font-style: normal;
}
format is for helping the browser to understand the font format if it can't infer it automatically.
Modern browsers will just like at the font extension (.ttf in your case) or possibly the mime-type and infer it automatically without the need to explicitly specify the format.
Probably the only reason you would need it today is if you're using a non-standard file extension, or no extension at all, or possibly not using the correct mime-type.
Related
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.
In /src/site/globals/site.variables, I can see how you can define google fonts, which get imported from when you compile. What I am interested in is defining my own custom fonts where I will supply my own font files.
I can’t find docs on how to do it. While I know how to do it in CSS, I am wondering if it is already built-in in this framework but I have simply missed it.
Thanks!
I don't believe there is a built-in way to do it. Here's how I did it.
I used the standard #font-face css rule. I then placed it in the site.overrides file. I am using a less variable (#font-path) to simplify my file paths.
#font-path: '../../fonts';
#font-face {
font-family: 'my-font';
src: url('#{font-path}/my-font.woff') format('woff'),
url('#{proxima-prefix}my-font.woff2') format('woff2');
font-weight: normal;
font-style: normal;
}
You'll have to make sure that the font files are served up appropriately by your server.
The above can be turned into a less mixin based on your usage as well.
A good resource on #font-face and formats: https://css-tricks.com/snippets/css/using-font-face/
A great answer on how to use different font weights/styles: https://stackoverflow.com/a/10046346/7681976
I've came across a problem with custom font i use for my website.
So i use following CSS for text.
font-family: "Open Sans",Helvetica,Arial;
font-weight:600;
As website is built in my native language, i have to use UTF-8 symbols, that doesn't seems to be included in Open Sans, so they are being shown in Helvetica instead, but the problem is that they have more weight.
Is there any possible solutions to set font-weight parameter to normal, if fallback font is being used?
You could define a new #font-face for each font you want.
#font-face {
font-family: 'mainFont';
src: url(/*Link to Open Sans*/);
font-weight: 600;
}
#font-face {
font-family: 'secondaryFont';
src: local('Helvetica');
font-weight: 400;
}
#font-face {
font-family: 'tertiaryFont';
src: local('Arial');
font-weight: 600;
}
Then you'll end up with font-family: 'mainFont', 'secondaryFont', 'tertiaryFont'; which should get the desired results.
Unfortunately, there is no way to define fallback font specific styling using CSS alone.
As such you may want to attempt to work out the font being used, then apply a style as a result, see here for one method which works out the width resulting from applying a font to an element before 'best guessing' which it is.
That said, it is essentially a hack/workaround.
Otherwise, you could look into implementing a method to identify where the symbols are and then wrap them in styles span tags, again this would be a fairly dirty hack as opposed to a clean solution.
I believe MichaelM's solution won't work. What you can do is specify the font files using the "postcript name" that you can find in various font info sites online.
font-family: "Open Sans",Helvetica-Light;
unfortunately specifying font-weight: 600 might result in undefined behavior. some browser might try to make it bolder, some might just leave it be.,
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.