I've been supplied an OTF font from a client and not following the web font trends for a while now in terms of support, if I remember correctly, the pattern used for cross browser support for web fonts would look like this:
#font-face {
font-family: 'AvalonBook';
src: url('Avalon-Book-webfont.eot');
src: url('Avalon-Book-webfont.eot?#iefix') format('embedded-opentype'),
url('Avalon-Book-webfont.woff') format('woff'),
url('Avalon-Book-webfont.ttf') format('truetype'),
url('Avalon-Book-webfont.svg#AvalonBook') format('svg');
font-weight: normal;
font-style: normal;
}
Probably because I've been so used to copying and pasting the above code and modifying it to my needs, I haven't got the chance to actually understand the reasons behind this pattern.
This begs the question, is OTF even supported in the browsers? What browsers and versions? Also why is it not in the above #font-face declaration if it is supported?
Thanks.
Related
Yes, I know there is an identical question and many similar ones asked and answered here and many resources online discussing this issue. None have helped in my case so I am taking desperate measures.
I am trying to load web fonts using the #font-face syntax. Here's the code (I am loading more than one but the syntax is identical):
#font-face {
font-family: 'MyFont';
src: url('../typography/MyFont-Book.eot');
src: local('?'),
url('../typography/MyFont-Book.eot?#iefix') format('embedded-opentype'),
url('../typography/MyFont-Book.woff') format('woff'),
url('../typography/MyFont-Book.ttf') format('truetype'),
url('../typography/MyFont-Book.svg') format('svg');
font-weight: normal;
font-style: normal;
}
As stated in the title, it's not working in ie8 (works fine in ie9 and 10 and obviously all other browsers). I have tried several things.
In the beginning, I got the error "CSS3111: #font-face encountered unknown error" and I found this site. I followed the steps, changed the names of the fonts and regenerated them. Apparently, that must have fixed something because I am not getting that error anymore. I also see the fonts being loaded correctly in the network sniffer, all coming back with a clean 200.
I have cleared my cache (several times) but still no dice. The font still doesn't show up on the page. Instead, the fallback "Arial" font is displayed, messing up the layout because it's way bigger than the web font.
Anyone got a clue what the eff might be going on?
I have several projects which load fonts down to IE8. They have an almost identical definition to the one you have but, without the src : local(?).
#font-face {
font-family: 'MyFont';
src: url('../typography/MyFont-Book.eot');
src: url('../typography/MyFont-Book.eot?#iefix') format('embedded-opentype'),
url('../typography/MyFont-Book.woff') format('woff'),
url('../typography/MyFont-Book.ttf') format('truetype'),
url('../typography/MyFont-Book.svg') format('svg');
font-weight: normal;
font-style: normal;
}
#font-face {
font-family: 'advertisingmediumregular';
src: url('fonts/advertisingmedium-webfont.eot');
src: url('fonts/advertisingmedium-webfont.eot?#iefix') format('embedded-opentype'),
url('fonts/advertisingmedium-webfont.woff') format('woff'),
url('fonts/advertisingmedium-webfont.ttf') format('truetype'),
url('fonts/advertisingmedium-webfont.svg#advertisingmediumregular') format('svg');
font-weight: bold;
font-style: normal;
}
the text disappear in google chrome when I wrote this code can anyone help me please
I already had the same problem. I was adviced to generate my web fonts with a tool like the FontSquirrel webkit fonts generator. Upload your font's files and download back a all browsers compatible pack. Include the css in your HTML page in addition to yours. And it seems to work since I do like this. I hope it will be the same for you.
Are .eot fonts supported via #font-face datauri on IE8?
Are datauris on IE8 supported only for images?
I know about the 32KB limitation. My base64 representation of the .eot font does not exceed this limit.
My css declaration goes something like this:
#font-face {
font-family: 'MyFont';
src: url(data:font/opentype;base64,B1QAAB9TAAACAAI.....);
font-weight: normal;
font-style: normal;
}
Data URIs should not be any issue for this...
...It should work, I have my .eot web font that works in all browsers (even IE7) by using this...but I also use WOFF/TTF/SVG also to support the rest of the browsers
#font-face {font-family: 'AllyourBase';
src: url('/fonts/allyourbase.eot');
src: url('/fonts/allyourbase.eot?#iefix') format('embedded-opentype'),
url('/fonts/allyourbase.woff') format('woff'),
url('/fonts/allyourbase.ttf') format('truetype'),
url('/fonts/allyourbase.svg?#allyourbase') format('svg');
font-weight: normal;
font-style: normal;
}
Make sure IIS has the correct mime type on your local/web server (EX: application/vnd.ms-fontobject for .eot files).
Lastly....I doubt Datauri is the cause but to play it safe try without data/base64 and see if it does anything
Here's an example #font-face CSS rule:
#font-face {
font-family: 'DroidSerifBoldItalic';
font-weight: normal;
font-style: normal;
src: url('DroidSerif-BoldItalic-webfont.eot');
src: url('DroidSerif-BoldItalic-webfont.eot?#iefix') format('embedded-opentype'),
local('Droid Serif Bold Italic'), local('DroidSerif-BoldItalic'),
url('DroidSerif-BoldItalic-webfont.woff') format('woff'),
url('DroidSerif-BoldItalic-webfont.ttf') format('truetype');
}
Don't you think, the following #font-face CSS rule is better? (As you can see, the browsers, in this case even IE, can first check if the font is available on the user's computer, before downloading it.)
#font-face {
font-family: 'DroidSerifBoldItalic';
font-weight: normal;
font-style: normal;
src: local('Droid Serif Bold Italic'), local('DroidSerif-BoldItalic');
src: url('DroidSerif-BoldItalic-webfont.eot');
src: url('DroidSerif-BoldItalic-webfont.eot?#iefix') format('embedded-opentype'),
url('DroidSerif-BoldItalic-webfont.woff') format('woff'),
url('DroidSerif-BoldItalic-webfont.ttf') format('truetype');
}
Are there any gotchas here? If not, why isn't everyone using the latter?
From what i know about #font-face, the main fear behind using local is that the font will not be named the same on someone's desktop. You're ceding control there, and if you're wrong it'll fail. You do pose an interesting question though, and i'm not saying you're wrong. You can read more about that here and here.
ADDENDUM
Normally, it’s used as a mask to prevent unwanted http requests in IE.
The order matters because IE (at least until IE8) doesn't support the local descriptor, and placing the local descriptor right after the EOT font format prevents the older versions of Internet Explorer from downloading the other font formats (in the src declaration) as they aren't supported, and won't be used anyway.
What #BoltClock commented is true. And that's the reason why we use two local definitions -- local('Droid Serif Bold Italic'), local('DroidSerif-BoldItalic'),. The first is the normal name of the font (which is recognized by all browsers except Safari), and the latter is the PostScript name of the font which is required by Safari (at least on Mac / OS X systems).
To avoid issues like two different fonts (mostly on two different OSs) having the same name, some simply use local('☺').
Check the site:
http://tinyurl.com/caljnqb
I'm using font-face:
#font-face {
font-family: 'SegoeUI';
src: url('{site_url}themes/site_themes/agile_records/fonts/segoeui.eot?') format('eot'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeui.woff') format('woff'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeui.ttf') format('truetype'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeui.svg#SegoeUI2') format('svg');
font-style: normal;
font-weight: normal;
}
#font-face {
font-family: 'SegoeUIBold';
src: url('{site_url}themes/site_themes/agile_records/fonts/segoeuib.eot?') format('eot'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeuib.woff') format('woff'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeuib.ttf') format('truetype'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeuib.svg#SegoeUI3') format('svg');
font-style: normal;
font-weight: bold;
}
#font-face {
font-family: 'SegoeUIItalic';
src: url('{site_url}themes/site_themes/agile_records/fonts/segoeuii.eot?') format('eot'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeuii.woff') format('woff'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeuii.ttf') format('truetype'),
url('{site_url}themes/site_themes/agile_records/fonts/segoeuii.svg#SegoeUI4') format('svg');
font-style: italic;
font-weight: normal;
}
And there is the problem with output in Firefox, Chrome and Opera browsers. Everything looks OK on IE. Font looks sharp. Why does it happens? Maybe I'm doing something wrong?
different browsers render fonts differently.
The solution I've used in the past is to re-arrange the order in which the fonts are supplied to the font face, based on which browser is rendering the page. Usually my problems are in the earlier versions of IE so I've used a separate style sheet that offered the .woff file before the ttf file. Because some browsers can only read certain font type files but can read both and stop looking after finding one that works. If you re-arrange them you may be able to use one that renders a bit better.
If you end up using separate css you can use the $_SERVER arrays http_user_agent property to set a font css based on the browser.
googles Droid font is a font that renders funny sometimes depending on the browser as well so researching that might help you find other approaches.
It seems that there are a few tricks in ordering properly each format
See for example
This is the Fontspring bulletproof syntax modified to serve the svg
first:
#font-face {
font-family: ‘MyWebFont’;
src: url(‘webfont.eot’);
src: url(‘webfont.eot?#iefix’) format(‘embedded-opentype’),
url(‘webfont.svg#svgFontName’) format(‘svg’),
url(‘webfont.woff’) format(‘woff’),
url(‘webfont.ttf’) format(‘truetype’);
}
From http://www.fontspring.com/blog/smoother-web-font-rendering-chrome
You may also take care of using the proper mime type for WOFF font , as of http://www.w3.org/TR/WOFF/#appendix-b
application/font-woff
to ensure proper handling by the browser