Chrome on Windows ^^^^
Chrome on Firefox^^^^
This seems to only happen at certain sizes and letters when the font in question does not have a supplied "bold" weight but one is declared in the styles. This "faux" bold is fine for all characters in Firefox, but not in Chrome (as of 109.0.5414.75) on Windows. As you change the size, even by fractions of pixels, it can come and go with no rhyme or reason.
Here is a codepen that illustrates the issue if you are in Windows Chrome: https://codepen.io/harrison-rood/pen/wvxyQer
<style>
body {
line-height: 1.6;
font-size: 16px;
color: #212529;
font-family:sans-serif;
font-weight:400;
}
.ct-text-block {
font-family:"Average";
color: #000;
font-weight: 700;
margin-top: .75em;
margin-bottom: .5px;
font-size: 1em;
/*change the above to font-size:1.01em to fix the issue*/
}
.larger{
font-size:16.5px
}</style><link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Average&display=swap" rel="stylesheet">
<body> <p>This seems to only happen at certain sizes, in this case 16px, and letters (K & R) when the font in question does not have a supplied "bold" weight but one is declared in the styles. This "faux" bold is fine for all characters in Firefox, but not in Chrome (as of 109.0.5414.75) on Windows. </p><div id="text_block-13-57265" class="ct-text-block"><span id="span-14-57265" class="ct-span">Here are Faux Bold characters at 16px:AAA BBB CCC DDD EEE FFF GGGG HHHH III JJJ KK LLL MMM NN OOO PPP QQQ RRR SSS TTT UUU VVV WWW XXX YYY ZZZ</span>
<div id="text_block-13-57265" class="ct-text-block larger"><span id="span-14-57265" class="ct-span">Here are Faux Bold characters at 16.5px:AAA BBB CCC DDD EEE FFF GGGG HHHH III JJJ KK LLL MMM NN OOO PPP QQQ RRR SSS TTT UUU VVV WWW XXX YYY ZZZ</span>
</div>
<div style="font-size:2em" id="text_block-13-57265" class="ct-text-block"><span id="span-14-57265" class="ct-span">2em (32px): KK RRR</span>
</div>
<div style="font-size:34px" id="text_block-13-57265" class="ct-text-block"><span id="span-14-57265" class="ct-span">34px: KK RRR</span>
</div>
<div style="font-size:5em" id="text_block-13-57265" class="ct-text-block"><span id="span-14-57265" class="ct-span">5em (80px): KK RRR</span>
</div>
<div style="font-size:90px" id="text_block-13-57265" class="ct-text-block"><span id="span-14-57265" class="ct-span">90px: KK RRR</span>
</body>
The font is not installed locally, as I've seen that be the cause in other cases. This is also not limited to my computer, as I've test a few others both on Win 11 and 10 and the same thing happens. Mac seems to work fine regardless of browser, at least in my limited testing.
I would expect that fonts would render consistently between characters, even if those results were sub-optimal. I know the faux-bold probably throws a wrench in everything, but its weird that some characters work consistently, and others break depending on size.
The font is not installed locally, as I've seen that be the cause in other cases. This is also not limited to my computer, as I've test a few others both on Win 11 and 10 and the same thing happens. Mac seems to work fine regardless of browser, at least in my limited testing.
Related
iPad Safari doesn't show feet (′ = \u2032) and inch (″ = \u2033) signs (prime and double prime, according to unicode specification) when using Anago font.
As I understand, this font doesn't contain corresponding symbols, but desktop browsers (including Safari on Mac) show them in default font. By some reason iPad behaves in the other way.
Also I checked the other chars not presented in the fiont (replaced latin ace via cyrillic асе), And they were shown using default font (see bellow).
What's the problem with these two chars?
How I can force them shown in default font?
<!doctype html>
<meta charset=utf-8>
<title>iOS Safari doesn't render feet and inches</title>
<style>
#font-face {
font-family: "Anago";
src: url("Positype - Anago-Book.otf");
font-weight: 300;
}
body {
font-family: Anago, sans-serif;
font-weight: 300;
font-size: 4em;
}
</style>
<p>Just a test - latin</p>
<p>Just а tеst - lаtin аnd сyrilliс</p>
<p>5′ 9.7″</p>
<p style="font-family: sans-serif">5′ 9.7″</p>
Desktop Chrome on Windows:
Desktop Safari on Mac:
Safari on iPad:
Other iPad browsers behave like iPad Safiri.
FontForge shows following for these chars:
PS: Same question in Russian.
I've imported the (in)famous open sans to my CSS. Everything was fine at first.
However, today I noticed that some of the characters (şğü) are not being displayed properly in Firefox. They work fine in Internet Explorer and Chrome, but they're being replaced by the default font in Firefox.
I was thinking, this should be a quick-to-solve issue. Any ideas?
#import url(http://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700,700italic,800,800italic);
p {
font-family: "Open Sans";
font-size: 4em;
}
<p>Example şğü.</p>
By default, many Google fonts support Basic Latin repertoire only (effectively Windows Latin 1 set); this covers e.g. ü but not the Turkish letters you are using. The repertoire can be selected with checkboxes in the UI of Google Fonts, but this is rather unnoticeable. In this case, you need to add the parameter subset=latin,latin-ext:
#import url(http://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700,700italic,800,800italic&subset=latin,latin-ext);
p {
font-family: "Open Sans";
font-size: 4em;
}
<p>Example şğü.</p>
There's a bug, or something, on my client's site where if you switch the language to any of the Asian options (CJK) then open the language selector again, "Russian" (in Russian), "Greek" (in Greek), and "Serbian" (in Serbian) have extra spaces between the letters. If you choose any other language, these words are fine in the language option list. The following style is on html element -
font: 200 100%/1.5 sans-serif;
I read that on Macs, sans-serif will pull in Helvetica as its first choice, and on Windows, it will be Arial. In the my dev tools, if I change sans-serif to Helvetica, it changes the font and fixes the problem, rather than the font looking exactly the same, which is what I expected. (I do have Helvetica on my Mac. I haven't checked this in Windows yet.) Below is a sample screenshot.
Actually, now that I've played with it a bit more, I found that when I select Korean, the non-Korean words are rendered in Apple Gothic, for Chinese the non-Chinese words are in Century Gothic, and for Japanese the non-Japanese words are in Avant Garde. Any thoughts on why? I could just create a rule set that assigns Helvetica, Arial, sans-serif as the font stack for these languages, but any explanation on what's going would be a great learning experience.
Edit: When I mentioned Apple Gothic, Century Gothic, and Avant Garde, what I meant was that for each of the Asian languages, I changed 'sans-serif' to some other font name in my dev tools to see if I could determine what sans-serif font was being defaulted to in CJK for the non-Asian words on the page. I find it weird that Chinese, Japanese and Korean each used a different sans-serif font.
Sample code of the language option list -
<ul>
/* other LIs here */
<li>Ελληνικά</li>
/* other LIs here */
</ul>
/* CSS for the LIs */
li {
font-size: .857em; /* computes to 16px */
list-style: none;
padding: .786em .714em .643em .714em;
transition: all 0.25s ease-in-out;
background-color: #fafafa;
border-top: 1px solid #d0d0d0;
color: #333;
margin: 0;
text-align: left;
}
This was tested in Chrome 37.0.2062.120 and FF 32 on a Mac (10.6.8). Incidentally, Safari 5.1.8 on the same computer did not repro the issue.
According to https://hsivonen.fi/hiragino/ (my emphasis added), "Mac OS X comes with new a family of high-quality Japanese fonts called Hiragino. The fonts also contain high-quality glyphs for the Western European subset of the Latin script. The glyphs for basic Greek and the Russian subset of the Cyrillic script look fine in isolation but are kerned to match the width of Kanji blocks. This makes the fonts ill-suited for Greek or Russian text."
My options at this point are to test other fonts that come with Mac OS to see if they do not apply the widths to Greek and Russian characters. If they all do, I'll resort to using my aforementioned font stack. Also, when I check this in Windows, I don't see this issue.
I'm working on a web app where I need to display a service mark character (℠). The stylesheet has a font-weight of 300 for the tag where the character is rendered. When rendered at this weight, the service mark character seems to become abnormally large and slightly thicker than one would expect given the appearance of the trademark character (™) at the same weight. The behavior is more pronounced when a font-weight of 100 or 200 is used.
Below is a test document which demonstrates the behavior. The output on Firefox 12.0 on OS X looks like this (sorry, too new to attach image inline). This behavior seems to persist regardless of font-family used. Chrome 19.0.1084.52 on OS X also displays the service- and trademarks with some inconsistency across weights, but the effect is much less noticeable.
Is this a bug with Firefox/Gecko, or am I doing something wrong here? Thanks!
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Service Mark Test</title>
<meta content='text/html; charset=utf-8' http-equiv='Content-type' />
</head>
<body style="font-family:sans-serif;">
<p style="font-weight:normal;">Here is a normal service mark℠ and trademark™</p>
<p style="font-weight:100;">Here is a weight 100 service mark℠ and trademark™ <span style="color:red;">(unexpected)</span></p>
<p style="font-weight:200;">Here is a weight 200 service mark℠ and trademark™ <span style="color:red;">(unexpected)</span></p>
<p style="font-weight:300;">Here is a weight 300 service mark℠ and trademark™ <span style="color:red;">(unexpected)</span></p>
<p style="font-weight:400;">Here is a weight 400 service mark℠ and trademark™</p>
<p style="font-weight:500;">Here is a weight 500 service mark℠ and trademark™</p>
<p style="font-weight:600;">Here is a weight 600 service mark℠ and trademark™</p>
</body>
</html>
Change the font family setting to e.g.
font-family: Calibri, Arial Unicode MS, Lucida Sans Unicode,
DejaVu Sans, FreeSans, sans-serif;
This is a font problem: when you use just the generic name sans-serif, each browser will use its own default sans serif font. This is typically Arial, which does not contain the service mark character. Browsers will be forced to use fallback fonts, and Firefox apparently uses different fallback fonts for different font weights—this is a bit strange, but surely possible.
The list above contains specific fonts that contain the service mark character. Most of those fonts have just one or two font weights, as most fonts, really. Even the bold version of e.g. Arial Unicode MS is “fake bold” (algorithmically bolded normal font), but the result is usually tolerable, though not pretty.
I found this which may help answer your question.
http://www.htmlcodetutorial.com/character_famsupp_197.html
As you see font-weight: 100 is pushing the font as thin as it can go, while 400 is normal, 700 is bold.
In between can make very little difference and in most cases 100 - 500 are exactly the same to the majority of font families.
I'm using the Google webfonts API to embed Droid Sans on a page. All is fine, except for the descenders (i.e. the dangly bits on y, g, etc). The latest versions of Firefox, IE and Chrome on my Windows Vista box are all cutting the bottom off.
<!DOCTYPE html>
<html>
<head>
<title>Droid sans descender test</title>
<meta charset="utf-8">
<link href="http://fonts.googleapis.com/css?family=Droid+Sans:regular,bold" rel="stylesheet" type="text/css">
<style type="text/css">
body { font-size: 16px; font-family: "Droid Sans", sans-serif; }
h1, h2, h3 { margin: 1em 0; font-weight: normal; }
h1 { font-size: 2em; }
h2 { font-size: 1.5em; }
h3 { font-size: 1em; }
</style>
</head>
<body>
<h1>A bug ran under the carpet anyway</h1>
<h2>A bug ran under the carpet anyway</h2>
<h3>A bug ran under the carpet anyway</h3>
</body>
</html>
The above code looks like this:
(source: thinkdrastic.net)
I've tried line-height, font-size, padding etc to no avail. I had some success with font-size-adjust, but the last time I checked it was Gecko only. Does anybody know of a fix for this?
With some help from #adamliptrot, I discovered that Droid Sans' descenders are absolutely fine at a few precise pixel sizes: 18, 22 and 27px. I adjusted my em's accordingly:
h1 { font-size: 1.6875em; }
h2 { font-size: 1.375em; }
h3 { font-size: 1.125em; }
Not ideal, but it works:
(source: thinkdrastic.net)
Although your question is in relation to the Google Web Fonts API, the principle of my answer beneath is the same.
If the descendants are being cut-off when serving a TrueType Font, the most likely cause is that OS/2 metrics are incorrectly set (negatively) on the font.
The values that may need adjustment are WinAscent & WinDescent.
A quick and dirty fix would be to adjust these both to 0.
This can be done using Font Forge. Once the font is opened in FontForge, you can gain access to these parameters via the 'Font Info' dialogue.
I have checked the referenced ttf files, and even in windows font viewer the descenders are being cut. Seems more of an issue with the font being served rather than with your styles.
If you're using Font Squirrel, it seems the issue with the sans variant has been sorted, but the issue remains with Font Squirrel's serif variant.
For a fix for the serif variant, go to the Web Font Generator and load the font files you need (do not rely on the package they provide).
Click the 'Expert' radio button, leave all of the settings but under 'Advanced Options' change the 'Em Square Value' to '2162' and generate the font.
This renders the font properly at all sizes
we've been having the same problem...we tried using font squirrel. we tried using google web fonts. The font kept cutting off "hanging" letters like g. Also, the google hosted version did not appear as true and clear as the other ones. The font seemed a bit choppy.
Our solution:
We hosted the font ourselves without formatting it for the web. Then we converted the ttf file to an svg, .eot, and .otf, and uploaded those as our fixes for ie and mozilla etc.
If the tip at the top - changing font-size to....
h1 { font-size: 1.6875em; }
h2 { font-size: 1.375em; }
h3 { font-size: 1.125em; }
doesn't work for you, then add "line-height" to the element that is cutting off the descenders. ``
I'm just guessing here, but I've had the same problem occur when fonts get substituted. I just wonder if this occurs when say a font substitution replaces a 1024em font with a 1000em font or vice-versa. I had some major descender cut-off using a 2048em font. Might be worth investigating.
I had a similar dilemma and the line-height fix worked for me (i.e. I added this code to the Custom CSS section):
h2 { line-height: 140%; }