4

更新:実際には問題の原因ではない相関関係に巻き込まれたようです。問題は、実際には CSS ファイルの展開方法とは無関係の問題でした。詳細については、以下の私の回答を参照してください。

@font-face は WebKit (Safari と Chrome) と Opera ではうまく機能しますが、Firefox 3.5 や IE 8 ではうまく機能しません。

Google などの推奨に従って、メイン サイトとは別のドメインから、CSS を含むすべての静的アセットを提供しています。同じドメインからすべてを提供すると、すべてのブラウザーで正常に動作します(注: これは、CSS 構文に関する回答が役に立たないことを意味します。私はすでにそのすべてを把握しており、うまく機能しています。これはクロスドメインの問題についてのみです)。 .

静的アセット ドメインから CSS とフォント ファイルを提供し、静的アセット サーバーに適切なアクセス制御ヘッダー(Access-Control-Allow-Origin) を設定させると、動作するはずですが、FF 3.5 と IE を除くすべての場所で動作します。

これを機能させるにはどうすればよいですか?

4

3 に答える 3

2

他の誰かに役立つことを願って、これまでに発見した最良の答え：

私が知る限り、重要な問題は (フォント ファイルではなく) CSS ファイルがクロスドメインで読み込まれるかどうかです。静的アセット ドメインから @font-face 宣言を含む CSS ファイルをロードすると、アクセス制御ヘッダーに関係なく、FF または IE でフォントが機能しなくなります。ページと同じドメインから CSS ファイルをロードするか、@font-face 宣言をページ ヘッドのスタイル ブロックに移動するだけで、すべてのブラウザーで動作します (フォント ファイルをクロスドメインでロードすることもできます)。アクセス制御ヘッダーが設定されている限り)。

要約すると、AFAICT、FF 3.5、および IE 8 は、何があっても、クロスドメインで読み込まれた CSS ファイルで @font-face 宣言を尊重することを拒否します。

誰かがもっとよく知っていて、私が間違っているかもしれないことを指摘できるなら、これを修正したいと思います.

確かに、私は間違っていました。専用ドメインから提供されるアセットをデプロイするために使用していた CSS コンプレッサーは、CSS のチャンク全体を「@media screen { ... }」でラップしていたことが判明しました。@font-face ルールを慎重に比較して、コンプレッサーが混乱していないことを確認しましたが、CSS ファイルの最初と最後をチェックしてそのラッピングをキャッチすることはありませんでした。同じドメインを提供するように切り替えたとき、そのラッピングは行われませんでした。

結局のところ、IE と Firefox は @media 内にラップされた @font-face 宣言を尊重しません。Safari、Chrome、Opera は受け入れます。

はぁ。

于 2010-01-09T00:46:58.490 に答える
-1

この IEBlog の投稿を参照することをお勧めします。IE でフォントを埋め込む方法が説明されています。いいえ、それは CSS3 の方法と一致しません。また、IE で @font-face を使用してそれを行う方法は他にありません。

Microsoft が EOT アプローチを標準化するために W3C に提出し、W3C がその一連の行動に関心を示したことは注目に値するかもしれません。

于 2010-01-09T00:56:52.357 に答える
-2

このリンクは私を大いに助けてくれました: http://snook.ca/archives/html_and_css/becoming-a-font-embedding-master

残念ながら、私が試したかったほとんどのフォントのテキストの品質には、ひどくがっかりしました。一部のフォントがアンチエイリアス対応でないかどうか判断できませんでしたが、結果は満足のいくものではなく、今でも画像置換を使用しています。

于 2010-01-09T00:53:02.337 に答える