4月1日は本当に「エイプリルフールじゃないの～！」と言いたいほど朝からメールで障害報告、仕様変更依頼、問い合わせが飛び込みました．それも複数のお客様からです．おかげで午前中はJavaの修正コーディング、午後はDITA Open tookitの調査という具合で昼ごはんもセブンイレブンのおにぎりを食べながらディスプレイを覗き込むという状態でした．
お客さんから出てきたPDFの表のレイアウトが崩れているとの指摘でXSL-FOをのぞいてみるとなんと、fo:table-rowの中でcolumn-numberの同じfo:table-cellが二つもあります．こりゃおかしいと思って、入力のDITAのオーサリング結果を見るとこちらの方はcolnameは正確です．そうです、かのジャストシステムのXMetalごときがこんな間違った出力をする訳がありません．仕方がないので、DITA-OTの生成した中間ファイルを見てみました．するとなんのことはない、確かにrow/entry/@colnameがダブっています．結局DITA Open Toolkit 1.5.1のバグと判明しました．
何故問題が深刻なのかというと、このバグ実はDITA-OT 1.5.2ではfixしているのです．実際私のローカルの試験環境でやってみたらなんの問題もなく表はきれいに出力されました．「じゃあお客さんのところもDITA-OT 1.5.2にしてもらえればいいじゃん」と言われそうなのですが、そうは行かないのです．お客さんの環境は世界的にも有名どころのCMSがバックボーンにあって、お客さんはすべてそのCMS環境下で仕事をやっています．そのCMSのpublishing engineがあるのですが、サポートしているDITA-OTが1.5.1止まりなのです．CMSのDITA-OTサポートは結構大変でヨーロッパから日本に出張してもらってカスタマイズしてもらっています．（時間単価高いだろうな～）そう簡単にDITA-OTのバージョンを変えてはもらえません．
あとなかなか悔しいのがDITA Open Toolkitの位置づけです．お客さんはCMS環境下で文書のオーサリングをやってCMSに保存し、必要な時に文書をPDFにして出力します．これもCMS環境下で、ちょいちょいとGUIを操作してOKボタンを押してジョブを走らせるだけです．DITA Open Toolkitがどうたらこうたらということなどほとんど意識にありません．要するにまともなPDFができるか否かなのです．
この仕事をやるとき、営業から「DITAからXSL-FOを生成するスタイルシートを作ってくれ」といわれてやり始めたのですが、DITA-OTのバグがあるたびにこちらで面倒を見なければなりませんでした．CMSがDITA Open Toolkitをのせかえる前にfixしてくれれば良いのですがこんどばかりはそうは行かなくなってしまいました．
仕方がないので昨晩sourceforge.netからDITA-OT 1.5.1と1.5.2のソースコードをダウンロードし、必死にどこがおかしいのかgrepで探しまくりました．そしてWinMergeでソースを比較しなんとかDitaWriter.javaが1.5.2で修正されているのまでは突き止めました．今までほったらかしにしていたJREとEclipseを最新にして、とりあえずdost.jar（DITA-OTのコアモジュール）のビルドまでたどり着きました．あとは1.5.2の修正を1.5.1のソースに取り込めるか否かです．どうなるのかなあ～！また来週は忙しくなりそうです．
（画像はDitaWriter.javaの比較結果．ガーン！結構修正されてる．）
