可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I have downloaded FontAwesome using npm and then copied the css-file and the fonts into the right folders in the root-diretory of my electron-application using grunts copy task.
So far so good. Everything is where it is supposed to be.
Now, when i am referencing FontAwesome in my app, the icons do not get loaded. These are the errors that I get in the console:
Failed to decode downloaded font:
file:///path/to/fonts/fontawesome-webfont.woff2?v=4.4.0
OTS parsing error: Failed to convert WOFF 2.0 font to SFNT
Failed to decode downloaded font:
file:////path/to/fonts/fontawesome-webfont.woff?v=4.4.0
OTS parsing error: incorrect file size in WOFF header
Failed to decode downloaded font:
file:////path/to/fonts/fontawesome-webfont.ttf?v=4.4.0
OTS parsing error: incorrect entrySelector for table directory
I have already tried to modify FontAwesome's css file by removing all the version parameters but this does not seem to be the problem. The Issues comes up both by starting the app via electron .
and when viewing the html-file in the browser.
UPDATE
To Answer some comments:
- This problem occurrs in electron as well as in the browser (tested in chrome and firefox)
- I am using the newest versions of both, FontAwesome (4.4.0) and Electron (0.32.1) (fresh install via npm)
- css is loaded like:
<link rel="stylesheet" type="text/css" href="css/font-awesome.css" >
回答1:
I had a similar issue (perhaps this answer will help someone). I use Maven to build projects (Java + JS). Maven Filter Plugin corrupted binary font files. I had to add includes and excludes:
<resources>
<resource>
<directory>${project.sources}</directory>
<filtering>true</filtering>
<excludes>
<exclude>**/*.woff</exclude>
<exclude>**/*.ttf</exclude>
</excludes>
</resource>
<resource>
<directory>${project.sources}</directory>
<filtering>false</filtering>
<includes>
<include>**/*.woff</include>
<include>**/*.ttf</include>
</includes>
</resource>
</resources>
回答2:
In my situation, Git was treating the file as a text file, and messing with its "line endings". This was corrupting the file.
Adjusting the .gitconfig to recognize *.woff files as binary, then removing the file, and adding a new copy from https://github.com/FortAwesome/Font-Awesome/raw/v4.2.0/fonts/fontawesome-webfont.woff solved the issue for me.
回答3:
For some people who are deploying to IIS, adding this to web.config file (the main one, not the one inside Controller directory) might be of help.
<system.webServer>
<staticContent>
<remove fileExtension=".eot" />
<mimeMap fileExtension=".eot" mimeType="application/vnd.ms-fontobject" />
<remove fileExtension=".ttf" />
<mimeMap fileExtension=".ttf" mimeType="application/octet-stream" />
<remove fileExtension=".svg" />
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
<remove fileExtension=".woff" />
<mimeMap fileExtension=".woff" mimeType="application/font-woff" />
<remove fileExtension=".woff2" />
<mimeMap fileExtension=".woff2" mimeType="font/woff2" />
</staticContent>
</system.webServer>
回答4:
I faced same issue, using API Gateway to serve static font-files on Amazon S3.
I fixed it by adding */*
as Binary Media Types on the AWS Console.
More information on binary media types management on https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-configure-with-console.html
回答5:
The Problem was in my grunt-file. I tried to reproduce the issue by simply downloading all dependencies manually at their vendors websites and placed them in the corresponding script-folder of my project - suddenly it worked.
I switched to gulp now and it still works. No idea what i was doing wrong with grunt though...
回答6:
try the following, call the font-face as the following in the beginning of your CSS file.
@font-face {
font-family: FontAwesome;
src: url(../fonts/fontawesome-webfont.eot?v=4.0.3);
src: url(../fonts/fontawesome-webfont.eot?#iefix&v=4.0.3) format('embedded-opentype'), url(../fonts/fontawesome-webfont.woff?v=4.0.3) format('woff'), url(../fonts/fontawesome-webfont.ttf?v=4.0.3) format('truetype'), url(../fonts/fontawesome-webfont.svg?v=4.0.3#fontawesomeregular) format('svg');
font-weight: 400;
font-style: normal
}
回答7:
If you are using the bower
you could rewrite your font-face
to:
@font-face {
font-family: FontAwesome;
src: url(font-awesome/fonts/fontawesome-webfont.eot);
src: url(font-awesome/fonts/fontawesome-webfont.eot?#iefix) format('embedded-opentype'),
url(font-awesome/fonts/fontawesome-webfont.woff) format('woff'),
url(font-awesome/fonts/fontawesome-webfont.ttf) format('truetype'),
url(font-awesome/fonts/fontawesome-webfont.svg#fontawesomeregular) format('svg');
font-weight: 400;
font-style: normal
}
回答8:
I'm sure this is solved, but this worked for me, so... I'm gonna leave this here:
I just had the same issue with a font I had used before. Turned out this was caused by a problem with FTP. The file was uploaded as text (ASCII) instead of binary, which corrupted the file. I simply re-uploaded the font files, and then it all worked.