標準フォントの送り幅

/Widths を持たないロード済み単純 PDF テキストは、サポート対象文字に Adobe コアフォントの水平送り幅を使います。インストール済み代替フォントのメトリックが異なっても、累積的な位置ずれを防ぎます

サポート対象の契約

各フェイスには 230 個のデコード済み Unicode エントリがあります。印刷可能 ASCII、Latin-1、定義済みの印刷可能 Windows-1252 文字に加え、dotless i、Lslash、lslash、caron、breve、dotaccent、ring、ogonek、hungarumlaut、fraction、fi、fl です

U+00A0 はスペースの送り幅を、U+00AD はハイフンの送り幅を使います。U+00B5 は Latin-1 のマイクロ記号ですが、ギリシャ文字の U+03BC は表の外です

生の StandardEncoding バイト 39 は U+2019 quoteright にデコードされます。WinAnsi のバイト 39 は U+0027 quotesingle にデコードされ、Helvetica の送り幅が異なります

サブセット接頭辞付きの名前、Arial や Courier New といったエイリアス、大文字小文字の違い、Symbol、ZapfDingbats、制御文字、ギリシャ文字、その他の未対応 Unicode は、既存のフォールバック動作を保ちます

明示的な PDF /Widths は、意図的にカスタマイズされた送り幅も含めて保持されます。フォントプログラムとエンコーディングマップはこれらの表とは別のままで、明示的な幅を持つ埋め込み TrueType フィクスチャは受け入れテストでカバーされます

これらは水平送り幅だけです。グリフの輪郭、バウンディングボックス、垂直メトリック、合字シェーピング、カーニングは供給せず、レンダラーは標準送り幅でテキストを配置しながら、インストール済み代替フォントで描画できます

計測とテキスト状態

HPDFGetStandardFontWidth は不変の表引きを行います。バッチにフォールバック文字が含まれる場合、HPDFMeasureBaseFontWidths はその結果を既存のプラットフォームバックエンドと組み合わせます

コンテンツインタープリターは、送り幅の解決後もフォントサイズ、Tc、Tw、Tz、TJ 調整、テキストマトリクス、グラフィックス変換を適用し続けます。これらの表が PDF テキストに自動カーニングを追加することはありません

検証と独立リーダーの境界

焦点を当てた受け入れは、12 フェイスすべて、StandardEncoding の引用符と合字、WinAnsi の句読点とアクセント付きテキスト、明示的な幅、埋め込み TrueType プログラム、変換された TJ テキストをカバーする 15 個の実際の PDF ページを構築します。ネイティブのグリフ原点は独立した MuPDF リーダーと比較されます

Unicode 送り幅プローブは表の全 2,760 エントリを検査します。2,756 は MuPDF と一致しますが、Helvetica ファミリーの 4 つの U+2044 fraction エントリは Adobe AFM WX 167 を保持し、MuPDF がその文字にスラッシュ風の送り幅 278 を返すため明示的に報告されます

共有 PDF ジオメトリ比較は、独立リーダーが一致する文字を使います。fraction の差異は、合格するリーダー間等価として報告されません

Windows の受け入れは Tests/Delphi/Run-StandardFontMetricsAcceptance.ps1 を使い、既存のテキスト抽出と幅のスイートも再生します。ネイティブ Linux の受け入れは、FPC_EXE、PYTHON_EXE、HPDF_LINUX_OUTPUT の上書き付きで Tests/Linux/Run-StandardFontMetricsAcceptance.sh を使います

すべての実行は外部リーダーの起動を抑制し、ネイティブログ、送り幅表、グリフ座標、描画プレビュー、independent-proof.json レポートを出力します

メトリックの根拠

送り幅は 1/1000 em 単位の Adobe コアフォント AFM WX の事実値です。座標とメトリックの規約はAdobe Font Metrics 仕様に文書化されています