I use as font-family stack like this:
body{
font-family: icon, 'Merriweather Sans', ui-sans-serif, sans-serif;
}
with icon being an icon-font that has some symbols in it for example arrows, which can occur in copy text or headlines.
The icon font is loaded like this (simplified example):
#font-face {
font-family: 'icon';
src: url(icon.woff2);
unicode-range: U+1F872, ..., ...;
}
That way whenever the 'arrow bold to right' is used in a text it will be rendered in the icon font. It works well and is foolproof.
I also use (simplified example again)
p.text{
max-width: 70ch;
}
which ensures that text paragraphs don't have too many characters in one line for readability.
Firefox makes those text paragraphs a lot smaller than chrome. And after some experimenting, I found that FF uses the icon-font to determine the width of the zero while Chrome uses Merriweather Sans.
The icon font has no zero-glyph in it and would be hindered by its Unicode range to display one.
So at first glace it seems correct that Chrome calculates ch based on the first font-family in the stack that contains a zero and is allowed to render a zero.
On the other hand I'd think that for calculating the abstract ch unit one can argue that the actual presence ot the zero character isn't necessary. Also it should be perfectly ok if one would use one font only for displaying number (through Unicode-Range) while the next font displays letters. What font should be used for calculating the ch value then?
Can anyone tell me if one or the other browsers does it wrong and the other does it right?
And has anyone an idea for a good workaround?
I've been building this site for a while, however the font I use for headers looks ragged on Windows using Chrome, although it looks perfect on Mac or using Edge: Link
I did try the various font smoothing properties to no avail and using text-shadow makes it look strange.
Is there anything else I can try?
The font I use for headers looks ragged on Windows using Chrome
Your webkit-font-smoothing rule is missing a - prefix, it should be -webkit-font-smoothing
To solve the issue of Chrome font-rendering, add -webkit-text-stroke: 0.3px;
Difference:
Final code:
h1, h2 {
-webkit-font-smoothing: subpixel-antialiased;
-webkit-text-stroke: 0.3px;
}
* You may need to apply the above CSS to all selectors that use the custom font.
Preview
Original answer: https://stackoverflow.com/a/11493510/877671
voting to close as duplicate.
I've seen a few issues with the cursor being improperly spaced in the ace editor. The problem has to do with the font-spacing and apparently the solution is to only use monospaced fonts.
Here's another SO question about the issue.
ace editor cursor behaves incorrectly
My problem may have something to do with using a Bootstrap theme, but I'm not entirely sure.
When I open chrome dev tools and look at the font used in the ace editor, it says that my Bootstrap template is using the fonts
input, textarea, input[type="submit"]:focus, div {
outline: 0 none;
font-family: 'Open Sans', sans-serif;
}
If I add to my css
.ace-editor {
font-family: monospace !important;
}
I still have a problem with the cursor spacing being wrong, and strangely, the font which is being used looks exactly the same as the 'Open Sans' defined in Bootstrap.
Opening in Chrome dev tools, says that the computed property is 'monospace', so something is supposed to be working, but it isn't. Here is where it get really weird.
If I remove the font entries for both .ace-editor and input, textarea..., I get a perfectly good looking font that works.
Going to the computed properties, is shows the font-family to once again be 'Open Sans'.
So the question I'm trying to answer, is how can I either figure out what font is ACTUALLY being used when I cancel out the textarea entry from Bootstrap? Or why is this not accepting the monospace font when it is specified.
I'm somewhat assuming that 'Open Sans' may be monospaced, but whatever, it's still causing massive headaches.
The issue is caused by div included in bootstrap rule.
It is too broad and breaks character width measurements for ace.
You can add
.ace_editor div {
font: inherit!important
}
as a workaround. Would be good to also report an issue to the creator of your bootstrap template.
I must have went through every page of google but haven't found the solution yet. I have a custom font that I'm using through css font-face. The font adds extra padding on the bottom depending on the browser and OS that I am using. The picture below shows an example with mac being on the left and windows on the right. It looks correct on the right (in windows) and i want it to be the same on mac.
#font-face
{
font-family: universLight;
src: url('http://www.viggi.com/fonts/UniversLTStd-Light.otf');
font-weight: normal;
font-style: normal;
}
#button{
font-family: universLight;
border: 1px solid black;
background: #ccc;
}
The code is located at http://jsfiddle.net/ZDh5h/
Here is what I already know won't work from my research.
line-height adds padding to the top and bottom so the extra padding on the bottom remains.
using different extensions such as .otf or .ttf also doesn't work. Just produces the same results
changing the font-size also doesn't really do anything
I use this font a lot through out the site and don't really want to add different CSS sheets for mac vs windows. If anyone knows anyway to fix this without having javascript add extra padding I will be very grateful.
Thank you.
See http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
normal
Tells user agents to set the used value to a "reasonable" value
based on the font of the element. The value has the same meaning as
. We recommend a used value for 'normal' between 1.0 to 1.2.
The computed value is 'normal'.
I think the behaviour you observe comes from different "reasonable" values across browser as normal is the default line-height value.
So specify your value (say line-height: 1.5em;) to get rid of the differences.
Recently a client has complained about the appearance of a system font in IE6. Basically th issue is that IE6 doesn't support font-smoothing/anti-aliasing (I know you can turn it on in an OS setting or something). But someone threw out this gem:
"You can force font anti-alias in css by using pt instead of px."
I did a quick POC in various browsers and saw no difference. I found one reference to it online, last post on this forum:
http://www.webmasterworld.com/css/3280638.htm
This sounds like the equivalent of a web developer urban myth, my feeling is it's BS. Has anyone ever encountered it?
Oh yes you can:
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
font-smoothing: antialiased;
Source for Firefox, thanks Justin for the heads up.
There's these exciting new properties in CSS3:
font-smooth:always;
-webkit-font-smoothing: antialiased;
Still not done much testing with them myself though, and they almost definitely won't be any good for IE. Could be useful for Chrome on Windows or maybe Firefox though. Last time I checked, they didn't antialias small stuff automatically like they do in OSX.
UPDATE
These are not supported in IE or Firefox. The font-smooth property is only available in iOS safari as far as I remember
No, there's not really any way to control this as a web developer.
Small exceptions are that you can do some fake forcing of anti-aliasing by using Flash through sIFR, and some browsers won't anti-alias bitmap/pixel fonts (as they shouldn't, more info: Anti-Aliasing / Anti-Anti-Aliasing).
Also, as Daniel mentioned, it's ideal to be using em units for all fonts, see The Incredible Em & Elastic Layouts with CSS for more information about this.
I found a really awkward solution using the zoom and filter ms-only properties
Example (try with no aa, standard and cleartype):
http://nadycoon.hu/special/archive/internet-explorer-force-antialias.html
How it works:
-zoom up text with zoom:x, x>1
-apply some blur(s) (or any other filter)
-zoom down with zoom:1/x
It's a bit slow, and very! memory-hungry method, and on non-white backgrounds it has some slight dark halo.
CSS:
.insane-aa-4b { zoom:0.25; }
.insane-aa-4b .insane-aa-inner { zoom:4; }
.insane-aa-4b .insane-aa-blur { zoom:1;
filter:progid:DXImageTransform.Microsoft.Blur(pixelRadius=2);
}
HTML:
<div class="insane-aa-4b">
<div class="insane-aa-blur">
<div class="insane-aa-inner">
<div style="font-size:12px;">Lorem Ipsum</div>
</div></div></div>
You can use this short jQuery to force anti-aliasing, just add the ieaa class to anything:
$(function(){ $('.ieaa').wrap(
'<div style="zoom:0.25;"><div style="zoom:1;filter:progid:DXImageTransform.Microsoft.Blur(pixelRadius=2);"><div style="zoom:4;"><'+'/div><'+'/div><'+'/div>'
); });
Adding the following line of CSS works for Chrome, but not Internet Explorer or Firefox.
text-shadow: #fff 0px 1px 1px;
I disagree with Chad Birch. We can force anti-aliasing, at least in Chrome using a simple css trick with the -webkit-text-stroke property:-
-webkit-text-stroke: 1px transparent;
I say its a myth.
The only difference I've found between pt, px, and percent based fonts is in terms of what IE will scale when the Menu > View > Text Size > ?Setting? is changed.
IIRC:
the px and pt based fonts will NOT scale
percent based fonts scale in IE just fine
AFAIK:
The font anti-aliasing is mostly controlled by the windows setting for "ClearType" or in the case of IE7/IE8 the IE-specific setting for ClearType.
I think you got it a bit wrong. Someone in the thread you pasted says that you can stop anti-aliasing by using px instead of pt, not that you can force it by using the latter. I'm a bit sceptical to both of the claims though...
The px to pt fix worked for me on a site that uses a font from Google Web Fonts. On Win7 - IE8 it correctly fixed the lack of anti-alias rendering.
Using an opacity setting of 99% (through the DXTransform filters) actually forces Internet Explorer to turn off ClearType, at least in Version 7. Source
Here's a nice way to achieve anti-aliasing:
text-shadow: 0 0 1px rgba(0,0,0,0.3);
I doubt there is anyway to force a browser to do anything. It would depend on the system configuration, the font used, browser settings, etc. It sounds like BS to me too.
As a note, always use relative sizes not PX.
Seems like the most exhaustive solution can be found at http://www.elfboy.com/blog/text-shadow_anti-aliasing/. Works in Firefox and Chrome, although Firefox is not quite as effective as Chrome.
As a side note, Gecko and WebKit support the the
text-rendering
property as well.
Not a pure CSS but natively supported method without any font replacement hacks:
Simply convert your font to SVG and place it higher(before WOFF or TTF) in #font-face order. Voila! Fonts are smooth now, because they're no longer treated as a font but an SVG shape which will be nicely smoothened.
Note: I noticed that SVG can weight more than WOFF or TTF.
I found a fix...
.text {
font-size: 15px; /* for firefox */
*font-size: 90%; /* % restart the antialiasing for ie, note the * hack */
font-weight: bold; /* needed, don't know why! */
}