I want to use the Aller font on my website, which seems to work fine in Firefox. In Chrome however, the 's' and 'k' characters (and only those) have a bigger height than the other characters.
The font renders correctly in Firefox (on Linux and MacOS), in Chrome (on MacOS), but not in Chrome on Linux. Font is not installed locally on the Linux machine.
Css rule:
#font-face {
font-family: "Aller";
src: url("../fonts/aller/Aller_Lt.ttf");
font-weight: 400;
font-style: normal;
}
Chrome (on Linux) preview of the font (seems to be good):
Screenshot of text on my website with incorrect font rendering (taller 's') with Chrome:
Screenshot of same website on same machine with Firefox with correct font rendering:
How can I make sure that in Chrome the font is rendered correctly? Is this an issue with Chrome, my code or the font itself?
This is usually a problem with fonts that aren't hinted, or not hinted correctly. There are PS Private settings you can configure in the font (called BlueValues, or OtherBlues - more information on these here) that help keep all of the characters on the same line like this - if they aren't present, the rendering just chooses the closest pixel without regard for if it's above the others. The problem will be less noticeable in the larger font sizes, and will vary from browser to browser like you've witnessed.
It doesn't look like this font is hinted - looking at the specimen page, you can see a similar issue with the a and p of alphabet. I'd advise trying to use a hinted font, or adding the hints yourself, if you're interested in that (and the license allows it).
Related
My website has the following base font:
body {
font:300 16px/1.5 Ubuntu,sans-serif;
...
}
The font is loaded via Google Fonts:
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Ubuntu:300,300i,700,700i&subset=greek,greek-ext">
All is expected font-wise in most browsers. However, on Chrome on Linux, I'm seeing the base font displayed with what appears to be font weight 500 instead of 300. The screenshot shows what I'm talking about. The normal text is too heavy. The italic text is displayed at the correct weight (and created using unstyled <em> tags). It also shows that Chrome understands that it's supposed to be using 300 weight.
This issue doesn't appear in Chrome on Windows or MacOS--only Linux. In addition, I've seen it in an old version of Chrome (48.0.2564.116) as well as a current Chromium (70.0.3538.67). I have no issues with Firefox, Edge, or Opera on any OS I've tested. My Linux machine is running Ubuntu 16.04. In addition, Chrome renders the Ubuntu font correctly at all weights on fonts.google.com.
Any ideas what may be going on?
This is due to a bug in Linux (possibly just Ubuntu).
How I solved it: The Googlefonts url fetches a plain text of css font-face rules (you can see that if you just call it from the browser). They contain the srcs where to look for the fonts in prioritized order. Googlefonts looks for local fonts first and then if they don't exist fetches them from their remote locations:
#font-face {
font-family: 'Ubuntu';
font-style: normal;
font-weight: 300;
src: local('Ubuntu Light'), local('Ubuntu-Light'), url(https://fonts.gstatic.com/s/ubuntu/v13/4iCv6KVjbNBYlgoC1CzjsGyN.woff2) format('woff2');
unicode-range: U+0000-00FF, ...
}
This is generally a good idea because fetching fonts that are already installed on the system is unnecessary and slows down page loading. However, there is a known bug in Ubuntu that causes the wrong installed fonts to be loaded: https://bugs.launchpad.net/ubuntu/+source/fonts-ubuntu/+bug/1512111 The font names on Googlefonts are actually correct, but for some reason the OS does not process them correctly. So, there is no way for Google to fix that on their side.
My solution is to just remove the local srcs in order to immediately fetch the fonts from remote. (I actually wonder why Google doesn't offer a "skip local fonts" option by default, maybe they don't want to waste their resources.) In that case it probably doesn't even matter performance wise because all other systems besides Ubuntu don't have this as a local font anyways.
Here's how I skip local fonts using Javascript:
fetch('https://fonts.googleapis.com/css?family=Ubuntu:300,400,500,700')
// get browser/OS specific googlefont font-face file and convert to string to make adjustments
.then(res => res.text())
.then(googleFonts => {
// remove "local" src locations to force using remote (or browser-cached) fonts (no locally installed system fonts)
googleFonts = googleFonts.replace(/local(.*),\s/g, '')
Note: It's important to not just copy the css from when you look at it in the browser because it varies depending on browser/OS - which is the whole point of Googlefonts.
Note: I'm not sure how to use this in HTML, but considering the JS generates plain text it should be easy to figure it out with css's #import from file.
I include say "Noto Sans" or "Ubuntu" on my webpage via css "#import".
If I compare the rendering on my page with the rendering on the GoogleFonts page it looks different for both fonts.
Even though I paste the same text into GoogleFonts and choose the same size, same background, same color.
Here is a picture: (especially visible with the "A")
Any idea if there is a setting I miss?
As you can see neither the weight nor the size matches. Especially the weight seems to be a problem. Comparing "Noto Sans" the font with the same weight looks much thicker on my page.
I downloaded the fonts from google into my system. But this also applies if I delete these fonts and the browser uses remote fonts.
I use MacOSX but checking in Browserstack it seems that the problem is effective in several browsers. I tested in Win7 with IE9 too.
Not sure about the IE browsers, but have you tried adding -webkit-font-smoothing: antialiased;? Google also uses -ms-text-size-adjust: 100%; for IE.
I am trying to use AGA Arabesque font (downloaded from here), with this CSS:
#font-face {
font-family: 'AGA Arabesque';
font-style: normal;
src: url('//example.com/wp-content/uploads/useanyfont/140705120824ARABSQ.eot');
src: local('AGA Arabesque'), url('//example.com/wp-content/uploads/useanyfont/140705120824ARABSQ.eot') format('embedded-opentype'), url('//example.com/wp-content/uploads/useanyfont/140705120824ARABSQ.woff') format('woff');
}
I am able to use the font properly in Chrome. In the latest Firefox and IE, all I see is an English letter in place of the desired symbol.
In Chrome:
In Firefox:
What could be going wrong? Is there a way I could use base64 encoding to try and get around this issue?
EDIT: Other fonts, used this way, work correctly on all three major browsers
I converted the font to WOFF, and I found that all glyphs got mapped into the Unicode Private Use Area, in the U+F000 block. I don't know if this is a bug in the conversion tools or in the font. But given that this font is quite old (it's dated 1994, so it's from the Windows 3.1 era), it's likely that it doesn't comply with current standards.
I see two options to get this font working:
Get a font editor and fix the character assignment.
Use entity references to access the glyphs. Not very convenient, but possible: look up the hex code for your character in an ASCII table, add F0 in front of it, and use that code in an entity reference. E.g. [ has hex code 5B, so use entity refrence . (Sample page download)
This works in Firefox and Chrome for me. I don't have a Windows system handy to test Internet Explorer and the EOT format, but I suspect the situation there will be identical.
I'm afraid your WebFont is too large to be considered for rending. During testing even Chrome decided to render with Times New Roman.
If you're only using a set of characters from the font, consider creating a new font with only those characters.
Encoding the font using base64 will on narrow your audience, since not all browser support it. Interestingly enough the webfonts are loaded without an error, the browser simply refuse to render them, even the font preview in Chrome is just plain Times New Roman.
Also the link you posted doesn't link to a web font, just to a regular desktop font.
http://img31.imageshack.us/img31/6730/4x1f.png
This is an example of the pixelated text when I set the font size to anything other than 80 or 65. Would anybody happen to know why the text gets pixelated like this?
Code to replicate this issue:
<div class="top_text">Hello! Please check back some other time, this website is in development.</div>
.top_text{
font-family: "Arial Black";
font-size: 38px;
}
Browser: Google Chrome
OS: Windows 8
It looks aliased, I would rather it be antialiased.
Google Chrome currently uses a really old text-rendering method, GDI, on Windows. Source. Firefox, IE (and most other applications you run) use ClearType, which has lots of features (like font hinting) which make text look more "anti-aliased".
Chrome devs are supposedly fixing it; if you believe the above link, the fix is due to be released soon. For now, however, most fonts will look badly-aliased in Chrome, except at specific font sizes.
[REVISED]
My custom icon font is not rendering in Mobile Safari on iOS 5. I've confirmed that the problem must be with my CSS.
The font works fine on iOS 6 and on desktop versions of Safari, Chrome, Firefox, and IE9 when using the corresponding eot and woff formats generated by http://www.fontsquirrel.com
#font-face
I'm currently using the following simplified #font-face declaration (SASS):
#font-face
font-family: 'Boundless'
src: asset-url('boundless.ttf', font) format('truetype')
font-weight: normal
font-style: normal
The following HTML works (it renders the desired icon character in Mobile Safari on iOS 5.1:
<h1></h1>
However, I see a <?> glyph if I try to render it in the way that Font-Awesome does:
SASS
i.bicon-biology:before
font-family: "Boundless"
content: "\f0000"
HTML
<h1><i class="bicon-biology"></i></h1>
Yet Font-Awesome icons render fine on the site.
Does anyone know what might be causing this issue?
I should also add that I tried all the recommendations made here: #font-face not embedding on mobile Safari (iPhone/iPad) and none worked. This includes adding the smiley-face hack, making sure my font urls are absolute, and trying svg fonts (which shouldn't be neccessary for iOS 5 anyway).
Mobile Safari apparently just doesn't like the utf-8 addresses I was using (/0f0000-/0f001e).
I edited the font to move the characters to the same positions that Font-Awesome uses (/00f000...), and presto, it works!
I also checked whether adding/removing 0's padding the left made a difference, and it works either way. There's just something about the other address range. :\
AGAIN: This is only an issue when the codes are used in pseudo element content. As you see above, (and ) rendered just fine when it was directly in the HTML.