Adobe Font Metrics
前提となるフォント環境
現在のコンピュータ環境では通常、ワープロやDTPソフト（に限らず実際には文字を利用するすべてのアプリケーション）では、そのコンピュータに搭載されているフォント以外は使用できない。（ただし、プリンタドライバの情報を利用するソフトウェアの場合、プリンタに搭載されているフォントを利用できるものもある。）
使いたいフォントがインストールされているコンピュータにデータを移動してフォントを置き換える、という方法もあるが、プロポーショナルフォントの場合に文字間の情報の違いからレイアウトが崩れてしまうなどの問題がある。また、組版においてはデザイン上の要求などから、文字の間隔を通常よりも狭くする処理（詰め組み）をおこなうことがある。日本語組版の場合、平仮名・片仮名の前後の間隔の場合にこの技法が多用される（これを特に「かな詰め」と言う）。デザイナーやオペレーターが適切な詰め量を判断して行う『手動詰め（手詰め）』と、フォントの持っている詰め情報を利用する『自動詰め』があるが、どちらも書体ごとに字形（タイプフェイス）が異なるため、フォントの置き換えを行うとレイアウトが崩れることは、上記の例同様であった。そのためフォントの置き換えをおこなうようなワークフローでは、すべて等幅フォントで、しかも詰めを一切おこなわずにレイアウトする、といった対策が採られる場合もあった。写研コンバータ（写研を参照）を使用する場合は、基本的にはこれに該当する。
AFMにより実現される機能
Adobe Font Metricsは、それに対応するアプリケーションにおいて、かな詰めなどを自由におこなえる仮想フォント環境を提供する。あるフォントの、各文字の幅・高さなどの詰め情報を記録したAFMファイルさえ用意すれば、当該フォントのない環境でもそのフォントを仮想的に扱うことができ、数段階の自動詰めも行うことができる。ただし、画面表示に使用される字形は実際のものとは大きく異なり、WYSIWYGからは一歩後退する。そのため、勘だけでおこなってほぼ差し支えのない数パーセントの字間調整などを除いて、字形に応じた手動詰めは原則的には不可能ということになる。
AFMファイルは、フォントではない。ただ、あるフォントの名前を代行し、縦組み、横組みそれぞれのための詰め情報を持っているだけである。縦横で異なる詰め情報が必要というのは、以下の例から説明できる。例えば漢数字の「一」は、横組みの場合には仮想ボディぎりぎりまで文字がデザインされているため詰められないが、縦組みの場合には前後の文字との間隔を九割がた詰めることが可能である。一方アラビア数字の「1」の場合は逆になる。AFMファイルの実体は単なるテキストデータであるので、使いたいフォントのAFMファイルが入手できない場合には、自分でつくってしまうことも理屈の上では可能ということになる。
AFMを使用したデータの出力
AFMファイルそれ自体はフォントではないので、そのフォントを積んでいないコンピュータから「ダイナミックダウンロード（コンピュータから字形を送信する方式）」を使用すると、正しい字形で出力されない。そのため、そのフォントを積んでいるコンピュータから出力するか、プリンタ自体がそのフォントを搭載しているプリンタから出力する。このどちらの場合も、AFMの効果によって正しいレイアウトが維持される。
AFMを利用したアプリケーションとしては、DTPソフトのEDICOLORなどが挙げられる。WindowsではMacintoshとまったく同じようにPostScriptフォントを使用するのは通常は不可能だが、この仕組みによって両オペレーティングシステム同士でファイルを交換してもレイアウトが崩れることがなく、また、Windowsからプリンタ搭載のPostScriptフォントを、かな詰めなどの処理をした状態で出力できる。かな詰めなどをおこなわないなら、フォント名（プリンタが認識するための名前）さえきちんとしていれば良い。なおMacintosh版EDICOLORではAFMは単一のファイルだが、Windows版では拡張子AFMと、拡張子RSRの2種類のファイルから構成される。
AFMファイル
AFMファイルの中味自体はシンプル極まりない。内容としては、文字幅、カーニング、バウンディング・ボックスなどの情報がASCII文字列で表記されている。TexにおけるTFMと同様のものである。ここに仮に、「Wikiゴシックｰミディアム」という、Macintosh用、縦組み対応のPostScriptフォントが存在するとして、そのAFMファイルがどのようになるかを示す。

StartFontMetrics 3.0
MetricsSets 0
FontName WikiGothic-Medium-83pv-RKSJ-H
IsBaseFont false
Characters 2502
FontBBox 0 -140 1000 880
EncodingScheme FontSpecific
MappingScheme 6
StartCharMetrics 2502
CH <20> ; W0X 250 ; B 0 0 0 0 ;
CH <21> ; W0X 333 ; B 109 -14 224 665 ;
CH <22> ; W0X 408 ; B 69 439 325 670 ;
CH <23> ; W0X 500 ; B 4 0 500 681 ;
CH <24> ; W0X 500 ; B 41 -82 406 699 ;
CH <25> ; W0X 833 ; B 61 -14 782 711 ;
CH <26> ; W0X 778 ; B 42 -19 750 676 ;
CH <27> ; W0X 180 ; B 45 430 124 685 ;
CH <28> ; W0X 333 ; B 48 -176 309 679 ;
CH <29> ; W0X 333 ; B 29 -175 284 680 ;
CH <2A> ; W0X 500 ; B 64 264 463 628 ;
CH <2B> ; W0X 564 ; B 65 5 543 321 ;
CH <2C> ; W0X 250 ; B 63 -123 234 110 ;
（中略）
CH <8140> ; W0X 1000 ; B 0 0 0 0 ;
CH <8141> ; W0X 1000 ; B 80 -74 329 176 ;
CH <8142> ; W0X 1000 ; B 80 -75 330 210 ;
CH <8143> ; W0X 1000 ; B 94 -130 245 121 ;
CH <8144> ; W0X 1000 ; B 100 -20 240 120 ;
CH <8145> ; W0X 1000 ; B 420 288 561 429 ;
CH <8146> ; W0X 1000 ; B 429 -21 525 687 ;
CH <8147> ; W0X 1000 ; B 423 -95 574 666 ;
CH <8148> ; W0X 1000 ; B 299 -39 702 750 ;
CH <8149> ; W0X 1000 ; B 440 -40 565 781 ;
CH <814A> ; W0X 1000 ; B 72 596 320 798 ;
CH <814B> ; W0X 1000 ; B 75 625 285 815 ;
（中略）
CH <EB71> ; W0X 1000 ; B 178 75 863 380 ;
CH <EB72> ; W0X 1000 ; B 172 366 813 665 ;
CH <EB73> ; W0X 1000 ; B 20 -37 925 352 ;
CH <EB74> ; W0X 1000 ; B 24 410 960 780 ;
CH <EB75> ; W0X 1000 ; B 63 -80 995 232 ;
CH <EB76> ; W0X 1000 ; B 18 510 930 831 ;
CH <EB77> ; W0X 1000 ; B 70 -55 990 220 ;
CH <EB78> ; W0X 1000 ; B 10 515 940 865 ;
CH <EB79> ; W0X 1000 ; B 18 -37 902 213 ;
CH <EB7A> ; W0X 1000 ; B 12 456 987 789 ;
（中略）
CH <EFF6> ; W0X 1000 ; B 0 0 0 0 ;
CH <EFF7> ; W0X 1000 ; B 0 0 0 0 ;
CH <EFF8> ; W0X 1000 ; B 0 0 0 0 ;
CH <EFF9> ; W0X 1000 ; B 0 0 0 0 ;
CH <EFFA> ; W0X 1000 ; B 0 0 0 0 ;
CH <EFFB> ; W0X 1000 ; B 0 0 0 0 ;
CH <EFFC> ; W0X 1000 ; B 0 0 0 0 ;
EndCharMetrics
EndFontMetrics
※なおこのAFM情報は、モリサワの和文PostScriptフォント、リュウミンL-KLのファイルを元に書き換えて作成したもので、数値はかなり無意味なものになっている。