I'm using a custom font which I imported like this:
#font-face {
font-family: 'Circular Std';
src: url('CircularStd-Bold.woff2') format('woff2'),
url('CircularStd-Bold.woff') format('woff');
font-weight: bold;
font-style: normal;
font-display: swap;
}
I'm developing on MacOS - and with every browser on this OS the font is displayed perfectly.
Somehow on Windows, even with the newest version of Chrome and every other browser, the font is not vertically centered, but rather aligned to the top.
How so?
With:
font-display: swap;
It gives the font face an extremely small block period and an infinite swap period.
To answer your question, try using:
font-display: auto;
REASON:
The reason why you want to use auto instead of swap is because
It's very good practice
The font display strategy is defined by the user agent, when using auto
So whether you're on Windows or Mac it will automatically change to your preference
Hope that cleared things up for you!
Related
I have the following structure for my CSS:
index.html
css
--fonts
----roboto
------roboto-italic-demo.html
------roboto-italic-webfont.woff
------roboto-italic-webfont.woff2
------stylesheet.css
--main.css
stylesheet.css contains the following CSS
#font-face {
font-family: 'robotoitalic';
src: url('roboto-italic-webfont.woff2') format('woff2'),
url('roboto-italic-webfont.woff') format('woff');
font-weight: normal;
font-style: normal;
}
roboto-italic-demo.html is a demo page with the entire alphabet characters displayed using font-family: 'robotoitalic';. Here the g appears like it should.
main.css contains the following css
#font-face {
font-family: 'roboto';
src: url('fonts/roboto/roboto-bolditalic-webfont.woff2') format('woff2'),
url('fonts/roboto/roboto-bolditalic-webfont.woff') format('woff');
font-weight: bold;
font-style: italic;
}
#font-face {
font-family: 'robototest2';
src: url('fonts/roboto/roboto-italic-webfont.woff2') format('woff2'),
url('fonts/roboto/roboto-italic-webfont.woff') format('woff');
font-weight: normal;
font-style: normal;
}
index.html includes the main.css stylesheet. Using font-family: 'roboto'; font-style: italic; cuts off the right side of the g character. using font-family: 'robototest2'; cuts the right side of the g character as well.
Here's what I tried in order to fix the issue:
Redownload roboto-italic-webfont.woff && roboto-italic-webfont.woff2
Put "Comic Sans MS" as a fall back to make sure I was actually using roboto or robototest2
Added letter-spacing
Placed the g character within a span with padding
edit:
This question was marked as duplicate. The question linked referred to text protruding from its container, where as this one is about a character being cut-off no matter its position within any tag. For example, this html
<p><em>This g is being cut off on its right side</em></p>
results in
I had the same issue, also with Roboto, italic at regular weight. The version of Roboto I was using was self hosted and downloaded from Font Squirrel.
I tried the Google hosted version of Roboto, and it rendered the "g" correctly, so I figured there must be something off with my version of the font. I found this answer on a separate Stack Overflow issue: https://stackoverflow.com/a/15976457/1786681 which recommended uploading your own ttf of the font to Font Squirrel's webkit generator, selecting the "Expert" option, and leaving all the defaults except changing the "Em Square Value" to "2162". I downloaded the .ttf file of Roboto from Google and went through these steps and voila! My italic "g"s are now rendering beautifully!
I'm using an icon font throughout a site I have been building, and just noticed that the font does not display in IE10 on Windows 8 only. The font works fine in IE10 on Windows 7, and in Chrome/FF across the board.
Worth noting that SOME fonts from this set DO work in IE10/Windows 8. E.g. '\2699' works, but '\E744' does NOT work in IE10/Windows 8.
UPDATE: Here is a JSFiddle that exhibits the issue: http://jsfiddle.net/wqs5C/
Can anyone help me understand why it may not be working?
Here is the font declaration:
#font-face {
font-family: 'icons';
src: url("../Fonts/icons.eot");
src: url("../Fonts/icons.eot?#iefix") format('embedded-opentype'),
url("../Fonts/icons.woff") format('woff'),
url("../Fonts/icons.ttf") format('truetype'),
url("../Fonts/icons.svg#icons") format('svg');
font-weight: normal;
font-style: normal;
}
Here is the style (in IE10 developer tools, these have a line through them):
.exp_closed > .widget-head > .toggle:after {
content: '\E744';
font-family: 'icons';
font-size: 16px;
}
So I've ultimately traced this back to "Protected Mode" in IE10. It was preventing ALL icon fonts from working. As soon as I disabled it, everything started acting like I'd expect it to. The failures in FF on the JSFiddle are likely from cross-domain restrictions on font downloads.
Chrome 26.0.1410.64m on Windows 8 has problems rendering WebFonts. It is a known problem and a solution is to first serve the svg version of the font instead of the woff version. It fixes the anti-aliasing and makes font look pretty again.
The downside of this method is the weird rendering inside the element inside select inputs.
I added a jsfiddle to see it in action : http://jsfiddle.net/4mSpv/6/.
The CSS is as simple as it can be.
#font-face {
font-family: 'Montserrat';
src: url('https://raw.github.com/louh/website/master/fonts/montserrat-regular-webfont.svg#montserratregular') format('svg');
font-weight: 400;
font-style: normal;
}
select {
font-family: 'Montserrat', sans-serif;
}
I remove the local installation of a font and noticed an other windows 7 computer doing the same. Anyone knows what is going on with chrome? (IE, Firefox, Safari all render fine)
PS: Other browser fonts not included in JSFiddle to filter out the problem and each browser have their own quirks (not allowing font-size etc) but render the text fine
There is no way to solve this problem.
This is NOT a Regression issue and is existing from M24.
I submitted a bug report and it Weird character rendering in option menu
As automaticoo stated, it is a known issue with Chrome. However, you can workaround the issue with a technique mentioned in the selected answer for this post: Google Webfonts Render Choppy in Chrome on Windows.
#media screen and (-webkit-min-device-pixel-ratio:0) {
select {
font-family: Arial; /* standard font */
}
}
That way you can use whatever font you want for browsers that still work, and replace it with a generic HTML font for Chrome.
So, I was actually looking for an answer for this, and I stumbled upon this question. I noticed this bug still exists today ( I just met it, such a happy meeting... ). Now I only found 1 solution, which is placing the svg font last in the #font-face declaration (this also means including all other formats). The only problem is that, when you for exampling try fixing the font rendering (to make it all smooth and stuff) you'd actually put the svg first.
Here are some examples to demonstrate it
1: SVG font last, no crisp font, options are displayed right
#font-face {
font-family: 'OpenSansLight';
src: url('../font/OpenSans-Light-webfont.eot');
src: url('../font/OpenSans-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('../font/OpenSans-Light-webfont.woff') format('woff'),
url('../font/OpenSans-Light-webfont.ttf') format('truetype'),
url('../font/OpenSans-Light-webfont.svg#open_sanslight') format('svg');
font-weight: normal;
font-style: normal; }
So as you can see, the options in the select box show just fine, but the font really isn't that crips, just look at "Register" (you might notice this better in comparison with my second example)
2: SVG font last, crisp font, stupid options in select
#font-face {
font-family: 'OpenSansLight';
src: url('../font/OpenSans-Light-webfont.eot');
src: url('../font/OpenSans-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('../font/OpenSans-Light-webfont.svg#open_sanslight') format('svg'),
url('../font/OpenSans-Light-webfont.woff') format('woff'),
url('../font/OpenSans-Light-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal; }
Now you will see that the font is a lot more crisp but the select is really stupid.
I suggest adding another font-face with the svg last just for select's. This will keep your fonts crisp throughout the website but display the options just fine.
Strange problem here. I'm using #font-face for a site and am having some issues. I initially wasn't getting capital "A"s to show up in Chrome on Mac. After setting a font-weight explicitly, anything above 300, it was fine.
Now, however, I'm seeing that it occurs in Firefox and on my clients machine in various browsers.
Here's my code:
#font-face {
font-family: 'Avenir';
src: url('../fonts/tricky.eot');
src: url('../fonts/tricky.eot?#iefix') format('embedded-opentype'),
url('../fonts/tricky.woff') format('woff'),
url('../fonts/tricky.ttf') format('truetype'),
url('../fonts/tricky.svg#ModernPictogramsNormal') format('svg');
font-weight: 300;
font-style: normal;
}
You can see it live here: http://infirmaryhealth.mdidev.com/
Thanks for any assistance-
Got the issue figured out.
I was using Zurb's Foundation framework. They have this applied to h1 to h6:
text-rendering: optimizeLegibility;
Commented it out and voila!
Try setting the font-weight to normal (that's the same as setting it to 400). It's what the fontsquirrel #font-face generator does after converting fonts and it works for me all the time.
I'm currently working on a little Project in which I'd like to use webfonts via #fontface.
I implemented the font's like this:
#font-face {
font-family: 'CardoRegular';
src: url('../fonts/Cardo104s-webfont.eot');
src: url('../fonts/Cardo104s-webfont.eot?#iefix') format('embedded-opentype'),
url('../fonts/Cardo104s-webfont.woff') format('woff'),
url('../fonts/Cardo104s-webfont.ttf') format('truetype'),
url('../fonts/Cardo104s-webfont.svg#CardoRegular') format('svg');
font-weight: normal;
font-style: normal;
Now as you have probably experienced Chrome has problems displaying these fonts in a smooth way.
After some searching I found a solution which seem to work: You simply move this part of the css:
url('../fonts/Cardo104s-webfont.svg#CardoRegular') format('svg');
So you end up with this:
#font-face {
font-family: 'CardoRegular';
src: url('../fonts/Cardo104s-webfont.eot');
src: url('../fonts/Cardo104s-webfont.eot?#iefix') format('embedded-opentype'),
url('../fonts/Cardo104s-webfont.svg#CardoRegular') format('svg'),
url('../fonts/Cardo104s-webfont.woff') format('woff'),
url('../fonts/Cardo104s-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
Now Chrome renders the Fonts in a smooth way, which is great.
BUT:
For some reason this SOMETIMES breaks the Layout. About each third time I load the page I'll get something like this:
Everything is moved to the left. Longer texts are breaking out of their containers. Looks really strange.
**Has anyone experienced this problem before?
I would be happy to get advice on this.**
Feel free to take a look for yourself:
View Fireflycovers.com online
Thanks a lot!
I have had this exact issue happen to a website of my own.
Instead of putting the svg at the top, keep the original formatting but add a media query as shown below. This will make chrome render the fonts perfectly and fixes the layout breaking.
#font-face {
font-family: 'CardoRegular';
src: url('../fonts/Cardo104s-webfont.eot');
src: url('../fonts/Cardo104s-webfont.eot?#iefix') format('embedded-opentype'),
url('../fonts/Cardo104s-webfont.woff') format('woff'),
url('../fonts/Cardo104s-webfont.ttf') format('truetype'),
url('../fonts/Cardo104s-webfont.svg#CardoRegular') format('svg');
font-weight: normal;
font-style: normal;
}
#media screen and (-webkit-min-device-pixel-ratio:0) {
#font-face {
font-family: 'CardoRegular';
src: url('../fonts/Cardo104s-webfont.svg#CardoRegular') format('svg');
}
}
I have seen the same issues (or worse) across a few sites. Most of the time the text is smashed together on top of itself.
My only solution at the point is to go back to the older font. You can also try to add the CSS rule: -webkit-font-smoothing: antialiased; for a small improvement.
The fix is in the duplication of the #font-face rule.
You don't necessarily need it in a media query in the Quka's answer, though that's a nice way to only target webkit browsers.
If you duplicate your #font-face declaration exactly as (svg first for better rendering), and paste it below the original, the funky layout/draw issues are gone.
Just calling out that the media query isn't important here—it's the duplicated rule. This is such a weird bug. So dumb.