XSL Formatter V2 Q&A

名前か値を入力した後に、下矢印キーを押すことで２行目以降の入力域が表示されます。

エラーメッセージを画面に出したくないときは次のようにしてください。

1. メニューバーから [組版] を選び、[組版オプション] をクリックします。
2. [組版オプション]ダイアログボックスから [ファイル出力・自動続行] タブを選びます。
3. [ログ出力・自動続行] チェックボックスをチェックします。
4. [OK] ボタンをクリックします。

V2.2から自動組版開始が行えます。
「ファイル」メニューの「ドキュメント／スタイルシート登録」で、常に使用するスタイルシートなどを登録しておくことで、その都度同じスタイルシートを指定する必要がなくなります。
このダイアログの自動組版チェックボックスをＯＮにすることで、ドキュメントを指定すると自動的に組版を開始します。よってディスクトップにあるXSL Fromatterアイコンにドキュメントファイルをドラック＆ドロップすることで、自動的に組版を開始することができます。

XSL Formatter V2.3から前回保存したフォルダを選択するように改良致しました。

XSL Formatter V2.4から、XMLとXSLの各「外部エディタ」を別々のエディタを指定できるようになりました。

この問題につきましては XSL Formatter V2.5 改訂３版 にて修正されました。

はい。XSL Formatter は、組版エンジン部（AXFO.dll）に、コマンドラインの引数からファイル名を渡すこと等のできるコマンドライン版のインターフェイス・プログラムを用意してあります。

option.ini ファイルはPDFを出力するのに必ずしも必要な条件ではありません。
iniファイルを指定しなかった場合は、XSL Formatter は組版オプションは規定値で組版を行います。

e.g. AXFOCMD
 -d "c:\My Documents\xml\sample.xml"
 -s "c:\My Documents\xml\sample.xsl"
 -p "Acrobat PDFWriter"
 -o "c:\My Documents\xml\sample.pdf" 

もしoption.iniファイルを指定したいのでしたら、組版する前に指定してください。サンプルはここから入手できます。

「-param パラメータ名=パラメータ値」というコマンドラインオプションを使用して指定します。 値が空白を含む場合は、「"パラメータ名=パラメータ値"」のように、ダブルクォーテーションで囲む必要があります。 以下の３パターンを処理可能です。

    -param name=value
    -param "name"=value
    -param name="value"

ダブルまたはシングルクォーテーション内なら '='(イコール)も使えます。 文字列としてのダブルクォーテーションは 「""」、文字列としてのシングルクォーテーションは「''」とします。

コマンドラインユーティリティ（AXFOCMD.exe）でPDFオプションを使用したいときは、プリンタ名に大文字で@PDFを指定してください。

AXFOCMD -p "@PDF" -d document.fo -o document.pdf

はい、区別します。したがって、ファイル名やプリンタ名は大文字／小文字を区別して指定してください。

ASPアプリケーション上でCOMインターフェイスを使用する場合のみ、PDFをブラウザにストリーム出力することができます。

1. IPrinterNameプロパティに"@PDF"を指定する。
2. OutputFilePathプロパティを指定しない。
3. Executeメソッドを呼び出した後、Response.Endを実行する。

なお現状では一時ファイルを経由して出力します。ご了承ください。

V2.2からPDF出力オプションを使用することによって「セキュリティ設定」が可能になりました。詳しくはオンラインマニュアルをご覧ください。

PDFフォームは、サポートしておりません。

JavaScriptの埋め込みは、サポートしておりません。

はい、同じページ番号になります。

同じ画像を繰り返し使用するような特殊なケースで、PDF出力オプションの圧縮設定に「自動」が指定されていると、時間がかかるケースがあります。 その場合はPDF出力オプションの圧縮設定に使用する画像に合わせて「JPEG」か「ZLIB」を指定することで時間を短縮することができます。次の方法に従って変更してみてください。

1. XSL Formatterのメニューから「ツール」から「PDFオプション」を選択する。
2. 「PDFオプション」ダイアログの「圧縮」タグを選択して、「圧縮」項目を「自動」から「JPEG」か「ZLIB」に変更してOKを押す。

PDFオプションがラスタグラフィックをPDFに出力する場合、JPEGとZLIBの圧縮をサポートします。そして「自動」の場合、サイズの小さい方を自動的に選択します。よって、この圧縮方法を固定（JPEGかZLIB）に固定することによって、処理時間の短縮を行うことができます。

PDF出力オプションの画像処理は、元のデータをそのまま、PDFに出力するということをしていません。 一旦、BMP、または WMF/EMF 形式にした画像データから、指定された圧縮方式・画質に従って、再度、JPEG画像または ZLIB圧縮のBMP画像に変換しています。 このため、サイズが小さくなったり、大きくなったりするケースが発生します。

「移動先(Destination)」機能をサポートしていません。ご了承ください。
「XSL Formatter V2.2 ではできたが、V2.3ではできない」との情報がありますが、V2.2、V2.3ともサポートしていません。これを実現するためには「アンテナハウス XSL 拡張仕様」プロパティが必要ですが、実装されていません。

XSL Formatter V2.5 から「アンテナハウス XSL 拡張仕様」を使用することによって可能になりました。詳しくは「オンラインマニュアル」をご覧ください。

XSL Formatter はC++にて設計されています。FOPはJavaにて設計されています。この違いから使用するメモリ量が違ってくるのではないかと思われます。

これは、PDF 出力オプションの「圧縮設定」が「自動」になっている場合に見受けられます。 原因は、「圧縮オプション」が「自動」の場合、「JPEG」ファイルと「ZLIB」ファイルの両方のイメージを作成してサイズの小さい方を選択するよう処理しているためです。つまり画像を２回作成しているので結果、処理が遅くなってしまいます。

回避する方法ですが、PDF 出力オプションの「圧縮設定」を「JPEG」か「ZLIB」に指定すれば、画像作成は１回になりますので、速度が改善されます。また、使用しているイメージが写真のような画像なら「JPEG」、ビジネスグラフィックスのようなものなら「ZLIB」を指定していただければ、より早くなると思われます。

1. XSL Formatter自体で処理が可能で、PDFにそのまま格納できる形式の画像は、 元のファイルをそのままPDFに挿入します。したがって、速度が速くなっています。
2. XSL Formatter自体で処理が可能で、PDFにそのまま格納できない形式の画像は、 形式変換をしてPDFに挿入します。 この場合、V2と同様に処理速度は、解像度設定／圧縮設定に依存します。
3. Windows環境では、Formatter自体で処理が不可能な形式の画像は、 Windowsの機能かLeadToolsの機能によってBMPに変換します。 この場合、V2と同様に処理速度は、解像度設定／圧縮設定に依存します。

PDF出力オプションにてPDFファイルを作成した場合、次の条件によってファイルサイズが大きくなることが分かっています。

1. 組版したドキュメントに、同一イメージが繰り返し使用されている場合、PDF出力オプションは全てのイメージを「異なったイメージ」として埋め込むため、作成されたPDFファイルが大きくなってしまいます。
2. 組版したドキュメントにLinkがあると、PDFファイルのサイズが大きくなります。 Linkが使用される場合、fo:block に id プロパティが付加されます。の PDF output potion は、id プロパティが付加された block 単位で、PDF内のstreamを分割してしまっているため、圧縮効率の低下を招き、結果サイズが大きくなってしまっています。

この２つの問題は XSL Formatter V2.5 にて修正されました。
ただし、 word-spacing,letter-spacing,justify プロパティで、文字間調整を行っているデータでは、大きくなる場合があることが判明しています。

なお、XSL Formatter V3 ではこの問題は発生しません。

使用されているWindowsシステムの「フォント」フォルダに、0 Byteのフォントファイルが存在すると、このエラーが発生することが分かっています。この問題はXSL Formatter V2.4以前のバージョンを使用すると発生します。この問題については XSL Formatter V2.4改訂１版にて修正されました。

これはPDF出力オプションの不具合です。 fo:basic-link external-destination が使用されていて、そのリンク先アドレスの末尾が ')' となっている場合に、不正なPDFを出力していました。 この問題はV2.5にて修正されました。

PDF ファイルは用紙サイズをmmでは無く、point で格納しています。1pointは 1/72inchです。

• PDFオプションの場合

  次のように mm から point への変換を行い、PDFに「595 × 841」pointのサイズが格納されます。

  210 × 72 / 25.4 = 595
  297 × 72 / 25.4 = 841
  

  そして、この PDF を Acrobat で表示する際には逆に point から mm への変換が行われます。

  595 / 72 × 25.4 = 209.9
  841 / 72 × 25.4 = 296.69
  

  したがって、用紙サイズは 209.9 × 296.69 と表示されます。

• Acrobat Distillerの場合

  Acrobat Distillerの場合はもう少し複雑になります。 出力先がプリンタドライバ（ Acrobat Distiller ）の場合、XSL Formatter から プリンタドライバ（ Acrobat Distiller ）へは「210 × 297」という値ではなく「A4」という情報が渡ります。
  A4 のサイズは「210.2241 × 297.3018」なので、この値で mm から point への変換を行い、PDF に「595 × 842」point のサイズが格納されます。

  210.224 × 72 / 25.4 = 595
  297.3018 × 72 / 25.4 = 842
  

  そして、表示する際は逆に point から mm への変換が行われますので

  595 / 72 × 25.4 = 209.9
  842 / 72 × 25.4 = 297.04
  

  となり、結果用紙サイズは 209.9 × 297.04 と表示されます。

XSL Formatter V2、及び PDF 出力オプションは CMYK をサポートしていません。よって残念ながら PDF 出力オプション、または Acrobat Distiller を使って PDF/X 仕様（ISO15930）の PDF ファイルを作ることはできません。しかしながら CMYK に関しては他のアプリケーションを使って前もって CMYK に変換することは可能です。

PDF/X 仕様については、今後検討していきます。

これはXSL Formatter V2の制限です。
XSL Formatter V2 が JPEG を処理するとき、画面に表示されるイメージにて処理されます。そのために、クライアントPCの画面設定とサーバPCの画面設定が異なると、このような現象が発生します。
それぞれのPCの「画面のプロパティ」の「設定」項目の「色」を同じ設定にしてください。

PDFオプションでPDFを作成したときに、fo:tableのセル間にわずかな隙間が発生する場合があります。
弊社にてサンプルデータで検証したときには 0.01mm の隙間が発生しました。 background-color などの指定がある場合は、PDFを拡大すると細い線があるように見えることがあります。
この問題につきましては XSL Formatter V2.5 改訂３版 にて修正されました。

XSL FormatterのPDF出力オプションで作成したPDFが使用するカラースペースは DeviceRGB を使用したものになります。

PDFオプションにて作成されるPDFファイルは、テキスト／ラインアートデータは常に圧縮の設定になっております。 この設定を変更することはできません。
画像データは圧縮方法をZLIB/JPEG/自動（「自動」は小さくなる方を自動選択）を選択することが可能です。

Acrobat 5.0 では、bold の文字が表示されない場合があります。Acrobat 5.0.5 またはそれ以降のバージョンでは表示されます。Acrobat をアップデートして下さい。

XSL Formatter とFOPでの「しおり」（ブックマーク）の作成方法は次の点が異なります。

1. 「しおり」作成方法の違い。

   XSL Formatterでは、

   <fo:flow flow-name="xsl-region-body">
       ...
       <fo:block axf:outline-level="1">Section 1</fo:block>
       ...
   </fo:flow>

   と書くことで、文書本文中に「Section 1」と書き込むと同時にしおりを作成することができます。

   FOPでは、

   <fo:root>
       <fox:outline internal-destination="sec1">
           <fox:label>What is FOP?</fox:label>
       </fox:outline>
   ...

   と書き、さらに

   <fo:flow flow-name="xsl-region-body">
       ...
       <fo:block id="sec1" >A   What is FOP?</fo:block>
       ...
   </fo:flow>

   と書かなければなりません。

2. ツリー構造の表現方法の違い。

   例えば「しおり」に下記のような文書構造を表現するとします。

   Section 1
     Section 1-1
      Section 1-1-1
      Section 1-1-2

   XSL Formatterの場合、

   <fo:block axf:outline-level="1">Section 1</fo:block>
   <fo:block axf:outline-level="2">Section 1-1</fo:block>
   <fo:block axf:outline-level="3">Section 1-1-1</fo:block>
   <fo:block axf:outline-level="3">Section 1-1-2</fo:block>

   このように outline-lebel 属性を使って明示的に構造を記述することができます。

   FOPの場合、

   <fox:outline internal-destination="sec1">
     <fox:label>Section 1</fox:label>
     <fox:outline internal-destination="sec1-1">
       <fox:label>Section 1-1</fox:label>
       <fox:outline internal-destination="sec1-1-1">
         <fox:label>Section 1-1-1</fox:label>
       </fox:outline>
       <fox:outline internal-destination="sec1-1-2">
         <fox:label>Section 1-1-2</fox:label>
       </fox:outline>
     </fox:outline>
   </fox:outline>

   このように、文書のツリー構造を、そのままの構造で表現する必要があります。

このように、XSL Formatterのしおり機能はFOPに比べて非常に簡単に使用することができ、また直感的に扱えますので作成だけでなく、修正等時にも効率の良い機能になっています。

なお、XSL Formatterでの「しおり」作成はオンラインマニュアルに記述しておりますので、そちらも併せてご覧ください。

V2.3からPDFMarkという機能(機能一般名称）を Postscript に埋め込むことが可能になりました。
Postscript Printer Driverで、Postscriptを出力するとき、PDFMarkを使って、しおり（ブックマーク）とリンクの機能を設定することができます。これによって、Distillerで作成したPDFにしおりとリンクを設定することが可能です。

Acrobat(Readerを含む）はタイ語を「しおり」として表示することができません。よって文字が点として表示されてしまいます。これはAcrobat(readerを含む）が、「しおり」のタイ語の表示はサポートしていないためです。「しおり」の文字はタイ語を使用しないようにしてください。

できません。

これはXSL Formatterv2.3までの不具合でした。 ネストされた block に axf:outline-level="2" がある場合、axf:outline-level が無視されてしまいます。

<fo:block axf:outline-level="1" axf:outline-title="Level1" >
     Level1
     <fo:block axf:outline-level="2" axf:outline-title="Level2" >
          Level2
          <fo:block axf:outline-level="3" axf:outline-title="Level3" >
               Level3
          </fo:block>
     </fo:block>
</fo:block>

上記のFOの例では、axf:outline-level="2" axf:outline-title="Level2"や、axf:outline-level="3" axf:outline-title="Level3" のしおりが作成できませんでした。
この問題は XSL Formatter V2.4 にて修正されました。

この問題は用紙方向が「landscape」（横方向）のときに発生します。
PSプリンタドライバによっては、用紙方向が「portrait」（縦方向）から「landscape」（横方向）に変化したときに、座標変換に問題があり、結果リンクスポットが正しい位置に配置されないためです。
この場合は、PSプリンタドライバを最新にしてみてください。

この問題は XSL Formatter V2.5 改訂２版で修正されました。

PDFの自動分割とリンクやしおりのクロス参照は実現できません。今後、拡張機能にて実装できるか検討中です。

fo:page-number や fo:marker 等の動的な内容をしおりに出力することはできません。これは XSL Formatter の制限です。

FOを確認したところ、

external-destination="url("www.antennahouse.com")"

と指定されていました。 絶対パスにてURIを指定したい場合は必ず、

external-destination="url("http://www.antennahouse.com")"

として、'http://'を記述してください。これがないと相対パス指定と見なされて正常に動作しません。（ちなみにV2.2で正しく動作するように見えたのは偶然です。）

この問題はAcrobat Distillerの不具合と思われます。（ちなみに、Acrobat Distillerを使用してPSファイルを作成して、これをAcrobat DistillerにてPDF化すると問題ありません）
XSL Formatter V2.3改訂１版以降でこの問題を回避することができます。

Acrobat Distillerの仕様で、タイトル名は127文字までとなります。
XSL Formatter は Acrobat Distillerを使用した場合、タイトル名は100文字を上限とします。これより文字数が長い場合は100文字目以降を省略して " ..." を付加します。

Acrobat Distillerは文字方向から、自動的に用紙方向を変更する処理があります。よって回転している文字数によって用紙方向が自動的に変わってしまいます。

これを回避する方法は２つあります。

1. もし、組版した結果の用紙方向が全て同一であるならばAcrobat Distillerの「ジョブオプション」ダイアログの「一般」タグ内にある、「ページの自動回転」項目を「ファイルごと一括」に指定してください。
2. もし、用紙方向が混在（用紙方向を縦、横両方使用）している場合は、「ページの自動回転」項目は「ページごと」に指定しなければなりませんが、Acrobat Distillerは、用紙の方向を「回転している文字数の割合」で決定している傾向がありますので、用紙方向に合った文字数を多く配置すれば回避できると思われます。

ただし、この方法はアンテナハウスにて調査した結果からの推測ですので、イメージなどが混在した場合は、これに適合しない場合があります。ご了承ください。

罫線が不ぞろいな太さになる理由はPDFが、Acrobat Distiller で作られたものだからです。この場合、Windows GDI を通して出力しています。線の太さは、出力解像度によります。0.1pt と小さな値を指定したとしても、もし解像度が72dpiであれば、最低の線の太さは 1pt という太さになってしまいます。さらに、隣接するピクセルにまたがるような位置にある線は2ピクセル分の太さになってしまう可能性もあります。

解決方法としてはPDF出力オプションを使用するか、もしくは Acrobat Distiller を使うならば、解像度の設定を高くすれば改善できます。
（出力するときの [Acrobat Distiller ドキュメントのプロパティ] ダイアログの [用紙/品質] タブで、[詳細設定...] ボタンをクリックして、[印刷品質] が 72dpi のような低い値になっていたら、それを 600dpi かそれ以上に変える。）

コマンドラインインターフェイスだけに限らず、COMインターフェースを使用して、プリンタ名に「Acrobat Distiller」を指定してもPDFファイルは作成されません。
XSL Formatterは出力先が「Acrobat Distiller」であることを判別することはできず、通常のプリンタと同じように組版結果を出力します。
そして「出力ファイル」パラメータに指定されたファイル名は印刷ダイアログの「ファイルへ出力」を選択したときのファイル名になります。
「Acrobat Distiller」はPostScriputプリンタドライバですから、結果指定した出力先にPSファイルが作成されます。

コマンドラインのインターフェイス・プログラムがありますので、これをお使いいただければ可能です。詳しくはオンラインヘルプをご覧ください。

プリンタの設定を記録したデータファイルを作成して、これを XSL Fomatter に指定すれば、プリンタ設定をそれに従って初期化することができます。
Windows では一般にプリンタに関する設定情報をやり取りする場合、 DEVMODE という構造体を使用します。プリンタドライバはこのDEVMODE構造体の情報に基づいて動作します。DEVMODE 構造体を作成してファイルに保存するアプリケーションとして、XSL Formatter では、AXFODEV.exe を添付しています。詳しくはオンラインマニュアルの「プリンタの設定を記録したデータファイルの作成方法」をご覧ください。

プリンタ名に空白がある場合は、

-p "EPSON LP-LP8700"

と、プリンタ名を""（ダブルクォーテーション）で囲んでください。
また、XMLやXSL、出力先のPDFファイル名なども、パス内に空白がある場合も併せて""（ダブルクォーテーション）で囲んでください。

XSL Formatter には Postscript を出力する機能はありませんが、Windows の Postscript プリンタドライバをインストールして使えば、Postsriptに出力することができます。

しおりやリンクはPDFファイルを作成したときのみ、サポートします。XSL Formatterから、PostscriptプリンタドライバによってPostscriptファイルを作成した場合、しおりやリンクが正常に配置できない場合があります。
しおりやリンク機能を使用したPostscriptを作成する場合は、使用する Postscript プリンタドライバに Acrobat Distiller を指定してください。

残念ながらこれはできません。

スペース類がどう出力されるかはフォントに依存しています。Arial フォントに、U+2003 (Em Space) は含まれていません。したがって、□が出力されます。このようなスペース文字には、ほかに次のものがあります。

• U+2000 (EN QUAD)
• U+2001 (EM QUAD)
• U+2002 (EN SPACE)
• U+2003 (EM SPACE)
• U+2004 (THREE-PER-EM SPACE)
• U+2005 (FOUR-PER-EM SPACE)
• U+2006 (SIX-PER-EM SPACE)
• U+2007 (FIGURE SPACE)
• U+2008 (PUNCTUATION SPACE)
• U+2009 (THIN SPACE)
• U+200A (HAIR SPACE)

Windows の標準的なフォントでこれらが含まれるのは、Tahoma、Lucida Sans Unicode、Arial Unicode MS などに限られています。 例えば、font-family="Tahoma" とすればこれらのスペースが正しく出力されます。
U+200B のZero-width space については、XSL Formatter が出力時にテキストから削除します。

"Mincho" というフォントは存在しませんので、XSL Formatter はシステムから "Lucida Sans Unicode"、"Arial Unicode MS"、"Tahoma, Microsoft SansSerif" をのいずれかを検索して、最初にヒットしたフォントを代替フォントとして使用します（このフォントを検索している理由はUnicodeであり、なおかつフォント文字数が多いので代替えにしやすいためです）。

代替として "LucidaSansUnicode" が使用された場合、本来この "LucidaSansUnicode" には日本語文字（グリフ）が存在していませんので、日本語文字を使用することができません。よって、PDFに出力した場合も、この存在しない日本語文字を埋め込むことができず、その結果、漢字の表示が空白になってしまう場合があります。

しかし、XSL Formatter 自体の表示で日本語の漢字が表示されるのは、XSL Formatter がシステム（Windows）に表示命令を出すと、Windows内部で、自動的に MS PGothic などの文字にてこれを代用して、表示させるためです。

よって、XSL Formatter の画面表示では正常に表示されるにもかかわらず、PDFに出力すると漢字部分が空白になってしまうという現象が発生します。 回避方法は以下の通りです。

1. font-family 属性には実際にシステムに存在するフォントを指定する。
2. font-family 属性に "serif"等を指定して、XSL Formatter の「組版オプション」「言語別指定・日本語処理」にて指定したフォントを使用する。

可能です。

font-family="Arial , MS 明朝"

としてください。font-familyに指定したフォントは、はじめのほうが優先されます。先にMS明朝があると、MS明朝で欧文も出るので､Arialは使われなくなります。Arialが先にあれば欧文はArialで、日本語はArialではだめなのでMS明朝で､ということになります。

XSL Formatter はシステムに存在するフォントを使用します。XSL Formatter 自体はフォントを持っていません。

Plantin ATM フォントはType1フォントになります。
XSL Formatter V2.3 PDF出力オプション以前では、ドキュメント側にて Type1 フォントを指定した場合に XSL Formatter のGUIとPDFファイルにて、表示が異なる場合があります。これはPDF出力オプションがType1フォントをサポートしていないため、フォントの埋め込みができないからでした。
V2.4 から Type1 フォントをサポートしました。動作確認済みのtype1フォントにつきましては、オンラインマニュアルをご覧ください。
なお、Acrobat PDF Distiller を使用しても、問題なくPDFが作成できます。

Acrobat(readerを含む）は上記のコードをしおりに指定することができません。よって文字が化けることがありますので、これらの文字は使用しないようにしてください。

これは、Unicode Line Breaking Properties 仕様 http://www.unicode.org/unicode/reports/tr14/ による行分割の仕様によるものです。
例えば「2002/11/22:Fry4」のような文字列が行末の改行位置にかかった場合、コロンでの後ろで分割して残りは次行に配置されます。

.........2002/11/22:
Fry4

Unicode Line Breaking Properties 仕様では次のように記述されています。

IS - Numeric Separator (Infix) (XB)

Characters that usually occur inside a numerical expression may not be
separated from following numeric characters, unless space character
intervenes. Since they are otherwise sentence ending punctuation, they
prevent breaks before.

There is no break in “100.00” or “10,000”, nor in “12:59”

002C  COMMA
002E  FULL STOP
003A  COLON
003B  SEMICOLON
0589  ARMENIAN FULL STOP

つまり、コロン（003A COLON）のあとが数字であれば分割禁止ですが、数字以外の場合は分割（改行）が許可されます。
もし、分割させないようにするには、次のようにU+2060をコロンの後に追加します。

2002/11/22:⁠Fry4

U+2060( = WORD JOINER) については、Unicode 3.2 仕様 http://www.unicode.org/unicode/reports/tr28/ を参照してください。

指定しているフォントタイプや、フォントサイズによっては単語の間のスペースがなくなってしまったように見える場合があります。まずは表示の「ズームイン」機能を使用して、拡大表示して確認してみてください。そしてフォントタイプや、フォントサイズを調整してください。

この問題はXSL Formatter V2.4までの不具合でした。 例えば

 font-family="ＭＳ 明朝, SimSun"

のように言語が違うフォントが並んでいるとき、たとえ日本語フォントで表示できる文字であっても、テキストが中国語と判定されれば中国語のフォントのほうが選択されるようになっています。

 font-family="ＭＳ 明朝,serif"

のような場合でも, 組版オプションの言語別の設定で serif に中国語のフォントの定義があれば、上記と同じ状況になります。
language="en"を指定のとき、なぜ中国語のフォントになるかといえば、スクリプトが漢字と判定されて、どこの言語の漢字かは不明なときは中国語が優先されてしまうためです。
XSL Formatter V2.5では、このような状況のときはXSL Formatterの動作しているシステム（OS）のロケールにて判断するように修正されました。

font-family に指定するフォント名はフォント名に完全に一致していなければなりません。
例えば "Times New Roman" の 'Times' と 'New' の間の空白は必ずなければなりませんし、空白の数は１つでなければなりません。
まずは、フォント名を再度ご確認ください。
なお、フォント名を間違えることなく指定するには、ワードパッドなどの「フォント選択ボックス」でフォント名を表示させて、このフォント名をコピーしてくるのが良いでしょう。

指定したフォントにグリフが存在しない場合、このような問題が発生します。
XSL Formatter の GUI は、Windows の機能を使用して組版結果を表示しています。このとき、指定されたフォントにグリフがない場合でも Windows が自動的にフォントの入れ替えを行っているため、問題なく表示されます。
しかし、Acrobat Reader は、Windows の機能を使用していないため、このようなフォントの入れ替えを行いません。したがって、指定されたフォントにグリフが存在しない場合は、XSL Formatter の GUI では表示されますが、Acrobat Reader ではエラーが発生します。
もう一度、指定したフォントを確認して使用している文字のグリフがそのフォントに存在するか確認してください。

はい、 TrueType フォントを PDF ファイルに埋め込むことは可能です。 （ただし、埋め込みが制限されているフォントは除きます）

• XSL Formatter PDF オプションの場合は、「PDF オプション」ダイアログで、「フォント」タブ内の「埋め込み可能なフォントを全て埋め込む」チェックボックスをONにしてください。
• Adobe Acrobat Distiller の場合は、メニューの「設定」から「ジョブオプション」を選択し、「フォント」タブ内の「全てのフォントを埋め込む」チェックボックスをONにしてください。

また、埋め込むフォントを個別に指定することも可能です。

スペースの幅は指定されたフォントから算出していますので、フォントが同一であれば変化することはありません。しかしフォントのグリフに存在する空白部分が影響してスペースの幅が異なっているように見える場合があります。このような場合は、XSL Formatter GUI にてボーダーを表示させて確認してください。

これは、XSL Formatter V2.4 PDF出力オプションの不具合です。 ボールド、またはイタリック書体を使用した文で、単語間の空白幅が正しく、再現されない場合があります。 この問題については、XSL Formatter V2.5 PDF出力オプションにて修正されました。

これは特殊なケースです。 この２つのフォントはType1フォントで、フォントの情報は下記のようになっています。

'Avenir-Heavy' Font
avenh___.pfm
    dfWeight=400(0x190)
    WindowsName='Avenir'
    mPostScriptName='Avenir-Heavy'

'Avenir-Roman' Font
avenr___.pfm
    dfWeight=400(0x190)
    WindowsName='Avenir'
    mPostScriptName='Avenir-Roman'

上記の情報から、Windowsではどちらのフォントも表示名は Avenir になります。（MS-Wordでも２つのフォントが見えないのは、これが原因です）

通常、Windowsはフォントをフォント名（WindowsName）か、dfWeight値（Bold とか Italic）で区別します。 しかし、この２つのフォントは WindowsName と dfWeight 値が同じなので、区別ができません。
そして、XSL Formatterはフォントの選択をWindows GDIを使用しているため、MS-Wordと同様、２つのフォントを区別できず、１つのフォントしかPDFに組み込むことができないのです。
この２つのフォントがWindowsシステムにインストールされているとき、PDFファイルには Avenir-Roman フォントが 組み込まれます。もし、Avenir-Heavyフォントを使用したければ、WindowsシステムからAvenir-Romanのフォントを削除してください。Avenir-HeavyフォントがPDFファイルに組み込まれます。

外字を使用するには、外字が格納されているフォントを指定して、使用したい外字の文字コードを記述します。
XMLとXSLでは次のように記述すれば外字をXSL-FOに埋め込むことができます。

XML側

    .
    .
    .
<FONT FACE="Font name of external character">
 &amp;#x260E;
</FONT>
    .
    .
    .

XSL側

    .
    .
    .
<xsl:template match="FONT">
 <fo:block font-family="{@FACE}">
  <xsl:value-of disable-output-escaping="yes" select="." />
 </fo:block>
</xsl:template>
    .
    .
    .

これはV2.4までの問題でした。現象はプロポーショナルフォントを使用したときに発生します。したがって使用するフォントをプロポーショナルフォントではないフォントを指定すれば、回避することができます。
XSL Formatter V2.5 でこの問題が解消されました。

XSL Formatter V2 では、Zapfdingbats や Symbol の Type1シンボリックフォントは Unicodeのコードポイントで指定された場合、GUIに表示されません。 GUIに表示するには、Unicodeではなく The PostScript encoding で指定してください。
The PostScript encoding はフォントに付属するテキスト（Zapfdingbats.txt）で確認することができます。下記のように指定してください。

<fo:block font-size="12pt" font-family="ZapfDingbats">
    &#xE4;
</fo:block>

XSL Formater では、InternetExplolre5.0以降と、Adobeのホームページから配布されているSVGビューアをインストールすれば、その機能を使って表示・印刷することができます。

XSL Formatter は XML ファイルが存在するパスを基準（ベース）パスとします。よってパスがない場合や相対パスで画像ファイルを指定した場合、XML ファイルの存在するパスを基準パスとして画像ファイルを検索します。
ご質問の状況の場合ですと、画像ファイルのパスを絶対パスで指定するか、XML ファイルが存在するフォルダに画像ファイルを保存しておく必要があります。

XSL Formatter V2.5 は XSL Formatter V2.0に比べて大幅にグラフィック機能を強化致しました。
XSL Formatter V2.5にてサポートするグラフィックの種類や注意事項などはこちらをご覧ください。

GIFを使用する場合はUNISYSとのライセンス契約が必要となります。
スタンドアロンでお使いの場合は、アンテナハウスはUNISYSとライセンス契約を結んでいますので、弊社からライセンス提供ができます。
インターネットサーバ、ウェブサーバ等にて XSL Formatter を使用してGIFをお使いになるのでしたら、UNISYSと直接ライセンス規約を結ぶ必要があります。

PDF 出力オプションを使用した場合、ベクタ画像をベクタ画像のままPDFに挿入することはできません。

Distiller または PDF Writer を使用した場合、SVG以外のベクタ画像をベクタ画像のまま、PDFに入れることができます。

PDF 出力オプションの場合

• ベクタ画像をラスタ画像にしたときの「圧縮」方法を変更することができます。XSL Formatter ツールメニューの「PDFオプション」で、設定することができます。これを調整して画像の品質を調整してみてください。詳しくはオンラインマニュアルをご覧ください。
• EPS画像の場合、プレビュー・イメージが埋め込まれますが、プレビューイメージがない場合はダミーイメージがPDFに埋め込まれます。

Acrobat Distiller または Acrobat PDF Writer の場合

• Distiller または PDF Writer を使用した場合、SVG以外のベクタ画像をベクタ画像のまま、PDFに入れることができます。
• SVGの場合、次の方法で画質を向上させることができます。
  1. 印刷ダイアログでAcrobat Distillerを選んだら「プロパテイ」をクリックして「Acrobat Distiller のドキュメントのプロパテイ」ダイアログを出す。
  2. 「Adobe PDF 設定」タブで､ジョブオプションがCJKScreen または Screenとなっているのを Printか Press に変更する。
     なにがどう変わるかは「ジョブオプションの変更」をクリックして「圧縮」タブを見ればわかります。ScreenやCJKScreenでは画像が72dpiという低い解像度にダウンサンプリングされます。PDFWriterの場合も、プロパテイの設定で画像のダウンサンプリングの設定を変えられます。
• EPS画像の場合、Windows2000/XPでAcrobatDistillerを使ったときのみベクタ画像になります。それ以外は、プレビューイメージがない場合はダミーイメージがPDFに埋め込まれます。

XSL Formatter V3 は、SVGイメージに限りベクターイメージとしてとしてPDFに組み込みます。したがって、劣化は発生しません。 SVG以外のイメージに付いては現在検討中です。

XSL Formatter は CGM の表示と印刷をサポートしています。 XSLFormater は、COREL(TM)のActiveCGM plug-inをインストールすれば、その機能を使って表示・印刷することができます(一部表示できないCGMファイルが存在しますが、これらはplug-inソフトの機能に依存します）。

PDFに埋め込まれるJPEGの画質を調整することができます。XSL Formatter ツールメニューの「PDFオプション」「圧縮」タグの「JEPG画質」を設定して画像の品質を調整してみてください。詳しくはオンラインマニュアルをご覧ください。

いいえ、サポートしておりません。 PDF出力オプションにてPDFを作成した場合、CMYKのイメージはRGBに変換されてPDFに埋め込まれます。
この件につきましては、今後、検討していきたいと思っております。

残念ながらできません。弊社は将来のバージョンでこれをサポートできるかどうか調査しています。

V2.3から、InternetExplolre6以降と、Design Science社 が提供している MathPlayer plug-inをインストールすれば、その機能を使って表示・印刷することができるようになりました。

Windows2000/XPの環境に限り、Postscriptプリンタを使用することで、EPSの中のPostscriptコードを印刷したり、Postscriptファイルに挿入することが可能です。 AcrobatDistillerのプリンタドライバはPostscriptプリンタと見なされますので、Acrobat Distiller を使用して作成したPDFには、EPSのPostscriptコードから作成した画像が埋め込まれます。しかし、これ以外の場合はEPSのプレビュー・イメージを使用して印刷、PDFへの画像埋め込みを行います。

V2.3から、EPS内のプレビューイメージが存在しない場合でも、ダミーイメージを使用してエラーが発生しないようになり、ダミーイメージも元のEPSサイズを再現するようになりました。印刷もプリンタが非Postscriptプリンタの場合はダミーイメージが印刷されます。
なおPDF出力オプションにてPDFを作成したときもダミーイメージを使用します。

V2.2から、表示されるように改訂致しました。 ただし、XSL Formatter を「サーバ」で使用している場合、指定されたファイルを一旦ローカル環境のテンポラリフォルダにダウンロードして、これを使用します。よって権限等によってダウンロードできなかった場合は表示されません。

プレビューイメージが入っていないEPSの場合、表示はダミーイメージが表示されます。 印刷は 印刷先が「Acrobat Distiller」か「postscriptプリンタ」の場合は、EPS内のPSコードを出力しますので、印刷、PDFファイルに画像を挿入することができます。

buffy.fo(13,249Byte)を添付されてきたデータのうちで最も小さい 下記データを使用するようにして、変換してみました。

画像 ReallySmall.gif 4,039Byte
圧縮方式 ：自動で(JPEG圧縮になります)

   V2.2: 15,112 Byte

   V2.3: 14,837 Byte

   ちなみに、DistillerのCJKScreen 設定では 13,394 Byte

このデータで見てみるとPDF内で 画像は 4,588Byte (元より少々大きくはなっていますが、法外という感じではないかと)テキストが 3,001Byte です。そして残り部分の主なところがなにかというと 文字幅のデータです。デフォルトの組版では Times New Roman を使用しますが、この文書では、Regular、Bold、Italic、BoldItalicの4書体を使用しています。
それぞれの書体で文字幅が違いますので、PDF内で 文字幅データを4種類もつことになります。foをちょっといじって、Regularだけにすると、10,652Byteになります。4KByteほど減っていますが、これが、3書体分の文字幅関連のデータになります。
だいたい 上記のような内訳です。テキスト部分の出力方法は 少しずつ削っていくというようなことはできるかもしれませんが、当面この文書についてはあまり削る余地はないように思います。

SVGをドキュメントに埋め込むには２つの方法があります。
一つは他のイメージファイルと同じ、'external-graphic'を使用して、外部参照することです。
もう一つは'instream-foreign-object'を使用して、直接SVGのコードをドキュメントに記述することができます。

.
.
.
<fo:instream-foreign-object content-width="215.9mm" content-height="279.4mm" >
<svg xmlns="http://www.w3.org/2000/svg">
.
（SVGのコード）
.
</svg>
</fo:instream-foreign-object>
.
.
.

このとき、必ず最初の要素は、svg または <abc:svg xmlns:abc="http://www.w3.org/2000/svg">（abcは任意の名前空間接頭辞）としてください。

SVGをドキュメントに埋め込んだ場合、SVGのサイズは 'instream-foreign-object'または'external-graphic'のcontent-width／content-heightプロパティ、これがなかったときはsvgタグのwidth／heightプロパティに指定されている絶対値となります。
このプロパティがない、または無効だとSVGの大きさはline-area（普通は font-size）と同じ高さになってしまいます。
次のようにcontent-width／content-height、またはsvgタグのwidth／heightプロパティに絶対値を指定してください。

.
.
.
<fo:instream-foreign-object content-width="215.9mm" content-height="279.4mm" >
<svg xmlns="http://www.w3.org/2000/svg">
.
（SVGのコード）
.
</svg>
</fo:instream-foreign-object>
.
.
.

残念ながら、XSL Formatteはそのような機能を持っていません。 また、対応策はありません。この問題については改良を検討中です。

XSL Formatter V2.4 以降および XSL Formatter V3 はベクタイメージがラスタイメージに変換される時の解像度の値を指定することが可能です。また、XSL Formatter V3.1 では SVG、EMF、WMF は、ラスタイメージに変換されることなくPDF内に描画されます。詳細はオンラインマニュアルを参照してください。

日本でのLZWに関する特許は、２００４年６月２０日をもって特許権が失効しました。 従いまして、GIFをご利用する際のLZWライセンスは必要ありません。 LZWライセンスの制約解除は、XSL Formatter V3.1 改訂３版からとなります。

ファイルのパスを確認してください。

1. 相対パスにて指定してある場合、XSL FormatterはXMLドキュメントが存在するパスを基準としてファイルを検索します。したがって、XMLドキュメントとXSLスタイルシートが別のパスに存在する場合は、注意する必要があります。
2. 絶対パスを指定していても、参照先がファイルサーバやHTTPなどのURLで指定されている場合は、ファイル名の大文字／小文字を確認してください。ＷＷＷサーバやファイルサーバがUNIX系の場合、大文字／小文字が違うと、別のファイルと見なされ、ファイルがないことになります。
3. 指定されている画像がPlug-inを必要としていないかを確認してください。XSL Formatterは一部の画像について、Plug-inを必要とします。 こちらで、画像タイプをご確認ください。

XSL Formatterでは、透過指定のある画像では、透過部分に反映されるのは background-color のみとなります。background-image は反映（透過）されません。これは、XSL Formatter V2 の制限です。

XSL Fromatter V3.1では、GIF/PNGの透過処理に対応しました。

MathMLに限らず直接 XSL-FO に記述できるイメージタイプがいくつかあります。 直接記述する際は、イメージデータを記述する前に、fo:instream-foreign-object メソッドを使用する必要があります。
次にMathMLの例を示します。

<fo:block>
  <fo:instream-foreign-object content-type="application/mathml+xml">
    <m:math xmlns:m="http://www.w3.org/1998/Math/MathML">
      .
      . (MathML データ)
      .
    </m:math>
  </fo:instream-foreign-object>
</fo:block>

SVGZ のイメージの場合、オリジナルの画像表示サイズが正しく取得できない場合があります。SVGZ を埋め込む場合は content-width ／ content-height を使用して、明示的に画像表示サイズを指定してください。

XSL Formatter V2.4改訂１版までの XSL Formatter では、同一のイメージであっても、使用されるイメージを毎回、PDF に組み込んでいました。このため、ファイルサイズが大きくなっていましたが、XSL Formatter V2.5から、このような場合にイメージの PDFへの組み込みが１回となるように修正を行いました。これにより、出力される PDFファイルのサイズが小さくなりました。

はい、GUIに表示されるEPS画像は、プレビューイメージであり、これが仕様になります。また PDF 出力オプションの場合もプレビューイメージが PDF に埋め込まれます。
Adobe Acrobat Distiller を使用すれば EPS画像は PSコードで PDF に出力されます。（ただし、これはWindows2000/XPでのみ有効です）

Raster Imaging Proライブラリは開発ライセンスに同梱されていません。したがって、評価版で対応しています「TIFF」の表示・印刷は不可能になります。
これはLead Technologiesからのライセンスが開発用として、画像処理ソフトウェア / モジュールを再配布することが禁止されているためです。

XSL Formatter V3 は baseline-TIFF に限り XSL Formatter自体のライブラリで処理しますのでSDKでも表示できます。baseline-TIFF以外のTIFFも今後対応していく予定です。

BMPの表示には、Raster Imaging Proライブラリは必要ありません。
現状では､BMP, JPEG, GIF, WMF, EMF, SVG, CGM, MathML は、RasterImagingProを使っていません。TIFF, PNG, CMYKカラーのJPEGは、RasterImagingProを使っています。
なお、ファイルの種別判別でも、content-typeや、拡張子が正しく指定されていない場合、RasterImagingProが必要になる場合があります。

XSL FormatterはCGMを出力するためにActiveCGM plug-inを必要とします。 ActiveCGMは、2byteの文字がパスに存在した場合、イメージを表示しません。 これは、XSL Formatter の制限です。
外部CGMイメージのパスに2byteの文字が入らないように変更して、回避してください。

これは、V2.5 の不具合です。この問題につきましては XSL Formatter V2.5 改訂３版 にて修正されました。

XSL Formatter では、Windows の標準の CJK フォントが有効になっているとき、言語ごとのデフォルトのフォントとしてこれらが使われるようになっています。

[組版オプション] ダイアログボックスの [言語別設定・日本語処理] タグを選択して、「言語」項目を確認してください。

serif: MS 明朝sans-serif: MS ゴシック
cursive: (設定なし)
fantasy: (設定なし)
monospace: MS 明朝

となっていれば、正常です。もしこのようになっていなければ、[組版オプション] ダイアログボックスの [標準の言語とフォント] タグで、[フォント設定をデフォルトに戻す] チェックボックスをオンしてください。これでフォント設定がデフォルトになります。

このデフォルトの設定があれば、FO の font-family プロパティに具体的なフォント名を指定しなくても、日本語などが表示されます。

<fo:block font-family="serif" xml:lang="ja">
   (Japanese text here)
</fo:block>

明示的にフォントの名前を指定するときは、そのフォント名が正確かどうか確認してください。例えば MS Mincho を MSMincho （スペースがない）とするのは誤りです。

<fo:block font-family="'Times New Roman', 'MS Mincho', Batang, serif">
   (Latin and Japanese and Korean mixed text)
</fo:block>

なお、CJKは同じUNICODEコードであっても国（Locales）によって文字形状（glyph）が異なります。よって、例えば日本向けの文書と中国向けの文書では同じUNICODEであっても、フォントは明確に切り替える必要があります。

XSL Formatter は、インストールして最初に実行されたとき、言語の標準とフォントを設定します。 そのあとで中国語フォントを追加したり、韓国語フォントを入れても、レジストリには新しいフォントには指定なしという設定が記憶されたままです。

新しいフォントを有効にするには、「組版」メニュー→「組版オプション」→「標準のフォントと言語」タグの「フォント設定をデフォルトに戻す」のチェックボタンをチェックして、「すべてのゼネリックフォント設定をデフォルトに戻します」を実行してください。

Windows に Arabic 言語をインストールしていないのが原因と思われます。Windows 2000以上ならば、コントロールパネルの Regional Options で言語をインストールしてください。 （NT4は未確認。Win9X系は非サポート） また、スタイルシートで writing-mode="rl-tb" を指定する必要もあります。

オンラインマニュアルに記載されていないフォントが指定されていると文字が表示されません。 組版オプションの sans-serif で指定されているフォントになりますが、既定値はArialになっている場合、これを「Microsoft Sans Serif」に変更すると出力できます。

この問題はArialがThai語のコードポイントのグリフを持っていないために発生します。（ Windowsの画面には他のフォントで代替えして表示していますが、PDF出力オプションはこの処理ができません。）

組版オプションで指定する標準フォントファミリ（defaultFontFamily）というのは、 スタイルシートで font-family 指定がないときのデフォルトを与えるもので、font-family 指定があるときには使われません。font-family 指定で、システムにないフォントや不明なフォントが指定されている ときは、defaultFontFamily ではなくて、AXFO.dll 内部でもっているfallbackFontFamily が使われます。

fallbackFontFamily = "Lucida Sans Unicode, Arial Unicode MS, Tahoma, Microsoft Sans Serif"

したがって、"Lucida Sans Unicode"になります。 スタイルシートの設定を、font-family="Arial Unicode MS, serif" のように変更してください。

XSL Formatter V2.4までは、長音（ー）は行頭禁則文字に含めていませんでしたが、XSL Formatter V2.5から行頭禁則文字に含めました。（長音の他に「ヾ」も含めました）
なお、XSL Formatter V2.4まではデフォルトで行頭禁則処理が行われましたが、XSL Formatter V2.5からデフォルトでは行頭禁則処理は行われません。行頭禁則処理を行いたい場合は、「アンテナハウス XSL 拡張仕様」の「axf:line-break」に'strict'を指定してください。

他の方法としては解決策としては、分割させたくないところに Unicode の制御文字であるU+2060(WORD JOINER)を入れることで分割がされなくなり、その結果として、禁則処理が行われます。

XSLT のプログラムで、"ー" をすべて "⁠ー" に置換すれば、自動で行うことも可能です。

ちなみに、普通は分割できないところを分割するには、 U+200B(ZERO WIDTH SPACE)を追加します。例えば、小さなカナの「ゃゅょ」などの前で分割を許可するなら、そこに U+200B を入れれば禁則されず、次行に分割されます。

U+2060 WORD JOINER は、Unicode 3.2 で追加されたものです。それまでは、U+FEFF ZERO WIDTH NO-BREAK SPACE がその役目だったのですが、BOM と同じコードであるのはまずいということでこうなりました。XSL Formatter ではどちらでも同じに機能しますが、Unicode 3.2 仕様では、U+2060 を使うことが推奨されています。

XSL Formatter V2.5から「アンテナハウス XSL 拡張仕様」の「axf:hanging-punctuation」を使用することでぶら下げ可能になりました。
axf:hanging-punctuation に「end」を指定した場合、行末での句読点のぶら下げを処理します。詳しくはXSL Formatter のオンラインマニュアルをご覧ください。

もう一つの方法は、段落の行を1文字（＋マル）だけにしないようにする処理を、U+2060(WORD JOINER)を使って 「で⁠す。」とすれば「です。」は分割されることはありません。しかし、XSL Formatter は追い込み処理を積極的に行わないため、「です。」自体が次行に移されます。よってこの場合は「です。」の前の文字間からU+2060(WORD JOINER)を指定して、調整していく必要があるかと思います。

日本語の禁則文字などの日本語独自の組版ルールに属する部分は、XSL-FOの仕様では規定していませんが、XSL Formatter の組版処理で実現しています。

XSL Formatter では Unicode Line Breaking Properties による標準の禁則処理を行います。 そしてV2.5からは、「アンテナハウス XSL 拡張仕様」によって行頭禁則や句読点のぶら下げなどをサポートしました。詳しくは XSL Formatter のオンラインマニュアルをご覧ください。

XSL Formatter はHATをサポートしております。ただし次の制限事項があります。

Thai:

V2.5から、組版時の自動改行（辞書による単語の区切り位置での改行）をサポートしました。（WindowsNT/2000/XPでのみ有効）

Arabic and Hebrew:

V2.3からKasidaをサポートしました。よって均等割付は正しく処理されます。

UnicodeBIDIの処理は、Window2000/XPに限りサポートしています。

xml:lang はcountryプロパティとlanguageプロパティのショートハンドになります。よってcountryプロパティとlanguageプロパティが指定できる部分に指定すれば問題ありません。また、countryプロパティとlanguageプロパティは継承プロパティですので、都合の良い所で指定できます。

<fo:block xml:lang="en">
    English flow（language code en）
</fo:block>

<fo:block xml:lang="zh-CN">
    Simplified Chinese flow（language code zh, country code CN）
</fo:block>

Arial Unicode MSは全てのUnicode文字を全てサポートしています。しかし、Arial Unicode MSは全ての言語を正しく表示できません。
それは中国語（Chinise）、日本語（Japanese）、韓国語（Korean）の CJK は Unicode では同一の領域を共有しているため、文字コードからその文字がCJK のどれかを判定できないからです。
よって、下記のようにCJKをについてはフォントを変える必要があります。

<fo:block font-family="MingLiU">
    沈下大海的島嶼(Traditional Chinese text)
</fo:block>

<fo:block font-family="SimSun">
    〓下大海的〓〓(Simplified Chinese text)
</fo:block>

<fo:block font-family="MS Gothic">
    海に沈む島(Japanese text)
</fo:block>

つまり、その国の言語を正しく表示するためには、その国のフォントを明確に指定する必要があります。

これは不具合ではありません。Unicodeの仕様によるものです。

Unicodeテキストの方向性は、Unicodeの仕様の中のbidiアルゴリズム(双方向アルゴリズム)によって決まっています。ラテンアルファベットはleft-to-right（書き順が左から右）、アラビア文字やヘブライ文字はright-to-left（書き順が右から左）です。

括弧はUnicodeではleft-to-rightでもright-to-leftでも使用できる「ニュートラル（neutral）」な文字とされています。
そして括弧のような対の文字は、right-to-leftの状況では、グリフもleft-to-rightと向きが逆になります。これをミラーリング（Mirroring）と言います。

つまり、括弧の文字はニュートラルな文字で、なおかつミラーリング対象文字となっていますので、左括弧'('が右括弧')'になり、右括弧')'が左括弧'('になります。 （厳密には、グリフを反転させているので右括弧')'が完全な左括弧'('になるわけではありません）

例を出して解説します。

FOには次のように書かれていたとします。 'Arabic' が アラビア語、'English1'、'English2' が英語です。 'English2' が括弧で囲まれています。

<fo:block-container writing-mode="rl-tb" language="ar">
<fo:block>
Arabic English1 (English2)
</fo:block>
</fo:block-container>

この出現順で right-to-left の場合、次のようになります。

(English1 (English2 cibarA

Unicodeの仕様では、「一般的に、ニュートラル（の文字）は周辺のテキストの影響を受ける。」とありますので、left-to-rightとleft-to-rightにはさまれたnuetralはleft-to-rightになりEnglish1とEnglish2の間の左括弧'('はleft-to-rightとなります。
しかし、English2の後ろの右括弧')'は、Unicodeの仕様で「対立（混在）した場合は、上で指定された方向で埋め込む。」とありますので、fo:block-containerで指定されたwriting-mode="rl-tb"により、right-to-leftとなります。
よって、右括弧はミラーリングによって左括弧になり、writing-mode="rl-tb"によって行末（right-to-leftなので一番左側）に配置されます。

これを解決する方法は２つあります。
１つは、Unicode 制御文字の U+200E (LRM, Left-to-Right MARK) を使用します。LRMは方向性のあるゼロ幅のマークです。English2の後ろの右括弧')'の後ろにleft-to-rightの方向性の文字を追加すれば、右括弧')'も、left-to-rightとなります。

<fo:block-container writing-mode="rl-tb" language="ar">
<fo:block>
Arabic English1 (English2) &#x200E;
</fo:block>
</fo:block-container>

２つめは「fo:bidi-override」を使用します。
'(English2)'の部分を <fo:bidi-override unicode-bidi="embed" direction="ltr"> で囲みます。

<fo:block-container writing-mode="rl-tb" language="ar">
<fo:block>
Arabic English1
<fo:bidi-override unicode-bidi="embed" direction="ltr">
(English2)
</fo:bidi-override>
</fo:block>
</fo:block-container>

なお、半角スペースもニュートラル文字ですので配置がかわります。上記の２つの方法の適切な方法を使用してください。

Unicodeの仕様はこちらをご覧ください。Unicode Standard Annex #9 The Bidirectional Algorithm: http://www.unicode.org/unicode/reports/tr9/

そうです。よって、level2の数値(EN)の部分を反転させて、この後、levelが1であるヘブライ語の部分を反転させます。
BIDI Algorithmについては、Unicode Standard Annex #9 とともに公開されている Reference Code でテストすることができます。

• http://www.unicode.org/unicode/reports/tr9/BidiReferenceCpp/
• http://www.unicode.org/unicode/reports/tr9/BidiReferenceJava/

XSL Formatter V2.3 の BIDI アルゴリズムには Windows Uniscribe API を利用しています。このため、Uniscribe の問題の影響を受けています。
Uniscribe API はおそらく Unicode 2.x のころの BIDI アルゴリズムを実装したものだろうと思います。Unicode 2.x のころの BIDI アルゴリズムでは、L(left-to-rightの文字)のあとの EN (数字) は L にするという規則がありませんでした。（http://www.unicode.org/unicode/reports/tr9/tr9-2.html）そのため、数字は、欧文のあとにあってもBIDIレベルが上がります。
最新の Unicode BIDI アルゴリズムには次の規則があります。（http://www.unicode.org/unicode/reports/tr9/tr9-10.html）

W7. Search backwards from each instance of a European number until the first
strong type (R, L, or sor) is found.
If an L is found, then change the type of the European number to L.

        L  N EN => L  N  L

IE の BIDI アルゴリズムは、Uniscribe API よりも、上記の最新の UnicodeBIDI アルゴリズムにより忠実なように見えます。つまり IE は Uniscribe API を使用していないと思われます。したがって、IEとXSL Formatterとでは、BIDIについて違いが発生すると思われます。 （ただし、これについては 正確に調査していませんので、あくまでアンテナハウスの推測です）
ちなみに、Windows の Edit controlは XSL Formatterと同じ結果が表示されます。これは Edit control が Uniscribe API を使用しているためだと思います。

最後に、このテストは、Windows XP Professional (SP1)で確認したものです。 ご了承ください。

全体の writing-mode が縦書き(tb-rl)であった場合、次のようにして実現可能です。

<fo:block>
 縦書き
  <fo:inline-container writing-mode="lr-tb" alignment-baseline="middle"
    text-indent="0mm" last-line-end-indent="0mm" start-indent="0mm" end-indent="0mm">

    <fo:block text-align="center" line-height="1em" wrap-option="no-wrap">
      縦中横
    </fo:block>

  </fo:inline-container>
  縦書き
</fo:block>

１つのドキュメントの一部分のページの流れを変更する(例えば、左から右へ流れるページの中に右から左へのページを埋め込む)といった処理は、XSL-FOでは不可能です。

この問題につきましては XSL Formatter V2.5 改訂３版 にて修正されました。
fo:inline ではなく、fo:block の中に直接タイ語のテキストを書くと問題が解決する場合があります。

このエラーは、MSXML3 か MSXML4 がインストールされていないときに発生します。XSL Formatter は MSXML3 か MSXML4 が必要です、まずは MSXML がインストールされているかご確認ください。

また、インストールされていてもインストールが正常終了していない場合があります。この場合もこのエラーが発生しますので MSXML を再インストールしてみてください。

なお、XSL Formatter V2.5から「MSXML がインストールされていない」エラーメッセージが表示されます。

XSL Formatter のGUIに「INIファイルのエクスポート」機能があります。これはGUIにて設定した各オプションをINIファイル形式で出力します。このINIファイルはそのまま、コマンドラインインターフェイスやCOMインターフェイスで引き渡すことができます。