カタログ制作における入稿システムについて（完全自動と半自動組版について）

数年前からカタログ制作における入稿システムのオーダーが増えているので、ちょっとまとめます。

入稿システムが必要とされる背景

WEB入稿システムが必要とされるのは、複数メーカーから原稿を受け付けるタイプがほとんどで、その理由は、「とりまとめるのが大変だから」がダントツです。

確かに、とりまとめ＝原稿整理、進捗管理は、非常に大変です。

原稿がなかなか出てこなかったり、画像がこなかったり、逆に一旦もらって進んでいる途中に差し替えが来たりと、、、下版日が刻々と迫る中、気が狂う人が出るのも頷けます。

それでも、カタログに手を出すのは何故でしょうか。

いわゆる厚物で、印刷会社としては金額もそこそこでしょうし、そういう大変なものが出来るというステータスもあるのかもしれません。自分にはこぞって獲りたがっているように見えます。

一方で、客側は、紙カタログの部数を減らして、WEB用にPDFで展開したり、検索サイトにしてしまったりということもしているので、紙が無くなるわけではないですが、そこへ向ける力のいれ具合は、違うように思います。

また、自社の基幹システムのデータなど、基本となるデータはあるのだから、これを上手く使えばDTPなんて楽にできるんじゃないの？と思われているかもしれません。

そういう中で、客側の手は煩わせず、データを渡すから上手く使ってね、最後にはデータを使いたいので返してね、印刷（制作も含む）が安ければ出すよ、と難題を受け入れざるを得ない状況ではないでしょうか。

相談を受けるカタログの特徴を挙げると、

• 頁ボリュームが多い
• 年1回、2回など定期もの
• 複数メーカーからの原稿回収、やりとりが大変
• メーカーから受け付けた後、掲載情報として精査、追加編集する
• 客先から何かしらの商品データがくる
• 商品スペック部分はある程度パターン化されている
• 商品の流用画像や新規撮影画像など画像の取り回しを考慮する必要がある
• 索引がある
• 完全自動組版にできない理由がある（デザイン調整が必要など）

となります。

そして、どの工程の人たちも一様に大変だ、というのが現状です。

この現状を打破するために、入稿システムが欲しい、となるわけです。

カタログ制作でやりたいことは？

やりたいことは、単純に書くとこうなります。

つまり「データを上手く使って本を作りたい」となります。

本やWEB、その他メディアに向けたコンテンツ制作における効率の良いサイクルを確立したい、ということです。

しかし、現実はなかなか難しい状況のようです。

今までに相談をしてくれた人たちの状況をみてみると、以下のようになります。

• 客先からきたエクセル（CSV,XMLなど）を使って手動DTP
• FileMakerからツールを経由して半自動DTP
• WEB入稿システムまでは作ったが、DTPは完全非同期
• 最後に返すデータはDTPから書き出すか、直接エクセルを手作業で作成

どうみても、それぞれの工程でデータが切り離されていて、本来やりたいことにはほど遠い状況で混沌としています。

「データがあれば本ができる」というのは難しいかもしれませんが、それでもこれを理想論で留めるのではなく、目指さなければいつまでたっても同じ悩みで停滞してしまいます。

入稿システムの範囲

一括りに入稿システムといっても、どこまでやりたいか、予算によってその範囲を決める必要があります。コストがかからない順にいくと、以下のようになります。

1. メーカーがログインして自社商品情報をエントリーするだけ（メーカー側の機能）
2. エントリーした商品情報を精査、管理するところまで（編集側の機能）
3. 自動組版または半自動組版データの生成（DTP側の機能）
4. データ活用のためのデータ出力（客先のシステム部などのための機能）

※3,4は手法によってコスト順位が変わります。

これらは、１だけ、２までなどでも可能ではありますが、本来の目的を達成するためには、3、4まで考えなければ中途半端になってしまいます。

入稿システムを使った制作サイクルの具体例

数年前から、色々なタイプのWPS.3をカスタマイズしたカタログ制作向けの入稿システムを稼働させていますが、事例をもとに前述の要望をもう少し具体化すると、以下のような制作サイクルになります。

これは、入稿システム上でデータ校了になったことを前提にDTP作業に入り、その後は一般的な印刷物制作の流れを組むものです。システム上からDTPへのデータの引き込みは、スクリプトやCSVなどいくつかの手法があります。

完全自動組版と半自動組版

1と2は、業務フローが確定すれば、それほど大変ではないので、3と4について、現実的な問題はさておき、考えてみます。

データ活用のために入稿システムが存在するとき、PDFを作る系統は２つあります。

上段の流れは、入稿システムから直接PDFを出力する流れ「完全自動組版」の例です。これはWPS.3（自動組版エンジンはAH Formatter）で実現しています。

下段の流れは、入稿システムからIDMLをダウンロードしてDTP作業（InDesign）によってPDFを作る流れ「半自動組版」の例です。IDML Binderが例となります。

※IDML Binderに関する記事は以下を参考にしてください。

• エクセルをアップしてInDesign（IDML）データをダウンロード
• IDML BinderでInDesignからWEB入稿フォームを作る

完全自動組版の場合の新規・修正の流れ

完全自動組版では、入稿システムから直接PDF（印刷仕上がり）を確認できるので、修正がある場合は、原稿を作成する本人がシステム上で修正をして再度PDFを生成すれば、入稿システム上で完全校了になります。DTP作業が介在する必要はなく、大きな業務効率化が可能です。

半自動組版の場合（入稿システムからの自動生成は初校時のみ活用）

半自動組版では、入稿システムで生成されたIDMLをダウンロードして、DTP側で開き、デザイン調整を行います。校正者から戻ってきた朱字をDTP作業で修正、調整します。

新規作成では、IDMLによって半自動で組版できるメリットはありますが、その後は通常DTPとなり、データを戻すためには、スクリプトなどを使って必要なデータを校了後のDTPデータから取り出して入稿システムへ戻します。

この戻す作業は、かなりテクニカルことが要求されたり、人の手によって無法地帯となったDTPから100%データを戻すことは不可能だと思った方がよいです。

半自動でもデータ活用を重視したい場合

半自動でもデータを戻したいということであれば、戻すことを考えるよりも、データとしてメンテナンスしなければいけないところは、入稿システムを修正し、再度IDMLをダウンロードして、変更部分だけを使う、というのでもよいのではないでしょうか。

この方法であれば、最新データは入稿システムに必ずある状態です。DTPで修正する場合も、最新のIDMLを使う（部分的にでも）ようにすれば正しいデータが反映されることになります。この考えは、カタログでよくある在版流用でも生きてくると思います。

完全自動と半自動のハイブリッド

もうひとつは、完全自動と半自動のハイブリッドです。

これは、データ部分は、自動組版によって、印刷仕上がりも確認しつつそれでOKならそこで完結し、それをラフデザイン原稿レベルとして、DTP用のデザイン原稿として使うというのもアリです。このあたりは組み合わせによって色々パターンがあると思います。

最後に

システムで楽になるか？というと、「楽になる」というポイントは、人によって違います。とにかく自分の手を煩わせたくない、丸投げタイプの人にとっては、システムによって増える工程を「手間が増えた」と考えます。

例えば、入稿システムがあれば、今まで期日通りに入れてくれなかったメーカーさんが原稿を入れてくれるかというときっと変わりません。システムはただ面倒に見えるだけです。別にそれが悪いとは思いません。どちらかというと普通だと思います。

一方で、データの活用や業務の効率化を真剣に考える人（普通ではない人）にとっては、システムによって安定したフローになったことで「無理しなくてよくなった、楽になった」と考えます。

原稿整理や進捗管理する人、メーカー担当者も、DTPもみんなの気持ちが楽になったと思えるようになればまずは成功だと思います。

システムに対する考え方が、それぞれの立場によってもこれだけ違うわけなので、目指すべきところは、何も考えなくてもいい、簡単に使える、という路線と、どんな要求にも対応できる柔軟な考え方と、データの居場所を確保する裏方の部分をしっかり構築する路線が必要なのだと思います。

また、カタログ制作が一様で、データの中身も変わらないのであれば、入稿システムは必要ありませんが、毎年更新が必要であり、内容もデザインも変わるということにシステム的に柔軟に対応し続けるためには、常にメンテナンスが必要、そこにコストがかかる、ということも内外で理解しておくことも重要です。

次の世代に繋ぐためにも、少しでも理想に近づくため、あきらめずに続けていきたいと思います。

page2015まとめ その2（paper-webについて）

page2015のまとめ　その２です。
組合の会報記事へそのままスライドするための草稿です。

その１では、カンファレンスとクリエイティブゾーンの事を書いたので、今回は、「紙面を1分でWEBへ！paper-web」について。

paper-webとは

WPS.3ユーザーであり今回共同出展企業のしずおかオンラインさん（以下SOL）の新しいサービスです。
貯まったデータをWEBやアプリなどへデータ配信ができるシステムです。

今回は、同社編集発行のフリーペーパー「womo」から「womoアプリ」へのコンテンツ配信の事例をデモ発表しました。

本の情報を上手に活用できていますか？

本の編集・制作の効率化も課題ですが、コンテンツを効率良く活用することも大きな課題です。

どこでもやりたいことは、下記のイメージです。

この業界（ほとんどは本作りからコンテンツ制作がスタートするので、そちらを基点として考えます。）でデータ活用というと、

• DTPから書き出して、
• 決められたフォーマットの
• CSVやエクセルにして渡す

という事がよくあります。

しかし、

• 何に使われるかよく解らない（渡す側）
• 100%の保証もない（渡す側、使う側）
• 使えたのかどうかもわからない（渡す側）
• 最終データがPDFならコピペするか（使う側）

と、折角データとしてDTPデータがあるわけですから、使わないのはもったいないのですが、とても不安定であり、渡す側にも、使う側にもしっくりこない作業です。

データ活用の裏事情

大抵の場合、思い通りスルッといかないわけなので、データ加工には、人による膨大な作業が存在します。手動DTPである以上、機械的に抽出をかけるのは困難なので、コピペしたりしながらデータを作り、場合によっては要求された形に加工をします。
さらに、そこにも人の手作業が発生すれば、校正も必要となります。
紙とWEBが違うじゃないか、と言われても、人がコピペしたり、加工しているのだから、仕方ないとしかいいようがありません。100%は約束できないものです。
であれば、そうならないシステムを組みましょう、はい、◯◯◯◯万円です、はい、無理です、なんでもいいので正しいデータをください、・・・となるわけです。
もっとよい方法があると分かっている人にとっては、苦痛でしかありません。
どんな仕事でも過酷な作業はあると思いますが、時間とコストを浪費していく将来の見えない無意味な作業はそのうち誰もやってくれなくなります。
このような裏事情をなくすためには、「もっとよい方法」を導き出さなければいけません。

紙とWEBの壁は人にある

例えばデータ活用する人たちを「WEBの人」とした場合、「紙の人」と「WEBの人」の意志の疎通が出来ていないことに問題があると思います。
構造的に部署が違うということもあります。また、「制作」ということ自体の考え方も違います。この両者をうまく繋ぎ合わせるには、紙もWEBも関係なく「データを中心に考える」ことが必要です。ただ、現実的にそういうハイブリッドな人はなかなかいないので、その中間を担う人（またはチーム）が必要となります。

WEB-APIを使ったデータ活用

paper-webは、NCとSOLの両側において「データを中心に考える」という意識を持って進めた結果、構想から二ヶ月余りでひとつの形となりました。
データはどこにあるか？NCが提供する自動組版システムWPS.3にあります。
使いたいデータは何か？コンテンツホルダーであるSOLが一番良く知っています。
であれば、SOL側がWPS.3にある欲しい情報を取り出せるようにAPIをNCで準備しました。
SOL側（paper-web）は、「◯◯号の◯◯カテゴリのデータが欲しい」と問い合わせすれば、WPS.3が「はい、これどうぞ」と返してくれるわけです。
ものすごく単純な話ですが、お互いが「データの居場所」をしっかり認識していれば、ものすごくスムーズに紙とWEBの連携が実現する、というとても良い事例となりました。

このように、紙とWEBの連動や、コンテンツデータの活用を考える際、今あるデータが取り出しやすい状態にあるか、というところから見直してみると、活用の実現だけでなく、全体的な業務効率化にも繫がります。
WPS.3、paper-webを是非参考にしてみてください。

page2015まとめ その1

2015年2月4日から3日間開催されたpage2015が無事閉幕しました。

2月ということもあり毎年天候に恵まれない印象がありましたが、今年は初日から来場者が多く、ブースにも沢山の方にお立ち寄りいただきました。ありがとうございます。

また、今年はブース出展の他に、

• カンファレンスのスピーカー
• クリエイティブゾーンセミナーの講師（？）
• ITmediaさんからの取材
• しずおかオンラインさんと共同出展「paper-web」の発表
• IDML Binderの公開

など、充実したものでした。

カンファレンススピーカー

2月4日に開催された「Web to printの新展開＜Web上で動作する新たな組版エンジンの可能性＞」 で、「WEB入稿自動組版の過去〜現在〜未来」をお話させていただきました。

"Web to printの技術は、ネット印刷ビジネスだけには留まらない。デザインテンプレートや共通パーツによる簡易レイアウト、Web制作と印刷の一元化など、DTPに置き換わる可能性を考える。

Web to printは、デザインテンプレートや共通パーツによる簡易レイアウト、Web制作と印刷の一元化など、独自の組版エンジンが動作することによって、DTPに置き換わる可能性がある。専門的な知識やスキルなしに自動組版や簡易レイアウトが行うことが可能になり、さらに印刷物と電子コンテンツのワンソースマルチユースも実現する。これからのWeb to printと新たな組版エンジンについて議論する。"(page2015カンファレンス紹介より)

• 村上 真雄(ビブリオスタイル)
• 藤原 広光(フィット)
• 川原 正隆(株式会社ニューキャスト)

の順番で、各社が取り組み等をお話していくわけですが、アンテナハウスを出てオープンソースプロジェクトでCSS組版を進めている村上さんも、自社自動組版エンジンを使ってマニュアル等のシステムを展開する藤原さんも、エンジンをお持ちですが、ニューキャストにはエンジンはありません。WPSの自動組版エンジンは、メーカー製エンジンであるEdian、MC-B2、Formatterと使用してきました。自動組版は、まだまだこれからも続けていくわけですが、我々が重要視する「エンジンは変わる、それよりもデータが大事」というコンセプトを提唱してきました。その点は、もっと将来を見ている村上さん、自動組版は単なるオプションになりつつあるという藤原さんも根本は同じであろうと思います。

当日の資料は、こちら。

クリエイティブセミナー講師

YUJIさんからお話をいただいて快諾しましたが、当日100人以上は参加いただいたのでしょうか、自分のセッションは10人ぐらいでこぢんまりかなと思っていたのでかなり驚きました。
InDesignを、DTPオペレーターだけでなく、みんなが知ることでやっとその機能が活かされると常々思っているので、営業さんなど普段InDesignに触れない人に聞いてもらいたかったのですが、圧倒的にオペレーター関係の方が多いという結果でした。

• 文字スタイル・段落スタイル
• ワード取り込み
• タグ付きテキスト
• XML取り込み
• データ結合
• スクリプト
• IDML

と、基本的なところから順番に進めていったのですが、つい「ちまちま」とやってしまう理由は何かというと、「機能が信用ならん」「上手く使えない」ということではないかと話ました。ソフトウェアなので、何か問題、課題は絶対ありますが、折角お金を出して買ったわけなので、単なるレイアウトソフトとして使うのではなく、自分の時間が持てるように使い倒しましょう、というお話でした。

当日の資料は、こちら。

今回は盛りだくさんだったので、また続きを書きます。（なるべく早いうちに）

WPSでOTFの異体字を適用する

WPSで外字を使いたい場合は、といった感じで、こちらからお知らせしている番号を入れていただきます。
このタグと番号を、DTPアプリが搭載している外字番号に関連付けて出力させています。

外字のエリアには、色々ありまして、
１．DTPアプリ側がもともと持っている外字エリア
２．このDTPアプリを使うユーザが登録するユーザ外字エリア
というものがあります。

さらに、外字を複数のフォントで使いたい場合には、それごとに持たせる必要があります。
DTPアプリによっては、ユーザ外字にあたるものを、フォントとして作成したりする場合もあります。
ちなみに、EdianWingの場合は、1外字にフォントの階層を持たせることができるので、使いたいフォント分の文字を1コードに収められます。書体を変えるだけで外字の見た目も変更されるということになります。
（MC-B2の場合は、また今度。）

一昔前までは、フォントメーカーが準備した文字が、なかなかなくって、結構なたくさん外字を登録していました。さらにシステム上決められた範囲のコードエリアしか使えないため、苦渋の策で、外字を入れ替えたりと、大変でした。
ですが、OTF（オープンタイプフォント）の登場によって、かなりの文字がカバーされることになり、ユーザ外字やユーザ外字フォントを準備する必要がなくなりました。
たとえば、印刷するときには、その外字フォントも同梱しなければらなない、など、印刷事故の原因の一つでしたが、その点がかなり改善されました。

アプリケーションによりますが、「吉」という字を入力した後、その異体字を選択項目から選択する、というような方法で、今まで出せなかった文字が出せるようになっています。

ですが、印刷のときに、出るかどうかというのは、また出力方法によりますので、注意が必要です。
WPS（現行運用バージョン）の場合は、ユーザ外字、異体字にかかわらず、リストから確認できる仕上がりの状態で、外字が適格に出力されていれば、印刷ではアウトライン化されていますので、不具合は出ることはありません。

ユーザに一覧表を渡したいですが、なかなかのボリュームなので、まだ渡していないです。
とりあえず、これに関わるお問い合わせ件数も少ないので、都度コード番号をお知らせしています。

組版エンジンの自動組版サーバ的な対応を（勝手に）比較

ご依頼ありまして、忘れてましたので、アップ。
うーん、最近ペースが悪い。

WEB入稿→自動組版→出力の流れに対応できる組版エンジンは、どんなものがあるか、
日進月歩、試行錯誤な毎日ですが、現状ということで。

その筋の方は、コメントして構いませんので、よろしくお願い申し上げます。

///XSLFormatter
アンテナハウス製品（いつもお世話になってます。）
xsl-foの標準仕様＋axf拡張で、FOに変換して取り込む。
WEB-Serviceオプションも用意されているので、WEBサービス経由で操作させることも可能。
あとは、コマンドキックとかもできます。
なんといってもPDF出力がデフォなので、PDF出力を最終と考えるなら、
組版→出力の流れは一番速いということになる。
日本語組版的な細かい組版仕様はできないことがある。
最近はまっているのでは、文字のボックスの一部に画像をおいて、そこを排除して文字を回り込ませるあたりは、できないレイアウトがある。
サーバ版という位置づけがこの製品の適切な区分けにはならないと思うが、販売形態としては、スタンドアロン版とサーバ版とある。サーバ版は、１CPUライセンスごと。不特定多数のインターネット利用の場合は、別途の構成がある。

///EdianWing
キヤノンITソリューションズ製品（いつもお世話になってます。キヤノンシステムソリューションズから改名。もとは住友金属。さらに開発しているのは、、、どこだっけ、、、えーと、桐とかの、、、いったことあるんだけど、、、物忘れ激しい、、、あ、管理工学研究所、そうそう）
もともとが、バッチ処理系に長けている製品なので、組版表現は100%（多分）トリガーテキストと呼ばれる文字データで制御できる。
ただし、見た目の判断によるオペレーションレベルまではトリガーテキストではいけない。
ただ、操作制御を行う「スクリプト」なるものがオプションであって、それを使うと、オペレベルのこともスクリプトに書いて実行すれば実現する、というレアな製品。
ちなみに、一般利用としてのAPIは公開されていないが、入稿システムに使うのであれば、WEB2Edian（今もあるのかな）なる、JAVAからソケット通信できるオプションがある。
問題は、価格が高すぎることと、PDFが直接吐けない。
そうなると、組版→EPS（PS）出力→PDF変換でPDF出力となる。
Adobe製品のDistillerをサーバに仕込むとしこたまお金をとられるので、小さい規模の仕組みには使えない。
ただ、結構丈夫なのはすばらしい。組版も速い。
このアプリをDTPとして、他のIDやQXと同等にしか使わないとするなら経営者的にNG。
だって、1台350万円もするんすよ。。。ちなみにうちは10台も20年近く使ってますが、台数の内訳はDTPと自動組版の半々になりましたね。
個人的な愛着もあってNo.1。（表作るの楽だし^^）

///Edicolor
同上の会社製品。地方新聞、広報誌などで現役で戦っておられる。IDへ移行するところもあるが、根強いファンがいるのも事実。
こちらは管理工学研究所ではなく、純日本製のパーソナルな組版ソフト。今のInDesignのインターフェースはEdicolorをまねたんじゃないかと思うところもある。ミスターEdicolorが引退したので今後どうかは不安。OCX、AppleScriptでの外部コントロールが可能。レイアウト、文字込みでEdicolorタグで再現可能。ただし、Edianほど再現力はない。その分を外部から制御する感じ。
このレベルでは何でもできそうだが、実際システムの中に組み込むのは実地による実験と検証が必要。スピードもそこそこ。ただし、マシンスペックに大きく左右する。
自動組版させるときは、ドキュメントがオープンするタイプ。
ちなみに上記Edianは開かない。
サーバとして動かすには、上記の会社にご相談ください。
単品の価格は、10万円台のはずだが、InDesignとの比較となると弱い。
PDF出力機能は、単体販売に附属しているが、サーバとしてその機能を使うのは、PDFエンジンの提供会社との契約上NGとのこと。

///MC-B2
モリサワ製品（いつもお世話になってます。）
正式なサーバ版もある。VB（VBScript）でコントロールできる。
もともとが、テキストベースで作業を行って、組版に反映させるタイプの組版エンジンであり、ローカルオペレーションでは、通常のDTPとは違う感覚。レイアウトが決まっているような場合は、B2タグを使って流し込みは可能。レイアウトまでとなると、レイアウト定義ファイルなどを準備する必要がある。
WEB入稿システムとの連携を考えると、事前準備などが多い印象があって、もう少しシンプルにデータを受け付けてくれないと、めんどくさいという印象。サーバ機能として吸収してほしいものだ。PDF出力は機能としてついている。
価格は、単体＋オプションで200万円前後。詳しくは販売店に。
ちなみに数式は、フォント屋さんということもあって、仕上がりがキレイ。
あと複雑な表組はオペ的に無理（というかできればB2でやりたくない。）

//WAVE
シンプルプロダクツ製品。（いつもお世話になってます。）
コアはAUTO-CADのエンジンだったと記憶してます。
判断組を得意とするということからも分かりますが、ロジックに基づいて組版するというDTPとは違ったコンセプトのアプリです。なので、他のツールとの連携も普通にアリです。
細かい組版になると、スピードの速さが実感できると思います。（内容によりますが）
自動組版としての機能は普通に持っていて、それをそのまま継承してサーバとして使えると思います。ロジックを作る部分は、それ自体が「人」の頭の中なので、簡単にやろう、と思うのは間違いです。ただ総合的な考え方がすごく面白い。

//InDesign
今、自動組版として注目されてるのは、やっぱりここでしょう。
スタンドアロン利用の価格は10万円を切っているというハイコストパフォーマンス。
ただし、サーバ利用は、結構なお値段。そりゃそうですよね。
それだけあって、サーバ利用の時に役立つAPIも公開されているのでWEB入稿システムとの連携はやりやすそう。あとPDFも出せるしね。
スピードはといえば、ここもマシンスペックに依存すると思われる。実験段階では特に気になることはない。ただ、自動組版ってのは、1日に何千件、何万件処理する可能性があるので、構成的には、最低2台で余裕みて3台のサーバ構成でスタートしないと厳しいかも。
自動組版から考えると、もともとDTPで、「あとこういう機能ついてれば最高なんだけど、、、」というのが結構出てくる。総合的に「惜しい」ので、それが自動組版的にも物足りない部分になってしまっている。いや、それ必要？という意見もあるので、ここで判断する必要はなく、バランスを見る必要はある。
一番の魅力は、クライアントマシンのInDesginもAirとかで制御できてしまえば、サーバ側でやることもない、サーバでもできる、という選択肢が広がる。この辺に傾倒しすぎると、Adobeが神様になってしまうので怖い、というのがいつも不安なだけ。他がなかなか根本的な部分の見直しをかけない（業界が落ち込んでるからかけられない）なか、将来性のある組版エンジンだと思う。た、だ、InDesignをAdobeが「そろそろやめちゃおっかな」となった時点で、普通に使っていると、写●で味わった憂き目と同じ運命を辿るから注意。
しかし、Adobe製品、ソリューションが本社の米国で、かなり「形」になってきているので、すごく楽しみ。やっぱりフォトショやイラレ、ブリッジ、Flex、アクロバットなどなど、連携が始まっていて緩い結合が徐々にされていっている気がして、さすがだなぁと。

//番外　TeX
最強です。

///総合
自動組版エンジンの選択する際に関連する要素といえば、
１．テンプレートが如何に簡単に作れるか、管理できるか。
２．組版スピード
３．ガンガン送っても落ちない安定性
４．PDFが出るか
５．サーバ利用としてのAPIを公開しているか
６．組版がどこまで再現できるか
７．初期コスト、メンテナンスにかかるコスト
８．PDFを配置できるか
９．RIP対応の最終出力ができるか

上記をバランスよくみて、選択する必要があります。

あと、一番重要なのは、メーカーが「それ」用に、如何に準備してくれているか、につきる。
メーカーの協力がなければダメ、言い換えれば「協力してくれるメーカー」でないとダメ。

サーバ版というのは、あらたにサーバとしての機能をつける、というより、
DTPアプリとして開発した部分から、いらないところを削る、ということだけなんだと思うんです。

QXの記事がないのは、知識がなくて自信がないので、決して嫌いだからではないです。
DBパブリッシャーとかあったよねえ。。。

SkyEdit/SkyRIP-GT（自動組版ASP）について

SkyEdit/SkyRIP-GT（自動組版ASP）
サイトからしか情報がないですが、
・クライアントアプリで自動組版？
・RIPできる（1MB50円　従量課金）
・使用料1時間100円（クラサバでないなら、通信が必要なときだけなのかな）
とのこと。
ここで比較表を公表すると問題なりそうなのでしませんが、
なるほど、、、、そういう方法もありますね。
WEBアプリではないように見えますが、マージしたEXCELを一気に流す方法なんだろうか。。。

現在、WPSで最終PSが1P約15MB（カラー・アウトライン済み）...

RIP後が1bittTiffなら大容量だけど、アウトラインのRIP'dPDFならかなり容量が軽量化されるのかな。

60P×5MB=300MB×50円=15,000円×3回=45,000円×4週＝180,000円
（※でも画像もあって1P5MBってことはありえないだろな。。。）
※計算上間違っているかもしれないので販売会社に確認してください。

転送方式は何だろう？FTP?
あぁそうすると、FTPサーバで印刷会社さんがログインして拾えるようにした方がいいんだな。
（最終のみだけど）

原稿作成時の留意点をまとめたものを発見したのでメモ。
http://adv.nishinippon.co.jp/top/seisakuguide-seisaku3.html