I'm using Google's Open Sans web-font as the main font in my website and it's rendering all the tilde character (~) as normal dashes while I'm using 13px as font-size
Is there a way to fix this without increasing font-size?
Use the full width tilde character.
Full width tile: ～
Regular tilde: ~
HTML escape codes: ～ ～
http://www.charbase.com/ff5e-unicode-fullwidth-tilde
Okay I found few methods to fix this issue.
Using <em>~</em>
Using <span class='tilde'>~</span> and applying some CSS like below:
.tilde { font-size: 14px !important; }
Update: fixed
Download fixed version here.
It's fixed in version 3.000! Which you can download from Google Fonts or their github.
Original:
It's a known bug in Open Sans. It was apparently fixed internally two years ago tomorrow, and the fix will be released “Hopefully in Q1 2020.”
FWIW, I see the same problem in MS Office at 2, 7, and 10, but not 13.
You can try a different font or font-family. For instance, the below fixes this problem at 13px:
font-family: cursive;
Related
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;
}
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
I'd like to include a down triangle in my CSS dropdown menu. It works correctly in every browser, except for IE9.
In normal browsers (Firefox, Opera, Chrome, etc.) it looks like this way:
However in IE9 it shows up like this:
The CSS code:
.parent-down > em:after,
.parent-down > a > em:after {
content: "\25be";
}
Any idea what can be the problem and how could I fix it?
You need to declare the font family for the (pseudo-)element containing the special character so that you use only fonts that are known to contain that character. For example, add the following rule into your declaration:
font-family: Arial Unicode MS, Lucida Sans Unicode, sans-serif;
When you declare Helvetica, as you say (in a comment) you do, Windows treats it as Arial by its own special internal rules (if Helvetica is not available, and it usually isn’t). Since Arial does not contain the character, the browser should check the different fonts in the system in some order set by its settings to find one that contain the character. Browsers may fail in doing so, and IE often does.
In this case, it is probably better to use another, more visible character, which happens to have better font coverage. The basic principle is still that special characters need special attention when declaring fonts. For generalities on this, see my Guide to using special characters in HTML.
I came to the solution by accident.
However IE9 doesn't show the "\25be" (▾) character, it shows the "\25bc" (▼).
It's the same down triangle, however somewhat bigger. So now I use this one and change its size with CSS, so it looks identical with the original version.
Don't ask why, IE9 is quite strange.
My new code:
.parent-down > em:after,
.parent-down > a > em:after {
content: "\25bc";
font-size: 8px;
vertical-align: 2px;
margin-left: 2px;
}
There is a bug in IE9 that causes the font of a container to be set to the font of the first element of that container. Try to set a :before selector like this:
.parent-down >em:before,
.parent-down> a > em:before {
content: '';
}
This will force IE9 to recognize that the font assigned to the container is the font meant to be used
See this site, which describes a similar issue and gives this workaround, which solved this very tricky problem for me.
As I mentioned in the title, when using css font-family, custom font (font-face), it messes up (black background, black text (I guess)) auto complete drop down list in Opera.
input[type='text'], input[type='password'], input[type='email'], input[placeholder] {
font-size: 1.2em;
font-family: sans-serif;
color: #2A873A;
padding-left: 25px;
}
Code above works fine, but if I replace "font-family: sans-serif;" with some font-face font (google web fonts too), then problem starts.
Here is the screenshot of "bug" in action.
P.S. I should mention that that is Opera's native autocomplete, not custom js, dropdown list.
EDIT:
http://jsfiddle.net/burCR/
Have you tried specifying the font directly in your css? for example:
div.magicsomething {font-family:CustomFont,Customfont2,sans-serif;}
Keep in mind nested elements get stuck with custom fonts, so if you don't do the above, you may also very well need font-family:inherit in your 'nested elements'.
For extra help, please mention the name of the custom font, your full css and a live link to your site
Although this may be something obvious, check to make sure that your font is compatible with Opera. Here is a list of some web safe fonts.
http://www.w3schools.com/cssref/css_websafe_fonts.asp
And if that doesn't work try taking the font you want from microsoft word and use #fontface to insert you custom font instead of using a websafe one.
And finally try using your font-family on the form and have the input inherit the font.
Hopefully this helped.
Ditto to specifying the font directly. You may also want to try using base64 encoding, which in my experience works beautifully and with great cross-browser compatibility.
You can specify colors for both the background and the text individually.
input {
background-color: white;
color: black;
font-family: "My Fontface Font", Verdana, ms serif;
}