I am having trouble with #font-face in CSS. The font I am using looks very different in each browser.
See this example in Firefox:
And here in Chrome:
I don't know what causes this problem. I already tried to use text-rendering and I also tried changing the order of the url-properties in the #font-face declaration.
I am using Windows 7 Professional and Firefox V30.
Can somebody inform me about the reason for this issue and tell me how I could fix it?
Many thanks.
//EDIT:
This is the #font-face declaration I am using:
#font-face {
font-family: 'MyFont';
src: url('myFont.eot');
src: url('myFont.eot?#iefix') format('embedded-opentype'),
url('myFont.svg#myfont') format('svg'),
url('myFont.woff') format('woff'),
url('myFont.ttf') format('truetype');
font-style: normal;
font-weight : normal;
}
As I wrote above I already played with the order of this commands.
In my particular problem you can see this page (footer) showing the problem.
Most modern browsers use DirectWrite on Windows to render text, except for Chrome. Luckily they are implementing it now and it was recently set as the default in the latest Chrome builds. Thats the good news, the bad news is that it still has bugs and doesn't always render fonts correctly. You can see if this is a problem by disabling it to see if that fixes the issue.
To disable DirectWrite type chrome://flags/ in the address bar and find the option labeled 'Disable DirectWrite'. If this does fix the issue, you should log a bug with the examples of your text rendering so that it can be fixed.
You can read more about it on the Chrome blog at http://blog.chromium.org/2014/07/chrome-37-beta-directwrite-on-windows.html.
This seems to be a font issue since all opportunities that work for others do not affect the problem. Switching to a other font is the only solution in this moment.
I had the same problem and fixed it with the follow small thing
color:#505563;
font-family: 'Dosis', sans-serif;
text-shadow: 0px 1px 2px #eeeeee;
In other words just add text shadow and it will work fine, play with the correct colors as an artist. Try this
text-shadow: 0px 0px 1px #eeeeee;
Browsers have accessibility features that override CSS. Make sure the text or page settings are not zooming. See https://support.mozilla.org/en-US/kb/font-size-and-zoom-increase-size-of-web-pages
If nothing else this will at least rule out one variable, making debugging more effective.
Related
I have an extremely strange issue that occasionally happens when viewing a site in Chrome. You can see the issue happening in the image below:
It looks like an overflow / word-break / word-wrap CSS issue, but it definitely isn't. I know this because if I change the font to a standard font like Helvetica in Chrome's dev console, it sort's itself out and goes back to normal, like below:
If I change it back to the font-face type, it then all works ok! It is a very strange problem this. It only occasionally happens, and I haven't seen it happen in any browser other than Chrome. It seems like Chrome is struggling to calculate the length of the words using the font or something. It happens for every element on the page as well, not just the paragraphs in the images above.
This is the CSS for the font-face:
#font-face {
font-family: 'gotham_lightregular';
src: url('/ekmps/shops/lm_boutique/resources/Other/gotham-light-webfont.eot.txt');
src: url('/ekmps/shops/lm_boutique/resources/Other/gotham-light-webfont.eot.txt?#iefix') format('embedded-opentype'),
url('/ekmps/shops/lm_boutique/resources/Other/gotham-light-webfont.svg.txt#gotham_lightregular') format('svg'),
url('/ekmps/shops/lm_boutique/resources/Other/gotham-light-webfont.ttf.txt') format('truetype'),
url('/ekmps/shops/lm_boutique/resources/Other/gotham-light-webfont.woff.txt') format('woff');
font-weight: normal;
font-style: normal;
}
EDIT
This is the site I am working on. But I'm not sure if it will help as the problem isn't currently occuring, it's hard to catch it when it's happening.
I was having the same issue and found it to be related to this style block that I had in my css document:
* {
/* optimize text for legibility */
text-rendering: optimizeLegibility;
}
I was able to solve it by deleting the offending css and then adding this bit of jQuery code:
$(function() {
$("body").css("text-rendering", "optimizeLegibility");
});
I think there must be a rendering issue in Chrome that causes this, but applying the optimizeLegibility style after the DOM is ready seems to fix the problem.
I use the Google Webfonts service on my website and rely heavily on it. It renders fine on most browsers, but in Chrome on Windows it renders especially bad. Very choppy and pixelated.
What i have found out so far is that Chrome requires the .svg format font to be loaded first. The font i am using however, called Asap, was only available in .woff. I converted it to .svg using a free online service, but when i added that to my stylesheet (before the .woff), it didn't change anything.
I've also tried:
-webkit-font-smoothing: antialiased;
text-shadow: 0px 0px 0px;
Hoping that either would help the text render more smoothly.
Right now i've run out of ideas and i would hate to change fonts. Does anyone have an idea how i can solve this problem? I've been using the Adobe Browserlab to test the rendering, seeing as how i only own a mac. The link to the site is: www.symvoli.nl/about
Thanks in advance!
Edit April 11th, 2013:
Chrome 35 Beta seems to have finally solved this issue:
Update August 2014
Google finally fixes this issue in Chrome 37 natively!!!. But for historical reasons I won't delete this answer.
Problem
The issue is created because chrome actually cannot render TrueType fonts with correct anti-aliasing. However, chrome still renders SVG files well. If you move the call for your svg file up in your syntax above the woff, chrome will download the svg and use it instead of the woff file. Some tricks like you propose work well, but only on certain font sizes.
But this bug is very well known to the Chrome developer team, and has been in fixing since July 2012. See the official bug report thread here: https://code.google.com/p/chromium/issues/detail?id=137692
Update Oct 2013 (Thanks to #Catch22)
Apparently some websites may experience intermittent spacing issues when rendering the svg. So there is a better way to skin it. If you call the svg with a media query specific to Chrome, the spacing issues disappear:
#media screen and (-webkit-min-device-pixel-ratio:0) {
#font-face {
font-family: 'MyWebFont';
src: url('webfont.svg#svgFontName') format('svg');
}
}
First approach solution:
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');
}
Further reading:
CSS properties that affect type rendering
Smoother Web Font Rendering in Chrome for Windows
How to Bulletproof #font-face Web Fonts
-webkit-text-stroke: 0.5px;
use it only on large text, since it will affect your page performance.
A fix has been suggested here by calling the .svg file first, http://www.adtrak.co.uk/blog/font-face-chrome-rendering/
I've tried a number of solutions and finally came up with one that works with newer versions of Chrome which don't fall for changing the order of the files:
Essentially, I moved the TTF file into a Mozilla specific section.
#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');
}
#-moz-font-face {
font-family: 'MyWebFont';
src: url('webfont.ttf') format('truetype');
}
Answer by Tom & font-spring didn't do it for me for some reason. This fix by Sam Goddard did though :
After experimenting myself, I stumbled across what appears to be a decent, very easy fix for this issue. It appears that Chrome utilises the .svg file in the #font-face kit, and doesn’t like being called last. Below is the standard call for #font-face using CSS:
// font-face inclusion
#font-face {
font-family: 'font-name';
src: url('path-to-font/font-name.eot');
src: url('path-to-font/font-name.eot?#iefix') format('eot'),
url('path-to-font/font-name.woff') format('woff'),
url('path-to-font/font-name.ttf') format('truetype'),
url('path-to-font/font-name.svg') format('svg');
font-weight: normal;
font-style: normal;
}
As can be seen in the example, the .svg file comes last in the list of called URLs. If we amend the code to target webkit browsers, then tell them to solely utilize the .svg file.
// Usage
#media screen and (-webkit-min-device-pixel-ratio:0) {
#font-face {
font-family: ‘font-name';
src: url(‘path-to-font/font-name.svg’) format(‘svg’);
}
}
It could just be the font your using "asap" doesn't render all that well at certain sizes. I changed the size of your h1 from 3.5em to 50px and it looks a little better. May not be the perfect solution but I have noticed that a lot of google webfonts can be unpredictable
I develop in Firefox. My experience is that FF displays ttf fonts very well without any extra rules (beyond the #font-face calling the url for the font file). Chrome, however, is a different story. Even with with the -webkit-font-smoothing: antialiased; rule it still displays any font quite raggedly. Safari doesn't seem to have that problem, so it's not inherently Webkit that can't render a font cleanly, it's a Chrome problem.
I haven't tried adding the -webkit-text-stroke: 0.5px; rule, but will.
Of the answers above I really like Tom Sarduy's answer best. Aside from a good description of the problem, he gives a great #font-face stack to use to cover all the major browsers.
Another link reference for web font rendering in chrome -
http://www.fontspring.com/blog/smoother-web-font-rendering-chrome
Had the same thing guys. Good in all browsers except chrome - even IE10 and 9 were fine. Dreamwaeevr CS6 also uses a similar version of fontsprings code, but has the svg at the end. Change it round for SVG before woff and ttf and all in the world is good. Tom is bang on with hos example there, in fact past that into your code and map paths to the fonts you need, and you're in business!
It seems that Google might serve different woff files depending on the browser and OS.
I found that if I download the font from IE, it's about 10k bigger than if done on Safari from the Mac for a particular font. 43k vs 33k. Also, the IE version seems to look fine on the Mac, but the Mac version doesn't seem to work fine on the PC. The Mac version looks the worst in Mozilla Firefox on the PC.
Try this:
http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600,400italic,600italic
SourceSansPro-Regular.woff PC version 27k
SourceSansPro-Regular.woff Apple version 24k
i have tried many ways:
-loading the svg with font-face
-webkit-font-smoothening
...
after
-webkit-transform: rotate(-4.7deg) translate3d( 0, 0, 0);
the rotating was smoother but the main problem hasnt gone.
For me the solution was adding:
-webkit-text-stroke: 0.5px;
https://www.gettingthingstech.com/how-to-fix-jagged-font-rendering-in-google-chrome/
This post explains a little about google chromes experimental functions. Apparently enabling the "DisableWrite" option fixes the jagged fonts. This is obviously a fix PER machine and not on a full scale.
I used the Museosans500 font with the following syntax
#font-face {
font-family: 'MuseoSans500';
src: url('MuseoSans_500-webfont.eot');
src: url('MuseoSans_500-webfont.eot?iefix') format('eot'),
url('MuseoSans_500-webfont.woff') format('woff'),
url('MuseoSans_500-webfont.ttf') format('truetype'),
url('MuseoSans_500-webfont.svg#webfontkQkWxTED') format('svg');
font-weight: normal;
font-style: normal;
}
It is working fine in Firefox, but it is not displaying the font correctly in Chrome.
I'm not sure what issues you are experiencing but this website http://seanmcb.com/typekit/webkit-antialiasing-test.html gives a great run-down of test cases of a webkit bug, which might be what you're experiencing.
I'm seeing the anti-aliasing issue in my own site and I'm going to try out the pseudo-element trick. The bug as described by the site: "In Webkit browsers on Mac, #font-face fonts render with whatever antialiasing setting the previously rendered text was using."
Next, would be good to see if webkit has a bug open for this issue.
Yes this is correct - make sure you define SVG first, otherwise Chrome will use that to display the font, and this will look jagged. By putting it first you ensure that Chrome will use one of the later definitions to display the font.
This might be due to the version of Chrome you're running on Windows. I know Chrome 10's #font-face rendering was not too smooth. Please take a screenshot and share with us and then possibly update your browser, take another screenshot and compare them.
Good luck!
Put SVG format before all others on your CSS.
I am using Google Web Font's PT-sans
font-family: 'PT Sans',Arial,serif;
but it looks different in Chrome and Firefox
Is there anything that I need to add so that it looks same in all browsers?
For the ChunkFive font from FontSquirrel, specifying "font-weight: normal;" stopped Firefox's rendering from looking like ass when used in a header. Looks like Firefox was trying to apply a fake bold to a font that only has one weight, while Chrome was not.
For me, Chrome web fonts look crappy until I put the SVG font ahead of WOFF and TrueType. For example:
#font-face {
font-family: 'source_sans_proregular';
src: url('sourcesanspro-regular-webfont.eot');
src: url('sourcesanspro-regular-webfont.eot?#iefix') format('embedded-opentype'),
url('sourcesanspro-regular-webfont.svg#source_sans_proregular') format('svg'),
url('sourcesanspro-regular-webfont.woff') format('woff'),
url('sourcesanspro-regular-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
Even then, Chrome's fonts look thinner than in Firefox or IE. Chrome looks good at this point, but I usually want to set different fonts in IE and Firefox. I use a mixture of IE conditional comments and jQuery to set different fonts depending on the browser. For Firefox, I have the following function run when the page loads:
function setBrowserClasses() {
if (true == $.browser.mozilla) {
$('body').addClass('firefox');
}
}
Then in my CSS, I can say
body { font-family: "source_sans_proregular", Helvetica, sans-serif; }
body.firefox { font-family: "source_sans_pro_lightregular", Helvetica, sans-serif; }
Likewise, in an IE-only stylesheet included within IE conditional comments, I can say:
body { font-family: "source_sans_pro_lightregular", Helvetica, sans-serif; }
There are a few fixes. But usually it can be fixed with:
html {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
Sometimes it can be due to font-weight. If you are using a custom font with #font-face make sure your font-weight syntax is correct. In #font-face the idea of the font-weight/font-style properties are to keep your font-family name across different #font-face declarations while using different font-weight or font-style so those values work properly in CSS (and load your custom font -- not "fake bold").
I've seen -webkit-text-stroke: 0.2px; mentioned to thicken webkit fonts, but I think you probably won't need this if you use the first piece of code I gave.
css reset may fix the problem, I am not sure .
http://yuilibrary.com/yui/docs/cssreset/
I've noticed that chrome tends to make fonts a bit more sharper and firefox a bit smoother.
There is nothing you can do about it. good luck
To avoid font discrepancies across browsers, avoid using css styles to alter the look of the font. Using the font-size property is usually safe, but you may want to avoid doing things like font-weight: bold; instead, you should download the bold version of the font and give it another font-family name.
i found this to be working great :
-webkit-text-stroke: 0.7px;
or
-webkit-text-stroke: 1px rgba(0, 0, 0, 0.7);
experiment with the "0,7" value to adjust to your needs.
The lines are added where you define the bodys font.
here is an example:
body {
font-size: 100%;
background-color: #FFF;
font-family: 'Source Sans Pro', sans-serif;
margin: 0;
font-weight: lighter;
-webkit-text-stroke: 0.7px;
As of 2014, Chrome still has a known bug where if the webfont being used has a local copy installed, it choses to use the local version, hence, causing OP rendering issues.
To fix this, you can do the following:
First, target Chrome Browser or OSX (For me, the issue was with OSX Chrome only). I have used this simple JS to get quick Browser/OS's detection, you can chose to do this in any other way you're used to:
https://raw.github.com/rafaelp/css_browser_selector/master/css_browser_selector.js
Now that you can target a Browser/OS, create the following 'new' font:
#font-face {
font-family: 'Custom PT Sans';
src: url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/jKK4-V0JufJQJHow6k6stALUuEpTyoUstqEm5AMlJo4.woff) format('woff');
font-weight: normal;
font-style: normal;
}
The font URL is the same your browser uses when embedding the google webfont. If you use any other font, just copy and change the URL accordingly.
Get the URL here http://fonts.googleapis.com/css?family=PT+Sans:400,700&subset=latin,latin-ext
You may also rename your #font-face custom font-family alias.
Create a simple CSS rule to use that font targeting Browser/OS or both:
.mac .navigation a {
font-family: "Custom PT Sans", "PT Sans", sans-serif;
}
Or
.mac.webkit p {
font-family: "Custom PT Sans", "PT Sans", sans-serif;
}
Done. Just apply the font-family rule wherever you need to.
Different browsers (and FWIW, different OSes) use different font rendering engines, and their results are not meant to be identical. As already pointed out, you can't do anything about it (unless, obviously, you can replace text with images or flash or implement your own renderer using javascript+canvas - the latter being a bit overboard if you ask me).
I had the same issue for a couple of months. Finally, it got worked by disabling below settings in Chrome browser's settings.
Set "Accelerated 2D Canvas" to "Disabled"
(In the browser's address bar, go to chrome://flags#disable-accelerated-2d-canvas, change the setting, relaunch the browser.)
Since the fix for this issue has clearly changed, I would suggest in general turning off any hardware-accelerated text-rendering/2D-rendering features in the future if this fix stops working.
On Google Chrome 55, this issue appears to have cropped up again. As anticipated, the fix was disabling hardware acceleration, it just changed locations.
The new fix (for me) appears to be:
Settings -> Show advanced settings... -> System
UNCHECK "Use hardware acceleration when available"
https://superuser.com/questions/821092/chromes-fonts-look-off
The issue might be more what we don't set in our CSS than what we do set.
In my case, FF is showing text in the default Times New Roman, while Chrome uses Montserrat as expected.
This happens to be because in Chrome I set Montserrat as the default, while FF has no default.
So, I think that some browser differences are rooted in the browser's configuration rather than in my CSS.
I've used http://www.fontsquirrel.com/ to create a #font-face kit.
It works fine, but the result on windows is different from the result on mac.
On windows the font seems to have a wrong anti-aliasing:
this is the result on Mac with FF, Chrome or Safari (all updated to last version).
this is the result on Windows with FF or Chrome.
As you can see, the result is not the same. On Windows the font is thicker and rougher.
How can I solve this?
I too have been plagued with this on Chrome and I think I've just found the answer!
Chrome didn't like the default fontsquirrel.com generated CSS.
#font-face {
font-family: 'HLC';
src: url('/_styles/hlc/hl-webfont.eot');
src: url('/_styles/hlc/hl-webfont.eot?#iefix') format('embedded-opentype'),
url('/_styles/hlc/hl-webfont.woff') format('woff'),
url('/_styles/hlc/hl-webfont.ttf') format('truetype'),
url('/_styles/hlc/hl-webfont.svg#HLC') format('svg');
font-weight: normal;
font-style: normal;
}
To fix, i moved the SVG line:
url('/_styles/hlc/hl-webfont.svg#HLC') format('svg')
to the top of the list. Now I see anti-alias fonts! I guess Chrome wants to be first...
/* THIS WORKS FOR ME */
#font-face {
font-family: 'HLC';
src: url('/_styles/hlc/hl-webfont.eot');
src: url('/_styles/hlc/hl-webfont.svg#HLC') format('svg'),
url('/_styles/hlc/hl-webfont.eot?#iefix') format('embedded-opentype'),
url('/_styles/hlc/hl-webfont.woff') format('woff'),
url('/_styles/hlc/hl-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
Hope it works for you too. Enjoy!
I'm surprised no one mentioned this. Applying a slight -webkit-text-stroke does the trick for me whatever the format (extension) of the font you are using. Some recommend a -webkit-text-stroke: 1px but to me it alters the font look too much (make it too strong). But a 0.5px one makes the stroke almost unnoticeable and it turns on the antialiasing:
-webkit-text-stroke: 0.5px;
Put it in your css definition for html tag and you're done!
This just looks like the normal ugly way fonts are rendered in WinXP. Some (IMO: misguided) people even prefer it.
To get anti-aliasing for desktop fonts in general on XP you have to turn it on, from Display Properties -> Appearance -> Effects -> Use the following method to smooth edges of screen fonts -> ClearType. The default setting “Standard” is the old-school Windows “font smudging” technique that only bothers to turn on at larger font sizes, and then often makes a mess.
IE7+ has an option—on by default—to always use ClearType anti-aliasing to render fonts in the web browser. Other web browsers will respect the user's configured font rendering method. It is a shame that so many people still have this beneficial setting turned off, but it's not really your problem.
(There is nasty hack to make Chrome perform some anti-aliasing on text, which is:
text-shadow: 0px 0px 1px rgba(0,0,0,0);
but I seriously wouldn't recommend it.)
One thing you can do when the “Use the following method...” setting is set to “Standard”, to try to make the font get some form of anti-aliasing, is to check that the font in question doesn't have a GASP table telling old-fashioned TrueType renderers to disable anti-aliasing at particular font sizes. You can change the GASP table using a font editor or with the ttfgasp.exe command-line tool.
There is also a font called Vegur that looks like Myriad Pro but is legal to embed in a website.
Hope that helps!
I've done a little research, and I've found a hack that I think makes a difference. Put this in your CSS with your font variables:
-webkit-transform: rotate(-0.0000000001deg);
As well, I find that a full-on black (#000000) doesn't help matters either. Using a very dark seemed to help me.
Changing setting in Windows or a browser itself is not a solution. When you use #font-face, you want the font to look nice on every screen in every browser, not just in yours.
The trick with
text-shadow: 0 0 1px rgba(255,255,255,0.1);
or
-webkit-transform: rotate(-0.0000000001deg);
doesn't work anymore in Chrome 16.0.912.63 m, Windows Vista.
I couldn't find a way to overcome this issue though.
This is code im using to fix "Chrome rendering problem":
#font-face {
font-family: 'fontname';
src: url('fonts/fontname.eot');
src: url('fonts/fontname.eot') format('embedded-opentype'),
url('fonts/fontname.svg') format('svg');
}
/*if mozilla*/
#-moz-document url-prefix() {
#font-face {
font-family: 'fontname';
src: url('fonts/fontname.ttf') format('truetype');
}
}
:) it works for me...FINALLY!
-webkit-transform: rotate(-0.0000000001deg);
Update: No longer working in Chrome 15.0.874.106 m. Though it does work in IE9 and Firefox – >Zequez Nov 4 at 15:28
UPDATE: This is working (at least for me) in Chrome 15.0.874.121 m.
IE9 and Firefox shouldn't need it, or be targeted by it since the selector specifies -webkit-.