Index > XML Round-Trip 方式による FrameMaker アプリケーションの開発
Tue, December 29, 2009

XML Round-Trip 方式による FrameMaker アプリケーションの開発

Adobe FrameMaker + XML のアプリケーション開発では、 One-Way 方式と Round-Trip 方式があります。

つまり、Round-Tripは いったんFrameMakerで開いてフォーマットした fm データをもう一度XML文書として 保存することができる形のFrameMakerアプリケーションということです。 この方式では FrameMaker上で変更した内容・レイアウト/スタイルに関する情報をXML文書に戻すことができることになります。 (どの変更内容までをXML文書書き戻しサポートするかは、FrameMakerアプリケーションによってまちまちです。)

Round-Trip開発どこまでサポートしているか →Adobe FrameMaker8

FrameMaker7 時代にRound-Tripの調査をしたときは、かなり大変、というイメージを持っていたのですが、 今回は FrameMaker8 で調査したところ、Round-Tripのサポートがかなりよいことがわかりました。

これは、FrameMaker8 になってサポートがよくなった、ということではなくて、 単に大島のスキルがあがったので、結果として好印象を抱いているだけのような気がするので、その点はご了承ください。 (7と8の違いとか、8でできたことが7でできない、とかいった細かい調査はしていません。)

特に便利に感じているのは、XSLTのPre,Postの2つをアプリケーション定義に指定できることです。 これは、FrameMaker標準の仕組みとして、XMLを開くときに適用するXSLTと、XMLを保存するときに適用するXSLTを指定できることを 意味します。 もし、簡単なアプリケーションであれば、この仕組みだけを使って XML Round-Trip を実現することが可能だと思います。

面倒なのは 表(Table)

数式も大変かもしれませんが、とりあえず自分の身に降りかかっていないのでパス(未調査)

FrameMakerはDocbookでも採用されている Cals Table のサポートがよい。 読み込みだけ考えた場合は、通常の表であればほぼ問題ないレベルまで言っている(と思う)。

ただし、Cals Table 自体の仕様が単純すぎて現実(=顧客からの厳しい要求)に追いついていない可能性があるが...orz

書き出すときはかなり制限が多い。 それに、FrameMaker上では、表に対していろいろ複雑なこと(罫線を消したり、セルの背景を自由に塗り分けたり) ができるので、その変更情報をXML文書に書き戻せるようにする、といったことを考えると、 (おそらくReadWriteルールで対応できないので)APIクライアントが必要になるのは当然のこととして、 開発者としては、かなりヘビーな対応を迫られることは間違いなさそう。

画像も若干癖あり

画像に関する XML を Round-Trip すると、XML 保存した段階で、想定していない属性が追加されてくることになります。 ただこの辺は、ReadWriteルールを適切に書いたり、(もし可能なら)アプリケーション側で、 FrameMakerと同じ属性を使うようにすれば問題を回避できるレベルです。

One-Way 方式の方が一般的 ?

One-Way 方式は、FOP(たとえば、Apache FOP やアンテナハウスの XML Formatter )と同じ処理フローになりますので、 個人的には、こちら主流と考えたいところです。

XML文書は基本的に内容中心になります。 一方で、印刷用レイアウト(PDFといってもいい)では、章の扉部分の特異なレイアウトや ハシラなどに表示するランニングヘッダをはじめ、印刷用のために必要な情報をかなり追加しています。 その結果、元のXML文書と印刷用のデータとの間で乖離が大きいのです。

Round-Trip 方式では、このように印刷用に追加した情報をすべて削除して元の(素朴な)XML文書に 戻す必要がある、という意味で、このプロセスを実装するのにかなりの体力を使わざる得ないケースが 多くなります。

 Twitter
follow me on Twitter
 Categories