どこで良いフォントの紹介を見つけることができます

Question

フォントで作業するコードを書く必要があります。私を始めさせる主題についての良い紹介はありますか？

Answer 1

What every developer should know about fontsには非常に良い紹介があります。

私はここに投稿をコピーしましたが、投稿の多くは特定のフォントに依存していますので、パーツは写真と絵が書き込まれているので、上記のリンクを強くおすすめします。

私はもともとフォントを使うのはかなりシンプルだと考えました。しかし、Windward Reports（XMLとSQL Reportingシステム）では、フォントの適切な処理が重要な作業になっています。フォームにテキスト行を配置するよりもはるかに多くを行う場合は、詳細が重要になります。

フォント&グリフ フォントとは何ですか？基本的に、フォントは一連のグリフです。あなたが文字Aのような文字として考えるのはグリフです。フォントは、そのフォント内のすべての文字のグリフのセットです。 Helveticaフォントを取得した場合、すべてのグリフが一方向に見えます。 Times Romanフォントを取得した場合、別のフォントが表示されます。それぞれは、そのフォントからのグリフのセットです。

ここでコードページの概念を紹介する必要があります。コードページは、文字番号から特定のグリフへのマッピングです。プログラムはもともと各文字をバイトとして格納していました。次に、アジアの文字セットの場合、DBCSシステムがありました（一部の文字は1バイトで、2文字は2文字でした）。今日のプログラムは、主にUnicodeを使用していますが、WebページはUTF-8である傾向があります。これは、最大4バイトまでのマルチバイトシーケンスです。

なぜエンコードを使用しますか？各フォントは、フォントによって使用されるコードページに応じて、文字番号178が非常に異なるグリフを返すことができるエンコーディングを持つためです。ほとんどのフォントファイルはUnicodeを使用していますので、そこに標準がありますが、多くのプログラムでは特定のコードページを使用しています。そのページはフォントにマッピングされています。これはABCを表示してフォントがWingdingsなので、あなたはを得ることができます。だから、使用するエンコーディングが一致するか、または使用するフォントのエンコーディングにマッピングされていることを確認する必要があります。

さらに複雑になります。値0xE000〜0xF8FFの文字は未定義です。それぞれのフォントは、必要なものを作ることができます（1つはKlingonスクリプトを追加することです）。したがって、この範囲の値を持つ文字は、そのフォントを表示するために使用しているフォントファイルに結び付けられています。これが、ほとんどのシンボルタイプのフォントが動作する方法です。

Unicodeを使用しているので、フォントファイルはUnicodeを使用し、文字列を渡すと文字列は空白になります。どうしたの？まあ、フォントファイルに任意の文字のグリフがあるという要件はありません。シンボルフォントにはABCはありません。ヨーロッパやアメリカで使用されているほとんどのフォントには、中国語、日本語、韓国語の字形がありません。フォントにはないグリフを使用するのは誤りではありませんが、空白ではなく何も表示されません（0ポイント幅）。

コードページに存在しないグリフを表示する場合は、古いコードページのいずれかを使用している場合も同様の問題が発生する可能性があります。その場合は、少なくともその文字のために別のコードページにマップする必要があります（Wordがこのケースを処理する方法です）。

フォントファミリー フォントはいくつかの異なるクラスに分類されます。まず、比例フォント対等幅フォントがあります。固定幅フォントでは、すべての文字が正確に同じ幅になります。そして、高さはすべての小文字がすべて大文字であるのと同じ高さであるという点で一貫しています。モノスペースフォントは、読みにくいため、できるだけ避けてください。アジアのフォントは、中国語の漢字の幅と高さがすべて同じであるため、モノスペースであるため、比例しても意味がありません。反面、ヘブライ語とアラビア語は比例する必要があります。

次は、ストロークの終わりに物を得るセリフ、最後に余分なものを得ないサンセリフ、普通の方向を超える装飾、何かを持つことができるシンボルグリフにマップされた文字コードのASCII番号と一致するバーコードを含む、ランダムな文字列です。これは西ヨーロッパのアルファベットだけです。

Fontmetrics これで、フォントの測定が始まりました。フォントの大半（一部ではない）がグリフを測定しています。フォントに使用される標準的な測定値はポイントであり、ポイントがもともと意味するものに多くの歴史がありますが、コンピュータの世界では72ポイント== 1インチでした。ポイントの20分の2を表すtwipも表示されるので、1440 twips == 1インチとなります。 EMUは現在914400 EMU == 1インチです（詳細はこちら）。ポイントを扱う場合は、浮動小数点変数を使用する必要があります。 Twipsは一般的には整数であり、EMUは間違いありません。

フォントポイントのサイズが表示されます。これは完全に任意の数です。実際のサイズが期待したサイズに近いが、決してその数ではなかった古いCRTモニターの対角サイズのように考えてください。ポイントサイズはレンダリングされたグリフのサイズを決定しますが、ページ上には特定の測定値はありません。

ここで興味深いのは、fontmetricsです。まず、すべてがベースラインから測定されなければならない。フォントの他の部分から作業することはできません - あなたは大きな問題にぶつかるでしょう。だからそこから始めよう。ベースラインより上に描画された部分のうち最も高いものは、ベースラインから測定されたベースラインの下の上昇と最も低い描画された部分です。

次に、2行のテキストの間にスペースがあります。これはフォント設定で、フォントデザイナーはそのフォントの適切な間隔を決定します。これは異なる方法で返すことができます.Windowsは、次の行の上に置く間隔をベースラインからベースラインに戻し、Javaは次の行の前の行の間隔としてそれを表示し、この値を返します。これは、同様の間隔を置いて配置された同じテキストの行間に配置する間隔です。間隔が単一間隔より大きい場合は、この値に追加します。

一般的に、表示する文字列のグリフ文字列ではなく、フォントのこれらの高さを取得する必要があります。どうして？なぜなら、もし行が "私たちがwroxだった"とすれば、上行や下降のない行は、段落の他の行の近くに置かれ、それは奇妙に見えるからです。また、テキストが大きい場合は、大きな上昇/下降/先行値を使用する必要があるため、すべてのフォントとポイントサイズを調べる必要があります。しかし、段落全体ではなく、より大きいテキストを持つ行に対してのみ。また、これはすべて、混合フォント/サイズを処理する唯一の方法であるベースラインから測定されます。

高さは少しばかりかかりますが、それはかなり簡単ですが、幅は非常に興味深いものです。面白いことに、私はあなたが正しいものをすべて手に入れなければならないということを意味します。基本的には、固定幅フォントを除いて、各グリフの幅を加算することは、一緒にレンダリングされるすべてのグリフの幅と等しくなりません。かなり決してありません。どうして？いくつかの理由があります。

•カーニングは、隣接する文字に基づいて文字が配置される場所です。そのため、ABがかなり重なっている間は、ABは区別されたままです。 •ラテンアルファベットの一部の文字の組み合わせは、aeがæ、ドイツ語がßになるなど、結合されます。 •ヘブライ語とアラビア語の字形は、同じ文字の場合、単語の先頭、途中、末尾に応じて異なります。アラビア語の場合、特に端で使用されるグリフは中央のグリフよりも幅が広い傾向があります。したがって、صの幅は、文字列内のどこに依存します。 ◦双方向フォントには以下の問題があります。 •Indic（インド）のような複雑なスクリプトは、グリフをいくつかの文字から構築する場所で変更します。したがって、3文字の文字列は、1〜3グリフ幅の任意の文字列にすることができます。 非常に単純に、完全にフォーマットされた完全な文字列を、実行中のプラットフォームが提供するfontmetrics APIに供給して、文字列の長さを取得する必要があります。文字列は長さを決定するためにメモリにレンダリングされるため、高価な呼び出しですが、正確な代替方法はありません。また、レンダリング時とまったく同じ設定を使用する必要があります。これらが一致していないときはいつでも、私たちは人間の目がそれらを作ることができるほど大きな差を見つけました。このためにコードをテストする最良の方法は、文字列の左端のベースライン位置を取得する必要があるため、右揃えのテキストを見ることです。長さを間違って計算すると表示されます。

双方向テキスト 最後に、双方向テキスト（アラビア語&ヘブライ語）の問題があります。双方向テキストは右から左に移動しますが、数字とラテン語は左から右に移動します。それで、それは右から左に読み込まれます。次に、数字またはラテン文字のシーケンスで最も左のポイントにジャンプし、左から右に読んで前のヘブライ語/アラビア語を完成した場所に戻り、次にラテン/数字の部分と右に戻る。

これらのスイッチがいつ行われるべきかについて、数多くの研究が行われています。方向が強い文字、方向が弱い文字、方向性のない文字があります。あなたはこれらの規則を正しく実施する祈りはありません。なし。しかし、すべてが失われません。 JavaやWindowsを含むほとんどすべてのプラットフォームには、読んだ順に文字列を提供するAPIがあり、ルールに従って正しく表示されます。また、キャレット1の文字を前後に移動する場合は、各文字の位置と移動先の文字を示すAPIも用意されています。

このAPIは、テキストに関係なくすべてのフォントレンダリングとキャレット移動に使用でき、複雑なスクリプトでもうまく動作します。あなたが双方向のスクリプトや複雑なスクリプトをターゲットにしていない場合は、これから始めるのが少し難しいですが、最終的にそこにいるのなら、それを使用して始めるのが最善です。コード。私を信じて、あなたは本当に本当に本当に再構築する必要はありません（私は一度 - OW！）。

警告 WindowsフォントをLinuxや他のオペレーティングシステムにコピーしないでください。 fontmetricsはオフになる傾向があり、テキストは見えなくなります。私は、TrueTypeが移植可能であるとはどういうものか分かりませんが、実際にはJavaはどこでもデバッグができるように、フォントは一度どこでも調整できる傾向があります。プラットフォームに合わせて最適化したベンダーからフォントを入手してください。