I'm using a custom font and loading it through #font-face. The text looks fine, but the numbers look screwy (only on chrome-windows, which is a very well know bug. And yes, I tried using the svg format for chrome, which solved the numbers but screwed the text). I decided to limit my own font to only [a-z][A-Z], and using this generator got this:
unicode-range: U+0041-U+005a, U+0061-U+007a;
And it seems to... not be working. Numbers are still being displayed using the font. How do I find the right range to use\some other solution? I'd love for a general solution, for example if I want to limit future fonts as well.
Thanks in advance!
P.s.
While I'm on the subject - I'm assuming there's no way to load the same font twice - using the .svg file for numbers and .otf for text, right? Because if possible that'd be awesome as well.
You can use #font-face rules to specify that a font family name (which is up to you to decide) is mapped to a specific font except for some character range, for which another font is used. This even works for local fonts, e.g. as follows:
<style>
#font-face {
font-family: foo;
src: local("Times New Roman");
}
#font-face {
font-family: foo;
src: local("Arial");
unicode-range: U+0030-0039;
}
p { font-family: foo }
</style>
<p>hello 123</p>
On supporting browsers, “hello” appears in Times New Roman (if available) but “123” in Arial (if available); the range U+0030-0039 is the common European digits 0 to 9.
You can use similar techniques for downloadable fonts.
The bad news is that unicode-range is not supported by Firefox or by IE 8 or earlier. They fail differently: for the code above, IE 8 uses Times New Roman, ignoring the latter #font-face rule, whereas current Firefox uses Arial, as if the unicode-range restriction were not there.
Finally, I used a "brute-force" method. Using Font Squirrel's webfont generator I recreated my font files, and using the advanced options > custom subsetting, I completely removed the numbers from the font.
Seems like a terrible solution, but the best I could find.
Related
I'm using the Roboto Family of fonts. In general, it fits perfectly to all my needs except one. The length difference between ndash and mdash is to small. It is a very important aspect, because as a part of our services - we are helping editors, proofreaders, writers and typeseters.
To fix the issue, we adjusted the font and we hosted it on our server. Unfortunatly, this has an significant impact on page loading and rendering speed (even the preloading the font is done).
I would like to switch into CDNJS version of the Roboto font and I'm wondering if there is a CSS or CSS+JS way to fix the issue. The idea is to select all the ndashes on the site and to shorten all of them with either JS or CSS, to be exactly in the middle of the length between dash and mdash. In the origin Roboto font ndash is twice so long as dash but mdash is just a little bit longer than ndash.
An alternative is, to replace all the ndashes with an ndash from another font.
Any other ideas?
You mention replacing the ndashes and mdashes from another font.
Have you considered using the CSS font-face unicode-range property?
If you have a font that has the sort of size dashes you want you could substitute those for the dashes in Roboto.
I couldn't immediately find a font that had sufficiently different dashes to the standard ones to demonstrate, but here's the code from MDN which substitutes the ampersand in Helvetica with the slightly more flamboyant one from Times New Roman. This method saves having to do anything to your actual text.
#font-face {
font-family: 'Ampersand';
src: local('Times New Roman');
unicode-range: U+26;/* 2013-2014 ndash and mdash */
}
div {
font-size: 4em;
font-family: Ampersand, Helvetica, sans-serif;
}
<div>Me & You = Us</div>
I'm going mad with an issue and I wonder if anyone can help. I'm currently using http://font-combinator.com to see what different style of fonts look like together. This website simply loads fonts in from Google Fonts and displays them onscreen.
Now I choose a font, think it looks ok, and head over to Google and download it. I then paste that font into my local font directory so I can see what it looks like locally, and add it's name in my css like so:
font: 100%/1.6 "Font name here";
color: #bbb;
font-weight: 400; (for example)
Problem is when I look at it in the same browser as I did the Font Combinator, it looks rougher and more jagged. No settings have been changed. The font on both sites is 16px. For reference I am using Windows XP with cleartype turned off (I don't like it).
Now if I link to Google Fonts directly through my website, then it displays the same as on the Font Combinator. I don't understand how installing the same font that Google uses produces a different result? Ideally I would like to host the font on my website myself, but can't see a way around this? Am I doing something wrong, or is there something I've missed? Thanks!
For reference I am using the following reset:
html,body,etc.... {
margin: 0;
padding: 0;
border: 0;
outline: 0;
list-style-type: none;
font-size: 100%;
}
Edit: #Fontface code that I've used, that does seem to look the same!
#font-face {
font-family: 'Molengo';
src: url('./fonts/Molengo-Regular.ttf')
format('truetype');
}
(just picked this font as an example)
I had same problem and it's a mess and hard to solve. The main problem is that the font you've downloaded is not actually the "same" that google webfonts provides.
The font family is the same, but Google can provide it in different formats. The font that you've installed on your system is probably a .ttf file, that's a truetype font and Windows can use it. But, if you look the css that Google serves you when you includes a font, it's something like this:
For this:
http://fonts.googleapis.com/css?family=Open+Sans
you get this:
#font-face {
font-family: 'Open Sans';
font-style: normal;
font-weight: 400;
src: local('Open Sans'), local('OpenSans'), url(http://themes.googleusercontent.com/static/fonts/opensans/v8/cJZKeOuBrn4kERxqtaUH3T8E0i7KZn-EPnyo3HZu7kw.woff) format('woff');
}
As you can see, if there is no local matching, it requests the font BUT in woff format, it's the same font but in another font format. In fact, I've done this example using chrome, but the css that google provides choose the best font format depending on browser and SO that made the request.
That's the reason why you see same font family rendering so different, the local one is .ttf, the another could be woff, svg (I think for IE), and there is other posibilities. And same font on different formats looks different, sometimes too much different.
I think the best choice is to create that css by yourself, not asking it to Google, and remove the local part, but it's important to add the other formats, other way it will not work on all supported browser.
This is potentially a duplicate of this question but this was my answer to that:
Fonts render differently based on:
Screen/Monitor resolution
Browser
Operating System
Size of use and hinting
Without seeing your code the only things I can recommend are:
Making sure you are using decent reset css (something like this: http://meyerweb.com/eric/tools/css/reset/).
Try adding font-weight: normal; to fonts to see if this makes a difference; sometimes browsers and frameworks try adding a fake bold to things.
Assuring you are using the actual versions of the fonts and not just applying CSS styles.
If all else fails then try bumping the font-size up/down a small amount and see if the font hints better at these sizes.
Some people also recommend not using the #import or direct link from google. Perhaps try downloading the file and using #font-face in your css.
Hope this helps!
EDIT:
If you’re hosting the font yourself — double check the #font-face call. Make sure you are calling all versions possible of the typeface. Also, Some browsers prefer certain formats being called earlier.
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 was wondering if it's possible to, when using #font-face, have a fallback setup so that if the text on my page contains characters that are not accounted for within the font (Japanese characters for example), only those characters are presented in a basic font and every other character remains as the custom font?
I'm imagining that potentially there'd be a mix of two fonts within one paragraph on occasion.
What you described is the default behaviour of a browser - it should naturally fall back to basic font for missing characters.
However, sometimes custom fonts use blank characters, in that case you can try using the unicode-range
For example:
#font-face {
font-family: BBCBengali;
src: url(fonts/BBCBengali.ttf) format("opentype");
unicode-range: U+00-FF;
}
Taken from this interesting article: Creating Custom Font Stacks with Unicode-Range
Unfortunatelly there are browser support issues.
CSS has default fallback to the system font if the specified font doesn't contain a character.
You can also specify which font to fall back to.
Example for a serif font:
body {
font-family: "MyNiceFontWithoutJapanesChars", "common serif font", serif;
}
As long as the fallback font has those characters your default font misses, you should be all right.
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.