ちょっと外れた話になります.もう数年前だったと思いますがdita-usersでDITA-OTがいろいろ言われたことがあったと記憶しています.曰く「処理が遅い」「JavaとXSLTとantの組み合わせではCMSへのインテグレーションがうまくできない」などなど.DITAの処理系はDITA Open Toolkitだけではありません.例えば
DITA - Beyond OT
では、DITA Converterと呼ばれるものや、DITA XProc Pipelinesと呼ばれるものが紹介されています.あともう開発者の方が亡くなってしまったので最近は表に出ませんがWordに変換するDITA2Goという処理系もありました.
確かにいろいろデザインの問題というのは存在すると思いますが、私が感じるのはDITA-OTのユーザーと他のインプリメンテーションとの利用者の数の違いです.勝手な独断ですが、DITA-OTがはるかに多いでしょう.多くの方に使っていただければ、不具合も発見されるし、ソフトウェアの質も向上するのだと思います.
畑はちょっと違いますが、XSL-FOの処理系も私の会社の出しているFormatterの他にも様々なインプリメンテーションがありました.IBMだってアルファワークスで試作品を作って公開しましたし、Adobeもサーバー製品を出しました.しかし現実にはこれら大手ベンダーが作ったソフトウェアでも、その分野を席巻するということにはなりませんでした.私は、どのくらいのユーザーに使ってもらい、そのフィードバックを受けてソフトの質を向上できたかがカギになっていたのではないかと思います.
話を戻して、それほどまでに使用されている(と思われる)DITA-OTですが、しかし未だにバグ報告は絶えません.以下を見ていただくとわかります.
dita-ot/dita-ot
私が現在非常に困っているのはDITA-OT1.8.5も2.0もそうなのですが、TppicMergeというmapとtopicをマージした中間ファイルを作るDITA-OTの中間処理が、もしtopic/@xml:langがないと勝手に@xml:lang="en"を付けてしまうことです.
TopicMerge sets unexpected @xml:lang attribute to topic.
一般にCMSをお使いのお客様は多言語展開があたりまえなので、CMSのリポジトリ上のあるtopicの識別子には、必ず@xml:langが付くでしょう.なぜならば、翻訳が行われれば翻訳された各国語のtopicが@xml:langを付け替えられて、その識別子の下に格納されるからです.
しかし、CMSを使用しないような小規模なDITAの利用ではmap/@xml:langに言語を指定して、それでpublicationに言語を識別させ、個々のtopicには@xml:langはまずつけません.このようなインスタンスを処理するプラグインもそのような作りになっています.
しかしこのような作りでは1つのpublicationで複数の言語がxml:langで指定されたtopicで構成されるような出力には決して対応できません.もしくはtopicに限らずphレベルでもxml:langで各国語が切り替えられるような場合も含みます.
bookmap/@xml:lang="ja"
topic/@xml:lang指定なし
だと、基本的にすべて日本語のフォントを割り当てますが、上記のようにTopicMergeが勝手に@xml:lang="en"を入れてしまうと
bookmap/@xml:lang="ja"
topic/@xml:lang="en"
という状態になってしまいます.@xml:langを素直に解釈すると、例えtopicの中が日本語であっても、topic/@xml:lang="en"を尊重して、例えばtopicに対してfont-family="Times New Roman"を生成せざるを得ません.ただしtopicのコンテンツが日本語だと賢いFormatterだったら自動的にフォントをフォールバックさせて、例えばMS-Minchoを自動的に割り当ててくれます.結果的には同じようなPDFが出来るのですが、これは事実上プラグインのスタイルシートの「敗北」ともいうようなものです.プロダクションユースのPDFを作る場合、決してフォントのフォールバックなどあってはならない事態だからです.
という訳で、DITA-OTのバグが早く治ってくれないかやきもきしています.上記のバグ報告は2013年3月に出したものですが未だに治ってくれていないからです.
※ ちなみにDITAの仕様ではmapの@xml:langはtopicには継承されません.ただしtopic/@xml:langが指定されていない場合、処理系は適切に既定の@xml:lnagを仮定する必要があります.私はmap/@xml:langを尊重して仮定してくれるのが一番理に適っているのではないかと考えます.
2.1.3.9.1 The @xml:lang attribute
If the @xml:lang attribute on the document (outermost) element of a map or of a top-level topic has no value, the processor should assume a default value. The default value of the processor may be either fixed, configurable, or derived from the content itself, such as the @xml:lang attribute on the primary map file. As the default value of a processor may be fixed, it is strongly recommended that the @xml:lang attribute be set on each map and top-level topic.