This is what I have: http://agents.jeneth.com/versions/new/
The <div class="hr"></div> looks perfect in IE, but the decorative font for the 'e' in the center of the line doesn't look so decorative in any other browser. It's just an 'e'.
Here's a codepen with the code: http://codepen.io/carolemagouirk/pen/ElxnD
I was trying to find an easy way to make a nice horizontal rule without a bunch of code. I read that <hr> is treated wildly different by different browsers so, I decided to go with a div.
I hope I'm missing something obvious and easy to fix.
Have you defined something like this..
#font-face {
font-family: 'nymphetteregular';
src: url('Nymphette-webfont.eot');
src: url('Nymphette-webfont.eot?#iefix') format('embedded-opentype'),
url('Nymphette-webfont.woff') format('woff'),
url('Nymphette-webfont.ttf') format('truetype'),
url('Nymphette-webfont.svg#nymphetteregular') format('svg');
font-weight: normal;
font-style: normal;
}
Here, I have defined it as nymphetteregular after this declaration, then one can use this in css as a font..
make sure your website have source of the files .. if you don't have one.. you may find it here.
Note: I am not sure if its allowed to use commercially. Please verify if not using personally.
I am sure this will solve the problem.
declare your #font face rules first before you use them
Related
Is it possible to load an external font via inline CSS?
Note: I'm not talking about using an external CSS file with a #font-face definition, but rather something like the following:
<h1 style="font-family:myfont;
src:('http://example.com/font/myfont.tff')">test</h1>
Is it possible loading an external font with inline css? NOT with an external CSS file [....].
Yes, you can base64 encode a font or fonts as shown in this article from Stephen Scaff and drop them into a style block in your page to avoid the external request.
It may also be possible to use this technique in the way you describe if the browser you're using supports it.
<style>
#font-face {
font-family: 'PT Sans';
font-style: normal;
font-weight: normal;
src: local('PT Sans'), local('PTSans-Regular'),
url(data:application/font-woff2;charset=utf-8;base64,d09GRgABAAAAAHowABMAAAAA+OAA) format('woff2');
}
#font-face {
font-family: 'PT Serif';
font-style: normal;
font-weight: normal;
src: local('PT Serif'), local('PTSerif-Regular'),
url(data:application/font-woff2;charset=utf-8;base64,d09GRgABAAAAAIQYABMAAAAA/MAA) format('woff2');
}
</style>
Every modern browser supports WOFF2, so you should probably use that and only that for the foreseeable future. Also, this technique will improve your page speed scores, but will degrade performance overall (even for first page loads), unless you're only base64-encoding critical page assets (e.g. glyphs of the font shown above the fold) and asynchronously load the rest.
Performance-wise your best bet right now is to use Brotli compression and pipe the webfont stylesheet down with HTTP/2 Server Push.
You cannot include a #font-face rule in a style attribute (which is “inline CSS” in the most narrow sense). By the HTML 4.01 specification, you cannot include such a rule inside the body element at all (“inline CSS” in a broader sense, which includes style elements). But in practice it is possible.
In practice, if you include a style element inside body, it will be processed by browsers just as if it were in the syntactically correct place, i.e. inside the head element. It even works “backwards”, effecting elements appearing before it.
You can even make this approach – which should be used only if you cannot change the head – formally correct as per HTML5 CR. It allows a style element at the start of any element with flow content as its content model. Current browsers ignore the scoped attribute.
Update: the following is not relevant any more, since the validator bug has been fixed.
However, there is a bug in the W3C Markup Validator and in validator.nu: they disallow style at the start of body. To overcome this bug, and to make your document validate in addition to being valid, you can use an extra div element:
<body>
<div>
<style>
/* your #font-face and other CSS rules go here */
</style>
<!-- your document body proper goes here -->
</div>
</body>
No, not that I know of. You will need to declare this kinds of things on a <style> block or an external CSS file.
Though if you want something like this, it's very probable you're doing it wrong.
If you use #font-face, you should be able to do something like this:
CSS
#font-face {
font-family: 'RalewayThin';
src: url('fonts/raleway_thin-webfont.eot');
src: url('fonts/raleway_thin-webfont.eot?#iefix') format('embedded-opentype'),
url('fonts/raleway_thin-webfont.woff') format('woff'),
url('fonts/raleway_thin-webfont.ttf') format('truetype'),
url('fonts/raleway_thin-webfont.svg#RalewayThin') format('svg');
font-weight: normal;
font-style: normal;
}
Make sure to include the fonts - the above example has placed all of the fonts in a relative-path directory to the css file.
HTML
<h1 style="font-family:RalewayThin,Helvetica, sans-serif;">
You should be able to find free web-based #font-face fonts here.
We're changing a font on our site from FontA to FontB. Seems simple enough. The problem is is that FontA is hardcoded everywhere, and even in places that we can't easily access (content that we're pulling in from external databases has this font hardcoded, etc.). What I'd like to do is something like this:
#font-face {
font-family: 'FontB', 'FontA';
src: url('fontB.eot');
src: url('fontB.eot?#iefix') format('embedded-opentype'),
url('fontB.woff') format('woff'),
url('fontB.ttf') format('truetype'),
url('fontB.svg#fontB') format('svg');
font-weight: normal;
font-style: normal;
}
So both FontA and FontB use the same font. That way, all the legacy hardcoded content that uses FontA will start using FontB instead, and all future content will just use FontB. Is declaring multiple font-family legal and valid? Will it work cross-browser for browsers that use #font-face? If this won't work, I can just declare two #font-face, so it's not a huge deal. I'm just wondering if it's possible.
Unfortunately, you'll have to make do with two separate duplicate #font-face rules. The syntax for the font-family descriptor, unlike the font-family property, does not permit more than one family, so the syntax you have is invalid.
Attempting to specify it in two declarations just causes the latter to override the former like you would expect in a style rule, meaning the following:
#font-face {
font-family: 'FontA';
font-family: 'FontB';
...
Is equivalent to:
#font-face {
font-family: 'FontB';
...
Chrome 26.0.1410.64m on Windows 8 has problems rendering WebFonts. It is a known problem and a solution is to first serve the svg version of the font instead of the woff version. It fixes the anti-aliasing and makes font look pretty again.
The downside of this method is the weird rendering inside the element inside select inputs.
I added a jsfiddle to see it in action : http://jsfiddle.net/4mSpv/6/.
The CSS is as simple as it can be.
#font-face {
font-family: 'Montserrat';
src: url('https://raw.github.com/louh/website/master/fonts/montserrat-regular-webfont.svg#montserratregular') format('svg');
font-weight: 400;
font-style: normal;
}
select {
font-family: 'Montserrat', sans-serif;
}
I remove the local installation of a font and noticed an other windows 7 computer doing the same. Anyone knows what is going on with chrome? (IE, Firefox, Safari all render fine)
PS: Other browser fonts not included in JSFiddle to filter out the problem and each browser have their own quirks (not allowing font-size etc) but render the text fine
There is no way to solve this problem.
This is NOT a Regression issue and is existing from M24.
I submitted a bug report and it Weird character rendering in option menu
As automaticoo stated, it is a known issue with Chrome. However, you can workaround the issue with a technique mentioned in the selected answer for this post: Google Webfonts Render Choppy in Chrome on Windows.
#media screen and (-webkit-min-device-pixel-ratio:0) {
select {
font-family: Arial; /* standard font */
}
}
That way you can use whatever font you want for browsers that still work, and replace it with a generic HTML font for Chrome.
So, I was actually looking for an answer for this, and I stumbled upon this question. I noticed this bug still exists today ( I just met it, such a happy meeting... ). Now I only found 1 solution, which is placing the svg font last in the #font-face declaration (this also means including all other formats). The only problem is that, when you for exampling try fixing the font rendering (to make it all smooth and stuff) you'd actually put the svg first.
Here are some examples to demonstrate it
1: SVG font last, no crisp font, options are displayed right
#font-face {
font-family: 'OpenSansLight';
src: url('../font/OpenSans-Light-webfont.eot');
src: url('../font/OpenSans-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('../font/OpenSans-Light-webfont.woff') format('woff'),
url('../font/OpenSans-Light-webfont.ttf') format('truetype'),
url('../font/OpenSans-Light-webfont.svg#open_sanslight') format('svg');
font-weight: normal;
font-style: normal; }
So as you can see, the options in the select box show just fine, but the font really isn't that crips, just look at "Register" (you might notice this better in comparison with my second example)
2: SVG font last, crisp font, stupid options in select
#font-face {
font-family: 'OpenSansLight';
src: url('../font/OpenSans-Light-webfont.eot');
src: url('../font/OpenSans-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('../font/OpenSans-Light-webfont.svg#open_sanslight') format('svg'),
url('../font/OpenSans-Light-webfont.woff') format('woff'),
url('../font/OpenSans-Light-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal; }
Now you will see that the font is a lot more crisp but the select is really stupid.
I suggest adding another font-face with the svg last just for select's. This will keep your fonts crisp throughout the website but display the options just fine.
Is it possible to load an external font via inline CSS?
Note: I'm not talking about using an external CSS file with a #font-face definition, but rather something like the following:
<h1 style="font-family:myfont;
src:('http://example.com/font/myfont.tff')">test</h1>
Is it possible loading an external font with inline css? NOT with an external CSS file [....].
Yes, you can base64 encode a font or fonts as shown in this article from Stephen Scaff and drop them into a style block in your page to avoid the external request.
It may also be possible to use this technique in the way you describe if the browser you're using supports it.
<style>
#font-face {
font-family: 'PT Sans';
font-style: normal;
font-weight: normal;
src: local('PT Sans'), local('PTSans-Regular'),
url(data:application/font-woff2;charset=utf-8;base64,d09GRgABAAAAAHowABMAAAAA+OAA) format('woff2');
}
#font-face {
font-family: 'PT Serif';
font-style: normal;
font-weight: normal;
src: local('PT Serif'), local('PTSerif-Regular'),
url(data:application/font-woff2;charset=utf-8;base64,d09GRgABAAAAAIQYABMAAAAA/MAA) format('woff2');
}
</style>
Every modern browser supports WOFF2, so you should probably use that and only that for the foreseeable future. Also, this technique will improve your page speed scores, but will degrade performance overall (even for first page loads), unless you're only base64-encoding critical page assets (e.g. glyphs of the font shown above the fold) and asynchronously load the rest.
Performance-wise your best bet right now is to use Brotli compression and pipe the webfont stylesheet down with HTTP/2 Server Push.
You cannot include a #font-face rule in a style attribute (which is “inline CSS” in the most narrow sense). By the HTML 4.01 specification, you cannot include such a rule inside the body element at all (“inline CSS” in a broader sense, which includes style elements). But in practice it is possible.
In practice, if you include a style element inside body, it will be processed by browsers just as if it were in the syntactically correct place, i.e. inside the head element. It even works “backwards”, effecting elements appearing before it.
You can even make this approach – which should be used only if you cannot change the head – formally correct as per HTML5 CR. It allows a style element at the start of any element with flow content as its content model. Current browsers ignore the scoped attribute.
Update: the following is not relevant any more, since the validator bug has been fixed.
However, there is a bug in the W3C Markup Validator and in validator.nu: they disallow style at the start of body. To overcome this bug, and to make your document validate in addition to being valid, you can use an extra div element:
<body>
<div>
<style>
/* your #font-face and other CSS rules go here */
</style>
<!-- your document body proper goes here -->
</div>
</body>
No, not that I know of. You will need to declare this kinds of things on a <style> block or an external CSS file.
Though if you want something like this, it's very probable you're doing it wrong.
If you use #font-face, you should be able to do something like this:
CSS
#font-face {
font-family: 'RalewayThin';
src: url('fonts/raleway_thin-webfont.eot');
src: url('fonts/raleway_thin-webfont.eot?#iefix') format('embedded-opentype'),
url('fonts/raleway_thin-webfont.woff') format('woff'),
url('fonts/raleway_thin-webfont.ttf') format('truetype'),
url('fonts/raleway_thin-webfont.svg#RalewayThin') format('svg');
font-weight: normal;
font-style: normal;
}
Make sure to include the fonts - the above example has placed all of the fonts in a relative-path directory to the css file.
HTML
<h1 style="font-family:RalewayThin,Helvetica, sans-serif;">
You should be able to find free web-based #font-face fonts here.
I have tried numerous things, including clicking on ALL of the questions related to my question (there were tons!) and tried all of their "solutions" but none worked for me. I tried wrapping the .eot file in a conditional IE statement but that didn't work either. Somebody said that #font-face won't work in Firefox if your not hosting the file on your own server... Or something like that. Anyway, go here to see the comparison between all other browsers vs Firefox. Please don't bash! I really did try every solution Google and stackoverflow had to offer. (Keep in mind that this is a Tumblr theme, and all files/images must be hosted via Tumblr's uploader .)
Thanks in advance!
Also, here is the code I have been using:
<!--[if IE]>
<style>
#font-face {
font-family: 'S';
src: url('http://static.tumblr.com/ctwb3zj/5bTlflus9/zegoelight-u-webfont.eot');
}
</style>
<![endif]-->
<style>
#font-face {
font-family: 'S';
src: url('http://static.tumblr.com/ctwb3zj/5bTlflus9/zegoelight-u-webfont.eot');
src: local('S'),
local('S'),
url('http://static.tumblr.com/ctwb3zj/n4Zlfluv6/zegoelight-u-webfont.ttf')
format('truetype'),
url('http://static.tumblr.com/ctwb3zj/ovQlfluz3/zegoelight-u-webfont.svg#font')
format('svg');
url('http://static.tumblr.com/ctwb3zj/1AJlfluwz/zegoelight-u-webfont.woff')
format('woff');
}
</style>
I tried going to about:config in Firefox and toggling security.fileuri.strict_origin_policy to false but it didn't work. Plus I need a way so all users who view my theme or use it to be able to view the font as well, and that is set to true by default.
Edit:
Here is the solution:
Cross domain workaround
Firefox does not like cross domain embedding.
Earl, I hate to be one to tell you this but your problem isn't with your #font-face rule. At least it wasn't when I checked out your site. When you use CSS font-family you need to make sure there is a comma between each different font in your chosen stack.
Your h6 selector was:
h6 {font-size:36px; font-family: 'S' sans-serif;}
It should be:
h6 {font-size:36px; font-family: 'S', sans-serif;}
Give this a try and I think it will work out for your. Just make sure all of your font-family stacks have commas in between multiple fonts. Firefox is a bit more strict with parsing technically incorrect CSS; Firefox just ignores it. That appears to be why you are having a problem, not your #font-face.
I'm not completely convinced by your #font-face rule. Can you copy the following and see what (if any) difference it makes? Just to clean things up.
#font-face {
font-family: 'S';
src: url('http://static.tumblr.com/ctwb3zj/5bTlflus9/zegoelight-u-webfont.eot');
src: local('☺'),
url('http://static.tumblr.com/ctwb3zj/n4Zlfluv6/zegoelight-u-webfont.ttf')
format('truetype'),
url('http://static.tumblr.com/ctwb3zj/ovQlfluz3/zegoelight-u-webfont.svg#font')
format('svg');
url('http://static.tumblr.com/ctwb3zj/1AJlfluwz/zegoelight-u-webfont.woff')
format('woff');
}
That just cleans a couple of minor things up. I'd also suggest changing your font name to something other than "S"; "Zegoe Light", for example.
Ivo Wetzel is correct from your comments though, this may be an issue with the way Tumblr serves up media with unknown file extensions.
I've had a similar problem, it worked everywhere, but not in Firefox4 on a Mac. I declared the #font-face-Stuff inside another #media block (only loading fonts for non-mobile devices) - and that's what caused the error.
This didn't work:
#media sth... {
#font-face {
...
}
}
This did work:
#font-face {
..
}
#media sth... {
}