FontAwesome kann Schriftarten nicht lokal laden und in Elektronen App

Question

Ich habe FontAwesome mit npm heruntergeladen und dann kopiert die CSS-Datei und die Schriftarten in die richtigen Ordner im Root-Verzeichnis meiner Elektronen-Anwendung mit Grunts Kopie Aufgabe.

So weit so gut. Alles ist da, wo es sein soll.

Jetzt, wenn ich FontAwesome in meiner App referenziere, werden die Symbole nicht geladen. Dies sind die Fehler, die ich in der Konsole:

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

Ich habe bereits versucht FontAwesome die CSS-Datei durch Entfernen aller Version Parameter zu ändern, aber dies scheint nicht das Problem zu sein. Das Problem tritt auf, wenn Sie die App über electron . starten und die HTML-Datei im Browser anzeigen.

UPDATE

einige Kommentare zu beantworten:

• Dieses Problem in Elektron sowie im Browser occurrs (getestet in Chrome und Firefox)
• Ich bin mit den neuesten Versionen von Sowohl FontAwesome (4.4.0) als auch Electron (0.32.1) (Neuinstallation über NPM)
• css ist geladen wie: <link rel="stylesheet" type="text/css" href="css/font-awesome.css" >

Answer 1

Das Problem war in meiner Grunt-Datei. Ich habe versucht, das Problem zu reproduzieren, indem ich einfach alle Abhängigkeiten manuell auf den Websites meiner Anbieter herunterlud und sie in den entsprechenden Skriptordner meines Projekts legte - plötzlich funktionierte es.

Ich wechselte jetzt zu schlucken und es funktioniert immer noch. obwohl keine Ahnung, was ich mit Grunzen falsch zu machen ...

Answer 2

versuchen Sie Folgendes, rufen Sie die Schriftart-Gesicht wie folgt am Anfang der CSS-Datei.

@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 
} 

Answer 3

Wenn Sie mit dem bower Sie Ihre font-face umschreiben könnte:

@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 
} 

Answer 4

In meiner Situation, Git wurde die Datei als Textdatei Behandlung und verwirrte mit seinen "Zeilenenden". Das korrumpierte die Datei.

Durch Anpassen der .gitconfig-Datei zum Erkennen von * .woff-Dateien als Binärdatei, Entfernen der Datei und Hinzufügen einer neuen Kopie von https://github.com/FortAwesome/Font-Awesome/raw/v4.2.0/fonts/fontawesome-webfont.woff wurde das Problem für mich behoben.

Answer 5

Ich hatte ein ähnliches Problem (vielleicht wird diese Antwort jemandem helfen). Ich benutze Maven um Projekte zu erstellen (Java + JS). Maven Filter Plugin beschädigte Binärschriftdateien. Ich musste hinzufügen enthält und umfasst nicht:

<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> 

Answer 6

Für einige Menschen, die auf IIS bereitstellen, das Hinzufügen dieser zu web.config-Datei (die wichtigsten, nicht derjenige innerhalb Verzeichnisses Controller) könnte hilfreich sein.

<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>

Answer 7

Ich bin sicher, dass dieses Problem gelöst wird, aber das ist für mich gearbeitet, so ... Ich werde das hier verlassen:

Ich habe gerade das gleiche Problem mit eine Schriftart, die ich vorher benutzt hatte. Es stellte sich heraus, dass dies auf ein Problem mit FTP zurückzuführen war. Die Datei wurde als Text (ASCII) anstelle von Binärdatei hochgeladen, wodurch die Datei beschädigt wurde. Ich habe die Schriftdateien einfach neu hochgeladen, und dann hat alles funktioniert.

Answer 8

Ich sah das gleiche Problem, mit API-Gateway statische Schriftart-Dateien auf Amazon S3 zu dienen.

Ich habe es durch Hinzufügen von */* als binäre Medientypen auf der AWS-Konsole behoben.

Mehr Informationen über binäre Medientypen Management auf https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-configure-with-console.html