Google Font Letter Height Not Consistent - html

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.

Related

Why is my SVG text different sizes in Chrome and Firefox? [duplicate]

font-variant: small-caps;
font-size: 12px;
Firefox:
Capital letters: 12px
Lowercase letters: 10px
Chrome:
Capital letters: 12px
Lowercase letters: 8px
How to harmonize that without using JavaScript?
Webkit browsers display small-caps smaller than other browsers so.. You can use CSS media queries to easily sniff out webkit browsers like Chrome and Safari. Try something like this:
#media screen and (-webkit-min-device-pixel-ratio:0) {
.some-element-using-small-caps {
font-size: .85em
}
}
You can target the browsers individually by using css hacks like this:
#-moz-document url-prefix() {
//firefox specific css here
}
#media screen and (-webkit-min-device-pixel-ratio:0) {
//chrome specific css here - this will also hit other webkit browsers like safari tho
}
A nicer way however in my opinion involves a tiny bit of javascript that detects the browser and sets a class on the html element and then you can use that class as a base for targeting the individual browsers.
in the end it would look something like this:
<html class="firefox">
...
</html>
.firefox .rulename {
//firefox specific css here
}
and of course the same for chrome and whatever else browser
I am having a similar issue with a much weirder issue between Safari on iPad vs Safari on Desktops, showing a different scale for small-caps at 16px. For some reason small-caps is a bigger size on iPads, kinda matching that of Firefox.
Adjusting the font size or letter-spacing a half pixel less or so, can mitigate the issue without further additional hack. By essentially finding a tiny middle adjustment which trigger on one browser but not on another, to try and get as close as possible.
What I have observed for Firefox and IE, is that fonts tend to scale with many more intermediate sizes than that of Webkit. For example, in IE and Firefox, 15.6px is a tiny bit bigger or use more tracking to adjust, than that of 15.5px, and so is 15.7px, 15.8px etc. With a difference for nearly every 0.1 pixel. Whereas in Safari the difference is only perceived for every 0.4px or so.
For my small-caps case here which created an overflow issue, I used 15.5px, which is barely different from 16px on Safari (Desktop), yet bring down the small-caps size for IE and Firefox as close as possible to Safari's.

Emoji rendered in Chrome have different widths than in other browsers

I have a page with an emoji followed by a space and some text. For example, "๐Ÿ‘ฅ Friends" (character is "busts in silhouette", U+1F465). In Safari and Firefox on macOS, it renders with a space between the emoji and the following text as expected.
In Chrome, however, the space appears as if it's absent:
If I remove the space, Chrome renders the text overlapping with the emoji. It seems like the width of emojis as rendered in Chrome is less than the actual character width.
Is there any way I can get the desired appearance (a normal-width space) cross browser without resorting to an image or icon font? I've tried messing with some CSS properties like text-rendering without success.
<style>
.friends {
font-family: Helvetica, Arial, sans-serif;
}
</style>
<span class="friends">๐Ÿ‘ฅ Friends</span>
JSFiddle
I had the same issue, and found out that it happened on non-retina screens only.
To fix it, we applied a margin through a media-query like this:
<span class="friends"><span class="emoji">๐Ÿ‘ฅ</span> Friends</span>
<style>
#media
not screen and (min-device-pixel-ratio: 2),
not screen and (min-resolution: 192dpi) {
span.emoji {
margin-right: 5px;
}
}
</style>
This is a pretty minimal media-query. You should probably use a more complete one like https://stackoverflow.com/a/31578187/1907212.
This is a Chrome bug (See detail here)
This is related to displaying emojis in Mac Chrome on a non-retina screen. My monitor had a non-retina screen (where the spacing / cursor position were info), but were absolutely fine on my Mac.
It's February, 2020, and this issue still very much exists (link to open Chrome bug). Chrome 88.0.4324.150 on MacOS X 10.15.7 on a 2019 16" MacBook Pro: dragging a browser window between the internal Retina monitor and an external ultrawide monitor changes the rendering of the emoji.
As an alternative to Julien's answer, instead of selectively specifying a margin-right to correct an imbalance, we can "force" the width of the actual emoji character(s) to be equal in a cross-browser way using letter-spacing.
In essence, our issue is that most characters with the Roman alphabet don't have a height-to-width ratio of 1:1, but most emojis (roughly) do have a height-to-width ratio of 1:1. This is one way of describing what we're seeing with the spacing between emojis and ANSI characters.
See example screenshot here
letter-spacing sets the horizontal spacing behavior between text characters. When paired with CSS em units, we can use this property to "force" each character/emoji to render in a roughly 1:1 box. This might need to be adjusted depending on the font or character set you use.
According to the sources below, a Roman character is often roughly 0.5 as wide as it is tall, so we can simply do:
span.emoji {
letter-spacing: 0.5em;
}
<span class="friends"><span class="emoji">๐Ÿ‘ฅ</span> Friends</span>
<style>
span.emoji {
letter-spacing: 0.5em;
}
</style>
This method means that in browsers that render emojis correctly, we aren't adding an extra margin-right.
https://graphicdesign.stackexchange.com/a/114955
https://web.archive.org/web/20210118205344/https://www.lifewire.com/aspect-ratio-table-common-fonts-3467385
What I would do is add another span within the .friends span that contains the emoji, have it use a right margin, and not have a space after it:
.friends {
font-family: Helvetica, Arial, sans-serif;
}
.friends span {
margin-right: 10px;
}
<span class="friends"><span>๐Ÿ‘ฅ</span>Friends</span>
That way you don't have to worry about space rendering ;)
Hope this helps! :)
Removing BlinkMacSystemFont from font-family fixed issue for me, you need to close and reopen tab to see effect.
As of (at latest) Chrome 79, this issue no longer exists.
This problem still exists on Chrome 83 on MacOS ๐Ÿคจ
I think I found the solution
[data-emoji] {
font-style: normal;
font-weight: normal;
}
[data-emoji]:before {
content: attr(data-emoji);
margin-right: .125em;
}

Font weight ignored in Chrome

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

HTML/CSS Webkit font render in webkit

So now i am very frustrated. You surely know Google Chrome with his font-face render problems. So i am currently redesigning my website an also i added a modern looking font with #font-face but in webkit (safari and chrome) it just looks horrible. One letter looks very sharp the other one is blurred out and so on ... I've tried it wih the webkit antialising function in css but this doesn't seems to work. I've read that Google deactivated that. Anyway i also tried it with the tricks with text-shaddow and text-stroke it worked a little bit but doesn't look very good. I saw other websites with the same font and there it looked fantastic. So how did they managed it? Is there another possibility to solve this?
Thanks.
http://blog.teamtreehouse.com/increase-your-sites-performance-with-hardware-accelerated-css
Towards the bottom of this article, it suggests applying the CSS below to smooth transitions.
.cube {
-webkit-backface-visibility: hidden;
-moz-backface-visibility: hidden;
-ms-backface-visibility: hidden;
backface-visibility: hidden;
-webkit-perspective: 1000;
-moz-perspective: 1000;
-ms-perspective: 1000;
perspective: 1000;
}
It forces the browser to use your GPU to render the CSS. A byproduct of this, for me, was smoother fonts -- consistent cross browser, and regardless of the transforms being applied. Maybe someone can chime in with why this worked!? Although I am not positive, I think it's likely this could help.
This is the site I tried it on, only built for Chrome right now;
http://dev.sitesma.de/
The black boxes underneath the 4 gray bubbles have text that shows extremely sharp inconsistently depending on browser on transition without the above CSS applied.
To avoid Chrome's font rendering problems, try this solution by Icomoon. It suggests loading the SVG font instead of the WOFF for Chrome. The SVG font will render properly on Chrome/Windows, and the only drawback is the bigger size of the SVG font file.
Load the font for Chrome only by adding this CSS:
#media screen and (-webkit-min-device-pixel-ratio:0) {
#font-face {
font-family: 'icomoon';
src: url('fonts/icomoon.svg#icomoon') format('svg');
}
}

Custom font rendering problems

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.