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の適用順序は、CSS2仕様で次のように規定されています。
AH Formatter V6.6 では、それぞれ次に対応します。
html.css です。 HTML用デフォルトCSS を参照してください。
オプション設定ファイルの <usercss> で指定されるもの、コマンドラインの -css や -s で指定されるものです。 (.NETやJavaなどのインターフェイスでは、対応するコマンドラインオプションと同等です。) これらは、次の順序で適用されます。
GUIではオプション設定ファイルのみが適用されます。 組版オプション設定ダイアログのCSSページで設定されるものは、オプション設定ファイルに反映されます。
HTML中の <link> や <style> で指定されたもの、XML中の <?xml-stylesheet ..?> の処理命令で指定されたものです。 これらは、次の順序で適用されます。
HTML用デフォルトCSSは、(X)HTMLを組版するときに、最初のスタイルシート(user agent declarations)として利用されます。これは、環境変数 AHF66_DEFAULT_HTML_CSS または AHF66_64_DEFAULT_HTML_CSS で示される場所にある html.css です。 (html.css が存在しないときは、すべての要素が inline であるとして組版されます。)
このスタイルシートは、ウェブブラウザの表示や、CSSで規定されているスタイルなどを元に作成されています。しかし、環境によってはうまく表示できない指定があるかも知れません。また、好みの違いもあるでしょう。 デフォルトCSSは、利用者が自身の環境などに合わせて、最適に調整しておくことが望まれます。 いくつか例を示します。
デフォルトCSSで次のように指定されています。
q::before { content: open-quote } q::after { content: close-quote }
AH Formatter V6.6 では、quotes の初期値は "\201C" "\201D" "\2018" "\2019" です。 次のような指定がお好みかも知れません。
q:lang(en) { quotes: '"' '"' "'" "'" } q:lang(no) { quotes: "«" "»" '"' '"' }
脚注番号は、左ページ余白にはみ出すように指定されています。はみ出さないようにしたいときは、@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; }
リストのマーカに使われる記号は、オプション設定ファイルの list-style-type で指定されています。その字形はフォントに依存するので、フォントが異なれば異なるマーカが表示されるでしょう。::marker には、特定のフォント指定がないので、利用されるフォントはそのときの文脈に依存します。必要ならば ::marker に特定のフォントを指定しておくのがよいでしょう。
組版種別を自動として組版を開始したときは、おおよそ、次のような手順で種別を決定します。
HTMLのときは、文書がXMLである必要はありませんが、HTML以外は、文書が整形式のXMLであることが要求されます。
AH Formatter V6.6 と AH Formatter V6.5 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。
HTML用デフォルトCSS(html.css)の記述に変更があります。
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 を指定してください。
次の文字を挿入することで、リガチャが抑制されるようになりました。
デフォルトで、STIXバージョン2.0 のフォントがインストールされているときはそれが採用されるようになりました。
OpenType に MATHテーブルがあれば、それを参照するようになりました。オプション設定ファイルの enableOpenTypeMATH、exceptOpenTypeMATHVariants で細かく制御できます。
<mlongdiv> の線の太さが、mslinethickness の太さで描かれるようになりました。
行分割が起こったときの各行の高さが、それぞれの高さとなるようになりました。 AH Formatter V6.5 までのように各行の高さが同一になるようにするには、オプション設定ファイルで、linebreakingHeightAdjust="false" を指定してください。
AH Formatter V6.4 と AH Formatter V6.3 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。
オプション設定ファイルの MathML に関する設定で、添え字の配置に関する初期値が若干修正されました。 AH Formatter V6.3 の設定にするためには、mathmlSettingsMode="6.3" を指定してください。
AH Formatter V6.3 と AH Formatter V6.2 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。
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 と同じ名前であっても、定義済みカウンタスタイルの実装には若干の相違があります。以前の list-style-type のスタイルを採用したいときは、axf:number-transform="lower-roman" ではなくて axf:number-transform="'lower-roman'" のように指定してください。
AH Formatter V6.2 と AH Formatter V6.1 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。
オプション設定ファイルの、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側のフロートの幅が領域いっぱいで、テキストの回りこむ余地がないとき、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" を指定してください。
AH Formatter V6.1 までは、BIDI 処理に問題があったことがわかっています。AH Formatter V6.2 では BIDI 処理が修正されました。そのため、V6.1 までと組版結果が異なることがあります。
AH Formatter V6.1 と AH Formatter V6.0 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。
AH Formatter V6.1 では、入力されたテキストに対して Unicode の正規化処理(UAX#15: Unicode Normalization Forms)が行われるようになりました。 axf:normalize を参照してください。 正規化処理は、組版速度に多少影響します。 デフォルトでの正規化処理を行わないようにするには、オプション設定ファイルで normalize="none" を指定してください。
AH Formatter V6.1 では、font-familyにファミリ名を指定したとき、font-stretch="condensed" などを考慮して、実際にcondensedフォントがある場合にそれを選択させることができるようになりました。 オプション設定ファイルで font-stretch-mode="6" を指定してください。 font-stretch-mode="5" と "6" の動作の違いは以下のとおりです。
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-Condended"> のように指定する必要があります。
<fo:block font-family="Foo" font-stretch="condensed"> とした場合、Foo-Regular.otf を圧縮して表示します。そのときの圧縮率は、OpenTypeの仕様に示されている値よりも若干小さく(伸張のときは大きく)なります。
フォント選択に、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フォントを圧縮するわけではありません。regularフォントの圧縮が行われます。
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 V5 で改良されましたが、縦書き時に欧文の文字(英数字)を正立させたときに中心が揃わない問題が残っていました。この問題は AH Formatter V6.1 で解決されました。 V5と同様に組ませたいときに、オプション設定ファイルで baseline-mode="5" と指定してください。
単位 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 が指定されているテキストでは、axf:punctuation-trim や axf:text-autospace などの指定が無効でした。AH Formatter V6.1 では、この制限が解除されています。
AH Formatter V6.1 では、全角空白(U+3000)の扱いが若干変更されました。
AH Formatter V6.0 と AH Formatter V5 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。
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"が指定された場合は、その block-containerの段組に対してスパンが指定されたものとなります。組版結果を V5と同様にするには、親の fo:block-contianerで span="all"を指定するようにしてください。
文書先頭での空のブロックとspan="all"のブロックの間の強制改ページの指定は、V5では無視されていましたが、AH Formatter V6.0 では強制改ページが有効となり、空白ページが生じます。組版結果を V5と同様にするには、次のようにしてください。
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"を指定しないようにしてください。
AH Formatter V5 では、下線上線取消線の位置について次のような問題がありました。
AH Formatter V6.0 では、次のように改良されています。
V5と同様に組ませたいときは、オプション設定ファイルで text-underline-mode="5" と指定してください。
AH Formatter V6.0 で intrusion-displace の実装が修正されており、AH Formatter V5 と異なります。
V5と同様に組ませたいときは、オプション設定ファイルで intrusion-displace-mode="5" と指定してください。
横書きの中の縦書きのブロックの幅(あるいは縦書きの中の横書きのブロックの高さ)の auto 値の扱いが AH Formatter V6.0 で修正されました。
AH Formatter V5 では、縦書きブロックの幅は外側のエリアの幅からとられました。AH Formatter V6.0 では、縦書きブロックのautoの幅は内容に合わせて小さくなります。それが望ましくない場合は width="100%" のように幅を明示的に指定してください。縦書きの中の横書きのブロックの高さについても同様です。
V5と同様に組ませたいときは、オプション設定ファイルで vertical-block-width-mode="5" と指定してください。
ZERO WIDTH SPACE(U+200B)の動作については、仕様上あいまいな部分があります。AH Formatter V5 では、text-align="justify" に対して、ZERO WIDTH SPACE もその対象となり、その部分が他よりも広くなります。また、ブロックの先頭末尾にある ZERO WIDTH SPACE も例外ではないため、そこも広がります。AH Formatter V6.0 では、これを次のように組ませることができます。
このことにより、<fo:block>​</fo:block> のようなブロックでは、1行空けるような効果が現れなくなります。 オプション設定ファイルで zwsp-mode を指定してください。
AH Formatter V5 と XSL Formatter V4 とで、組版上の相違がいくらかあります。ここでは、それらを列挙します。
例えば、
<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
AH Formatter V5 で otf-metrics-mode の初期値が "windows" から "typographic" へ変更されました。 フォントによって、ベースラインが若干変化することがあります。特に、モリサワフォントで違いが出るでしょう。
AH Formatter V5 では、行の追い込み処理が改良されました。これに伴い、axf:text-justify-trim によってよりきめ細かな制御が可能となりましたが、XSL Formatter V4 と、1行に入る文字数に違いが生じることがあります。 axf:text-justify-trim を利用していないFOで、V4と同様に組ませたいときは、オプション設定ファイルで text-justify-mode="4" と指定してください。
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 からいくらか非互換な変更がなされています。
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" と指定します。
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 V6.6 では、簡略記法でのこのようなあいまいな表現に対して、次のように処理します。
FOの簡略記法中で式を使うときに、括弧で囲むなどすることもできます。
CSSでの calc() 関数中では、calc(10pt-5pt) のように書いたとき、- は演算子として評価されます。
XSL/CSS拡張でのプロパティ値(Value)の記法の構文について、一部を簡単に解説します。この記法は、CSS でのそれにのっとっています。詳細は Value Definition Syntax を参照してください。
AH Formatter V6.6 は、Unicode 7.0 に対応しています。 新しく追加された文字は、正しく扱えない可能性があります。 また、サポートされていないスクリプトの文字を正しく扱うことはできません(☞ 対応スクリプトと言語)。 以下の文字には対応していません。
U+2066 は U+202D と、U+2067 は U+202E と、U+2069 は U+202C とそれぞれみなされます。
フォント構築ファイルやオプション設定ファイルなどで、プロパティ値として 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 の指定とみなされます。
XSL仕様での <uri-specification> は、url() 内に IRI(RFC3987)仕様を満たす文字列を指定することになっています。 ここでは、便宜上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.png | file:///C:/dir/foobar.png |
url('foobar.png') | file:///C:/dir/foobar.png |
url('url(foobar.png)') | file:///C:/dir/url(foobar.png) |
subdir\foobar.png | file:///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.png | file:///C:/dir/foo%20bar.png |
url('foo bar.png') | file:///C:/dir/foo%20bar.png |
foo%20bar.png | file:///C:/dir/foo%2520bar.png |
url('foo%20bar.png') | file:///C:/dir/foo%20bar.png |
foo%%20bar.png | file:///C:/dir/foo%25%2520bar.png |
url('foo%%20bar.png') | file:///C:/dir/foo%25%2520bar.png |
foo#bar.png | file:///C:/dir/foo#bar.png |
url('foo#bar.png') | file:///C:/dir/foo#bar.png |
foo%23bar.png | file:///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での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/... はサポートされません。
☞ | 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-layout | fo: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 とは異なる処理をしています。
JIS X 4051:2004 での行頭禁則和字は、axf:line-break で制御することができます。
UAX#14 の LB30 は、開き括弧類の前、閉じ括弧類の後に関する規則ですが、AH Formatter V6.6 は、全角括弧類に対しては分割を許可するように処理します。 対象となるのは、axf:punctuation-trim に示されている、全角開き括弧、全角閉じ括弧、全角句読点です。
CJKスクリプト中の行分割クラスAIは、IDとして処理します。 ただし、U+2015(HORIZONTAL BAR)は、JIS X 4051:2004 での分離禁止文字なので、INとして処理します。
半角カナ(U+FF61~U+FF9F)の行分割クラスはALです。これは、アルファベットと同じで分かち書きをしないと行分割されません。 半角カナは、全角カナ(U+3001~U+30FF)として行分割処理します。
全角空白(U+3000)は行頭禁則されます。これは、Unicode 6.3 での仕様変更を受けてのことです。行頭禁則したくないときは、オプション設定ファイルで non-starter-ideographic-space="false" と指定してください。
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)を持っている場合は、それを適切に処理します。例えば、次のように異体字を表現できます。
葛󠄀城市 | ![]() |
葛󠄁飾区 | ![]() |
異体字選択機能を持っていないCIDフォントに適用した場合でも、次のIVD(UTS#37: Ideographic Variation Database)に従ってCIDを選択します。
異体字選択機能を持っていないフォントの場合、対応する異体字がない場合、範囲を超えた異体字指定の場合は、󠄀等は無視されます。これは、同じ指定でも、フォントがどの異体字をサポートしているかによって表示される字形が異なるということを意味します。
注意: | Ideographic 以外の Variation Sequence には対応していません。 |
---|
FOやCSS中でのフォントの指定は、font-familyプロパティで行います。 指定には、font-family="'Courier New', serif" のようにフォントの候補が列挙されている場合や、font-family の指定がない場合など、さまざまな場合があります。 AH Formatter V6.6 は、文字列に対してどのフォントを適用すべきかを次のように決定します。
領域内の文字列を、Unicodeで定義されている文字に対応するスクリプト情報、FOやCSSに指定されている言語やスクリプト情報などによって、同一の性質を持った文字列に分割し、分割された文字列のスクリプトを決定します。 Unicodeには、全角かどうかあいまいとされる文字などが含まれている、文字としての漢字だけでは言語が決定できないなどの理由で、この決定方法は複雑です。
オプション設定ファイルで font-selection-mode="6" が指定されているときは、 この部分文字列の各文字に対して、FOやCSSで指定されているfont-familyが、そのグリフを持っているか調べ、最初に見つかったグリフを持っているフォントが採用されます。 そうでないときは、 この部分文字列の各文字に対して、FOやCSSで指定されているfont-familyが、そのグリフを持っており、Unicodeの範囲またはスクリプトをサポートしているかを順に調べます。最初に見つかったサポートしているフォントが採用されます。 font-familyが何も指定されていないときは、標準フォントファミリに指定されているゼネリックフォントファミリが指定されているとみなされます。
XSLやCSSでは、ゼネリックフォントファミリとして、次の5つが利用できます。
AH Formatter V6.6 は、これらに対して実際にはどのフォントを対応させるのかという情報をスクリプトごとに持っています。また、どのスクリプトにも属さない標準ゼネリックフォントも定義できるようになっています。 これらは、グラフィカルユーザインターフェイスの組版オプション設定ダイアログのフォント設定ページでの指定、オプション設定ファイルの<script-font>で指定されているものです。
ゼネリックフォントに対しては、対象文字列のスクリプトに対応するスクリプト別ゼネリックフォントが指定されているときは、それがその文字列をサポートしているかどうか調べます。
対応するスクリプト別ゼネリックフォントが指定されていないときは、標準ゼネリックフォントに対して調べられます。
オプション設定ファイルで auto-fallback-font="true" が指定されていて、font-familyに指定されているどのフォントも対象文字列をサポートしていないときは、次のフォールバック処理をします。
対象文字列をサポートしているフォントが見つからないときはエラーです。
組版オプション設定ダイアログの指定は、オプション設定ファイルへ反映されます。 例えば、
<script-font script="Hans" serif="SimSun" sans-serif="SimHei" monospace="SimSun"/>
というように書かれています。ここにはcursiveの指定はないので、Hansのcursiveに対しては、標準ゼネリックフォントのcursiveが採用されます。 もし、インストール直後のように、<script-font script="Hans"/> 自体が指定されていないときは、デフォルトの組が指定されているとみなされます。 Windows版では次のデフォルトの組を設定します。ここに明記されていないスクリプトは何も設定されません。また、実際にそのフォントが存在しないときは設定されません。
Script | serif | sans-serif | cursive | fantasy | monospace |
---|---|---|---|---|---|
標準 | 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版では次のデフォルトの組を設定します。
Script | serif | sans-serif | cursive | fantasy | monospace |
---|---|---|---|---|---|
標準 | 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版では次のデフォルトの組を設定します。
Script | serif | sans-serif | cursive | fantasy | monospace |
---|---|---|---|---|---|
標準 | Times | Helvetica | Times | Times | Courier |
日本語や中国語の文書中の文字の向きは、基本的には次の 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 が作業用の一時ファイルを作るのは以下の場合です。
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によって適宜一時ファイルが生成されます。