Ça me rend fou.
Je viens de tester un site sur IE9 et de découvrir que la version "live" rendait une police Web que j'utilise plus petite que sur la version dev.
Voici une sélection de captures d'écran:
J'utilise le kit Font Squirrel @ font-face. Comme vous pouvez le constater, tout va bien sous Firefox, Chrome et même IE9 lorsque vous consultez une version locale du site.
La seule différence entre les versions locale et réelle réside dans le fait que la police est chargée à partir d'un domaine différent du site actif (j'ai correctement configuré la stratégie inter-domaines, comme illustré par le fait qu'elle fonctionne sous Firefox et Chrome).
Je ne me souviens plus à quoi cela ressemblait dans IE8 (Microsoft, encore une fois, n'a pas pensé aux développeurs et a installé IE9 par-dessus IE8 sans pouvoir les exécuter simultanément)
Le site est à http://enplanner.com afin que vous puissiez voir la source.
Toute aide à ce sujet serait très appréciée - merci d’avance.
Edit: J'ai supprimé IE9 et découvert que son apparence est identique, que ce soit en local ou en direct dans IE8. Il semble que IE8 possède un moteur de rendu supérieur, plus proche de FF/Chrome que IE9. C'est une découverte assez déprimante.
IE9 prend en charge .WOFF; IE8 ne le fait pas et ne prend en charge que les polices .EOT.
Ouvrez les outils de développement IE9 F12 et vous verrez les messages suivants:
CSS3117: @font-face failed cross-Origin request. Resource access is restricted.
Neuton-webfont.woff
CSS3117: @font-face failed cross-Origin request. Resource access is restricted.
YanoneKaffeesatz-Regular-webfont.woff
CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable.
Neuton-webfont.ttf
CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable.
YanoneKaffeesatz-Regular-webfont.ttf
En examinant vos en-têtes HTTP, il est clair que votre accès entre domaines n'est pas configuré correctement, car il n'y a pas d'en-tête de réponse Access-Control-Allow-Origin
dans vos fichiers WOFF. Ils sont également livrés avec le mauvais type MIME (text/plain
) bien que cela ne pose pas votre problème. Cependant, l'échec de mappage de woff
sur le type MIME correct can cause des problèmes, car certains serveurs ne serviront pas les fichiers avec des extensions "non définies" et renverront une erreur HTTP/404
.
OK, voici ce qui a fonctionné. Placez la section suivante dans votre configuration Apache pour l'hôte à partir duquel vous servez les polices:
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://mydomain.com"
</IfModule>
</FilesMatch>
Remplacez «mydomain.com» par votre propre domaine ou par *
(mais faites attention en utilisant *
car cela signifie que tout le monde peut utiliser votre CDN)
Le '| woff' était ce que j'avais oublié. Doh!
Pour IIS, ajoutez les lignes ci-dessous .... fonctionne à merveille
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
</customHeaders>
</httpProtocol>
</system.webServer>
En ce qui concerne la réponse de meanstreakuk ci-dessus, je voudrais compléter… .. Nous avons eu le même problème et nous avons cherché à savoir ce que Google Web Font fait. Donc, nous avons mis dans notre htaccess, ceci:
Ensemble d'en-têtes Access-Control-Allow-Origin "*"au lieu de notre domaine .. Si l'astérisque, comme le fait Google, cela fonctionne tout le temps.
Une solution alternative à l'utilisation de l'en-tête Access-Control-Allow-Origin consiste à incorporer la police dans votre CSS à l'aide des données:.
Vérifiez si vous pouvez ouvrir le fichier dans IE (your-web.com/your-font.woff). Si vous recevez une erreur 404, allez à IIS, double-cliquez sur l'option de configuration "Types MIME" tout en ayant IIS nœud racine sélectionné dans le panneau de gauche et cliquez sur le lien "Ajouter ..." dans le panneau Actions à droite. Cela fera apparaître le dialogue suivant. Ajoutez l’extension de fichier .woff et indiquez «application/x-font-woff» comme type MIME correspondant.
J'utilise ces instructions sur ce site ( Robòtica educativa ), je convertis ma police .ttf d'origine sur ( http://www.font2web.com/ )
J'ai trouvé une solution de contournement. Ajouté ceci à htaccess.
BrowserMatch MSIE best-standards-support
Header set X-UA-Compatible IE=8 env=best-standards-support
N'oubliez pas d'inclure .svg - cela peut être nécessaire dans certains cas. L'ajouter a résolu le problème dans IE 11
<FilesMatch "\.(eot|otf|svg|woff|ttf)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
Notez également que si vos actifs sont hébergés sur Amazon AWS S3, vous ne pourrez pas définir les en-têtes envoyés par le serveur. Au lieu de cela, vous devrez configurer les paramètres CORS sur votre compartiment, conformément aux instructions suivantes:
Pour implémenter dans ASP.Net, vous pouvez utiliser cette syntaxe
Response.AppendHeader("Access-Control-Allow-Origin", "*");
PAS TESTÉ!
Nginx bit de fichier de site permettant uniquement l’accès d’origine aux fichiers de polices si votre CDN n’est pas public :-) Bon codage
location ~ \.(ttf|otf|eot|woff)$ {
Access-Control-Allow-Origin: *
}
J'ai tout essayé, de la modification de ma configuration Apache aux fichiers .htaccess sans succès. Dans les outils de développement IE, je suis tombé sur "Mode Document" et IE7 était le paramètre par défaut. Donc, après quelques recherches, j'ai trouvé cette balise META:
<meta http-equiv="X-UA-Compatible" content="IE=9">
Maintenant, IE 10 et 9 formatent correctement mon site Web et affichent correctement toutes les icônes de Font Awesome.
J'espère que cela pourra aider...