Index > 自動組版を前提に考えた場合の InDesign と FrameMaker との比較
Wed, February 27, 2008

自動組版を前提に考えた場合の InDesign と FrameMaker との比較

FrameMakerとInDesignを使って自動組版をすることについて ここ一年くらい具体的にマニュアルの制作にも関わりつつ検討している。

いずれも内容をXMLで表現し、それをFrameMaker/InDesignを使って、 自動的に(ルールベースで)レイアウトしていく、というアプローチを取るのだが、 両者はかなり得意分野が違う。

全体的に言えば、ページ数が多い印刷物の場合はFrameMakerが有利で、 それ以下であれば、レイアウトの柔軟性や最悪手作業でDTPになったとしても ちからわざで対応可能、という意味で、InDesignが有利な場合がある。

InDesignのうれしいところは、 InDesignは FrameMakerにくらべて 後発ということもあり、拡張しやすいという点です。

DOMっぽくJavaScriptでInDesignドキュメントにアクセスできますから。 FrameMakerのFDK経由でのAPIはDOMっぽくない、と思う。

一方、制作ビジネスとしてみた場合、 コストパフォーマンスを考える必要がある。

普通に考えると、 FrameMakerが得意とする領域の印刷物制作に、 InDesignをカスタマイズして使用すると、カスタマイズ分だけコストアップ要因になるので、 InDesignで対応できるからといってそうすべきではない。

しかし、ビジネスでは制作の都合以外に検討することがたくさんあって、たとえば...

とか、そういう理由によって、どちらを使うか決める必要が出てきます。

そんなこともまで考えはじめると、どこに最適解があるのか、混乱してきますね。 だから、ここでは、制作のことだけを考えることにします。

FrameMaker

FrameMakerでは、 DTDにレイアウトルールを追加した EDD(Element Definition Document) を使ってページをつくっていく(組版する)。

DTDとは文書構造を規定したもので、 そこにはレイアウトやスタイル情報を含んでいない。
印刷物をつくるには、ページネーションやページ上に各要素をどう表現するか(スタイル)を決める必要があるため、 その部分をFrameMaker独自の言語を使ってルールとして決めていく。

CSS と EDD

これは、 Webの世界でいえば、EDDがCSSと同じ役割を果たしているのだが、 CSSとは違い、 条件やコンテキストに応じて割り当てるスタイルを切り替える、など 一種のプログラム言語的にスタイル指定できるため、柔軟性が高い。

CSSとJavaScript

CSSは、JavaScriptで実行時に操作できる...つまりプログラムできる ので、そういうところまで考えると、 CSSの能力は、EDDと同じなのかもしれないですね。

EDDの特徴

EDDは文書構造情報に対してレイアウトルールを割り当てていくため、 ページ上にどういう風に文字やイラストを割り付けるか、という考え方は しない です。

FrameMakerの考え方は あくまでテキストや図版をフローに沿って流し込むことが大前提で、 その流れの中でEDDの指定により、 ある文書構造要素(たとえば"見出しレベル1のエレメント")では、必ずそこで改ページするとか、 見出しとそれに続く本文がページをまたいでしまう場合に、そうしないようにする、 とかいった指定により、結果としてページができあがっていきます。

したがって、 ページ上にイラストや文字を割り付けていくという、ある意味 普通の発想でページレイアウトをコントロールできると考えると失敗する ことになります。

手作業でDTPしていたときには何てことない処理が、 ルールベースのレイアウトでは、簡単にはいかないことになります。 いちいち細かいレイアウトルールを受け入れていると、EDDが管理しきれないほど複雑になりますし、 それを避けるために、タッチアップ (=最終出力直前に手作業でレイアウト調整すること) で対処すれば、DTPオペレータは泥沼です。

発注者側を含めその制作プロジェクトに関わる人が このことを理解していないと、 特に下流行程で作業しているDTPチームがデスマーチに陥ることは 間違いないでしょう。

FrameMakerの将来性

ごく最近、FrameMaker8が出荷され、開発は継続されていることはわかったのだが、 CSシリーズに組み込まれることもなく、今後10年くらい先のことまで考えると (開発中止になってしまうのではないかと)不安の残るソフトウェアである。

2009-07-14 追記

FrameMaker9 も出荷されて、さらに Adobe Technical Communication Suite の一部になっているので、ちょっと安心ですね。 まだ見捨てられてなかったようです。

とはいえ、FrameMaker9 のUNIX版が出なかったのがちょっと残念です。 Solarisを用意したり、フォントを揃えたり・・・ということを考えると私がUNIX版を使える日は かなり遠そうですけど。

InDesign

InDesignは、見た目重視の印刷物で使用されることが想定されているようで、 いままでIllustratorでつくっていたような印刷物をInDesignでつくることができます。 (できるそうです。)

InDesignでは、XML対応が宣伝されていて、 確かに対応しているのですが、 JavaScriptを使わないでできる範囲は非常に限定的で、 商用印刷物をつくる現場の現状に耐えられるほどの柔軟性はないと思います。

2009-07-14 追記

これは...CS3の話、 CS4のInDesignでは IDML(InDesign Markup Language)という新機能があり、 使ったことはないのですが、期待が持てそうな気がします。

しかし、InDesignは、組版エンジンであり、 そのエンジンをJavaScriptから完全にコントロールできるようになっています。 したがって、JavaScriptを使って、 InDesignをコントロールすれば完全な自由を(プログラマは)得ることができます。

InDesignはあくまでページ主体の考え方をします。 この点はFrameMakerとは違って、普通の人の考え方に沿っているため お客さんなどに理解されやすいと思います。 ページがあり、オブジェクトを配置する、そいういう考え方で 組版エンジンはつくられているし、JavaScriptでページをつくっていく場合も それは同じです。

想定しているページを超えてしまう場合への対処

しかし、そのことは、当然ながら代償もあります。 それは、 ある内容がページを越えてしまった場合の対処方法を自分でコーディングする必要がある ということです。 データベースやXMLデータから自動で組版できるということは、 データベースやXMLの内容は変更になる、ということです。 したがって、 内容がページからあふれているかどうかのプログラムによる監視が必要になります。

つまり、 ある今回のXMLコンテンツはページあふれが起こっていなくても、 次回のXMLコンテンツではページあふれが起きる可能性があるということです。

内容がシンプルで、レイアウトが定型で、 それほどバリエーションがない場合は、 自分で書いたJavaScriptで自動組版の対処することが可能です。

しかし、内容・レイアウト・見た目の複雑さの要求がエスカレートしていくと ある段階で、自前JavaScriptによる自動組版は破綻する可能性があります。
救いは、InDesignでは、 手作業による従来型DTP作業とスクリプトによる自動組版の 協調作業ができるように設計されていることです。

ある程度ページレイアウトに対する要求がプログラマの手に負えない範囲まで 膨らんでしまった場合、 その部分については、手作業でタッチアップとして最終出力直前にDTPしてしまう、 という手段が残されています。
自動組版がコストダウンや品質に対する要求からきている場合、 手作業部分が増えてしまうと、元も子もなくなることになりますから、 このアプローチは注意が必要ですが、 すべてをプログラマが解決することはやはり無理な場合があると思います。

なお、InDesign向のサードパティー製品の説明を見ていると このあたりの問題を解決を提供する商品があるようです。

まとめ

自動組版に関する参考情報リンク

 Twitter
follow me on Twitter
 Categories