The bizarre thing is that on the same machine, in the same browser, using the same font files, the same glyphicon renders just fine on a different site that I developed. And that most glyphicons work on both sites.
As you can see, even the relevant CSS code is basically the same (aside from that upper case E when specifying the character which doesn't make a difference).
Thus, it seems to me that all of the common problems like the font being missing/corrupted or the browser being unable to interpret the character code don't apply. What else could cause this?
It seems that the problem was a corrupt font file.
I did not use this CDN for my other page and once I used the fonts contained in the Bootstrap Sass npm package instead, the icons showed up.
Related
I converted an SVG font to OTF using FontForge. I know the original font has certain errors, but really don't think any of those errors would cause the following issue:
When using CSS
writing-mode:vertical-lr; text-orientation:upright, I get the following results. The Firefox rendering is perfect, but for some reason the results seem to kern certain letter combinations in Chrome (ver. 96). I've tried doing everything I can think of in FontForge as far as clearing kerning tables, toggling options for "old kerning" and "microsoft kerning", etc. Nothing seems to make any difference to the result.
I know that upright orientation is not well supported by browsers in general, but it's apparent that Arial font renders perfectly under Chrome, so I think there must be something I can do to fix this problem.
The font is generated in FontForge from an SVG font that uses vert-adv-y. The values for that parameter are correct in the SVG (the SVG has other errors, but I don't think they have any bearing here). I'm linking a copy of the exported OTF file. Perhaps someone may discover some sort of kerning or letter-advancing issue there.
Or perhaps Chrome is doing some sort of automatic kerning, in which case, why doesn't it happen to the Arial font? Maybe the Arial font has GPOS settings, whereas my font has old-style kerning? I really have no clue.
LINK TO DOWNLOAD OTF FILE.
Although the letters on the left of the image are lowercase, they are produced using the uppercase keys A, B, C, etc.
Okay, so this seems to have been one of those miraculous-seeming instances when a problem seemed to fix itself. I resaved the file, which then kicks it to a microservice running FontForge, which coverts the SVG to an OTF, and when it reloaded everything appeared good.
I still have no idea why, since I didn't update the microservice, and I haven't changed the SVG-generating code AFAIK. All I did was upgrade Chrome (and the new version had been showing the issue with the old file), but it should still be sending the same data. Still, I'm not complaining!
I'm in the process of migrating a website from an existing CMS over to WordPress. They use font-face for their primary type on the site. I've copied over the font files and replicated the CSS file but it appears that the font on the dev site is not rendering the same that it did on the initial site (dev site has lighter weighted font).
Anyone have an idea why this may be?
Dev Site: http://gldev.staging.wpengine.com
Original Site: http://growingleaders.com
Your dev site has a lighter font appearance because it uses
-webkit-font-smoothing: antialiased;
which makes fonts appear lighter. This is done quite often for exactly this purpose, though doing so is somewhat problematic
The rule is applied on line 19 of your compiled CSS file, applied to all elements.
There are several differences on the Dev page compared to the original. If you look at the CSS file called screen.css it is a quite different file on the two sites, that is one of the reasons the fonts differ. Furthermore there are 13 CSS files linked to the original page and 15 to the Dev page. Also the scripts differ, so I wouldn't be surprised if there are even bigger discrepancies than the font rendering.
Copying a WP site can sometimes be more tricky than just copying files. I would suggest you use a good migrating tool. There are some out there.
I found the solution.
Apparently having text-rendering:optimizeLegibility; in your code causes webkit to render the font thinner than FireFox. Once that was removed from the HTML & body CSS, the font renders the same weight cross-broswer.
I've been looking for an answer for 3 days straight now (i did sleep a few hours though).
I'm using a wordpress theme that integrates font awesome icons smoothly. But i wanted to alter these icons and use my own, but they won't show in Firefox but do show in Safari, Chrome etc.
I'm using this css code to alter the icon to my own icons:
.fa-euro:before {content:url(http://nip10.nl/xtra-icons/icon-2.png);}
.fa-glass:before {content:url(http://nip10.nl/xtra-icons/icon-1.png);}
.fa-bell:before {content:url(http://nip10.nl/xtra-icons/icon-3.png);}
.fa-coffee:before {content:url(http://nip10.nl/xtra-icons/icon-4.png);}
You can see the website here: www.nip10.nl
Hope someone can tell me how i can alter the css code so the icons also show in FireFox.. I've tried anything from naming images to .jpg files etc. etc..
You should validate your HTML. See here: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.nip10.nl
I'm going to guess that the problem is that firefox is running into this error
Line 1069, Column 26: Element style not allowed as child of element
div in this context. (Suppressing further errors from this subtree.)
And failing to parse the embedded style sheet. You should also not embed your large stylesheets like that. Make them external style sheets. Once that's done, find where your HTML error is that's causing the validator to think you don't have the style sheet in the head tag and it should fix itself.
I am compiling several stylesheets into one min stylesheet in a staging environment The styles are applied locally in IE where each stylesheet is separate, but they are not being applied in the staging environment in IE where the stylesheets are compiled into one min stylesheet. I have run the stylesheets through a CSS validator and have gone through each stylesheet and corrected any syntax errors that I found. I don't necessarily need to know how to solve the problem, I mainly want to know where the problem exists. The IE developer tools aren't giving me any feedback related to the problem of styles not being applied.
Here is a link to the login page in the staging environment: https://s-app.joinhere.com/manage/sessions/new. The styles are in the stylesheet, they just aren't being applied in IE. Here's a link to the compiled min stylesheet: https://staging.joinhere.com/assets/manage-d4f70cefc93b170b5f2a04509db697c8.css
Thanks!
I tried your page, and it works fine in Chrome. However it looks weird in IE9, as if the CSS styles are not being applied, just as you described. For example, the style body#manage-sessions #main_container #login_container is not getting applied. I looked at the css tab in the developer tools, and it turns out the style is not even there, which explains how it is not working. To find out why, I used the networks inspector from the developer tool and examined the response when IE9 is downloading the css, and the style body#manage-sessions #main_container #login_container is indeed in the response. This lead me to believe that there must be some limit on the max css file size for IE. It appears that this is indeed the case as described here. Apparently IE simply ignores additional styles if the css file gets past a certain size. So this explains why everything works when the css files are separate, and why things fall apart after you combine them. To solve the problem try splitting up your large css file into 2 or more smaller ones that fall under the IE limit, and see if this corrects the problem.
I'm not sure about your personal setup, however, anything < IE 10 can only handle 32 individual stylesheets, anything after will still show up in the Dev tools like its working but rest assured, the 33 stylesheet is committed to a life of silent failure.
In my .gwt.xml file I have uncommented the following:
<inherits name='com.google.gwt.user.theme.chrome.Chrome'/>
When I run my application I do not see any stylesheet applied. Using Firefox there are a large number of warnings associated with Chrome.css. These mostly say that it doesn't recognize 'zoom' and 'cursor' so it is dropping the declaration. This seems to indicate that it is trying to use the theme but I see no evidence of it. The background remains white and the fonts seem to be the defaults.
Is there another step I need to take for stylesheets to be applied?
Stupid mistake. I tried the dark theme which is more dramatic and discovered they were being applied. They Chrome and Standard just don't look like much on the standard widgets.