So I sometimes want to emphasize certain words like this:
<h1>I want to <span class="emphasis">emphasize</span> some text.</h1>
At the same time, I would like to use a custom font for h1 text:
#font-face
{
font-family: 'MuseoSlab';
src: url('https://digital_time_capsules.s3.amazonaws.com/fonts/Museo_Slab_500-webfont.eot');
src: url('https://digital_time_capsules.s3.amazonaws.com/fonts/Museo_Slab_500-webfont.eot?#iefix') format("embedded-opentype"), url('https://digital_time_capsules.s3.amazonaws.com/fonts/Museo_Slab_500-webfont.svg#MuseoSlab500Regular') format("svg"), url('https://digital_time_capsules.s3.amazonaws.com/fonts/Museo_Slab_500-webfont.woff') format("woff"), url('https://digital_time_capsules.s3.amazonaws.com/fonts/Museo_Slab_500-webfont.ttf') format("truetype");
font-weight: normal;
font-style: normal;
}
Example here.
Problem is, Chrome in Windows overlaps the span text:
Firefox and IE don't seem to render the font smoothly:
Opera seems to render it just the way I want:
Can anyone tell me what's going on, and how I can fix these problems?
EDIT:
Sometimes I have that egregious problem in Chrome; sometimes I don't. And I have the latest Chrome installed, too:
The reason why Firefox and IE show the font the way they do is that h1 element has font-weight: bold by default, and you are declaring the font as normal weight. What this browsers do is arguably the correct move: in lack of a bold typeface, they algorithmically bold the letters.
To avoid that, add h1 { font-weight: normal; }. Alternatively, use a bold typeface of the font family.
The odd overlap in your Chrome sounds like an installation-specific problem, so you should first consider updating or re-installing Chrome.
I had once exactly the same issue with Chrome. It appears to be related to the rendering of SVG fonts in Chrome. If you change the order of the font files in the #font-face so that the SVG is at the end of the list, the issue disappears. Your example on jsfiddle still renders incorrect in the current version of Chrome (29.0.1547.76), so the render bug is still present.
Hopefully this helps someone in the future, but I was able to correct this issue by following the solution in the following question: Chrome svg-Font-Rendering breaks Layout
This successfully fixed the non-smooth edges without breaking the layout and/or squishing the fonts.
Related
Using the normal CSS font-face does not appear to work properly on the new Windows 10 Edge browser. Works fine on IE11 and all other browsers. Has anyone else seen this? Seems like a bug in the browser.
Here’s the CSS we’ve been using.
#font-face {
font-family: "Univers";
src: url("../fonts/univers-webfont.eot");
src: local(Univers), url("../fonts/univers-webfont.eot"), url("../fonts/univers-webfont.svg"), url("../fonts/univers-webfont.ttf"), url("../fonts/univers-webfont.woff");
font-weight: normal;
font-style: normal;
}
.button_black {
font-family: "Univers";
font-size: 18px;
color: #slb-off-black-1;
}
Short Answer
Put quotes around the font name when using the local("Font Name") syntax.
Explanation
"Univers" renders fine in both Edge and Firefox. Your "Please log in..." element, though, is targeting "Univers Condensed", which renders in Edge only if you use local("Univers Condensed") with quotes. That is probably because Edge is more strict that Firefox is. MDN says...
src URL for the remote font file location, or the name of a font on the user's computer in the form local("Font Name"). You can specify a font on the user's local computer by name using the local() syntax. If that font isn't found, other sources will be tried until one is found.
Some Snips
Here are some screen shots that show the problematic CSS and HTML on your site.
Univers Condensed
No Quotes on local()
I have imported a font in my code like this:
#font-face {
font-family: 'BYekan';
src: url('/Contents/Fonts/BYekan.eot');
src: url('/Contents/Fonts/BYekan.woff') format('woff'),url('/Contents/Fonts/BYekan.ttf') format('truetype'),url('/Contents/Fonts/BYekan.svg') format('svg');
font-weight: normal;
font-style: normal;
}
When I run my code in Chrome, sometimes some characters are shown like squares.
As soon as I resize the window, the characters go normal and they're displayed correctly!
I have <meta charset="utf-8"> in my code so the problem is somewhere else.
Any ideas? Thanx in advance.
Found the solution!
If we don't set font-size for out texts, the default font size is 1em. And apparently Chrome has problems with this font size for some fonts!
So I just set font-size something else (for example font-size: 1.001em) and now the fonts are displayed correctly :)
Try and check another font.
May be the errors in your font file.
I am having a weird issue in Chrome where a Google Font is showing inconsistent letter heights. It only happens when I use text-transform: uppercase and it is fixed if I use font-weight:bold. I have some example code, where you can see the S is too tall in the word TESTING:
body {
font-family: 'Exo 2' !important;
line-height:1.42857143;
}
div {
width:40px;
}
span.upper {
display:block;
margin-top:20px;
font-size:18px;
text-transform:uppercase;
}
span {text-transform:uppercase; }
<link href="//fonts.googleapis.com/css?family=Exo+2:200,300,400,700,300italic,400italic,700italic|Raleway:200,300,400,600" rel="stylesheet" type="text/css">
<div>
Broken:<br>
<a href="#">
<span class="upper">Testing 123</span> </a>
<br>Normal:<br><br>
<span>Testing 123</span>
</div>
If I change the font to arial, it's fixed. Is there some CSS property I need to reset so that the font will render correctly?
This is a well known bug in Chrome on Windows. Chrome has made the political/ecosystem move to reduce dependencies on other companies and other established tech, like the move to fork Blink from Web-Kit. Chrome has also decided to ditch Microsoft font rendering. The result is poor sub-pixel rendering. You've noticed that once you bump your font up in size or weight the issue is resolved because the character strokes are wider than one pixel.
One solution for you: you can go into Chrome's flags:// to enable Direct Write.
But that doesn't help your users, of course. There are a few hacks.
One hack is to change up your font stack, so that SVG is called specifically for web-kit.
You can do this with a media query hack:
#media screen and (-webkit-min-device-pixel-ratio:0) {
#font-face {
font-family: 'chunk-webfont';
src: url('webfont.svg') format('svg');
}
}
So there are issues with this. It's not future-proof. It's a hack. But it works for now, and Chrome will be fixing this in the near future. Other, hacks include calling SVG first in your stack, but it has less reliable results.
I was having the same issues with Windows browsers and I tried using SVG first in the stack but it didn't work - I later found out that Chrome has since ditched support for SVG fonts. So I tried using a TTF version of my font placed first in the stack and for some reason it resolved the issue. Tested it in Chrome, Firefox and Edge. Oddly if I reference the TTF in a data URI it goes back to inconsistent letter heights again.
I created a fiddle trying to use Open Sans font with font-weight 300:
HTML
<span class="demo">example</span>
CSS
.demo {
font-weight: 400 !important;
font-family: 'Open Sans' !important;
font-style: normal;
font-variant: normal;
}
I use Google fonts to define the CSS
I can see a difference in Firefox (Ubuntu 13.10) when rendering at font-weight: 300 (light) and at font-weight: 400 (normal) but none in Chrome (Version 33.0.1750.117
), where everything looks like it's rendered at font-weight:400. Am I doing something wrong or is there a bug in Chrome? Is there any known workaround?
Update:
There is definitely something wrong with chrome I have two instances of the same page open in 2 different windows in Chrome. One is rendering the font ok (300 weight corresponds to the light variant) and one is not (300 weight is the same as the Normal variant). Any clues? I've made sure to refresh the page in each tab so they are actually the same page.
Update 2:
Attached screenshot: of the bug:
Update 3
This is not a duplicate of this. In that question the problem is that "Arial Black" and "Arial" are different fonts actually. In my case Open Sans is the only font and the problem is Chrome picking up the incorrect weight some times. As you can see from the screenshots, Chrome is not consistent with the font rendered even between two instances.
Add this to your CSS:
* {-webkit-font-smoothing: antialiased;}
This seems to be a Chrome/Chromium bug, caused by having the font installed locally on your system. Other browsers don't seem to suffer from this issue.
So far, it seems to occur on Linux and Windows (confirmed).
For some reason, it will just load your local font and ignore any of your font-weight rules, even if they're !important. It won't even be consistent with itself: the font weight can change randomly between tabs and page reloads.
The simplest workaround is to remove the font, but that could be an issue if you need it for something else.
You might also try renaming the font to something else in order to force Chrome to use your web font and honour your CSS font rules.
I was having this issue with a variable font. It was solved by defining a font-weight range in the font-face definition.
#font-face {
font-family: …;
font-weight: 1 999;
src: …;
}
Try changing the font family to 'Open Sans Light', sans-serif;. I had the same problem and this worked for me.
i overlaid them on top of each other and they look good on osx chrome.
font-weight: 400 !important;
beneath
font-weight: 300 !important;
http://jsfiddle.net/gpmXe/22/
My solution is download and install all the weight types of the font on your machine, or don't install it at all. That's odd solution, but works for me.
For me the solution was to include the CSS in the head-section instead of using #import inside the stylesheet.
<link href="https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght#0,700;1,400&display=swap" rel="stylesheet">
In HTML use this instead of using it in CSS. Best Solution 👍
<link href="https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght#0,700;1,400&display=swap" rel="stylesheet">
Doc for ital & wght
Chrome 26.0.1410.64m on Windows 8 has problems rendering WebFonts. It is a known problem and a solution is to first serve the svg version of the font instead of the woff version. It fixes the anti-aliasing and makes font look pretty again.
The downside of this method is the weird rendering inside the element inside select inputs.
I added a jsfiddle to see it in action : http://jsfiddle.net/4mSpv/6/.
The CSS is as simple as it can be.
#font-face {
font-family: 'Montserrat';
src: url('https://raw.github.com/louh/website/master/fonts/montserrat-regular-webfont.svg#montserratregular') format('svg');
font-weight: 400;
font-style: normal;
}
select {
font-family: 'Montserrat', sans-serif;
}
I remove the local installation of a font and noticed an other windows 7 computer doing the same. Anyone knows what is going on with chrome? (IE, Firefox, Safari all render fine)
PS: Other browser fonts not included in JSFiddle to filter out the problem and each browser have their own quirks (not allowing font-size etc) but render the text fine
There is no way to solve this problem.
This is NOT a Regression issue and is existing from M24.
I submitted a bug report and it Weird character rendering in option menu
As automaticoo stated, it is a known issue with Chrome. However, you can workaround the issue with a technique mentioned in the selected answer for this post: Google Webfonts Render Choppy in Chrome on Windows.
#media screen and (-webkit-min-device-pixel-ratio:0) {
select {
font-family: Arial; /* standard font */
}
}
That way you can use whatever font you want for browsers that still work, and replace it with a generic HTML font for Chrome.
So, I was actually looking for an answer for this, and I stumbled upon this question. I noticed this bug still exists today ( I just met it, such a happy meeting... ). Now I only found 1 solution, which is placing the svg font last in the #font-face declaration (this also means including all other formats). The only problem is that, when you for exampling try fixing the font rendering (to make it all smooth and stuff) you'd actually put the svg first.
Here are some examples to demonstrate it
1: SVG font last, no crisp font, options are displayed right
#font-face {
font-family: 'OpenSansLight';
src: url('../font/OpenSans-Light-webfont.eot');
src: url('../font/OpenSans-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('../font/OpenSans-Light-webfont.woff') format('woff'),
url('../font/OpenSans-Light-webfont.ttf') format('truetype'),
url('../font/OpenSans-Light-webfont.svg#open_sanslight') format('svg');
font-weight: normal;
font-style: normal; }
So as you can see, the options in the select box show just fine, but the font really isn't that crips, just look at "Register" (you might notice this better in comparison with my second example)
2: SVG font last, crisp font, stupid options in select
#font-face {
font-family: 'OpenSansLight';
src: url('../font/OpenSans-Light-webfont.eot');
src: url('../font/OpenSans-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('../font/OpenSans-Light-webfont.svg#open_sanslight') format('svg'),
url('../font/OpenSans-Light-webfont.woff') format('woff'),
url('../font/OpenSans-Light-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal; }
Now you will see that the font is a lot more crisp but the select is really stupid.
I suggest adding another font-face with the svg last just for select's. This will keep your fonts crisp throughout the website but display the options just fine.