技術的資料

HTMLの組版

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

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

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

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

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

注意: AH Formatter V6.6 は、印刷用に組版するので、GUIの画面であっても @media screen は適用されません。

CSSの適用順序

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

  1. user agent declarations
  2. user normal declarations
  3. author normal declarations
  4. author important declarations
  5. user important declarations

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

HTML用デフォルトCSS

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

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

組版種別の判定

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

  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 V6.5 との組版上の相違

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

AH Formatter V6.3 との組版上の相違

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

AH Formatter V6.2 との組版上の相違

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

AH Formatter V6.1 との組版上の相違

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

AH Formatter V6.0 との組版上の相違

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

AH Formatter V5 との組版上の相違

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

XSL Formatter V4 との組版上の相違

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

XSL 1.0 と XSL 1.1 の非互換性

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

簡略記法

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

margin="0pt -10pt"

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

margin-left="0pt -10pt"

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

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

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

プロパティ値の構文

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

Unicode

AH Formatter V6.6 は、Unicode 7.0 に対応しています。 新しく追加された文字は、正しく扱えない可能性があります。 また、サポートされていないスクリプトの文字を正しく扱うことはできません( 対応スクリプトと言語)。 以下の文字には対応していません。

U+2066 は U+202D と、U+2067 は U+202E と、U+2069 は U+202C とそれぞれみなされます。

Unicode範囲

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

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

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

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

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

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

URI

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

注意: XSL仕様では、url()中の文字列を引用符で囲む必要がないことになっています。しかし、文字列に括弧が含まれている場合など、url( に対応する ) を正確に認識するのが難しいことがあります。 url() 中の文字列は引用符で囲むことを強く勧めます。

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

url() を利用せずに裸の文字列を指定した場合も、他の値のどれにもマッチしないときは、URIが指定されたとみなされます。例えば、

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

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

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

foobar.pngfile:///C:/dir/foobar.png
url('foobar.png')file:///C:/dir/foobar.png
url('url(foobar.png)')file:///C:/dir/url(foobar.png)
subdir\foobar.pngfile:///C:/dir/subdir/foobar.png
url('subdir\foobar.png')file:///C:/dir/subdir%5Cfoobar.png
url('subdir/foobar.png')file:///C:/dir/subdir/foobar.png
foo bar.pngfile:///C:/dir/foo%20bar.png
url('foo bar.png')file:///C:/dir/foo%20bar.png
foo%20bar.pngfile:///C:/dir/foo%2520bar.png
url('foo%20bar.png')file:///C:/dir/foo%20bar.png
foo%%20bar.pngfile:///C:/dir/foo%25%2520bar.png
url('foo%%20bar.png')file:///C:/dir/foo%25%2520bar.png
foo#bar.pngfile:///C:/dir/foo#bar.png
url('foo#bar.png')file:///C:/dir/foo#bar.png
foo%23bar.pngfile:///C:/dir/foo%2523bar.png
url('foo%23bar.png')file:///C:/dir/foo%23bar.png

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

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

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

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

WindowsでのUNCUniversal 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/... はサポートされません。

dataスキームと jarスキームに関しては、グラフィクスを参照してください。

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

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

マルチドメイン証明書に対応しています。ただし、Solaris版は非対応です。 V6.6

表の自動レイアウト

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

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

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

table-layoutfo:tableの幅処理方法
fixedあり 幅の指定されていないカラムに対しては、幅が等分されて割り振られます。 内容がその幅を超える場合はオーバーフローします。
なし 表の幅は 100%となります。 幅の指定されていないカラムに対しては、幅が等分されて割り振られます。 内容がその幅を超える場合はオーバーフローします。
autoあり 幅の指定されていないカラムに対しては、カラムの内容を勘案して幅が割り振られます。 カラムの最小幅を採用しても指定されている表の幅を超えるときは、表の幅がその幅に拡大されます。
なし 幅の指定されていないカラムに対しては、カラムの内容を勘案して幅が割り振られます。 カラムの最大幅を採用しても 100%に満たないときは、それが表の幅となります。 カラムの最小幅を採用しても 100%を超えるときは、それが表の幅となります。 それ以外のときは、表の幅は 100%となります。

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

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

注意: fo:retrieve-table-marker で内容が生成されたテーブルセルのカラム幅は、自動的に計算されません。

行分割

AH Formatter V6.6 は、UAX#14: Line Breaking Properties に従って行分割処理をします。 その際、いくつか UAX#14 とは異なる処理をしています。

ハイフネーション

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 V6.6 は、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 V6.6 は、この副作用による widows="3" を解消することができません。 これは、制限事項となります。widows="2" ではこのような事態にはなりません。

異体字選択

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

葛&#xE0100;城市葛城市
葛&#xE0101;飾区葛飾区

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

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

注意: Ideographic 以外の Variation Sequence には対応していません。

フォントの選択

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

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

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

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

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

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

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

  3. オプション設定ファイル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

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

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

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

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

Scriptserifsans-serifcursivefantasymonospace
標準 Times New Roman Arial Segeo Script または
Comic Sans MS または
Monotype Corsiva
Impact Courier New
Jpan MS 明朝 MS ゴシック MS 明朝 または
MS ゴシック
MS 明朝 または
MS ゴシック
MS ゴシック または
MS 明朝
Hans SimSun または
MS Song
SimHei または
MS Hei または
MS Song
SimSun または
MS Song
SimSun または
MS Song
SimHei または
MS Hei または
MS Song
Hant MingLiU
Hang Batang または
BatangChe
Gulim または
BatangChe
Batang または
BatangChe
Batang または
BatangChe
BatangChe
Ethi Nyala
Arab Arabic Typesetting
Syrc Estrangelo Edessa
Hebr FrankRuehl
Deva Mangal
Beng Vrinda
Guru Raavi
Gujr Shruti
Taml Latha
Telu Gautami
Knda Tunga
Mlym Kartika
Sinh Iskoola Pota
Thai Angsana New
Khmr DaunPenh
Laoo DokChampa
Mymr Myanmar Text

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

Scriptserifsans-serifcursivefantasymonospace
標準 Times または
Times New Roman
Helvetica または
Arial
Monaco または
Chalkboard
Monaco または
Chalkboard
Courier
Jpan ヒラギノ明朝 Pro W3 ヒラギノ角ゴ Pro W3 ヒラギノ丸ゴ Pro W4 または
ヒラギノ角ゴ Pro W3
ヒラギノ丸ゴ Pro W4 または
ヒラギノ角ゴ Pro W3
ヒラギノ角ゴ Pro W3
Hans STXihei STSong STXihei STXihei STSong
Hant LiHeiPro LiSongPro LiHeiPro LiHeiPro LiSongPro
Hang AppleMyungjo AppleGothic AppleMyungjo AppleMyungjo AppleGothic
Arab Geeza Pro
Hebr NewPeninimMT
Deva DevanagariMT
Thai Thonburi

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

Scriptserifsans-serifcursivefantasymonospace
標準 TimesHelveticaTimesTimesCourier

縦書きでの文字の正立

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

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

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

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

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

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

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

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

大規模文書の組版

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

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

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

注意: CSS組版では、2パス組版を行うことはできません。
注意: グラフィカルユーザインターフェイスでは、2パス組版を行うことはできません。

一時ファイル

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