これは私を夢中にさせます。
IE9でサイトをテストしたところ、「ライブ」バージョンが、使用しているWebフォントを開発バージョンよりも小さくレンダリングしていることがわかりました。
画面グラブの選択は次のとおりです。
Font Squirrel @ font-faceキットを使用しています。ご覧のとおり、Firefoxでは、Chrome、そしてローカルバージョンのサイトを表示する場合はIE9でも問題ありません。
ローカルバージョンとライブバージョンの唯一の違いは、フォントがライブサイトの異なるドメインからロードされることです(FirefoxとChromeで動作するという事実が示すように、クロスドメインポリシーを正しく設定しました)。
IE8の外観を思い出せません(Microsoftは開発者のことを考えず、IE8をIE8の上にインストールし、同時に実行するオプションはありません)
このサイトは http://enplanner.com にあるため、ソースを表示できます。
これに関するどんな助けも最も感謝されます-事前に感謝します。
編集:IE9を削除し、IE8でローカルとライブの両方でまったく同じに見えることを発見しました。 IE8には、IE9よりもFF/Chromeに近い優れたレンダリングエンジンがあるようです。これは非常に憂鬱な発見です。
IE9は.WOFFをサポートしています。 IE8はサポートしておらず、.EOTフォントのみをサポートしています。
IE9 F12開発者ツールを開くと、次のメッセージが表示されます。
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
HTTPヘッダーを調べると、WOFFファイルにAccess-Control-Allow-Origin
応答ヘッダーがないため、クロスドメインアクセスが適切に構成されていないことは明らかです。また、間違ったMIMEタイプ(text/plain
)で配信されますが、問題は発生していません。ただし、woff
を適切なMIMEタイプにマッピングできない場合canは、一部のサーバーが「未定義」の拡張子を持つファイルを提供せず、代わりにHTTP/404
エラーを返すため問題が発生します。
OK、これがうまくいったものです。フォントを提供するホストのApache構成に次のセクションを配置します。
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://mydomain.com"
</IfModule>
</FilesMatch>
「mydomain.com」を独自のドメインまたは*
(ただし、*
これは、だれでもCDNを使用できることを意味するため)
「| woff」は私が忘れていたものです。ドッ!
IIS以下の行を追加します。..チャームのように動作します
<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>
上記の手段の答えについて、補足したいと思います。同じ問題があり、Google Web Fontの機能を検索しました。したがって、htaccessに次のように入れます。
ヘッダーセットAccess-Control-Allow-Origin "*"
Access-Control-Allow-Originヘッダーを使用する代替ソリューションは、data:を使用してCSSにフォントを埋め込むことです。
IEファイル(your-web.com/your-font.woff)で開くことができるかどうかを確認します。エラー404をIISに送信する場合は、[MIMEタイプ]構成をダブルクリックしますIISルートノードを左パネルで選択し、右側の[アクション]パネルで[追加...]リンクをクリックします。これにより、次のダイアログが表示されます。追加.woffファイル拡張子を指定し、対応するMIMEタイプとして「application/x-font-woff」を指定します。
このサイトでこのインストゥルメントを使用します( Robòticaeducativa )、オリジナルの.ttfフォントを( http://www.font2web.com/ )に変換します
私は1つの回避策を見つけました。これをhtaccessに追加しました。
BrowserMatch MSIE best-standards-support
Header set X-UA-Compatible IE=8 env=best-standards-support
.svgを含めることを忘れないでください-これは場合によっては必要になることがあります。これを追加すると、IE 11
<FilesMatch "\.(eot|otf|svg|woff|ttf)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
また、アセットがAmazon AWS S3でホストされている場合、サーバーが送信するヘッダーを設定できないことに注意する必要があります。代わりに、次の手順に従ってバケットのCORS設定を構成する必要があります。
ASP.Netに実装するには、次の構文を使用できます
Response.AppendHeader("Access-Control-Allow-Origin", "*");
未検証!
Nginxサイトファイルビット。CDNが公開されていない場合に、Originだけがフォントファイルにアクセスできるようにします:-)ハッピーコーディング
location ~ \.(ttf|otf|eot|woff)$ {
Access-Control-Allow-Origin: *
}
Apacheの設定や.htaccessファイルを変更することからすべてを試してみましたが、運はありませんでした。 IE開発ツールで「ドキュメントモード」に出くわし、デフォルトはIE7でした。そこで調査を行ったところ、次のメタタグが見つかりました。
<meta http-equiv="X-UA-Compatible" content="IE=9">
現在、IE 10、and 9は私のWebサイトを正しくフォーマットし、すべてのFont Awesomeアイコンを正しく表示します。
お役に立てば幸いです...