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.
Related
I need your help in solving a very strange issue.
We need to make "Arial" to be 100% similar in all browsers. To do that we used #font-face and used a different file name for Arial.
It works fine in all browsers (pixel by pixel similar), however in some machines it is behaving different .... all systems have same configuration and browser versions.
issue seems to be with Mozilla so far.
I have tried everything but no result.
I used 'font squirrel' to convert fonts (basic/optimal/expert).
here is my CSS.
#font-face {
font-family: 'conduit_arial';
src: url('../Helper/Fonts/conduit_arial.eot');
src: url('../Helper/Fonts/conduit_arial.eot?#iefix') format('embedded-opentype'),
url('../Helper/Fonts/conduit_arial.woff2') format('woff2'),
url('../Helper/Fonts/conduit_arial.woff') format('woff'),
url('../Helper/Fonts/conduit_arial.ttf') format('truetype'),
url('../Helper/Fonts/conduit_arial.svg#conduit_arial') format('svg');
font-weight: normal;
font-style: normal;
}
we used different name in font face and different file name also so that browser do not load Arial from system fonts.
Friends kindly help me to identify the issue.
Thanks
I'm afraid that this is not posible at 100%. Let me explain you why:
Arial could be probably the most wide spread font. Let's say that this doesn't make us feel safe.
As you've done, you can be sure to load the same font by using font-face and a diferent name for the font. Can you be sure now? not completly, as there are browsers that may not support font-face...
Let's say you don't need to support browsers older than ie9. Now you must be sure... No again! Different browsers and different OS's have diferent ways of dealing with fonts. Windows has the ClearType engine for rendering and is different from OS X's engine (more info here: http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/)
Let's say you only need to support Windows 7 and 8. Now you must be sure... No again! Different browsers may render the fonts in different ways. For example, older versions of Chrome didn't have a very good antialiasing on windows. Their fonts were sharper but uglier!
My advice: As you can see, there are many things you can't control... Still, there are some good-practices that you could follow so as to diminish problems. Try to give exact pixel dimensions to your fonts, even when you are using em's and specially for smaller font sizes. For example, use 0.875em rather than 0.9em, avoid fonts designed for printing, specially in content (like the commonly used Helvetica) and make wise use of font fallbacking.
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.
I have a basic question that probably refers more to design field, but still it is a web programming.
Let say I need to use Palatino-Linotype font in my web application. How do I better embed it in to my web page application?
My known way:
1) Go to font.com and buy all kinds of palatino-linotype: normal, bold, italic, italic-bold. 4 different files.
2) Then I load fonts via fontface style
#font-face {
font-family: "Palatino-Linotype-normal";
src: "..."
}
#font-face {
font-family: "Palatino-Linotype-italic";
src: "..."
}
3) A I have 4 different fonts, in HTML markup I need explicitly set font of the element to make it bold, or italic, or italic-bold (that what I don't like the most).
Question:
1) is that workflow of using custom web fonts?
2) Maybe there is a way to treat this fonts as usual fonts in term of setting only one font on parent element, and for inner set only style="font-style: italic;" if I want them to be italic.
3) question about performance, does web font rendering speed differs from rendering of usual fonts?
The logical way, generally supported by browsers, is to declare each typeface in a separate rule, as in
#font-face {
font-family: foobar;
src: url("foobar-regular.woff");
}
#font-face {
font-family: foobar;
font-style: italic;
src: url("foobar-italic.woff");
}
and then just declare font-family: foobar and use font-style: italic directly or indirectely via <i>, <em>, and other markup that causes default rendering in italic.
I have simplified the code in an obvious way; naturally you should normally make the font available in different formats, as recognized by browsers.
Services like FontSquirrel generate different code, but it is fairly straightforward to fix the code they produce, or write the code from scratch.
I have intentionally used “foobar” and not “Palatino Linotype”, since the latter is not legally available for use as a downloadable font; at least this is what presume until proven otherwise. (There are many sites on the web that distribute or sell fonts illegally.)
Check out Fontsquirrel http://www.fontsquirrel.com/ it helped me to generate fonts and css:s compatible for multiple browsers.
If you only use Palatino Linotype Normal, and then change it to bold in CSS you won't get the same results as Palatino Linotype Bold. The thing here is that the browser rendering will be used to achieve that and it will suck a lot. I mean, for me and probably for you it will look the same - but not for designers :)
Also there are a lot more to one font than normal, bold and italic. There are light, semi light, black and so on. And designers tend to use those a lot.
So in general, for the first and second question: use different font faces for different styles and no way to use different faces for different styles, another font family indication is needed.
As for the 3rd one: performance is an issue with embedded fonts. But mostly not because of rendering, but because the font files are heavy to download. So be sure to cache them and use only those needed. For example http://www.fontsquirrel.com/ in the previous answer actually by default adds too many files that are all downloaded, so make a little research to know about different formats and what you need to embed.
You use Palatino-Linotype font in your web application use web font from google.
https://developers.google.com/webfonts/docs/webfont_loader
The Web Font Loader is a JavaScript library that gives you more control over font loading than the Google Web Fonts API provides. The Web Font Loader also lets you use multiple web-font providers. It was co-developed by Google and Type kit.
More inforamtion follow this link to my blog:
http://webtemplatesmonster.blogspot.in/2013/02/how-to-use-font-face.html
#font-face { font-family: 'Awesome Font'; src:
url('awesome-font.eot'); /* IE9 Compat Modes */ src:
url('awesome-font.eot?#iefix') format('embedded-opentype'), /*
IE6-IE8 */
url('awesome-font.woff') format('woff'), /* Modern Browsers */
url('awesome-font.ttf') format('truetype'), /* Safari, Android, iOS */
url('awesome-font.svg#svgFontName') format('svg'); /* Legacy iOS */ }
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.
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 */
}