I created a font with icomoon
and I wanted to use ligatures. Currently all my ligatures have hyphens in the ligature code.
For example: my-ligature
So when I use
<i>my-ligature</i>
It works as expected in Firefox and IE but not Chrome.
When I add a or any other character like
<i>my-ligature </i>
<i>my-ligature </li>
It also works in Chrome.
As soon as I replace the hyphen in the ligature code with something else like an underscore it works in Chrome as expected (no whitespace etc. necessary)
Is this a Chrome Bug or are hyphens not allowed here?
You'll find a demo of the whole thing here (made with a standard icomoon icon)
http://www.swisscocktailblog.ch/icomoon/demo.html
EDIT:
As requested the css for the ligatures (it's the one used in the demo)
#font-face {
font-family: 'icomoon';
src:url('fonts/icomoon.eot?6mfq3a');
src:url('fonts/icomoon.eot?#iefix6mfq3a') format('embedded-opentype'),
url('fonts/icomoon.ttf?6mfq3a') format('truetype'),
url('fonts/icomoon.woff?6mfq3a') format('woff'),
url('fonts/icomoon.svg?6mfq3a#icomoon') format('svg');
font-weight: normal;
font-style: normal;
}
i, .icomoon-liga {
font-family: 'icomoon';
speak: none;
font-style: normal;
font-weight: normal;
font-variant: normal;
text-transform: none;
line-height: 1;
/* Enable Ligatures ================ */
letter-spacing: 0;
-webkit-font-feature-settings: "liga";
-moz-font-feature-settings: "liga=1";
-moz-font-feature-settings: "liga";
-ms-font-feature-settings: "liga" 1;
-o-font-feature-settings: "liga";
font-feature-settings: "liga";
/* Better Font Rendering =========== */
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
.icon-wifi-full:before {
content: "\e600";
}
This bug has been identified elsewhere in Chromium, and more specifically affects ligatures named with non-alphabetical characters:
https://bugs.chromium.org/p/chromium/issues/detail?id=277677
It was marked fixed on that thread, but that doesn't seem to be the case.
On a hunch I checked whether the character was there but not visible by adjusting letter-spacing, and that worked. Something as negligible as the following will allow the icon to render:
i {
letter-spacing: .001em;
}
If you apply this style to your demo page via devtools and inspect the two i elements, you'll see that the second is rendered as a sliver as compared with the first. If you add text after each you'll see that the text begins at a different point. To avoid this you could write more CSS, something like this:
i {
display: inline-block;
letter-spacing: .001em;
width: 1.2em;
}
This should ensure that all of your icons render consistently in spite of the bug, and will scale properly with the font-size. But at this point it's probably best to accept as best practice that ligatures should avoid non-alphabetical characters.
While the bug's cause is still unclear, the above should provide a workable solution. The reason the additional characters allow the icon to render is that they provide the missing character spacing made up for here by the additional CSS.
We too have the same issue in Angular 4 when creating our own icon in chrome 59.0. using css property
{
white-space : pre;
}
does solve this.
Mozilla 54.0.1 its working fine.
Related
The width of the space character (char code 32) varies in my text. This occurs in Firefox and Chrome. You can see the difference between the fullstops and C's in the below screenshot.
Relevant CSS:
#font-face {
font-family: "NewsGothDmBTWXX-Demi";
src: url('/wp-content/themes/bluedot/fonts/NewsGothDmBTWXXDemi/font.woff2') format('woff2'),
url('/wp-content/themes/bluedot/fonts/NewsGothDmBTWXXDemi/font.woff') format('woff');
font-weight: normal;
font-style: normal;
}
p {
font-family: "NewsGothDmBTWXX-Demi", helvetica, arial, sans-serif;
font-size: 20px;
text-align: left;
}
What I've tried:
Checked that I don't have the custom font installed on my machine.
The spaces are even when using the fall back sans-serif font
The spaces are definitely the same characters (asci 32)
Changing various properties like letter-spacing, font-kerning and text-rendering
The issue was due to being displayed wider than a regular space.
This was difficult to pick up on as viewing the source in both Firefox and Chrome didn't display the - I only picked up on this when copy and pasting from view-source to an IDE.
I'm hosting my own fonts, but I've also created a fiddle linking to Google fonts and the problem remains.
All browsers change the weight of the font in the H tags.
I find this a bit disconcerting particularly when in my case I'm specifying the font file that should be used.
If for example I set, both <h3> and <p>, with font-family: 'robotoregular'; and use the same exact font-size in both cases, I would expect the same exact result in both of them. Instead, what the browsers produce is a bold version of the font in the <h3>, and the only way to set it right is to specify the font-weight, which shouldn't be necessary if I'm already indicating a specific font file.
Is this behavior to be expected, and why does this happen?
Here's a Fiddle
#font-face {
font-family: 'robotoregular';
src: local('robotoregular'), url('../fonts/roboto-regular-webfont.woff2') format('woff2'),
local('robotoregular'), url('../fonts/roboto-regular-webfont.woff') format('woff');
font-weight: normal;
font-style: normal;
}
p {
font-family: 'robotoregular';
font-size: 27px;
}
h3 {
font-family: 'robotoregular';
font-size: 27px;
font-weight: normal; /*IF NOT INCLUDED, THE BROWSER WILL MAKE IT BOLD*/
}
Browsers apply a wide variety of defaults. Headers get font-weight: bold, among other things (like margins).
If you want complete, total control, consider a reset stylesheet.
I have an issue with trying to maintain a constant font style across all browsers. As seen below, safari's font rendering system makes the font weight smaller than the font weight of chrome's.
Safari:
Chrome:
I've tried using the solutions found on other questions though they have not solved this issue. How can I maintain a constant font style across all the major browsers? That is Chrome, Safari, Opera, Firefox and Internet Explorer.
Here is what I have tried.
-webkit-font-smoothing: antialiased;
font-weight: 800;
text-rendering: optimizeLegibility;
Browsers, by and large, have different font rendering engines/methods. For more details, I recommend reading this, this, and/or this.
Honestly, to the average user, the difference will not be all that noticeable and for the most part, pixel-perfect cross-browser display of anything has been long abandoned as a print-world aftereffect.
If, for some masochistic reason, pixel perfection is more important than sanity and maintainable code, you can try the old standy-bys (text-in-images, image/text replacment) or turning off subpixel rendering via CSS (although not all browser support it, and the text will be less readable).
Hope that helps.
A lot of the differences are more to do with the fact browsers add or omit different default weights / styles to fonts. To stop this happening make sure in your CSS you have font-weight: normal and font-style: normal in your #fontface code block.
You then need to apply the necessary styles to the HTML elements.
So if I have a font called geo-light I would do:
#font-face {font-family: 'geo-light';
src: url('fonts/geo-extralight.woff2') format('woff2'), url('fonts/geo-extralight.woff') format('woff');
font-weight: normal;
font-style: normal;
}
And then add the specific styles for each element that uses that font.
/*SET STYLES ON ELEMENTS*/
h1, h2, h3, h3 > a, p, li {
font-family: 'geo-light', sans-serif;
font-weight: normal;
font-style: normal;
text-decoration: none;
}
I hardly ever see this done on sites, and the pre-cursor to this is what is happening in your image. Those differences are not being caused by an anti-aliasing issue.
This 1st and 3rd articles in the original answer are regarding a completely different problem and the middle article that is being linked to would mean the reverse effect happening in your image examples.
The previous comment helped me a lot, thank you. I managed this way in wordpress and it works. Put this code with your font "YOUR-FONT" in to your CSS.
#font-face {
font-family: 'Conthrax';
src: url('/wp-content/uploads/fonts/conthrax-sb.eot');
src: url('/wp-content/uploads/fonts/conthrax-sb.eot') format('embedded-opentype'),
url('/wp-content/uploads/fonts/conthrax-sb-webfont.wofff') format('woff'),
url('/wp-content/uploads/fonts/conthrax-sb.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
Using a combination of the following styles should result in an almost consistent rendering of a font across all browsers.
{
-webkit-font-smoothing: antialiased;
font-synthesis: none;
text-rendering: optimizeLegibility;
}
I have problem with CSS content value. It’s not displayed at all, just codes, like in the picture. Can anyone explain what causes it? I’ll try to fix it, without posting code here.
HTML:
<i class="icon-map-marker"></i> Atlanta
CSS:
.icon-map-marker:before{
content: "\f041"
}
#font-face {
font-family: 'FontAwesome';
src: url('fontawesome-webfont.eot');
src: url('fontawesome-webfont.eot') format('embedded-opentype'),
url('fontawesome-webfont.woff?') format('woff'),
url('fontawesome-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal
}
[class^="icon-"], [class*=" icon-"] {
font-family: FontAwesome;
font-weight: normal;
font-style: normal;
text-decoration: inherit;
-webkit-font-smoothing: antialiased;
display: inline;
width: auto;
height: auto;
line-height: normal;
vertical-align: baseline;
background-image: none;
background-position: 0 0;
background-repeat: repeat;
margin-top: 0
}
This is caused by the character not being defined in the font used to display it. A placeholder is displayed instead. In Font Awesome, the fa-map-marker character is on that position.
Clearly font-family: FontAwesome is not used for the :before pseudo-element. Either it is not set, the font is not available, or a browser bug is triggered. I assume that no other CSS rules are used (otherwise overriding somewhere in the cascade could take place).
font-family: FontAwesome not set?
:before is child of the element it is “before”, so it inherits font-family correctly. The parent has font-family: FontAwesome unless the rule is invalid, which is not the case. Therefore the problem is not here and it must be in the unavailability of the font.
To be absolutely sure, try changing your rule for :before to
.icon-map-marker:before {
content: "\f041";
font-family: FontAwesome;
font-weight: normal;
font-style: normal;
}
and see if now the character displays OK.
FontAwesome font family not available?
Either the font cannot be downloaded, is broken, or the #font-face at-rule is invalid.
The at-rule seems perfectly valid to me. I’m just wondering, why the question mark after the WOFF path? I think this is a left-over after old IE (< 9) hack, but it should do no harm.
Checking the ability to download correct font file is up to you. You can verify that the font is loaded by sniffing the network traffic, e.g. using Firebug or LiveHTTPHeaders (but be sure to use your font and reload skipping cache via Ctrl + F5).
I think your problem is a browser bug. You did not specify what browser in which version you use, so I cannot say anything more specific.
To be always sure, you can use CSS from the CDN. Or follow the instructions on the same site to get Font Awesome working. You can also read more on bulletproof #font-face yourself, but then you need to keep up with the current implementation status of #font-face in browsers you want to support.
Quick test of fa-map-marker in :before using CSS from CDN
Insert this into your location bar:
javascript:'<title>Font Awesome test</title><link href="http://netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" rel="stylesheet"/><style>body:before {font-family: FontAwesome; content: "\\f041";}</style>Atlanta'
The \\ is needed instead of \ inside JavaScript string. The string is a valid HTML5 document.
Side notes
U+F041 is a character from range reserved for private use. Consequentially different fonts may have different characters for this code point.
Maybe it would be better to use more classes instead of the two-in-one. Using icon and map-marker could both simplify your selectors and tell you that your classes could be more semantic. Using a CSS preprocessor could let you compose the more semantic class city of lower, purely presentational units.
Your HTML markup is terrible. It is awfully bent to serve your presentational requirements, but HTML should mark up the structure that is presentation-agnostic. Why don’t you use Atlanta?
may be its a cache issue on your browser, try adding version numbers next to file name.
#font-face {
font-family: 'FontAwesome';
src: url('fontawesome-webfont.eot?v1');
src: url('fontawesome-webfont.eot?v1') format('embedded-opentype'),
url('fontawesome-webfont.woff?v1') format('woff'),
url('fontawesome-webfont.ttf?v1') format('truetype');
font-weight: normal;
font-style: normal
}
When I apply a font-weight:bold style, the look of the font is too bold in Safari when compared to other browsers. I tried below css as suggested in some site but its still the same.
text-shadow: #000000 0 0 0px;
Screenshots of text rendering:
Chrome
Safari
Here's my css declaration:
p {
margin: 8px 5px 0 15px;
color:#D8D2CE;
font-size:11pt;
letter-spacing:-1px;
font-weight: bold;
font-family: LektonRegular;
}
#font-face {
font-family: 'LektonRegular';
src: url('myfonts/lekton-regular-webfont.eot');
src: url('myfonts/lekton-regular-webfont.eot?#iefix') format('embedded-opentype'),
url('myfonts/lekton-regular-webfont.woff') format('woff'),
url(myfonts/lekton-regular-webfont.ttf) format('truetype'),
url('myfonts/lekton-regular-webfont.svg#LektonRegular') format('svg');
font-weight: normal;
font-style: normal;
}
How can this be fixed?
Use -webkit-font-smoothing: antialiased;
The text-shadow trick doesn't work anymore.
For rendering bold text consistently across browsers, your font should explicitly contain bold characters. Otherwise, browsers probably try to make bold variants of characters based on their normal variants, and results are inconsistent across browsers since they likely have different algorithms for such conversion.
Also note that text rendering may be different on different platforms on system level (e.g. Windows, Mac OS). Such differences are OK and do not typically need to be fixed.
See also topic about -webkit-font-smoothing property.
The -webkit solutions won't work for the strong issue for many google fonts, custom fonts and fonts that don't have preset values.
The problem is that you need to specify the value of bold in the strong tags.
This can be done by two ways:
You can either include from Google Fonts or wherever your font is from in your header; it needs both the regular font and the bold font each should have a different font-weight number like 400 regular and 600 bold for example:
<link href="https://fonts.xxx.com/css?family=XXX:400,600" rel="stylesheet">
Or use the aboves source code and paste into your own css like below:
#font-face {
font-family: 'XXX';
font-style: normal;
font-weight: 600;
src: local('XXX SemiBold'), local('XXX-SemiBold'),
url...
}
Use whatever your font is instead of XXX.
Then also in strong {font-weight:600;}
None of the answers here worked for me. Possibly because I am using the windows version of Safari for testing. I had to include the bold font in my CSS to fix the problem. In the case of the original question he would need to add the following (notice it uses the same font-family name)
#font-face {
font-family: 'LektonRegular';
src: url('myfonts/lekton-bold-webfont.eot');
src: url('myfonts/lekton-bold-webfont.eot?#iefix') format('embedded-opentype'),
url('myfonts/lekton-bold-webfont.woff') format('woff'),
url(myfonts/lekton-bold-webfont.ttf) format('truetype'),
url('myfonts/lekton-bold-webfont.svg#LektonRegular') format('svg');
font-weight: bold;
font-style: normal;
}
This worked in all browsers for me.
I found a solution for this particular issue. Actually any of above solutions dint work for me. So started checking the default webkit styles added by safari and found that -webkit-text-stroke-width was applied to body having value 0.5px. I set it to 0!important and solved the issue for me.