When working on my website www.monkey-touch.com I started using a custom font for the headers and in several other places. It looks great and thanks to the font-squirrel it works on all browsers.
However, I realized later that the fonts rendered differently in some browsers. Chrome, Opera and Safari all render the custom font slightly higher than others. This is not that big of an issue there, but when trying to add another page http://monkey-touch.com/sandbox/products.php with the custom font of a big size, the offset becomes larger to the point where it is very much a nuisance as the text renders outside of the divs.
Please note that the issue apparently has nothing to do with faulty css styling of other divs as even rendering the font in the body tag with no other divs has the offset as can be seen here: http://monkey-touch.com/Sandbox2/
Can anyone tell me why this is and what the best way is to fix the issue?
My css for the font-face is:
#font-face {
font-family: 'Bebas';
src: url('bebas-webfont.eot');
src: url('bebas-webfont.eot?#iefix') format('embedded-opentype'),
url('bebas-webfont.woff') format('woff'),
url('bebas-webfont.ttf') format('truetype'),
url('bebas-webfont.svg#Bebas') format('svg');
font-weight: normal;
font-style: normal;
}
Thanks all in advance.
I have figured it out and it is rather strange and consists of two things.
1) The .ttf and .eot I got from the font-squirrel were no good. Getting the original .ttf back from the font-site and converting it to .eot myself was necessary for proper rendition. I do not know whether this is actually font-squirrel's fault because the differences in rendition seem very arbitrary and strange, also see point 2).
2) Removing the .woff entry from the css. The .woff was only added for safety, I was not sure whether this was used by any, but it seems all browsers still render it correctly.
It seems very bizarre, because the browsers involved all use the same .ttf (except IE8 and less which use the .eot) but render it differently. Also the .woff has to be removed, why? ALthough I have solved my problem it still seems a rather random and strange problem. If anyone knows more about this stuff I would love to know.
I hope this question will be of use to others to come. font-face has still a long way to go in being easy to use, and browsers should be more wary of proper compliance regarding it.
The problem is caused by the browser negating to compute exact glyph bounds (Done for the sake of performance.)
The solution to this problem is to add a single line of text into your CSS:
text-rendering:optimizeLegibility;
this line can be added to the CSS of the div that requires it, and that way there's no extra processing done to the rest of the page.
You need to specify a line-height. Try
body,html
{
line-height: 18px; /* or whatever height you want */
}
Related
I'm using a custom font in a page I'm developing, Droid Sans, and at certain font sizes, the bottom is cut off, but only in Opera and webkit browsers.
It's easy to reproduce on Google's own webfonts page looking for Droid Sans and showing the whole alphabet at 18px: http://www.google.com/webfonts
It's especially clear for the lower case g.
Is there some css trick / hack I can use to increase the line height / show the whole character or am I really limited to only certain sizes of the font?
line-height and padding for example don't change anything and 20px font-size works fine and at the moment I am using Windows 7.
Edit: By the way, I am aware of a similar question here but as the accepted answer is changing the font size and the rest of the answers do not apply, it is of not much use to me.
Edit 2: An example that at least for now shows the problem (left hand column, under the slideshow, Il Cerca Viaggi).
Edit 3: The problem seems to be limited to Windows although I'm not sure which versions.
Edit 4: I have added a screenshot from Google Webfonts to show that the problem is not specific to the site I'm developing.
Although it is not the solution I am looking for, I have found a possible solution that might work for others:
In my original style-sheet I have specified the font as follows:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype'),
url('droid-sans/DroidSans-webfont.svg#DroidSans') format('svg');
font-weight: normal;
font-style: normal;
}
This is causing webkit browsers to use the woff file / format.
Changing the order of the font specifications and removing the hash-tag after the svg specification (why is that there anyway?), causes webkit browsers to use the svg file / format:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.svg') format('svg'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
This solves the problem, all characters are displayed correctly.
However, at least in Windows 7 64bit, the svg font is not as sharp as the woff font, it's kind of blurry so I will not be using this solution and am hoping for a better one.
To a similar question, one answer suggested that, while this appears to be a Windows font rendering issue specifically, hosting svg, eot and otf versions of a TrueType font (TTF) containing the font, which was not optimized for the web, had fixed the problem for its provider. If possible, get a clean, un-optimized version of the DroidSans font and export the web fonts yourself.
EDIT: Sorry all, I was out for the holiday and didn't have access to SO. Since I've been back, I've done a little research into exactly what's causing this problem on Windows machines...
It appears that the issue lies with the way the OpenType format is rendered on Windows machines. The issue with truncated descenders seems to transcend software type to affect multiple Windows programs attempting to render OpenType. Currently, you have the Embedded OpenType format (EOT) version of the font listed first in your CSS document under #font-face. Since Chrome and Opera both recognize this format, they'll disregard the subsequent source declarations and use EOT to display the font. Unfortunately, there doesn't seem to be a quick fix that you could apply to an OpenType font itself to force the software rendering it to allow adequate line-spacing for the lowest of its descenders on Windows machines...
However, you can be choosy about which fonts you feed to your viewers' browsers. Personally, I would recommend placing the SVG version first in your CSS, and for browsers that don't recognize this format, suggest TrueType (TTF) second, then WOFF, then EOT for browsers that don't support any of the aforementioned (some older versions of IE appear to support OpenType exculsively). If the SVG rendering isn't much to your liking, try TrueType first instead.
Alternatively, although I'm no longer really that confident that it will help, you can download a TTF of DroidSans at FontSquirrel and use a software package like Typograf to export web fonts (EOT, WOFF, SVG). Try rearranging the sources in your CSS as outlined above first, though.
ANOTHER EDIT: My erroneous use of TIFF instead of TTF has been redacted to avoid confusion in the future. Apologies for the mix-up, guys...
I am not sure but try to add this for padding to work
display:block;
padding-bottom:20px;
margin-bottom:10px;
line-height:normal !important;
line-height:55%;
Set the line height to normal, it is a firefox bug and use the line height in %
I think this might do the trick
It all boils down to the font itself.
Look here
http://jsfiddle.net/DdMej/2/
The first row uses Drod Sans by Google fonts.
The second row uses the font you have on your site.
edit 1
Screenshot
http://imageshack.us/photo/my-images/811/screeniy.png/
I too was seeing my Google Font 'Lato' cut off at the bottom portion of the rendered text. In my case, I needed to serve the font files locally instead of using Google Fonts. To do this I:
Converted the font from .ttf to webfont files with Font2Web
Served the font files locally as static file assets from the localhost
Included fonts in my css with the bulletproof #font-face implementation
This eliminated my cut off rendered text issue.
In doing some research on the "correct" syntax for using #font-face in a cross-browser friendly way, I came across the following site, which makes a lot of sense:
http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax
However, if you look at any of the #font-face demo code provided by Font Squirrel, the #font-face definitions are as follows:
#font-face {
font-family: 'OswaldLight';
src: url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.eot');
src: url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.woff') format('woff'),
url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.ttf') format('truetype'),
url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.svg#OswaldLight') format('svg');
font-weight: normal;
font-style: normal;
}
Why do the Font Squirrel demo scripts all contain two src declarations? I can't understand this.
It's an IE9 compatibility mode issue.
For a full explanation, first see: http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax
How it works
Internet Explorer <9 has a bug in the parser for the src attribute. If you include more than one font format in the src, IE fails to load it and reports a 404 error. The reason is that IE attempts to load as a file everything between the opening parenthesis all the way to the very last closing parenthesis. To deal with that wrong behavior, you merely declare the EOT first and append a single question mark. The question mark fools IE into thinking the rest of the string is a query string and loads just the EOT file.
Then see the follow up article: http://www.fontspring.com/blog/further-hardening-of-the-bulletproof-syntax
A potential looming problem with the new syntax we introduced earlier this month was raised by Microsoft. The soon-to-be-released IE9 comes with a feature that allows it to render in both IE7 and IE8 Modes. In these two modes, Microsoft 'fixed' the parser bug that affected the actual IE7 and IE8. This fix breaks the #font-face syntax for those compatibility modes.
...
This syntax is exactly the same as our previous iteration with the addition of a second 'src:' attribute that specifies the EOT again. We'll leave it up to you to decide if this is necessary.
If you don't care about compatibility view you can clear that first src right out.
The second one overrides the first if the browser understands the second one, but not the first one. This way you can add compatibility for multiple browser. Browser A uses the first SRC and Browser B, C and D use the second SRC statement.
I've had this problem in a lot of different webs. You have a font which has different anti-aliasing options, the designer uses the same font with different anti-aliasing options on different parts of the text on the web. So there is a difference between some elements.
In this case I have sharp, crisp, strong and smooth. I've used a font generator to get the code to access it via #font-face. Even so, I also have the original .otf if important to know. Is there a method to access this?
I upload a picture of what I mean and my actual code:
#font-face {
font-family: 'light';
src: url('../_fnt/light/gothamrnd-light.eot');
src: url('../_fnt/light/gothamrnd-light.eot?#iefix') format('embedded-opentype'),
url('../_fnt/light/gothamrnd-light.woff') format('woff'),
url('../_fnt/light/gothamrnd-light.ttf') format('truetype'),
url('../_fnt/light/gothamrnd-light.svg#../_fnt/light/gothamrnd-light') format('svg');
font-weight: normal;
font-style: normal;
}
No, there is no way to control the rendering of text in that way. Those are Photoshop specific settings as it has its own rendering engine, they aren't even available to other programs.
Actually, different browsers will render the text in different ways, and even the same browser on different computers will render it differently depending on the system settings.
If you make the page look exactly like the design in one browser, it will look rather different in another browser. You should normally test it in different browsers and try to make it look as close as possible to the design in most of them, and make sure that it's not too far from the design in any of them.
Only WebKit browsers on Mac OS X have recognized a CSS property related to font smoothing, namely -webkit-font-smoothing. Even there, it’s unclear what’s happening, as they seem to be removing the antialiazed value, see webkit-font-smoothing: suddenly different results in chrome and safari
So for practical purposes, regard font smoothing as being out of your hands as an author, and test your fonts under different smoothing options to check that the results are at least tolerable.
I downloaded a custom font (Gotham-Light.eot), but it doesn't work on Internet Explorer 9.
#font-face {
font-family: Gotham-Light;
src: url('Gotham-Light.eot');
}
This doesn't work. I'm using ASP MVC3 rebuilt, used custom tool, still nothing.
First, the goods:
#font-face {
font-family: 'ludger_duvernayregular';
src: url('http://jfcoder.com/css/fonts/ludgerduvernay-fontsquirrel/ludgerduvernay.eot');
src: url('http://jfcoder.com/css/fonts/ludgerduvernay-fontsquirrel/ludgerduvernay.eot?#iefix') format('embedded-opentype'),
url('http://jfcoder.com/css/fonts/ludgerduvernay-fontsquirrel/ludgerduvernay.woff') format('woff'),
url('http://jfcoder.com/css/fonts/ludgerduvernay-fontsquirrel/ludgerduvernay.ttf') format('truetype'),
url('http://jfcoder.com/css/fonts/ludgerduvernay-fontsquirrel/ludgerduvernay.svg#ludger_duvernayregular') format('svg');
font-weight: normal;
font-style: normal;
}
p.test {
font-family: 'ludger_duvernayregular', Arial, serif;
font-weight: 400;
color: blue;
}
Note, I used a font face that was purposefully easy to see as working. (And I don't have access to Gotham in a web font, so... I'm not even sure Gotham is licensed to use in web font form. If you do not have a license or the license does not allow for it, please respect that.) So you will have to do a little thinking about the paths to your font files.
What I've done is consult the blog post AlienWebGuy linked to, which is good. It's not long, so I'd read it. It boils down to:
Possibly a misconfigured MIME type for the font file. See below for more info. There's also a note that Apache may have this problem, it seems to be more of an IIS issue (according to the article).
You can trick (?) IE9 to use the EOT file instead of the WOFF, which apparently fixes the issue (according to the article).
Additionally, and as an aside, IE9 had a problem displaying the font with a jsFiddle demo using the same exact CSS. Very weird. IE7 and 8 worked fine, so I know it was working in some ways. I did not figure out what that was about, but I saved the same markup and CSS to a file on my site and it works fine.
Breakdown...
Let me explain what's going on in the above CSS. I'll go through each line. However, keep in mind I have the web font in the following file formats:
eot
woff
ttf
svg
You really probably only need eot, ttf and woff if you don't care to support legacy iOS. SVG translations are hard to obtain, though.
Now, first name your font so you can reference it:
font-family: 'ludger_duvernayregular';
IE9 Compat Modes:
src: url('http://jfcoder.com/css/fonts/ludgerduvernay-fontsquirrel/ludgerduvernay.eot');
Remember to verify the URLs you're using here actually lead to a real file. Put it in the address bar and see what happens (does it download? 404?).
On the following, though, I'm going to remove the full URL so you can see the entire statement, including the end.
IE6, 7 and 8:
src: url('http://../ludgerduvernay.eot?#iefix') format('embedded-opentype'),
Note this part:
.eot?#iefix <<< See below for an explanation.
Further IE CSS Fix
In some rare cases, IE will fail because the #font-face declaration
has too many characters. This can be solved in most instances by
adding a ‘#’ hash mark after the ‘?’ question mark. This buys you a
bit of extra room.
- From the Font Spring article
I have no idea why this works, so I'm taking their word for it.
Modern Browsers:
url('http://../ludgerduvernay.woff') format('woff'),
Safari, Android, iOS:
url('http://../ludgerduvernay.ttf') format('truetype'),
Legacy iOS:
url('http://../ludgerduvernay.svg#ludger_duvernayregular') format('svg');
Then use it:
p {
font-family: 'ludger_duvernayregular', Arial, serif;
}
I was actually surprised this works back to IE6. Anyways, notice that I use a full path to the file, not a relative one. That's usually a good place to start; check to make sure the link downloads. I'm making a big deal of this because it's basic and easy to screw up.
So if the file is downloading with the url and you've got it working in other browsers, and in IE6, 7 and/or 8, you can look at another possibility:
Fix IE9 on the Server Side (IIS)
Microsoft’s IIS server will refuse to send resources that it does not
have a MIME type for. The syntax we developed forces IE9 to take the
WOFF over the EOT, but if it is served on IIS, it will fail. This is
because IE9 requests the WOFF file, but since WOFF is not a defined
MIME type in IIS, a 404 Not Found error is returned. To solve this,
you must add ‘.woff’ with MIME type ‘application/x-font-woff’ to your
IIS installation.
- From the Font Spring article
So you may have to check your server isn't borking it. You can also use Chrome Console or Firebug NET tab to view the headers sent with the file.
Now I had a little help here, and I think you should think about the following options:
Google Web Fonts. Don't be a hero. They host the font, give you the include stylesheet markup, and presto whammo, you're in business. They also have some pretty cool fonts. There are other web font services, such as Typekit, Webtype, Fontdeck, and Fonts Live.
Font Squirrel has a #Font-Face Generator, which can give you all of the files you need (Warning: Only submit fonts you know to be licensed for web use.). Use the Expert mode, and it will give you a ZIP file with lots of great stuff, including a demo. The one I received you can download here. The interesting thing is, the generated CSS is identical to the Font Spring one, minus the comments. That's probably not a coincidence.
I found that awesome tool on this Opera Dev page. That is also worth reading.
And of course, that blog post AlienWebGuy linked to at Font Spring.
This stuff isn't hard, but you need to know how to troubleshoot. Always check that the file is downloading; you can use Chrome Console Resources tab or Firefox's Firebug add-on and watch the NET tab to see if it downloads. It if just literally won't work, post the page or code somewhere where we can get to it and we can review it.
Happy coding. :)
The super awesomely cool font used in the demo is Ludger Duvernay Regular. For more information, see Steve Cloutier/Cloutierfontes site. Thank you for making it free for personal use. :)
If you're following the instructions layed out here -- http://www.fontspring.com/blog/fixing-ie9-font-face-problems -- then it's most likely how your calling the fonts.
Make sure you are pointing to the right location from your stylesheet - the code you have above will only work if the font file is in the same directory as the stylesheet.
Hope this helps.
Gotham is a commercial product, and if you have just downloaded it from somewhere, it’s probably an illegal copy or a fake, and may well be technically broken too.
Consider using a free font of similar design, such as Cicle.
For googlers: I had a problem with either long font name or conflict with already installed font. Anyway IE were the only browser having problems.
I changed
font-family: 'HelveticaLTUltraCompressedRegular';
to
font-family: 'HelveticaLTUCR';
which solved my issue.
I'm using a custom font in a page I'm developing, Droid Sans, and at certain font sizes, the bottom is cut off, but only in Opera and webkit browsers.
It's easy to reproduce on Google's own webfonts page looking for Droid Sans and showing the whole alphabet at 18px: http://www.google.com/webfonts
It's especially clear for the lower case g.
Is there some css trick / hack I can use to increase the line height / show the whole character or am I really limited to only certain sizes of the font?
line-height and padding for example don't change anything and 20px font-size works fine and at the moment I am using Windows 7.
Edit: By the way, I am aware of a similar question here but as the accepted answer is changing the font size and the rest of the answers do not apply, it is of not much use to me.
Edit 2: An example that at least for now shows the problem (left hand column, under the slideshow, Il Cerca Viaggi).
Edit 3: The problem seems to be limited to Windows although I'm not sure which versions.
Edit 4: I have added a screenshot from Google Webfonts to show that the problem is not specific to the site I'm developing.
Although it is not the solution I am looking for, I have found a possible solution that might work for others:
In my original style-sheet I have specified the font as follows:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype'),
url('droid-sans/DroidSans-webfont.svg#DroidSans') format('svg');
font-weight: normal;
font-style: normal;
}
This is causing webkit browsers to use the woff file / format.
Changing the order of the font specifications and removing the hash-tag after the svg specification (why is that there anyway?), causes webkit browsers to use the svg file / format:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.svg') format('svg'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
This solves the problem, all characters are displayed correctly.
However, at least in Windows 7 64bit, the svg font is not as sharp as the woff font, it's kind of blurry so I will not be using this solution and am hoping for a better one.
To a similar question, one answer suggested that, while this appears to be a Windows font rendering issue specifically, hosting svg, eot and otf versions of a TrueType font (TTF) containing the font, which was not optimized for the web, had fixed the problem for its provider. If possible, get a clean, un-optimized version of the DroidSans font and export the web fonts yourself.
EDIT: Sorry all, I was out for the holiday and didn't have access to SO. Since I've been back, I've done a little research into exactly what's causing this problem on Windows machines...
It appears that the issue lies with the way the OpenType format is rendered on Windows machines. The issue with truncated descenders seems to transcend software type to affect multiple Windows programs attempting to render OpenType. Currently, you have the Embedded OpenType format (EOT) version of the font listed first in your CSS document under #font-face. Since Chrome and Opera both recognize this format, they'll disregard the subsequent source declarations and use EOT to display the font. Unfortunately, there doesn't seem to be a quick fix that you could apply to an OpenType font itself to force the software rendering it to allow adequate line-spacing for the lowest of its descenders on Windows machines...
However, you can be choosy about which fonts you feed to your viewers' browsers. Personally, I would recommend placing the SVG version first in your CSS, and for browsers that don't recognize this format, suggest TrueType (TTF) second, then WOFF, then EOT for browsers that don't support any of the aforementioned (some older versions of IE appear to support OpenType exculsively). If the SVG rendering isn't much to your liking, try TrueType first instead.
Alternatively, although I'm no longer really that confident that it will help, you can download a TTF of DroidSans at FontSquirrel and use a software package like Typograf to export web fonts (EOT, WOFF, SVG). Try rearranging the sources in your CSS as outlined above first, though.
ANOTHER EDIT: My erroneous use of TIFF instead of TTF has been redacted to avoid confusion in the future. Apologies for the mix-up, guys...
I am not sure but try to add this for padding to work
display:block;
padding-bottom:20px;
margin-bottom:10px;
line-height:normal !important;
line-height:55%;
Set the line height to normal, it is a firefox bug and use the line height in %
I think this might do the trick
It all boils down to the font itself.
Look here
http://jsfiddle.net/DdMej/2/
The first row uses Drod Sans by Google fonts.
The second row uses the font you have on your site.
edit 1
Screenshot
http://imageshack.us/photo/my-images/811/screeniy.png/
I too was seeing my Google Font 'Lato' cut off at the bottom portion of the rendered text. In my case, I needed to serve the font files locally instead of using Google Fonts. To do this I:
Converted the font from .ttf to webfont files with Font2Web
Served the font files locally as static file assets from the localhost
Included fonts in my css with the bulletproof #font-face implementation
This eliminated my cut off rendered text issue.