技術的資料

AH Formatter V7.2 を用いて、Web用にデザインされたHTMLを組版することができます（フレームを用いたHTMLを除きます）。 ただし、何も手を加えずに組版して、よい結果を得られるHTMLは多くないかも知れません。 その理由は次のようなものです。

• HTMLが画面用に特化してデザインされており、印刷媒体のことが考慮されていない。
• HTMLが仕様から大きく逸脱している。
• CSSが仕様どおりに用いられていない。

例えば、ウェブブラウザから印刷してみて、右側などが欠けずに印刷できれば、AH Formatter V7.2 で組版してもそれなりの結果が得られるでしょう。しかし、よりよい結果を得るには、HTMLが画面用と印刷用とを意識して設計されていなければなりません。印刷用のCSSには、

@media print { ... }
@page { ... }

のようなルールできめ細かくスタイルを指定してあるでしょう。 また、現在のウェブブラウザ間のCSS実装レベルには、大きな差があります。特定のブラウザでの表示を意識して、誤った文法のHTMLであったり、不正なCSSを多用しているHTMLでは、よい結果を得ることはできないでしょう。

多くのWeb上の(X)HTMLは、具体的なフォントの指定を行っていません（それはWebの性格上好ましい）。 AH Formatter V7.2 Windows版のGUIでは、オプション設定ファイル中のスクリプトごとのフォント設定が常に有効なので、適切なフォントが選択されます。 しかし、Windows版のGUI以外では、そのようなことはありません。オプション設定ファイルで <script-font> を適切に設定し、組版時にそのオプション設定ファイルを指定するようにしてください。

CSSの適用順序は、CSS3仕様で次のように規定されています。

1. Normal user agent declarations
2. Normal user declarations
3. Normal author declarations
4. Animation declarations (未サポート)
5. Important author declarations
6. Important user declarations
7. Important user agent declarations
8. Transition declarations (未サポート)

AH Formatter V7.2 では、それぞれ次に対応します。

• user agent declarations

  html.css です。 HTML用デフォルトCSS を参照してください。

• user declarations

  オプション設定ファイルの <usercss> で指定されるもの、コマンドラインの -css や -s で指定されるものです。 （.NETやJavaなどのインターフェイスでは、対応するコマンドラインオプションと同等です。） これらは、次の順序で適用されます。

  1. オプション設定ファイルと、-css で指定されたCSSを出現順序どおりに適用。
  2. -s で指定されたCSSを適用。

  GUIではオプション設定ファイルのみが適用されます。 組版オプション設定ダイアログのCSSページで設定されるものは、オプション設定ファイルに反映されます。

• author declarations

  HTML中の <link> や <style> で指定されたもの、XML中の <?xml-stylesheet ...?> の処理命令で指定されたものです。 これらは、次の順序で適用されます。

  1. XML中の処理命令 <?xml-stylesheet?> を出現順序どおりに適用。（XMLまたはXHTML）
  2. HTML中の <link> や <style> を出現順序どおりに適用。（HTMLまたはXHTML）
  3. HTMLやSVG、MathML中の style属性を適用。

  <link> では、次のような rel="stylesheet" または rel="alternate stylesheet" が指定されたCSSが適用されます。

  <link rel="stylesheet" href="main.css" />
  

  <?xml-stylesheet?>、<link>、<style> には、title 属性を持たせることができます。alternate でなく title 属性のないものはすべて適用されますが、空でない title 属性を含めた場合は、それらは必ずしも適用されません。 最初に出現した alternate でない title と同じものだけが適用されます。 例えば、

  <link rel="stylesheet" href="main.css" />
  <link rel="stylesheet" href="A.css" title="A" />
  <link rel="stylesheet" href="B.css" title="B" />
  <link rel="alternate stylesheet" href="C.css" title="A" />
  <style title="S">...</style>
  

  とあった場合、B.css と <style> は適用されません。 alternate には title が必要です。title のない alternate の <link> が適用されることはありません。

HTML用デフォルトCSSは、(X)HTMLを組版するときに、最初のスタイルシート（user agent declarations）として利用されます。これは、環境変数 AHF72_DEFAULT_HTML_CSS または AHF72_64_DEFAULT_HTML_CSS で示される場所にある html.css です。 （html.css が存在しないときは、すべての要素が inline であるとして組版されます。）

このスタイルシートは、ウェブブラウザの表示や、CSSで規定されているスタイルなどを元に作成されています。しかし、環境によってはうまく表示できない指定があるかも知れません。また、好みの違いもあるでしょう。 デフォルトCSSは、利用者が自身の環境などに合わせて、最適に調整しておくことが望まれます。 いくつか例を示します。

• <q>

  デフォルトCSSで次のように指定されています。

  q::before { content: open-quote }
  q::after  { content: close-quote }
  

  AH Formatter V7.2 では、quotes の初期値は "\201C" "\201D" "\2018" "\2019" です。 次のような指定がお好みかも知れません。

  q:lang(en) { quotes: '"' '"' "'" "'" }
  q:lang(no) { quotes: "«" "»" '"' '"' }
  

• footnote

  脚注番号は、左ページ余白にはみ出すように指定されています。はみ出さないようにしたいときは、@footnote に padding-left を指定したり、list-style-position:inside を指定したりしてください。 また、番号付けに decimal が指定されています。 super-decimal を使いたいときは次のように修正するとよいでしょう。

  ::footnote-call {
    content: counter(footnote, super-decimal);
  }
  ::footnote-marker {
    content: counter(footnote, super-decimal);
    -ah-margin-end: 0.5em;
    text-indent: 0;
  }
  

• ::marker

  リストのマーカに使われる記号は、オプション設定ファイルの <list-style-type> で指定されています。その字形はフォントに依存するので、フォントが異なれば異なるマーカが表示されるでしょう。::marker には、特定のフォント指定がないので、利用されるフォントはそのときの文脈に依存します。必要ならば ::marker に特定のフォントを指定しておくのがよいでしょう。

組版種別を自動として組版を開始したときは、おおよそ、次のような手順で種別を決定します。

1. MIMEの指定があるときは、それに従います。すなわち、text/html ならばHTMLとします。application/xhtml+xml ならばXHTMLとします。
2. オプション設定ファイルで auto-formatter-type="html" が指定してあり、入力文書の拡張子がわかっているときは、それに従います。すなわち、.htm や .html などHTMLのものらしければHTMLとします。.xht や .xhtml などXHTMLのものらしければXHTMLとします。
3. XML宣言がなく、DOCTYPEがHTMLのものであればHTMLと、XHTMLのものであればXMTMLとします。
4. オプション設定ファイルで auto-formatter-type="xhtml" が指定してあり、名前空間がXHTMLのものであれば、XHTMLとします。
5. XML宣言がなく、名前空間もなく、ルート要素が大文字小文字区別なしの <HTML> ならば、HTMLとします。
6. （外部または文書内に）XSLTでないCSSのようなものが指定されているときは、XML+CSSとします。
7. 名前空間がXSL-FOのものであれば、XSL-FOとします。
8. これら以外のときは、XML+CSSとします。

HTMLのときは、文書がXMLである必要はありませんが、HTML以外は、文書が整形式のXMLであることが要求されます。

AH Formatter V7.2 と AH Formatter V7.1 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• CSS解釈の相違

  以下の相違があります。

  • 関数名と括弧の間に空白があると、正しく文法エラーになります。例えば、rgb (...) は文法違反です。
  • CSSでは裸の式はプロパティに指定できません。例えば、

    font-size: 20pt + 30pt;

    のような記述は文法違反です。正しくは、

    font-size: calc(20pt + 30pt);

    としなければなりません。AH Formatter V7.1 では calc() で囲まれていない裸の式をある程度許容していました。そのようにしたいときは、オプション設定ファイルで css-allow-bare-expression="true" を指定してください。
  • :first-child や :only-of-type などの疑似クラスがルート要素にマッチするようになりました。AH Formatter V7.1 のようにマッチしないようにしたいときは、オプション設定ファイルで css-child-match-root="false" を指定してください。

• <link>

  HTMLの <link> で、titleの指定されたものが指定順のとおりに適用されないことがありましたが、指定順のとおりに適用されるようになりました。また、<link rel="alternate stylesheet"> で指定されたスタイルシートが適用されるようになりました。CSSの適用順序を参照してください。

AH Formatter V7.1 と AH Formatter V7.0 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• 画像サイズの%指定

  (X)HTMLで、<img src="xxx" width="50%">としたときの%は画像のサイズが基準となります。 CSSで img { width:50% } としたときは親要素のサイズが基準となります。 しかし、AH Formatter V7.0まではCSSの場合でも、以下のプロパティの%が画像のサイズを基準として計算されていました。

  • width
  • max-width
  • min-width
  • height
  • max-height
  • min-height

  AH Formatter V7.1ではこの誤りが訂正され、親要素のサイズを基準として計算されます。 もし、以前と同じように計算させたいときは、オプション設定ファイルで fix-css-img-percentage="false" を指定してください。

AH Formatter V7.0 と AH Formatter V6.6 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• 行分割

  行分割処理が改良されました。行分割を参照してください。 また、Unicode の仕様変更により、行分割位置が変化することがあります。

• axf:suppress-if-first-on-page

  axf:suppress-if-first-on-page の動作が改良されました。

  • axf:suppress-if-first-on-page により削除されたブロックに続くブロックにも指定された axf:suppress-if-first-on-page が有効になりました。
  • 段組エリア内で axf:suppress-if-first-on-page が有効になりました。
  • axf:suppress-if-first-on-page により削除されたブロックに続くブロックに指定された space-before が無効になりました。
  • ページ先頭の fo:table-row に fo:marker が指定されていたとき、それに続く fo:table-row に指定された axf:suppress-if-first-on-page が有効になりました。

• ::first-letter

  CSS の ::first-letter擬似要素で文字を大きくしたような場合、line-height が明示されていないと行間が広がってしまうことがありました。AH Formatter V7.0 では、::first-letterにline-heightが明示されていないときには不必要に行間が広がらないようになりました。

• zwsp-mode

  zwsp-mode のデフォルト値が 6 に変更されました。

• hyphenation-keep-mode

  hyphenation-keep="page" などで、ページ（段）末の単語がハイフネーションされているときの処理方法が改良されました。 オプション設定ファイルの hyphenation-keep-mode を参照してください。 V6と同様に組ませたいときは、hyphenation-keep-mode="line" と指定してください。

• white-space-collapse-mode

  white-space-collapse は、<fo:inline> をまたいで適用するように実装されていますが、AH Formatter V6.6 までは、無条件に適用していたので、<fo:inline> にボーダーがあるようなケースでも collapse されていました。AH Formatter V7.0 では、以下の条件のときは collapse しないようになりました。

  • <fo:inline> の境界に border や padding があるとき
  • 間に幅指定のある <fo:inline> があるとき

  V6と同様に組ませたいときは、オプション設定ファイルで white-space-collapse-mode="6" と指定してください。

• font-stretch-mode

  font-stretch-mode="6" の動作が修正されました。
  font-stretchにcondensedなどのキーワードを指定したとき、フォント選択にその情報を利用します。そして、例えば、extra-condensedを指定したとき、condensedフォントがあればそのフォントを元に圧縮が行われます。そのときの圧縮率は (62.5/75)% = 83.3% となります。ただし、選択候補の中にnormalフォントがない場合は 62.5% の圧縮率となります。

• マルチメディア埋め込みのポスター画像

  AH Formatter V7.0 では、マルチメディアの埋め込み時に axf:poster-image が指定されていたら、その画像サイズを使用するようになりました。AH Formatter V6.6 までと同じように動作させるには、scaling="non-uniform" content-width="scale-to-fit" content-height="scale-to-fit" を <fo:external-graphic> に指定してください。

• BIDI

  UAX #9: Unicode Bidirectional Algorithm のリビジョン41に対応しました。V6と同様のアルゴリズムで処理したい場合は、unicode-bidi-rev で37未満の値を設定してください。37以上の値は41とみなされます。 ☞ BIDIアルゴリズムの実装上の制限

AH Formatter V6.6 と AH Formatter V6.5 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• html.css

  HTML用デフォルトCSS（html.css）の記述に変更があります。

  • li::marker {...} が ::marker {...} と変更されました。これにより、<li> 以外の list-item のマーカにもこのスタイルが適用されます。 そのため、-ah-margin-end:0.5em; によって今までと違うマージンが付くようになります。必要なら -ah-margin-end:0; などを指定するようにしてください。
  • *[hidden] { visibility: hidden } が追加されました。

• -ah-force-page-count

  CSSで

  @page {
    -ah-force-page-count: document 4;
  

  のように書くと、AH Formatter V6.6 では、すべてのページの切り替え時に -ah-force-page-count が作用します。AH Formatter V6.5 までと同じように最後のページにのみ作用させるには、最後に使うページセレクタのある @page に -ah-force-page-count を指定してください。

• リガチャの抑制

  次の文字を挿入することで、リガチャが抑制されるようになりました。

  • U+200B
  • U+200C
  • U+2060
  • U+FEFF

• MathML

  デフォルトで、STIXバージョン2.0 のフォントがインストールされているときはそれが採用されるようになりました。

  OpenType に MATHテーブルがあれば、それを参照するようになりました。オプション設定ファイルの enableOpenTypeMATH、exceptOpenTypeMATHVariants で細かく制御できます。

  <mlongdiv> の線の太さが、mslinethickness の太さで描かれるようになりました。

  行分割が起こったときの各行の高さが、それぞれの高さとなるようになりました。 AH Formatter V6.5 までのように各行の高さが同一になるようにするには、オプション設定ファイルで、linebreakingHeightAdjust="false" を指定してください。

AH Formatter V6.4 と AH Formatter V6.3 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• MathML

  オプション設定ファイルの MathML に関する設定で、添え字の配置に関する初期値が若干修正されました。 AH Formatter V6.3 の設定にするためには、mathmlSettingsMode="6.3" を指定してください。

AH Formatter V6.3 と AH Formatter V6.2 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• keep-footnote-anchor

  AH Formatter V6.2 では、アンカーを含むブロックが orphansなどの条件によって次のページに送られてしまい、脚注自身が前のページに配置されるということがまれに起こります。AH Formatter V6.3 では、アンカーの後の分割可能な位置までを前のページに収めようとします。これは、元のブロックに axf:footnote-keep="always" を指定しても同じ効果を得ることができます。 AH Formatter V6.2 までと同じように動作させるには、オプション設定ファイルで keep-footnote-anchor="false" を指定してください。

• list-style-type

  list-style-type の実装が、定義済みカウンタスタイルを利用するように変更されました。以前の list-style-type にあって定義済みカウンタスタイルに含まれない名前は以下のとおりです。

  • cjk-ideographic
  • japanese-formal-obsolete
  • urdu
  • lower-norwegian
  • upper-norwegian
  • hangul
  • hangul-consonant
  • halfwidth-katakana
  • halfwidth-katakana-iroha

  以前の list-style-type と同じ名前であっても、定義済みカウンタスタイルの実装には若干の相違があります。以前の list-style-type のスタイルを採用したいときは、axf:number-transform="lower-alpha" ではなくて axf:number-transform="'lower-alpha'" のように指定してください。

AH Formatter V6.2 と AH Formatter V6.1 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• latin-ligature / pair-kerning

  オプション設定ファイルの、latin-ligature と pair-kerning のデフォルト値が変更されました。AH Formatter V6.1 までは、これらのデフォルト値は false でしたが、AH Formatter V6.2 では true に変更されました。これは、デフォルトでよりよい組版結果を得ることができるように、ということを意図しています。 FO中でそれらについて、axf:ligature-mode と axf:kerning-mode が明示的に指定されている場合は、組版結果に影響はありません。 また、これらの指定は組版速度に影響します。

• ブロックの分割

  CSSで、高さが auto のブロックが、例えばページ末で分割されたとき、AH Formatter V6.1 までは、前のページでのそのブロックの高さは分割位置のままでした。AH Formatter V6.2 では、ページ末までの高さに調整されます。これは、ブロックに背景やボーダーが指定されているときに違いが顕著です。段の末尾等でも同様です。 ☞ 5.3. Splitting Boxes
  なお、FOには適用されません。
  オプション設定ファイルで splitting-blocks-space="true" と指定することで、V6.1の動作に戻すことができます。

• beforeフロートの回り込み

  before側のフロートの幅が領域いっぱいで、テキストの回りこむ余地がないとき、intrusion-displace="auto" などでは、テキストはフロートをよけて配置されますがブロック自身はフロートに重なっていました。これは、ブロックに背景やボーダーを付けると確認できます。intrusion-displace="block" のときはブロック自身もフロートをよけて配置されます。AH Formatter V6.2 では、intrusion-displace の指定によらずにブロック自身がフロートをよけて配置されるようになりました。

• 脚注の分割

  AH Formatter V6.1 までは、footnote-body内でページ分割（段分割）することはありませんでした。AH Formatter V6.2では、footnote-body内での分割が可能です。脚注の分割は axf:footnote-max-height の指定によりますが、デフォルトでは分割が起こるため、AH Formatter V6.1 と組版結果が異なることがあります。自動的な分割をしないようにするには、オプション設定ファイルで auto-break-footnote="false" を指定してください。

• BIDI

  AH Formatter V6.1 までは、BIDI 処理に問題があったことがわかっています。AH Formatter V6.2 では BIDI 処理が修正されました。そのため、V6.1 までと組版結果が異なることがあります。

AH Formatter V6.1 と AH Formatter V6.0 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• normalize

  AH Formatter V6.1 では、入力されたテキストに対して Unicode の正規化処理（UAX#15: Unicode Normalization Forms）が行われるようになりました。 axf:normalize を参照してください。 正規化処理は、組版速度に多少影響します。 デフォルトでの正規化処理を行わないようにするには、オプション設定ファイルで normalize="none" を指定してください。

• font-stretch-mode

  AH Formatter V6.1 では、font-familyにファミリ名を指定したとき、font-stretch="condensed" などを考慮して、実際にcondensedフォントがある場合にそれを選択させることができるようになりました。 オプション設定ファイルで font-stretch-mode="6" を指定してください。 font-stretch-mode="5" と "6" の動作の違いは以下のとおりです。

  • font-stretch-mode="5"

    AH Formatter V5 と同じ動作をします。フォント選択に、font-stretch の情報は利用されません。つまり、condensedフォントがファミリ内にあっても選択されません。condensedフォントを選択するには、そのフォント名を明示する必要があります。例えば、Fooというファミリ名のフォントに、Foo-Regular.otf と Foo-Condensed.otf というフォントがあったとき、<fo:block font-family="Foo" font-stretch="condensed"> としても Foo-Condensed.otf は選択されません。<fo:block font-family="Foo-Condensed"> のように指定する必要があります。

    <fo:block font-family="Foo" font-stretch="condensed"> とした場合、Foo-Regular.otf を圧縮して表示します。そのときの圧縮率は、OpenTypeの仕様に示されている値よりも若干小さく（伸張のときは大きく）なります。

  • font-stretch-mode="6"

    フォント選択に、font-stretch の情報を利用します。上の例で、<fo:block font-family="Foo" font-stretch="condensed"> とすれば Foo-Condensed.otf が選択されます。font-stretch に数値を指定したときはcondensedフォントは探されません。また、<fo:block font-family="Foo" font-stretch="extra-condensed"> としたとき、extra-condensedフォントがないときにcondensedフォントを圧縮するわけではありません。normalフォントの圧縮が行われます。

    condensedフォントがないときの圧縮率は、OpenTypeの仕様に示されている次の値となります。

    ultra-condensed	50%
    extra-condensed	62.5%
    condensed	75%
    semi-condensed	87.5%
    normal	100%
    semi-expanded	112.5%
    expanded	125%
    extra-expanded	150%
    ultra-expanded	200%

  AH Formatter V7.0 で動作が修正されました。 ☞ font-stretch-mode

• baseline-mode

  ベースラインの位置は、AH Formatter V5 で改良されましたが、縦書き時に欧文の文字（英数字）を正立させたときに中心が揃わない問題が残っていました。この問題は AH Formatter V6.1 で解決されました。 V5と同様に組ませたいときに、オプション設定ファイルで baseline-mode="5" と指定してください。

• viewport-length-units-mode

  単位 vw、vh の解釈が変更されました。以前はページ余白を含むページ全体のサイズを基準としていましたが、AH Formatter V6.1 ではページ余白を除くサイズが基準となります。また、ページ全体を基準とする単位 pvw、pvh 等も追加されています。 V5と同様に組ませたいときには、オプション設定ファイルで viewport-length-units-mode="5" と指定してください。このとき、vw=pvw、vh=pvh、vmin=pvmin、vmax=pvmax となります。

• letter-spacing / word-spacing

  letter-spacing や word-spacing が指定されているテキストでは、axf:punctuation-trim や axf:text-autospace などの指定が無効でした。AH Formatter V6.1 では、この制限が解除されています。

• 全角空白の扱い

  AH Formatter V6.1 では、全角空白(U+3000)の扱いが若干変更されました。

  • axf:punctuation-trim="adjacent" のとき、全角括弧との間で詰めが起こります。
  • 行頭禁則されます。これは、Unicode 6.3 での仕様変更を受けてのことです。行頭禁則したくないときは、オプション設定ファイルで non-starter-ideographic-space="false" と指定してください。

AH Formatter V6.0 と AH Formatter V5 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• span

  AH Formatter V6.0 では、span="all"の振る舞いが、AH Formatter V5 と異なっています。

  • AH Formatter V5では、<fo:block-container>などの参照領域を生成するFOの、入れ子になった内側のspan指定も有効になっています。これが AH Formatter V6.0では、参照領域を生成するFOの中に入れ子になったFOでのspan指定は無効となります。例えば、

    <fo:block-container>
    <fo:block span="all">
    <fo:block>ABC</fo:block>
    </fo:block>
    </fo:block-container>
    

    のようなとき、<fo:block>ABC</fo:block>に対して、V5では span="all"が有効でしたが、AH Formatter V6.0では無効となります。また、axf:column-countを使った <fo:block-container>の段組の中の <fo:block>で span="all"が指定された場合は、その <fo:block-container>の段組に対してスパンが指定されたものとなります。組版結果を V5と同様にするには、親の <fo:block-contianer>で span="all"を指定するようにしてください。

  • 文書先頭での空のブロックとspan="all"のブロックの間の強制改ページの指定は、V5では無視されていましたが、AH Formatter V6.0 では強制改ページが有効となり、空白ページが生じます。組版結果を V5と同様にするには、次のようにしてください。

    • 空のブロックをbreak-before="page"を指定したブロックの前に置かない。または、
    • break-before="page"を指定しない（<fo:flow>の先頭なので不要）。または空のブロックの方に指定する。

  • 1段組の場合に、V5ではspan="all"の指定の効果がありませんでした。AH Formatter V6.0 では1段組であっても参照領域が生成されます。これは、例えば次のような違いを生みます。

    <fo:block>AAA</fo:block>
    <fo:block space-before="1cm" span="all">BBB</fo:block>
    

    1段組の場合、V5ではAAAとBBBの間にspace-before="1cm"によるスペースができますが、AH Formatter V6.0 ではできません。なぜなら、1段組でもspanによる参照領域が生成されて、参照領域の先頭でspace-before.conditionality="retain"の指定がないスペースが除去されるためです。組版結果を V5と同様にするには、1段組のときはspan="all"を指定しないようにしてください。

• text-underline-mode

  AH Formatter V5 では、下線上線取消線の位置について次のような問題がありました。

  • axf:text-underline-position が指定してあると、axf:vertical-underline-side が効かなくなる。
  • axf:text-underline-position に数値が指定してあると、常にbase-lineからのオフセットとして解釈される。
  • axf:vertical-underline-side によって下線の位置が変更されても、上線の位置は変更されない。
  • CSSで、-ah-line-stacking-strategy:line-height のときに -ah-line-stacking-strategy:max-height のときと異なる位置に下線、上線が引かれていた。
  • 横書きで下線などを引くとき、途中に baseline-shift="super" などがあると、線が不揃いになるが、縦書きでは一直線に揃う。
  • 取消線を引くとき、文字のサイズが異なっていたり baseline-shift="super" などがあると、線が不揃いになる。
  • axf:text-line-width="auto" のときの線の太さはフォントサイズに依存する。ただしCSSでは 行領域の高さに依存する。

  AH Formatter V6.0 では、次のように改良されています。

  • axf:vertical-underline-side は、axf:text-underline-position があっても有効。
  • axf:text-underline-position に指定する数値には、基準となる位置を併記できる。
  • 上線は、常に下線の反対側に位置する。
  • CSSで、-ah-line-stacking-strategy の値によらず同じ位置に引かれる。
  • 横書きで下線などを引くとき、途中に baseline-shift="super" などがあっても一直線に揃う。
  • 取消線を引くとき、文字のサイズが異なっていたり baseline-shift="super" などがあっても一直線に揃う。
  • axf:text-line-width="auto" のときの線の太さは行領域の高さに依存する。

  V5と同様に組ませたいときは、オプション設定ファイルで text-underline-mode="5" と指定してください。

• intrusion-displace-mode

  AH Formatter V6.0 で intrusion-displace の実装が修正されており、AH Formatter V5 と異なります。

  • intrusion-displace="line" または "auto" の場合に text-indent が消えないようになりました。
  • intrusion-displace="indent" の場合に start-indent および end-indent による相対的なインデントが保持されます。AH Formatter V5 では intrusion-displace="indent" を指定しても text-indent が保持されるだけでした。

  V5と同様に組ませたいときは、オプション設定ファイルで intrusion-displace-mode="5" と指定してください。

• vertical-block-width-mode

  横書きの中の縦書きのブロックの幅（あるいは縦書きの中の横書きのブロックの高さ）の auto値の扱いが AH Formatter V6.0 で修正されました。

  AH Formatter V5 では、縦書きブロックの幅は外側のエリアの幅からとられました。AH Formatter V6.0 では、縦書きブロックのautoの幅は内容に合わせて小さくなります。それが望ましくない場合は width="100%" のように幅を明示的に指定してください。縦書きの中の横書きのブロックの高さについても同様です。

  V5と同様に組ませたいときは、オプション設定ファイルで vertical-block-width-mode="5" と指定してください。

• zwsp-mode

  ZERO WIDTH SPACE（U+200B）の動作については、仕様上あいまいな部分があります。AH Formatter V5 では、text-align="justify" に対して、ZERO WIDTH SPACE もその対象となり、その部分が他よりも広くなります。また、ブロックの先頭末尾にある ZERO WIDTH SPACE も例外ではないため、そこも広がります。AH Formatter V6.0 では、これを次のように組ませることができます。

  • ZERO WIDTH SPACE を justify の対象から除外します。
  • ブロック先頭末尾の ZERO WIDTH SPACE を削除します。

  このことにより、<fo:block>&#x200B;</fo:block> のようなブロックでは、１行空けるような効果が現れなくなります。 オプション設定ファイルで zwsp-mode を指定してください。

AH Formatter V5 と XSL Formatter V4 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。

• capitalize

  例えば、

  <fo:block text-transform="capitalize">
  HELLO world!
  </fo:block>
  

  に対して、V4では

  Hello World!

  と変換されていましたが、AH Formatter V5 では

  HELLO World!

  と変換されます。つまり、V4では頭文字以外を小文字に変換していましたが、AH Formatter V5 では何もしません。V4と同様にするには、

  <fo:block text-transform="capitalize-lowercase">
  

  としてください。 ☞ text-transform

• text-justify-mode

  AH Formatter V5 では、行の追い込み処理が改良されました。これに伴い、axf:text-justify-trim によってよりきめ細かな制御が可能となりましたが、XSL Formatter V4 と、1行に入る文字数に違いが生じることがあります。 axf:text-justify-trim を利用していないFOで、V4と同様に組ませたいときは、オプション設定ファイルで text-justify-mode="4" と指定してください。

• baseline-mode

  AH Formatter V5 では、和欧混植のように、ベースラインの異なるフォントを並べたときの処理が改良されています。例えば、

  <fo:block>Latin漢字</fo:block>
  <fo:block>漢字Latin</fo:block>
  <fo:block>Latin</fo:block>
  <fo:block>漢字</fo:block>
  

  というようなとき、Latinに日本語フォントが適用されないように font-family="'Times New Roman', 'MS Mincho'" のように指定するでしょう。このとき、XSL Formatter V4 では、font-family に指定されている最初のフォントによってベースラインを決定してしまうため、行の高さに違いができてしまうことがあります。 AH Formatter V5 では、そのときのスクリプトや言語の指定によって、font-family 中のフォントを選択するので、上記の例では language="jpn" と指定することによって適切なベースラインが適用されます。 V4と同様に組ませたいときに、オプション設定ファイルで baseline-mode="4" と指定してください。

• フォントの選択

  AH Formatter V5 で、font-selection-strategy="character-by-character" がサポートされました。 また、オプション設定ファイルでのauto-fallback-fontで、フォールバックの制御ができるようになりました。 フォントの選択を参照してください。

XSL 1.1 は、XSL 1.0 からいくらか非互換な変更がなされています。

• from-page-master-region()

  XSL 1.1 では、<fo:region-*> に writing-mode や reference-orientation を指定しても、そのままでは無視され、効果がありません。 XSL 1.1 でこれらの指定を有効にするためには、<fo:page-sequence> へ

  writing-mode="from-page-master-region()"
  reference-orientation="from-page-master-region()"
  

  を指定する必要があります。

  FOの修正なしに、XSL 1.0 と同様に評価させるには、オプション設定ファイルで default-from-page-master-region="true" と指定します。

• fo:table

  XSL 1.0 では、fo:table は参照領域を生成することになっています（5.6参照）。しかし、XSL 1.1 では、これが誤りであったとして修正されました。これは、主に、fo:table に指定されている margin-* から start-indent、end-indent への変換で違いが生じます。例えば、

  <fo:block margin-left="10pt">
    <fo:table margin-left="0pt">
    ...
  

  のような表は、XSL 1.0 と XSL 1.1 では左マージンが異なっているかも知れません。 margin-* の代わりに、start-indent などを利用すれば、このような非互換性は発生しません。

  FOの修正なしに、XSL 1.0 と同様に評価させるには、オプション設定ファイルで table-is-reference-area="true" と指定します。

XSLのプロパティでの簡略記法はCSSの定義を引き継いでいるので、その値はCSSのように評価されます。 つまり、

margin="0pt -10pt"

は、ひとつの式ではなく、ふたつの値と評価されます。 しかし、簡略記法でないときは、これはひとつの式として評価されます。 例えば、次はひとつの式です。

margin-left="0pt -10pt"

AH Formatter V7.2 では、簡略記法でのこのようなあいまいな表現に対して、次のように処理します。

• "0pt 10pt" のようにひとつの式になり得ないときはふたつの値
• "0pt -10pt" のように符号と数値がくっついているときはふたつの値
• "0pt - 10pt" のように符号と数値の間に空白が含まれるときはひとつの式
• "0pt-10pt" はエラー（XSL仕様の 5.9.5 Numerics 参照）

FOの簡略記法中で式を使うときに、括弧で囲むなどすることもできます。

CSSでの calc() 関数中では、calc(10pt-5pt) のように書いたとき、- は演算子として評価されます。

XSL/CSS拡張でのプロパティ値（Value）の記法の構文について、一部を簡単に解説します。この記法は、CSS でのそれにのっとっています。詳細は Value Definition Syntax を参照してください。

• 値の組み合わせ
  • 単純に並べられた値は、その順序どおりにすべてが現れなければなりません。
  • && で区切られた値は、任意の順序でそれらすべてが現れなければなりません。
  • || で区切られた値は、任意の順序でそれらのうちどれかひとつ以上が現れなければなりません。
  • | で区切られた値は、それらのうちどれかひとつだけが現れなければなりません。
  • [ ] は、内容をグループ化します。
  • [ ]! は、グループ化された内容の値がひとつ以上現れなければなりません。
• 値の繰り返し
  • * は、0回以上の繰り返しを意味します。
  • + は、1回以上の繰り返しを意味します。
  • ? は、0回または1回の繰り返しを意味します。
  • {N} は、N回の繰り返しを意味します。
  • {N,} は、N回以上の繰り返しを意味します。
  • {N,M} は、N回以上M回以下の繰り返しを意味します。
  • # は、カンマ区切りで1回以上の繰り返しを意味します。

AH Formatter V7.2 は、Unicode 13.0 に対応しています。 新しく追加された文字は、正しく扱えない可能性があります。 また、サポートされていないスクリプトの文字を正しく扱うことはできません（☞ 対応スクリプトと言語）。 BIDI制御文字については、オプション設定ファイルの unicode-bidi-rev を参照してください。

BIDIアルゴリズムの実装上の制限

<fo:block>aaaa <fo:inline property="xxxx">bbbbb</fo:inline> ...</fo:block>
<fo:block>(aaaa<fo:inline property="xxxx">bbbbb</fo:inline> ...)</fo:block>

<p>xxxx<span ref="#yyy" style="content:target-text(attr(ref, url))"></span>zzzz</p>
<p><span id="yyy">ref</span></p>

a::before {
	content: leader(dotted) " " target-counter(attr(ref, url),page);
	unicode-bidi: embed;
	direction: rtl;
}

<toc>حول xxxx <a ref="#yyy"></a></toc>

フォント構築ファイルやオプション設定ファイルなどで、プロパティ値として Unicodeの範囲を表現するときは次の書式で行います。

[ <urange> | <string> ]# | all

<urange> は U+ が先行する16進数で、次のいずれかです。16進数の大文字小文字は区別されません。（Unicode仕様ではコードポイントは4～6桁でなければなりませんが、ここでは表記上4桁未満も許しています。）

• 単一のコードポイント（例えば U+416）
• 範囲を示すコードポイント（例えば U+400-4FF）
• ? が後行する範囲指定（例えば U+4??）

U+4?? は、U+400-4FF と等価です。U+??? は、U+000-FFF と等価です。 有効なUnicodeは、U+10FFFF までです。 それより大きな範囲を指定しても無視されます。

<string> は引用符で囲まれた任意の文字列です。例えば、U+0028-0029 は '()' と書くことができます。

all は、U+0-10FFFF の指定とみなされます。

XSL仕様での <uri-specification> は、url() 内に IRI（RFC3987）仕様を満たす文字列を指定することになっています。 ここでは、便宜上IRIのことをURIと呼びます。

AH Formatter V7.2 で実際に指定できるスキームは、以下のとおりです。

• http:
• https: (証明書に問題のあるサイトにはアクセスできません)
• file:
• data: (RFC2397)
• jar: (JarURLConnection)

スキーム名を含む正しい絶対URIは、url() を利用せずに裸で指定することができます。例えば、

<fo:external-graphic src="url('http://localhost/image.png')"/>

を

<fo:external-graphic src="http://localhost/image.png"/>

と指定することができます。 また、スキーム名を指定せず、相対URIを指定することができます。

<fo:external-graphic src="url('image.png')"/>
<fo:external-graphic src="image.png"/>

AH Formatter V7.2 は、利用者の便宜のために、URIではなく、ローカルなファイルシステム上のファイル名を指定することを許しています。 しかし、一般にURIとローカルファイル名には互換性がありません。例えば、URIに空白は許されませんが、ローカルファイル名に空白を使用できることがあります。 また、%を直接利用できることもあるので、foo%20bar.png という文字列は、URIとして評価する場合とローカルファイル名として評価する場合で異なるリソースを指すことになります。

AH Formatter V7.2 は、この問題を次のように解決します。

• スキームが明示されているときは、それがそのまま採用されます。
• スキームが明示されていず、url() で囲まれているときは次のように処理します。
  1. URIが正しければそれがそのまま採用されます。
  2. URIが正しくなければ、それを %エスケープ処理します。
• スキームが明示されていず、裸で指定されているときは次のようにします。
  1. Windows環境では、\ を / に変換します。
  2. %エスケープ処理します。

相対URIは、base-uri と組み合わされて絶対URIに変換されます。このとき、ローカルファイル名は、すべて fileスキームに変換されます。例えば、Windows環境で base-uri が C:\home\ であるとき、以下のように変換されます。

url() の中に、ローカルなファイル名を直接書くことはできません。例えば、

url('C:\My Document\foobar.png')

のような指定は、期待どおりには動作しないでしょう。ローカルなファイル名は、url() で囲まずに指定してください。

# はフラグメントの区切りとなります。file:///C:/home/foo#bar.png で、実際にアクセスされるリソースは、file:///C:/home/foo です。foo#bar.png というリソースにアクセスしたいときは、url('foo%23bar.png') としてください。

WindowsでのUNC（Universal Naming Convention）、例えば、\\host\My Document\foobar.png は、file://host/My%20Document/foobar.png と変換されます。 また、//host/My Document/foobar.png では、base-uri が http: のときは、http://host/My%20Document/foobar.png のように変換されます（https: も同様）。Windows以外では、file://host/... はサポートされません。

RFC2397 で定義される dataスキームの書式は次です。

"data:" [ mediatype ] [ ";base64" ] "," data

base64を指定するときはセミコロン ; が必要であること、データの区切りはカンマ , であることに注意してください。

JarURLConnection で定義される jarスキームを指定できます。これは、JARまたはZIPに有効で、その中のエントリを指定できます。

jar:http://www.foo.com/bar/baz.jar!/COM/foo/Quux.png

最初の区切り !/ 以降をエントリ指定とみなします。JARまたはZIPの入れ子には対応していません。

非Windows環境では、HTTP または HTTPS へプロキシを経由してアクセスする場合、プロキシアドレスを環境変数で指定する必要があります。

非Windows環境では、ルート証明書が必要な場合、ルート証明書の場所を環境変数で指定する必要があります。

マルチドメイン証明書に対応しています。

表（<fo:table>）には、table-layout="fixed" と table-layout="auto" という属性があります。 前者はカラム幅が決まっている固定レイアウトを指定するものであり、後者はカラム幅を自動的に計算する自動レイアウトの指定です。省略した場合のデフォルトは table-layout="auto" です。 XSL仕様では、自動レイアウトは実装依存となっています。 ここでは、AH Formatter V7.2 の実装について解説します。

自動レイアウトは、カラムの幅計算のために、少なからず時間がかかります。高速な組版を望むのなら、table-layout="fixed" を指定してください。

AH Formatter V7.2 の表の組版処理では、table-layout の指定と、<fo:table> への幅の指定によって、処理方法が異なります。 すべてのカラムの幅が指定してある場合は、table-layout="auto" であっても table-layout="fixed" として扱われます。 また、proportional-column-width() の指定は、XSL仕様では、table-layout="fixed" の場合にのみ指定できることになっています。AH Formatter V7.2 では、proportional-column-width() の指定があるカラムと幅指定のないカラムが混在したとき、幅指定のないカラムには column-width="proportional-column-width(1)" が指定されているとみなし、さらに table-layout="fixed" とみなして処理します。つまり、このようなときは、すべてのカラムに幅の指定があることになります。

table-layout="auto" のとき、幅の指定されていないカラムに対して、その内容を調べます。すべての行に対して調べれば、より好ましいカラム幅を決定できますが、大きな表に対しては時間がかかり過ぎます。 AH Formatter V7.2 は、通常最大 100行分のカラムに対してだけ調べて、カラムの幅を決定します。 この行数は、オプション設定ファイルの table-auto-layout-limit で変更することができます。

table-layout="fixed" のときは、カラムの内容を調べることはないので、常に高速です。

AH Formatter V7.2 は、2種類の行分割処理を行います。ひとつは 1行ずつ行幅に入るところで逐次行を分割していくもの、もうひとつは Knuth-Plass の Breaking Paragraphs into Lines の行分割アルゴリズムに従ったものです（以下BPILと略）。BPILは、主に欧文組版のためのアルゴリズムで、ブロック全体のバランスを考慮して分割位置を決定します。

行分割位置の候補は、UAX#14: Line Breaking Properties の処理によって求められます。UAX#14 の処理では、以下のようにいくらか Unicodeの仕様と異なる処理をしています。

• JIS X 4051:2004 での行頭禁則和字は、axf:line-break で制御することができます。

• UAX#14 の LB30 は、開き括弧類の前、閉じ括弧類の後に関する規則ですが、AH Formatter V7.2 は、全角括弧類に対しては分割を許可するように処理します。 対象となるのは、axf:punctuation-trim に示されている、全角開き括弧、全角閉じ括弧、全角句読点です。

• CJKスクリプト中の行分割クラスAIは、IDとして処理します。 ただし、U+2015（HORIZONTAL BAR）は、JIS X 4051:2004 での分離禁止文字なので、INとして処理します。

• 半角カナ（U+FF61～U+FF9F）の行分割クラスはALです。これは、アルファベットと同じで分かち書きをしないと行分割されません。 半角カナは、全角カナ（U+3001～U+30FF）として行分割処理します。

• UAX#14 では、U+002F (SOLIDUS) 直後の分割が許可されているため、km/h や w/o などの略語でも分割が起こります。このような分割が好ましくないことは、UAX#14 にも明記されています。AH Formatter V7.2 では、axf:abbreviation-character-count によって、略語のような語の分割を制御することができます。

• 全角空白(U+3000)は行頭禁則されます。行頭禁則したくないときは、オプション設定ファイルで non-starter-ideographic-space="false" と指定してください。

• U+200C と U+200D は次のように処理されます。
  1. U+200D の前後では行分割しません。
  2. U+200C の前後では行分割可能と判断します。

BPILは、次のようなブロックに適用されます。

• axf:line-break="bpil" が指定されているブロック
• axf:line-break でアルゴリズムが指定されていず、オプション設定ファイルの bpil で指定された言語であるブロック

ブロックの言語は、xml:lang や language プロパティで明示されているか、オプション設定ファイルの default-lang で指定されているものとなります。 ただし、あらゆる場面にBPILが適用できるわけではありません。以下のような場合は、BPILは適用されず、1行ごとの分割処理が行われます。

• リーダ（<fo:leader> など）が含まれるブロック
• フロートが含まれるブロックや複雑に食い込んでいるブロック（簡単な食い込みのときはBPILが適用されることがあります）
• フォームフィールドが含まれるブロック
• ルビが含まれるブロック
• BIDI処理を要するブロック
• axf:indent-here が含まれるブロック
• <axf:tab> や axf:tab-treatment="preserve" であるタブ文字の含まれるブロック
• wrap-option="no-wrap" などで行分割が制限されていない行でオーバーフローした行の含まれるブロック
• font-sizeが0またはline-heightが0以下のブロック
• 狭い領域（限界幅はオプション設定ファイルのbpil-minimum-line-widthで指定されています）
• 巨大なブロック（限界文字数はオプション設定ファイルのbpil-limit-charsで指定されています）
• 版面のサイズの異なるページマスタに切り替わったブロック

以下のような制限があります。

• <fo:initial-property-set> または ::first-line が含まれるブロックは、2行目以降にBPILが適用されます。
• 3ページ（段）以上に渡るブロックのとき、2ページ（段）目以降にBPILが適用されないことがあります。

引用符は、UAX#14: Line Breaking Properties で文字クラス QU に属する文字です。一般に引用符には開きと閉じの向きがありますが、QU にはその区別がありません。そのため、このままでは行分割に際して望ましくない結果をもたらします。これに対して Unicode は、言語の情報があれば引用符が開きか閉じか判定して、OP または CL として扱うとよい、としています。

AH Formatter V7.2 では以下の文字を引用符として扱います（ここには UAX#14 での QU でない文字も一部含まれています）。ここに示されている QU/OP/CL は、AH Formatter V7.2 がその文字をどの向きで扱うかを示しています（UAX#14 の文字クラスではありません）。

主にヨーロッパの言語によっては引用符の向きが異なっています。例えば、フランス語では «Guillemets» であり、ドイツ語では »Guillemets« となります。AH Formatter V7.2 は、デフォルトで上の設定を用いますが、言語によってこれを次のように補正します。空欄やここにない文字はデフォルトと同じです。

オプション設定ファイルの quotationmark で、引用符の向きを変更することができます。 また、axf:quotetype でも引用符の向きを指定することができます。

CSSの open-quote/close-quote で採用される quotes 中の文字は、これらの設定によらず OPまたはCLに強制されます。

OP は開き括弧と、CL は閉じ括弧と同様に扱われる引用符です。 QU は向きのない引用符です。QU である文字に対して、AH Formatter V7.2 は次のように処理します。

• 文字列頭の QU は、OP とみなす。
• 文字列末の QU は、CL とみなす。
• 文字列中の QU は、直後が空白でなく直前が空白なら OP とみなす。
• 文字列中の QU は、直前が空白でなく直後が空白なら CL とみなす。
• これら以外のとき QU のままとする。

hyphenation-keep="page"（または "column"）を指定したときの、ページ（段）分割時の振る舞いについて、説明しておきます。hyphenation-keep="page" で次のような文章があったとします。

xxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxx
xxxxxxxxxxx abc-
def xxxxxxx ghi-
jkl mnopqr.

最後の行の前でページ分割が起こると、ghi が次のページに追い出されて、

xxxxxxxxxxxxxxxx
xxxxxxxxxxx abc-
def xxxxxxx
---------------- page break
ghijkl mnopqr.

となります。このとき widows="2" が指定されていると、もう1行追い出され、

xxxxxxxxxxxxxxxx
xxxxxxxxxxx abc-
---------------- page break
def xxxxxxx ghi-
jkl mnopqr.

となりますが、さらに hyphenation-keep="page" に違反しています。 このとき、AH Formatter V7.2 は、abc だけを追い出すことができず、1行追い出されてしまいます。

xxxxxxxxxxxxxxxx
---------------- page break
xxxxxxxxxxx abc-
def xxxxxxx ghi-
jkl mnopqr.

前の行がハイフネーションで終わっていれば、次々と行が追い出されます。 hyphenation-ladder-count を併用するとよいでしょう。

少し違うケースで、ghi を追い出したとき、次のように行が増えることがあります。

xxxxxxxxxxxxxxxx
xxxxxxxxxxx xxxx
xxx xxxxxxx
---------------- page break
ghijkl xxxx mno-
pqr.

widows="3" だと、もう1行追い出されます。このとき、次のように行が減ってしまうことがあります。

xxxxxxxxxxxxxxxx
xxxxxxxxxxx xxxx
---------------- page break
xxx xxxxxxx ghi-
jkl xxxx mnopqr.

AH Formatter V7.2 は、この副作用による widows="3" を解消することができません。 これは、制限事項となります。widows="2" ではこのような事態にはなりません。

AH Formatter V7.2 は、Unicode の異体字選択（Variation Sequence）に対応しています。 OpenTypeフォントが異体字選択機能（cmap Format14）を持っている場合は、それを適切に処理します。例えば、次のように異体字を表現できます。

葛󠄀城市
葛󠄁飾区

異体字選択機能を持っていないCIDフォントに適用した場合でも、次のIVD（UTS#37: Ideographic Variation Database）に従ってCIDを選択します。

• /ivd/data/2007-12-14 Combined registration of the Adobe-Japan1 collection and of sequences in that collection

異体字選択機能を持っていないフォントの場合、対応する異体字がない場合、範囲を超えた異体字指定の場合は、&#xE0100;等は無視されます。これは、同じ指定でも、フォントがどの異体字をサポートしているかによって表示される字形が異なるということを意味します。

FOやCSS中でのフォントの指定は、font-familyプロパティで行います。 指定には、font-family="'Courier New', serif" のようにフォントの候補が列挙されている場合や、font-family の指定がない場合など、さまざまな場合があります。 AH Formatter V7.2 は、文字列に対してどのフォントを適用すべきかを次のように決定します。

1. 領域内の文字列を、Unicodeで定義されている文字に対応するスクリプト情報、FOやCSSに指定されている言語やスクリプト情報などによって、同一の性質を持った文字列に分割し、分割された文字列のスクリプトを決定します。 Unicodeには、全角かどうかあいまいとされる文字などが含まれている、文字としての漢字だけでは言語が決定できないなどの理由で、この決定方法は複雑です。

2. オプション設定ファイルで font-selection-mode="6" が指定されているときは、この部分文字列の各文字に対して、FOやCSSで指定されているfont-familyが、そのグリフを持っているか調べ、最初に見つかったグリフを持っているフォントが採用されます。そうでないときは、この部分文字列の各文字に対して、FOやCSSで指定されているfont-familyが、そのグリフを持っており、Unicodeの範囲またはスクリプトをサポートしているかを順に調べます。最初に見つかったサポートしているフォントが採用されます。 font-familyが何も指定されていないときは、標準フォントファミリに指定されているゼネリックフォントファミリが指定されているとみなされます。

XSLやCSSでは、ゼネリックフォントファミリとして、次の5つが利用できます。

• serif
• sans-serif
• cursive
• fantasy
• monospace

AH Formatter V7.2 は、これらに対して実際にはどのフォントを対応させるのかという情報をスクリプトごとに持っています。また、どのスクリプトにも属さないゼネリックフォントも定義できるようになっています。 これらは、グラフィカルユーザインターフェイスの組版オプション設定ダイアログのフォント設定ページでの指定、オプション設定ファイルの<script-font>で指定されているものです。

3. ゼネリックフォントに対しては、対象文字列のスクリプトに対応するスクリプト別ゼネリックフォントが指定されているときは、それがその文字列をサポートしているかどうか調べます。

4. 対応するスクリプト別ゼネリックフォントが指定されていないときは、ゼネリックフォントに対して調べられます。

5. オプション設定ファイルで auto-fallback-font="true" が指定されていて、font-familyに指定されているどのフォントも対象文字列をサポートしていないときは、次のフォールバック処理をします。

   1. 対応するスクリプト別のfallbackに指定されているフォントを調べます。
   2. ゼネリックフォントのfallbackに指定されているフォントを調べます。
   3. それでもどのフォントも対象文字列をサポートしていないときは、次のフォントが順に調べられます。
      • Windows版のとき
        1. Lucida Sans Unicode
        2. Microsoft Sans Serif
        3. IPAGothic
        4. Code2000
        5. MS PGothic
        6. Arial Unicode MS
      • 非Windows版のとき
        1. Helvetica
        2. IPAGothic
        3. Code2000

6. 対象文字列をサポートしているフォントが見つからないときはエラーです。

組版オプション設定ダイアログの指定は、オプション設定ファイルへ反映されます。 例えば、

<script-font script="Hans" serif="SimSun" sans-serif="SimHei" monospace="SimSun"/>

というように書かれています。ここにはcursiveの指定はないので、Hansのcursiveに対しては、ゼネリックフォントのcursiveが採用されます。 もし、インストール直後のように、<script-font script="Hans"/> 自体が指定されていないときは、デフォルトの組が指定されているとみなされます。 Windows版では次のデフォルトの組を設定します。ここに明記されていないスクリプトは何も設定されません。また、実際にそのフォントが存在しないときは設定されません。

Macintosh版では次のデフォルトの組を設定します。

Linux版では次のデフォルトの組を設定します。

日本語や中国語の文書中の文字の向きは、基本的には次の 3通りあります。

横書きのとき	縦書きのとき
	SVO	MVO

縦書きにおける文字の向きを、U または R で表現します。U は紙面に対して正立しています。R は紙面に対して 90°時計回りに回転しています。 すると、ここでの縦書きの文字の向きは次のようになっています。

• 「漢字」などの和字は、U である。
• 括弧は、R である。
• 句点は、縦書き用グリフを用いた上で、U である。
• 「Abc」などの欧字は、SVOでは U であり、MVOでは R である。

縦書き文書で、どの文字を正立させてどの文字を90°回転させるのかは、UAX#50: Unicode Vertical Text Layout で議論されています。現在、ここにはMVO (Mixed Vertical Orientation) に関する記述しかありませんが、以前はSVO (Stacked Vertical Orientation) も含まれていました(tr50-6.html)。 AH Formatter V7.2 では、axf:text-orientation="mixed" はMVOに従い、axf:text-orientation="upright" はSVOに従うように実装されています。 ただし、AH Formatter V7.2 では若干の修正を加えたものを利用しています（☞ tr50-x.Orientation.txt）。このデータは、オプション設定ファイルで一部を任意に変更することができます。UAX50を参照してください。

通常縦書きに対応しているフォントは、一部の文字に対して縦書き用のグリフを持っています。それは、横書き用のグリフを単純に回転させただけでは縦書きに適用できないものがあるためです。小書きのかなや句読点、長音などです。 縦書きでは、縦書き用グリフがある文字に対しては、それを用いることになります。

文字をどちら向きに表示するか（U および R）は、横書き用グリフの向きに対してどちら向きか、という決め方をしています。しかし、縦書き用グリフには、横書き用グリフとは向きの異なるものが存在しています。次の例は、U+3083、U+FF08 と U+2190 の例です。U+FF08 と U+2190 では向きが異なっています。

横書き用のグリフ	縦書き用のグリフ

先に、「括弧は、R である」と書いていますが、実際には、縦書き用グリフを用いて U として表示しなければなりません。つまり、縦書き用グリフが横書き用とは異なる向きにデザインされているという暗黙の仮定がここにあります。 現実には、フォントが縦書き用グリフを持っているかどうか、その向きが横書き用グリフと同じかどうかは、フォントによって異なっています。特に、矢印などの記号類の向きにおいてフォントによる差異が顕著です。グリフがどちら向きにデザインされているかを知るのは不可能なので、この問題を一般的に解決することはできません。したがって、AH Formatter V7.2 では、代表的な実装に合わせて文字の向きを制御しています。

例えば、<fo:page-number-citation> のない単純なFOを組版してPDFを出力する場合、AH Formatter V7.2 は、組版済みのページを捨てながらPDFを出力するので、どんなに大きな文書でも１ページ分以上のメモリを消費せずに処理することができます（GUIを除く）。 しかし、<fo:page-number-citation> によって、後方のページを参照するようなページでは、その参照しているページが何ページになるのか、そのページまで組版してみなければわかりません。そのため、未解決の <fo:page-number-citation> を含むページが現れると、AH Formatter V7.2 は、組版途中の結果をメモリ上に蓄えたまま出力を保留します。 先頭の方に目次があるような文書では、目次に現れるページ番号がすべて解決するまで出力が行われないことになります。これは、メモリを大量に消費するため、組版できるページ数に限界が生じ、大規模な文書の組版が不可能なことを意味します。

この問題を解決するために、AH Formatter V7.2 は、文書を2パスで組版することができるようになっています。 最初のパスでは、<fo:page-number-citation> の解決だけを目的に組版が行われ、必要なすべてのページ番号情報を収集します。次のパスで再び先頭から組版を始めます。このとき、<fo:page-number-citation> はすべて解決しているので、組版済みのページを捨てながら出力することができます。 組版に要する時間は増えますが、組版に要するメモリはほとんど消費されず、大規模な文書の組版が可能となります。ただし、出力に要するメモリ消費には効果がありません。

2パス組版を行うには、次のような方法があります。

• コマンドラインインターフェイスで、-2pass を指定する。
• .NETインターフェイスで、TwoPassFormatting=true を指定する。
• COMインターフェイスで、TwoPassFormatting=true を指定する。
• Javaインターフェイスで、setTwoPassFormatting(true) を指定する。
• C/C++インターフェイスで、setTwoPassFormatting(true) を指定する。
• オプション設定ファイルで、<formatter-settings two-pass-formatting="true"> を指定する。

AH Formatter V7.2 は、不可避な場合を除いて作業用の一時ファイルを作りません。 AH Formatter V7.2 が作業用の一時ファイルを作るのは以下の場合です。

• COMインターフェイスで、ウェブブラウザへPDFを直接出力するとき、組版結果のPDFを一時ファイルへ保存します。

• COMインターフェイスで、DOMを使って渡されたXMLドキュメントは、一時ファイルを使って処理されます。ただし、組版種別にFOが指定されたときは、直接DOMを処理するので一時ファイルは生成されません。

• 印刷で、ファイル出力を行うときに、一時ファイルを生成します。

• 外部XSLTを使うときなどのXSLT変換で、ファイルインターフェイスが必要な場合、一時ファイルを生成します。

• Javaインターフェイスのrenderメソッドで、XML+XSLからの変換が必要なとき、その結果FOを一時ファイルとして生成します。

• Windows版で、PDFに埋め込めない画像を埋め込もうとしたとき、その変換処理では、一時ファイルを生成します。

• Distiller、Ghostscriptを使ってEPSをPDFへ変換するとき、一時ファイルを生成します。

• Distillerを使ってEPSを処理するとき、joboptionsが指定されていないとデフォルトのjoboptionsを一時ファイルとして生成します。

• XPS出力時に一時ファイルが生成されます。

• Windows版のGUIでは、Windowsによって適宜一時ファイルが生成されます。