第35回DTPの勉強部屋で「まとめて解る!InDesign自動化の全て」を再演してきました〜その1

1年ぐらいご無沙汰していたDTPの勉強部屋に行ってきました。

page2015のAdobeクリエイティブセミナーで講演した「まとめて解る！InDesign自動化の全て」を再演してきました。聞いていただいた方々ありがとうございました。

時間を30分に圧縮して駆け足だったので、少し解説を付け足したいと思います。
（書き始めたら量が多くなってしまったので、数回に分けます）

※後述でも紹介していますが、dproofsのクーポンコードを当日配布しました。
　使い方は、dproofsクーポンコードの使い方を参照してください。

今回「その１」では、以下を補足します。

• はじめに
• 段落・文字スタイル
• ワード取り込み
• タグ付きテキストデータの取り込み

…が、その前に、「フォーマットをつくる」を講義していただいた鈴木誠一先生のかつてのインタビュー記事にあった「資本主義が消費をあくまでも拡大し続けるのであれば，人間をどんどんわがままにしていく宿命を持っている。なるほどと思い…（引用：インタビュー 鈴木一誌氏に聞く『知恵蔵裁判全記録』「思想的事件」の全貌）」）」を読んだときに、自動化というものが、ただ趣味趣向のお遊び、やれたらやる、という類のものではなく、「やるべきものである」ということがしっくりきました。この辺りは、また別で書こうと思います。

1. はじめに

今回のテーマは、

• InDesignの自動化機能を知る
• InDesignを触らない人にも知ってもらうことでメリットが活かされる
• 自動化の先に何があるか

と、だいたいこんなところです。

InDesignを上手く使って、時間とお金を獲得しようぜ、ということなんですが、 そのためには、DTPオペだけだ知っている、使っているというより、営業も機能を知れば「こう作ろう」「こう直そう」「こういうデータをお客さんからもらおう」と考えることができたり、校正者も作り方がわかれば「ここを見れば良い」「こういう指示をすればいい」となり、それは効率化に繫がるはずです。

2. 段落・文字スタイル

レイアウトソフトにおいて、とても基本的なことですが、word（よく知らないけど）なんかに比べると、組版作業を楽にしてくれるようになってます。
大昔のソフトには、スタイルという概念は無かったですが、タグやファンクションといったものがそれをなしていたのでしょう。
今回は例として、ドキュメント内の特定の文字列に対してスタイルを当てられる正規表現スタイルや、自動番号付き箇条書きなどを紹介しました。設定しておけばInDesignが勝手にやってくれるので、できる限り組版作業のルール（仕様）をこのスタイルの中に入れてしまいましょう、ということです。

そのためには、前段の見本組などの仕込みとお客さんも含む理解が重要ですね。
ポイントは、この設定でいける範囲に仕様を絞り込まないと、ここからはみ出たところは手作業であり、リスクを伴うよ、ということがあります。

3. ワード取り込み（リッチテキスト取り込み）

ワードでもらって、InDesignに取り込んで、またワードで返して、InDesignに取り込み直す、という夢のようなことが果たしてできるのか？
今回は、この機能の精度がどんなものか実際InDesignを動かしながら皆さんと一緒に確認してみました。

1. まず、完成したドキュメントからリッチテキスト形式で書き出す
2. 検証用にpdfを書き出す
3. リッチテキストをwordで開き、doc保存（とりあえず何もせず）
4.  「3」のデータをInDesignに取り込み（配置）
5. pdfを書き出して、dproofsでチェック

この機能を信用できるかという質問を会場でしてみたところ、半数以上が信用しないということでした。
実際、取り込む時のオプションやテクニックが若干必要なわけですが、ちょっと当日は時間がなかったので、正解も解説しておきます。
上記1〜5の結果のPDFをdproofsにかけて出た差分が以下です。（ドキュメントは２と同じ）

なんか、違いますね。これが当日見せたものですが、以前YUJIさんの紹介記事にもあったような気がするのですが、スタイルパネルで「オーバーライドを消去」した結果が以下です。

「No Diff!」なので、違いなしです。
だから、100%信用していいよ、というわけではないですが、wordというアプリのバージョンとかOSとか、色々あるので、このように検証して、使い処によっては使える機能として知っておいた方がよいと思います。

4. タグ付きデータの取り込み

昔からレイアウトソフトにはテキストデータにタグを付けて、流し込むときに自動で設定させる機能があります。というか、ウン百万する組版ソフト達は、一人一台なんて大変だったので、そもそもそれを前提としていたと思います。
画面上でテキストを選択して、こちこちスタイルを付けるのではなく、

• 行頭にといったタグをいれる
• テキストフレームに配置

すれば、勝手にスタイルが付いてくれます。

これらのタグは、InDesign用となります。他にも色々タグがあるので、それを見たかったら、タグ付きテキスト書き出しをして調べてください。

これの何が良いかというと、InDesignが入っていないPCでも作業ができる、という点です。原稿がどっと入ってくるというようなことはよくあることなので、InDesignが足りないなと思ったら、テキスト作業を他の人にやってもらう、という方法がある、ということです。
pstyleとか入力間違えしやすいので、「★見出し★」とかで代用するとか、よくやりますね。

その1のまとめ

当日言わなかったですが、InDesignのこの機能を使ったら、こうなった、使えねえとか、そういう考えを減らしたい。
InDesign信者でも何でもないですが、そもそも月5,000円ぐらい？、そんな金額で手に入るようなソフトウェアであって、ソフトウェアを作る側からすると、だったらもっと高級なソフト買え、となるでしょう。
でも今はもう無理ですね。印刷業界のワガママに飽きて開発側が手を引いてしまっている。
こういう事態になっていることをよく理解して、もっとInDesignをシンプルに使って可能な範囲はここ、って割り切ってやることや、dproofsなどその他のツールを使って検証することも自動化や効率化に繫がる考えだと思います。

次回以降は…

• データ結合
• XML取り込み
• 検索置換
• スクリプト
• もっと効率化できないか、の考察
• 完全自動組版はアリなのか？
• IDMLについて
• IDMLでライトなWEB自動組版を
• 自動化のその先

となります。

書き切れるのかしら。。。

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

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

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

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

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

当日の資料は、こちら。

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

IDML BinderでInDesignからWEB入稿フォームを作る

先日紹介した「エクセルをアップしてInDeisign（IDML）をダウンロード」を早速、近所の印刷会社さんでネタ話してきたのですが、

デザインテンプレートとなるIDMLをアップロードすると、タグが入稿フォームになるよ

というのを書き忘れたなと気付きましたので、追記です。
※IDML Binderは、page2015 ブース（D-28）、クリエイティブセミナー（まとめて解る！　InDesign自動化の全て 2/5 11:40〜12:30）、カンファレンス（）【G2】Web to printの新展開＜Web上で動作する新たな組版エンジンの可能性＞ でもお話＆デモします。

 

つまり、

IDMLのタグ = 入稿フォームのフィールド = エクセルの項目

になります。

これは、先に開発を進めていたWPS4IDML（WPSのIDML出力版）の中にあった機能で、これを切り出してよりライトな仕組みからやってみようというのが、IDML Binder。
WEB上の入稿フォームというと、大がかりなデータベースを想像してしまうのですが、自分達が欲しいのは、掲載情報を入れる場所。それが、エクセルでくる、それをInDesignにはめ込みたいだけ。というようにシンプルに考えています。

タグ付けは、データ結合と同じイメージでいいと思います。
データ結合の場合、

• InDesignフォーマットを作る
• CSVを指定
• CSVのフィールド項目をInDesignのフォーマットにマッピング

となりますが、
IDML Binderの場合は、

• InDesignフォーマットを作る
• タグをInDesignのフォーマットにマッピング

となります。
データ結合の不便なところは、ドキュメントとなるInDesignとCSVとマッピングしたセットの情報が残らないので、一連の作業を一気にやらないといけないのが、
「いいんだけどイマイチなぁ。。。」 となるのですが、
IDML Binderは、テンプレートをあげておけば、項目名をもとに、InDesignとエクセルデータを紐付けしてくれます。
なので、項目名さえ合わせておけばいいということになります。
この辺りもデータのハンドリングが軽やかになっていいのではないかと思います。

是非ブースで見ていただいて、感想など意見交換できたらいいなと思います。

エクセルをアップしてInDesign（IDML）データをダウンロード

ずっと組版を自動でやりたくて、WPSが出来たことによって「入稿データをそのままサーバで自動組版する」というところは完結。

その後、「もっと自由度の高いレイアウトに対応して対象範囲を拡げたい」となって、WPS.3がそれを解決し、でもやっぱり「自動で組んだあとInDesignで触りたくもなる」という気持ちをWPS4IDMLが解決へと導きつつあります。

これらのアプリケーションは、10年の歳月を経て、色んなことを想定して改良を重ね、そして、たくさんの人たちに使ってもらえるようになりました。

WPS系列は、今ではかなり沢山の機能を詰め込んだサービスとなっていますが、世の中にはまだまだ大変な作業、非効率な作業を強いられている現場があることも事実です。

今日紹介するのは、デキタテほやほやの「IDML Binder」

いわゆるオンライン自動組版のアプリケーションです。

制作入稿したエクセルと、流し込みたいデザインがあるとき、どうしてますか？

コピペ？データ結合？プラグイン？

きっと、それぞれのやり方があることと思いますが、

エクセルを投げたら、InDesignデータが出来るなんていうサービスがあったらいいよね、

という話を前から言っていて、つい昨日見せてもらったのが今から紹介するアプリケーション「IDML Binder」です。

0. 準備

流し込みたいテンプレートは、IDML形式です。

データ結合で使うイメージで、タグを付けたInDesignデータを作成し、IDML書き出ししておきます。

また、タグに対応するエクセルも準備しておきます。

※テンプレートアップ後に、空のエクセルをダウンロードも出来ます。 

サンプルデータのイメージ

 

 

ちょっとまだURL非公開です。（page2015でお知らせするかも）

 

1. サインインは、googleアカウントで。

 

アカウントを選択すると、登録画面が表示されます。名前をいれて登録を完了します。

 

2. まずはプロジェクトを作る

ログインすると自分のプロジェクトが表示されます。
新規プロジェクト作成をクリックしてプロジェクトを作成します。

名前を付けたらプロジェクト完成です。 

 

3. テンプレートをアップロード

「テンプレート管理」をクリックして、IDMLテンプレートリストを表示します。

 

 IDMLアップロードに準備したIDMLをドラッグしてアップロードします。

アップロードが完了すると、リストに表示されます。これでテンプレート登録は完了。プロジェクトへ戻ります。

 

4. エクセルをアップロード

エクセルはIDMLのタグと紐付いていれば良いですが、最初から作りたい場合は、「記事データダウンロード」をクリックすると、空のエクセルデータをダウンロードできます。

 

アップロードするサンプルエクセル

 

 「Excelデータ取込」ボタンのあたりにエクセルをドラッグ＆ドロップしてください。

 

アップロードが完了すると、リストを表示します。

※データはすべて上書きされます。

 

5. IDMLをダウンロードして、InDesignで開く

上記スクリーンショットの「Edit」ボタンをクリックすると、データの編集ページを開きます。

「IDML生成」ボタンをクリックしてIDMLを生成後、「ダウンロード」ボタンをクリックしてダウンロード。InDesignで開いてみてください。

 

内容のデータを直したいときは、編集画面で、デザインを直したい場合は、テンプレートを変更して再度アップロードして、同じ手順で進めれば修正が可能です。

 

さて、これで何が想像できますか？

制作の効率化ってなんだ？とよく聞かれますが、ずばり「入り口と出口の距離を縮める」ことだと思います。

今回は、カタログのスペックっぽいものですが、フォーマットのあるページレイアウトなら何でもよいと思います。

例えば、

• エクセルをもらった営業さんが、これを使ってIDMLをデザイン担当に渡したら、これを調整しておいて、で済むかもしれない。
• そもそもエクセルをもっているお客さんが先にアップロードして、営業さんにIDMLで渡してくれるかもしれない。

などなど、「入り口と出口」が少しでも縮まるのではないでしょうか。

そして、これによって効率化のための色んな想像ができそうです。

「IDML Binder」は、今まで色んな事に取り組んできたけれど、もう一度やりたかった原点に立ち返り、今何ができるのか、今後どうなっていけるのかをイメージさせてくれる夢の詰まったアプリケーションだと思います。

これから「IDML Binder」をブラッシュアップしていきたいと考えています。

page2015のセミナーで紹介もしますし、ブースでデモもできます。

これからの制作効率化について是非皆さんと一緒に考えたいと思います。

page2015展示会に向けて

pageです。
印刷メディアビジネスの総合イベントです。
（開催概要はこちら ）

またそんな季節がやってきました。

出展情報を暫定版で更新しました。

この時期は、制作的には２〜３月下版、印刷、そして4月にはサイトリリースなんていう案件が目白押しなので、なんでこの時期なのかといつも思いつつも、他の時期も思いつかないのでよしとして。

来場する企業側的にも会場で決裁するわけでもないので、色々見て今後の参考にということであれば、出展社側としては、会期終了から半年ぐらいの長いフォローアップが必要となるのかなと。
ということは、展示会に至るまでの導線と当日のデモ、その後の営業活動やサイト告知なり戦略的にいかなければいけないのだろうと思います。

と、いつも思っていても、例年時間がない。
僕らはメーカーではないし、少人数なのでプロモーション専任もいない。
そして、そもそも営業がいない。
制作しつつ、開発しつつ、サービスのサポートをしつつ、
展示会の準備をするしかない。

しかし、良い事もある。
展示するものは、実戦で自分達が自ら使ってきたものだから、
ユーザーと同じ目線で話しができる。

原稿の催促や、バラバラな原稿を読み解いたり、繋げたり、確認したりする原稿整理の大変さや、
わざわざ面倒臭くなっている組版仕様との戦い、
どこにあるのか、もらったのかどうかも分からない画像の捜索、
いざ印刷入稿時に未知のエラー検証、
DTPデータをWEB用に取り出すときのあの何とも言えない非効率感、
丸投げ感満載の担当者との闘いは、
かなり多くの人と共感しながら話ができます。

なので、共感してくれた人を裏切らないように、
少しずつかもしれないけど、毎年進化していっているということを伝えたり、
これから先をイメージできるものを考えて、展示会に出すということを続けています。

今年は、例年以上に明確なメッセージを伝えられるのでは無いかと自分自身期待しています。

キーワードは、IDMLとAPIの活用です。
※IDMLのAPIという意味では無く別ものです。

眠たくなってきたので詳しくは次回に回しますが、InDesignデータとなるIDMLを現実的な線で、うまいこと制作の効率化に繋げられないか、
WPSのデータをAPIを使って取り出して別のサイト、アプリに持って行く仕組み（しずおかオンラインさんと共同開発）がメインとなりそうです。

ご期待ください。

そんなことより、お前、、、進行中の案件大丈夫だろうな。。。
と思われないように、勿論そちらも頑張ります。

【dproofs】制作現場に合わせたプランの選び方(1)〜フリープランを試してみよう

2013年5月1日に、校正支援クラウドサービス【dproofs】をベータリリースしました。

紹介ページはこちら

様々な制作現場で使っていただきたいので、

• フリープラン（無料）
• パーソナルプラン（月額1,980円） 2013年7月にスタンダードプランに名称を変更しました。
• オプションプラン

などいくつかのプランを用意しています。
※詳細については、公式のプラン紹介ページをご覧下さい。

1人で使っても良いですし、少人数の制作チームから大人数で使うこともあるかもしれません。より多くの人に使ってもらって、

• 安心できる制作、信頼される制作現場作り

に役立てていただければと思っています。

そこで、今回から、使い方や、どのような現場でどのように使えるのか、どのプランが良いのかなどを解説していきたいと思います。

まずはフリープランで試してみる

フリープランは、プロジェクト1個、プロジェクトにアップできるPDFは2ファイルまで、それぞれのPDFファイルは30MBとなります。無料ですから、このフリープランをうまく利用することをお奨めします。

アカウント登録は、こちらから
2014年2月追記）アカウントIDは、英数小文字のみです。

使い方1）まずは、プロジェクトを作る

最初は空っぽの状態なので、下の写真のように「新規作成」をクリックしてください。

プロジェクト名を設定して、「作成」をクリックすると、新規プロジェクトが作られます。

使い方２）初めてのPDFアップロード

水色の部分の「ココにPDFをドラッグしてください。」のところに、PDFをドラッグします。

きゅきゅっとPDFがアップされていきますので、しばらく待ってください。

ここで待ちきれずに、ブラウザを閉じたり、リロードしたり閉じたりすると上手く登録されない可能性があります。

時間帯や環境にもよりますが、この時には20MBが1分ぐらいでアップされました。

下のようになれば成功です。別のファイルをアップロードするときは、同じように作業してください。これで差分元となるファイルの準備ができました。

使い方３）差分をとりたいPDFをアップ！

ここからが本番です。そして、今のところお問い合わせNo.1の「で、どこにアップすんねん」にお答えします。

そうです。ここに重ねるのです。（もっと分かりやすくする予定※自分タスク）

また、きゅきゅっとアップロードされていきますので、ほっておいて次の仕事をしてください。次の黄色いバーが出てくるまでは、リロードしたりせずにお待ちください。

そして、そのまま次は、dproofsが頑張っている画面になります。

しばらくすると、差分があれば、下のように緑のボタン「Latest Diff PDF」が出てきます。（なければ、No Diff!と出てきます）

このボタンをクリックすると差分結果のPDFをダウンロードできます。

容量が大きい場合、前の画面で止まったように見えるときがありますが、200ページ20MBぐらいの差分出力が、約5〜10分程度（混み具合による）ですので、この目安でそれよりも長いなと思うときは、画面をリロードしてみてください。

アップロードが完了した状態であれば、差分処理に入っていますので、リロードしても問題はありません。

フリープラン制限の30MBでいけるのか

「30MB」という制限は、アップロードするPDFの1ファイル当たりの容量です。100P程度の文字物、ページ物なら30MBに収まるはず（経験値でしかないですが）。
ものによってまちまちなので何とも言えませんが、だいたいそのレベルだと思います。

チラシだとB4クラスで片面50MBを超えることもありそうですが、内校用と考えたときに、PDF作成時の解像度を下げておくなど、ファイルサイズを小さくしてください。

これは80MB制限の上位プランでも同じことなのですが、アップロードするファイルが大きなサイズになればなるほど、転送時間、差分生成時間がかかります。これが生産性を下げてしまってはいけないので、できるだけ軽くするように考えてください。
※それなりの高精細で運用したい、という場合は別途ご相談ください。

そもそも1ドキュメントで大量ページや大容量の写真は制作で扱いにくい

InDesignで100Pの文章ものって、ちょっときつい。ページものに強いとされていたEdianでさえ、実際には多くて50Pぐらいだった気がします。

ドキュメントを開くのも遅いし、ページ移動も結構大変。
どうしても1ドキュメントとして扱いたい場合を除いて、大抵は章ごと、節ごとでドキュメントを分割していると思います。

写真点数が多い場合も同じで、マシンスペックが良くなったとは言え、チラシなどで1P100点以上の実画像を扱うのは結構大変です。
そういった問題の解決策もありますが、要望があれば、また別の機会に紹介します。

30MBでは足りない？

パーソナルプランへの移行（80MBまで可）を考える前に、PDFを２つに分割してアップしましょう。フリープランはプロジェクト1個の中に、２つのPDFをアップすることができますので、事足ります。

プロジェクト、ファイル制限を超えないように消す!!

フリープランは、プロジェクト数１、アップできるPDFが2と、制限があります。案件を1人で同時に沢山扱っている場合には、パーソナルプランへの移行が賢いかもしれませんが、無料で貫きたい場合は、終わったものから消して、必要なときにアップするという手もあります。

制限は、あくまで現在の暫定数値です

みなさんのご意見を聞いて最適なプラン設定を考えますのでご相談ください。

次回は、もう少し具体的な例としてチラシ制作での使い方を書きたいと思います。

InDesignを「連続で開く」「何かする」「上書き保存して閉じる」スクリプト覚え書き

連発で何かしたいことがよくあるので、メモ。

制作現場でさくりと使いたいので、下記の例では、例外処理とか何もしてません。

とりあえず開くファイル名は、CSVで与えるとする。
フォルダを選んでその中にあるファイルとかありますが、
ゆくゆくファイル名以外の情報も与えて与えてそこだけ何かするとかにも使いたいので、
こんなプランにしてます。
※例えば、ファイル名,50-53とかでページ数を与えて、そこだけプリントするとかね。

CSVの取り込みは、配列にさくっとしてくれる「CSVData.js」を使用。

下記サンプルは、
・CSVで与えたファイルを開いて、
・「す」という文字を探して、
・文字スタイルを変更して、
・上書き保存
するだけ。。。

#include 'CSVData.js';

var csvFile = new File('data.csv');

if(csvFile.open('r')){
  var csv=csvFile.read();
}

var fileList = CSVData.parse(csv);

for (i=0;i<fileList.length;i++){
  fileObj = new File(fileList[i]);
  app.open(File(fileObj));
  app.findTextPreferences = NothingEnum.nothing;
  app.changeTextPreferences = NothingEnum.nothing;
  app.findTextPreferences.findWhat = "す";
  var myFoundItems = app.documents.item(0).findText();
  myFoundItems[0].select();
  myFoundItems[0].appliedCharacterStyle= "あか文字"

  app.activeDocument.close(2036691744,fileObj,"",true);
}

上書きしますからね。テストとかするんだったら気をつけてくださいね。
怖かったら、

app.activeDocument.close();

としときましょう。確認ダイアログが出ます。

もうちょっとはしょってみると

#include 'CSVData.js';

var csvFile = new File('data.csv');

if(csvFile.open('r')){
  var csv=csvFile.read();
}

var fileList = CSVData.parse(csv);

for (i=0;i<fileList.length;i++){
  fileObj = new File(fileList[i]);
  app.open(File(fileObj));

  //やりたいことを書く

  app.activeDocument.close(2036691744,fileObj,"",true);
  // or app.activeDocument.close();
}

※ちなみにこれCS3でやったものです。

ADOBE® CREATIVE SUITE® 5 デザインセミナーツアー in 名古屋で「テクニカルDTP」を紹介

2010年5月18日名古屋ミッドランドホールにて「ADOBE® CREATIVE SUITE® 5 デザインセミナーツアー in 名古屋」が開催されました。

地元企業として20分のセッション枠が用意されたので、「テクニカルDTP」を紹介させてもらいました。
CS5の発表のために集まった300名近い人たちを前にしたとき、なんてぇ安請け合いをしたもんだと反省。

CS5の話を聞きに来たのに、、、と思ってる人もいたんだろうな。。。まあしょうがないね！

当日話しきれなかった、伝えきれなかった内容を、ここに書いておこうと思います。
※当日の資料はこちら。
テクニカルDTPというと、スクリプト使ってとか、自動組版とかの話でしょ、とか言われると困るのです。
それはあくまで、そういうこともできるよね、というだけのことであって、
もっと制作という部分にスポットライトをあてるべきだ、というところなのです。
またまた長い戯言。お付き合いいただけそうな人は、付き合ってください。

テクニカルDTPについて、20分で語れるものではないですが、せっかくAdobeさんのセミナーなので、

１．どんなにソフトウェアが良くなろうとも、使う側がその価値を理解して、その価値を対価に変えないといけないよね、
２．僕ら制作側（ソフトウェアを使う側）の人たちは、その価値を理解する必要があるし、
３．対価によって得た価値を、今度は自分たちの対価に変えていかないといけないよね、
と、いうことが言いたかったんです。

そうしないと、制作は環境も良くならないし、給料も良くならない。
ソフトウェアを出すメーカーさんも買う人がいなくなれば、オープンソースにでもしない限り続けられない。
作る側、使う側が共存できる関係になければ継続はない。
素晴らしいソフトウェアを開発する人たちも、それを使ってクリエイトする人たちも、みんないなくなる。
であれば、今、この時代はなんなんだと。僕らがやっていることはなんなんだ、ただただ衰退に向かうだけのことなのか。

どれだけ「お求めやすく」なったからって、金はかかる。
Adobeさんからして、開発してバージョンアップするにも金はかかるから、その価値の対価を求めているわけで、
僕らは制作という中で、価値を高めてその対価を要求すべきである、と思う。
そういった努力をせずして、現状に甘んじるのは負け犬だなと、自分に照らして思うわけです。

印刷費の中に制作費がコミコミなる時代に慣れすぎている僕も含めた制作側の人たちは、
作ることに自己満足しすぎて、そしてやりすぎている（時間をかけすぎている）部分もある。
クリエイティブでありたいならば、価値を対価に変えるべき。変えていくべき。主張すべき。
何も間違っていないと思うのだけど、どうなんでしょう。

勘違いしてもらうと困るのは、金を出せ、といっているのではない。
限りあるお財布と、でも今後こうしていきたい、というようなやりたいことがあるのなら、
順番にやっていきましょうよと。
今は、ただ作るだけ、その場しのぎの積み重ねが、今の状態を作り出していると気付かないといけない。

制作の仕事は、直接その版元となる会社から請けることもありますが、まだまだ印刷会社からお仕事をもらうことが多いのが実情。
印刷会社に比べれば、営業の人数は圧倒的に少ない。うちなんて一人もいない。
でもそういう会社だからこそ、「制作＝物作り」を真剣に考えて生きている。
情報を伝える手段として、紙が減っていく中、ユーザー自身がその情報を得るデバイスを選択する時代に、
それを主に考えている人たちのビジネスにぶら下がって、コスト削減要求に応じる必要なんてあるのでしょうか。


営業が「ああ、そんなら他でやってもらうからいいや」「お客さんがここまでしか出せない」と言うならば、
それが、全うであると諦めるしかないのであるなら、そこに未来はないでしょう。
彼らは、その価値を対価に変えようとは何も思ってないということです。
ただただ価格競争に勝つために値下げを受け入れる。
お金を出す側、請ける側、作る側というところの変な上下関係が続くのであれば、この先、紙の世界なんて存在しないでしょう。
それは、「紙」を必要としないから、というわけではない気がします。

別に営業さんだけが悪いわけでもない。その価値を伝えられない、対価に変えられない体制、それを作り出している業界自体が悪いということになります。

オペレーターも、営業さんも、経営者も、お客さんもみんな悩んでるのに、
ポイントがずれている。
自らそうさせている、というところに全体で取り組まないといけない。

その不合理さ、矛盾を一番押しつけられるのは、誰ですか。結局、末端の制作です。
システム開発でいえば、プログラマです。

物が出来た後で、何か言おうとしても遅い。
出来てしまえば、彼らはというか自分も含めて、その苦労、こうした方がいいんじゃないか、ということは
きれいさっぱり忘れてしまいます。

作っているとき、その工程の最中（原稿作りから、DTP、校正、プログラミングなどなど）にこそ、
今の課題をクリアするためのヒント、次の時代へのヒントがいっぱいあるわけです。
だから、制作という工程を大事にしないといけない、ということなのです。

だって、確実に紙は減っていくんです。
ならば、制作の人たち、クリエイトすることが好きな人たちは、情報を提供する側のひとたち（出版社であったり、著者であったり、編集の人たちであったり）ともっとどうすべきかを一緒に考え、違う方、別の未来へ向いていってもいいと思う。
もっともっと、ものを言っていいと思う。

さてさて、みなさんどうお考えになりますか？

「テクニカルDTP」第1回勉強会 無事終了

2010年3月20日ニューキャストのセミナールームで、テクニカルDTP勉強会の記念すべき第1回が開催されました。

お題を一切決めてませんので、適当に開始されたわけですが、
参加メンバーからして特に心配することもないなと思いつつも、
どうなるかしら、という一抹の不安も抱えつつ開催したのでした。

テクニカルDTPとは、tyamaさんによる命名ですが、その意味を私なりの解釈で解説すると、DTPというもの自体に写植や製版などいろんな意味が込められ、まして今はワードもDTPとして存在するわけで、そんな中、従来の情報処理的な組版というものがその中で陰を潜めている感があります。しかし、これから時代はまさにこの部分が脚光を浴びなければいけません。それこそ、テクニカルDTPという発想は、Webさえも包み込むものだと考えています。Publishのためのデータは、印刷、WEB関係なく、データ作りという点において、テクニカルな手法が必要だということを広めていきたいと思っておる次第です。（多分概ねそういうことだと）

当日は、15名＋αのメンバーが集まり、14:00〜18:00のタイムスケジュールで開催されました。


まずは、自己紹介から。
それぞれ自分が今やっていることなどしていただきまして、
だいたいどういうメンバーか把握できたところで、山本氏からスタート。

セッションテーマ１　IDML
山本氏「TwitterアカウントからIDMLでInDesignで名刺を作ってみる」
ブログはこちら

PAGE2010の頃に、ちゃちゃっと作ったやつですが、IDMLのこういう使い方もあるんだというのをデモしてもらいました。Web入稿されたデータからどうやってIDMLに落とし込むかというところで、議論がなされたのでした。

セッションテーマ２　電子書籍
YUJIさん「自分の本を電子書籍にしてみる。そしてiPhoneとかも」
まだ、実験段階ということでしたが、最近いろいろと挑戦している電子書籍（EPUB形式）とか、iPhoneアプリなどなど、現状と今後についてお話していただきました。
テクニカルDTPという分野が、一般的に言われているDTPと、WEBとを融合させるためには、絶対に必要な気がしてきたのでした。

セッションテーマ３　Script
カネムー「IllustratorのScript作成Tips〜ExtendScriptを自分はどう使って書いているか」
実際、どうやって書いてるかをとつとつと説明してくれました。スゴイ結果も、地道な作業で組み立てたコードで実現しているんですよというところがカネムーらしいお話でございました。
ブログ

セッションテーマ４　XML　GoogleAPI　翻訳
大島さん「XML＋GoogleAPIを使ったなんちゃって翻訳」
いまいろいろ一緒に動いてもらっている大島さんです。翻訳にGoogleAPIを使って、XMLを翻訳してしまいましょうという遊びネタです。遊びといっても、こういうやり方もあるんだよねと。そして、いつかそうなっていく、というのを今まで体感してきたわけですので、今はちゃんと出来なくても、これからの技術の基本になるかもしれませんね。

セッションテーマ５　InDesign　XML　多言語展開
大島さん「InDesign + XML による即効多言語展開」
多言語というと、FrameMakerがまず浮かぶわけですが、ここはひとつInDesignでということで挑戦したデモでした。次のセッションにも関わってきますが、データに自動的にタグ付けを行うという発想。そこまで出来ればFMと同等になれるわけなので、そこにInDesignを使うことで自由度が増す（んじゃないかと）。FMも人口が減ってきてそうなので、今なら、InDesignでも代用できるんじゃないの？ということでした。

セッションテーマ６　InDesign　データ解析　データベース
大島さん「DTPデータを解析しながらデータベースを作る」
このセッションは、ニューキャストネタですが、うちのカネムーとともに大島さんにもいろいろ手伝っていただいて形にすることができました。何より説明がへたくそな我々なので、お任せした次第です。
かなりの反響でその後もしばらく話題の核になりましたが、InDesignのデータを解析しながら、データベースを作っていこうというもので、既存のプロジェクトで苦戦している方々には、目から鱗的な手法です。
この辺をオープンにする太っ腹さを感じていただければ幸いです。
こういう風にでもしないと、業界の技術の底上げなんぞできません。
これが一番だとは思いませんが、いろんな技術がどしどし世に出てくることを期待しています。

第2回も4月後半か、5月にはやりたいなと思ってます。
正直ここまで反響があるとは思わなかったのですが、
下記Googleグループでも開催情報など流していく予定です。
Googleグループ「テクニカルDTP勉強会」
※ユーザになるには申請が必要です。

ということで、テクニカルDTPをどんどん広めていきましょう！

InDesignをiPhoneのStanzaで読める電子書籍にしてみる

ざっくりですが、、、、

InDesignCS4で、「Degital Editions用に書き出し」というメニューからePub形式に持って行けますが、iPhoneの電子ブックリーダーのStanzaにそのまま持ってこれるかなと思いきや、エラーで持って来れず。。。

なので、とりあえずうまくいった方法を。
１．InDesignCS4→「Degital Editions用に書き出し」でとりあえずePub保存する
２．ePub形式のデータを作ってくれる「Sigil」で、１のデータを開き、Save asで保存しなおし。
３．先に「Stanza Desktop版」をインストールしておいて、それで２のデータを開く。
４．iPhoneでStanzaを開き「ライブラリ」→「共有ブック」とタップすると、「Books on 某」と出てくるので、そうすると、３で開いているデータが出てくるので、それをダウンロードする。
※InDesignから書き出したデータだとここでエラー。
５．取り込み完了すれば自分のiPhoneで見れる。

ということで、なんとなくInDesignからiPhoneで読める電子書籍にできると。

今後例えばですが、AdobeからInDesignで書き出したデータを「うまいこと」持って来れるような繋ぎのツールが出てきたりすると、すごく加速しそうだなと。リーダーとかもですが。

それとInDesignで作ったデータを電子書籍にする場合、というかePubにする場合、作るときに想定した作り、例えば、タイトル、見出し、箇条書きなど、表現しやすい、持って行きやすい作り方にしておくのは重要と感じましたね。
※ちなみに、合成フォントはブブーとなったり現時点ではしています。

DTPにもテストという概念がますます必要なんじゃないかしら

DTPってある意味、システム開発でいう「アジャイル」な方式で出来ていくものだという話をこの前していた。

ここはやっぱりこういう機能が欲しい＝ここはやっぱりこういう文面にしたい

これは完成物を見て出てくる意見（欲求※要件、要求ではなく）であって、僕はそのケツを決定するもの、もしくはそれをやるかどうかは、時間（割り当て可能な時間）だと思ってるんですが、この作業の積み重ねで出来ていくものとすれば、同じような感覚が必要だと考えられます。

反して、ウォーターフォールな方式でいけるかというと、DTPは無理。言うなればシステム開発も無理。
DTPにいたっては、「これ追加」「これ変更」は当たり前であって、それがあるからこそ、DTPの仕事があるわけで、それに対応しません、ということであれば、職自体必要ない。だって、それはただコンバートしただけだもんね。

「無いもの（見えないもの）」を作り出すということは、その目指す先の「有」は、だれも見たことがない。だれもそれが完璧だという姿をなんとなく想像はしていても固定的に限定的に指し示すことはできない。なんとなく自分の想像に近いところで、OKを出すしかない。

だから、DTPもシステム開発もクリエイティブな世界なんだと思うのです。

だからこそ、作り手は、お客さんの想像から、創造しなければいけない。
常にプロフェッショナルな立場からそれを作り出すという関係で成り立つものだと思うのです。
だから、色んな便利なツールとか沢山あって、誰にでもできるんかというと、そうではなく、やっぱりそれが成り立つには相当な努力をした人たち、それが好きな人たちだけが生き残っていく世界なんじゃないかと。

話逸れますが、先日美容院の年下の店長が言うとりました。
たまたま美容院関係を目指す人向けのフリーペーパーがあって、その話題の中ですが、
「美容師ってさ、結構目指してる人多いよね？専門学校とかもあって」
「いっぱいいますけど、結局なれるのはホント一部だけで、みんな対外辞めていきますね。」
「ネイルとかはやってるっぽいじゃん」
「誰でもできるようになっちゃって、どんどん値が下がっちゃって、今やっていけなくなってるみたいですよ。僕らは値段は下げないんですよ。そもそも誰でもができるものではないんですから。」

これを聞いて、ああこいつもクリエイティブな世界のプロなんだなと。そして厳しい修行に耐えて今があるんだよなと思ったわけです。

んでんで。。。話戻します。

僕らの世界に戻すと、どちらかというと完成したものにクリエイティブさを求めるのではなく、その作る過程において求められるものとなります。
だって、DTPでいけば完成したものはレイアウトされたページだし、システムでいっても、使う側からすれば、別に中身のソースコードが綺麗かどうかなんてのは関係ない。

ただ問題は、どう作られたかが重要で、ちゃんと出来ていなければいけない。
DTPで言えば、間違いがない（印刷トラブルになるような要素も含む）かどうか、
システムで言えば、ちゃんと動くかどうか、
両方ともお粗末なミスを含んでいるようではプロとは言えない。

それには、作り方が非常に重要ということで、DTPにもその品質を担保する「テスト」という概念への取り組みが必要だと思うのです。

そのテストは、
・最初の要件では、前述通り決められないので、随時変わっていくもの、足されていくものというのが前提
・プログラム的チェックが可能か、目検が必要かを振り分けをする
・テストが通るように作る
・テストして、それが通ってから初校、再校ごとに納品する
というようなことを考えています。

印刷のためのプリフライトチェックとかありますが、それも含まれます。
しかし、その内容まではチェックされません。
データなんですから、今後は、もっと内容まで掘り下がったチェック（文字、文言とか、画像、著作権とかもあるかも）が必要とされると思います。

それから、もう一つ、なんで必要かという理由になるものは、電子書籍やコンテンツの再利用など、今後「データ」としての扱いが重要になってくるということです。

なので、印刷は、その出力方式の一部でしかなく、当然その品質を保つことも重要ですが、今までのように「印刷ありき」という考え方から、徐々にシフトできるところから「データありき」という認識に変わっていくと思われます。

僕らは印刷にするところが得意だというアプローチから、その制作の仕事をいただいているわけですが、ただ出来るというわけでなく、プロフェッショナルに展開できないと意味がない、ということだと思うのです。

著者が書いたTeXは出版物の制作現場で有効に使えます

「雑な物づくり」に未来があるを読んで思ったこと。

なんか、我慢できないので他の保留記事をさしおいて早速投稿します。
この記事を書いた方ではなく、TeXが使えないと言っている出版業界にです。

「少なくとも電子原稿は、「手書き原稿の山」なんて状態に比べれば、出版社の人も圧倒的に楽できるだろうなんて思ってたんだけれど、手間はそんなに変わらないらしい。」（前出より）
これは間違ってますよね。
使い方によっては、「圧倒的に楽」で合ってます。少なくとも「楽」です。

まったくもう。。。

ちょっと間違いを正します。
このままだと、著者が書いたTeXは出版物では使えない、なんてことになる。

誤「原稿は、今のPDFからテキスト部分だけを抜き出して、それをDTPソフトで再編集」（前出より）
　↓
正「いただいたTeXからスタイル情報を（例えば）InDesignのスタイルに置き換えて再現」
※とかね

ここでフォントの影響で文字の送りが変わるかもしれないので、一度著者に確認したり、合わせて、文字化けが残ってないか確認してもらう。まあ、ここでプロの編集者の方の朱入れが入るかもしれないです。
ここが自動でいけるようなら、修正はもとのTeXでしてもらうとかもできますよね。

誤「TeX の図版はそのままだと使えないので、これはイラストレーターで全部作り直したうえ」（前出より）
　↓
正「一度、図版全部ください。保存形式、画質によっては作り直しになると思いますが、素材としては有効です。」

誤「ページの相互参照が200箇所ぐらい、索引が300箇所以上あるんだけれど、こういうのは全部「手」でやるんだという。」（前出より）
　↓
正「定義されたものを上手く使えばそのままいけるかもしれないですね」

加えて言うなら、TeXで書いた数式とかも再現できますよ、DTPアプリによりますが。

データをみないと、最終的にどうなるか、どう言えるか分かりませんが、まずは解析してからです。基本的に、あっても変わらない、なんてことはないです。

通して読めば、「雑な物作り」で出来たものこそ、コンテンツとして高品質な素材であって、「プロの物作り」と言っている方は、今までの体裁に拘った「無駄な物作り」なんじゃないかしら。それによって、かえってコンテンツの質の低下に繋がらないか心配です。
なんなら、TeXの方がよっぽど高品質だったりするんじゃないの、とも思います。
※そうなると仕事が減るのであんまりいいたくないですが。

本物のプロの物作りは、一般の人が作ったものをちゃんと印刷できるように、その人が納得いくレベルで仕上げるところに付加価値があるわけであって、使える素があるなら、それを最大限に活用して、効率よく作ることなんじゃないの。間違ってますかねえ。

もし、100％いけたら、TeXを管理すれば、改訂のときもそのまま使えたりするとか、めっちゃ便利になりますよね。著者と出版社が協力して、そこを目指すべきだと思います。
※ちょっと古いけど、こんな感じで。大好きな本（アジャイルプラクティス）がこうやって作られたのは嬉しいです。

だって、「たとえばそれを電子化したいなら、LaTeX ならhtml の出力も簡単だから、こういうのが、少しは役に立つだろうなんて考えてた。」（前出より）、これ合ってますもん。

もちろん、出版社の方のプロによる編集作業で、文章を整えたり、分かりやすい表記するとかプロデューサー的なことというのは、重要なことです。それこそ僕にはできません。でも、著者が作ったTeXをうまく使えば、自分たちも楽になるのに、ということが理解されていないのは非常に残念です。

出版不況だって言いながら、こういうポイントを外すのはどうかなと思います。
制作会社はもっと厳しい。せめて無駄なことはさせないで欲しい。無駄なことをしないで済むなら、いくらでも協力しますよ。テストとか。

TeXに限らず、今は一般の人でも、プロが使うDTPアプリもしくは同等アプリを使って原稿を書くことができる。そういう時代なんですから、コンテンツの価値を高めるために、書く、編集する、制作する、印刷するというそれぞれのパートではあるけれど、どこに向かうのか、何を目指すのかを、一緒に考えないと、いつまでもこの不況からは脱出できないと思います。

DTPの勉強部屋 第14回に行ってきました

昨日Twitterで、ブログ３本かかなきゃと言い放った後、爆睡zzz
お昼近くに目が覚めたとき、今日が何曜日か分かってなかったので、そうとう深いところまで行ってたと思います。帰って来れてよかった。。。

せっかく、浅田さん（psychocatさん）が、このブログを紹介してくれたのに、「ザリガニ釣り」の話だと「？？？」になってまぅーっ、、、はい、ということで。。。

なんと80名ぐらいですか、すごい人数集まってましたね。

セッション１．DTP作業を楽にするスクリプト入門

発表者：たけうちとおるさん（遊文舎）

現在、InDesign、Illustratorのスクリプトが50個ぐらいになって、
たけうちとおるのスクリプトノートからダウンロードできます。

そのスクリプトを1個ずつ、丁寧に解説してもらいました。
「へー…」と思いながら聞いてましたが、たけうちさんて、仕事もしながら、こういうのまとめてるんだよな、、、と。スクリプトを書く人は沢山いると思うんですが、ちゃんとまとめて、そして人前で紹介するというのは、、、よっぽど好きじゃないとできないですよねえ。

こういったスクリプトって、結構「使い捨て」になる可能性が高い。
だから、上手く出来ても自己満の世界で終わる可能性も高い。
スクリプトを書くこと自体は、それほど技術的にスゴイスキルが必要というわけではない。
誰でも「やろう」と思えば、絶対にできる。スゴイのは、実作業の経験、現場経験の中で、「やろう」「やってみよう」と思って実行に移せる実行力だと思う。多分好きか嫌いか、興味があるかないかの違いです。
その時には、時間がかかってしまうかもしれないけれども、経験を積めば、足し算できるものだから、徐々に効率は上がるはずです。

たけうちさんやせうぞーさんなど、参考にさせてくれるサイトもあるので、勉強するには敷居は低いと思います。まずは自分で試しながら、そのうち、ユーザーインターフェース（たけうちさんのはやっぱり経験豊富だからぱっと見使いやすい、使いたくなる）も洗練されてきて、使いやすくできれば、他の人にも喜ばれるようになると思います。DTPオペレーターは、仕事柄お隣の席に座っているオペレータとコミュニケーションするのもなかなかできない気がしています。そういうコミュニケーションのツールとしてもいいんじゃないかなと、あの大勢の参加者を見て思いました。

最後に見せてもらった、Rubyで作ってるのかな？Word→XML→InDesignタグテキスト出しする仕組みも面白かった。まずはクライアントで動くスクリプトを作って、それを活かしていけば、WEB入稿の仕組みを作ることも今はそれほど難しくないと思います。皆さん、というか僕もですが、もっと進めていきたいですね。

セッション２．自動組版のはじめの一歩

発表者：Psychocatさん

まずは自動組版とはなんぞやということについて、メーカーではなく、ひとりの現場の人間としての意見をまとめておられました。共感できる内容ばかりで、「自動組版」という言葉に踊らされてしまう、だまされてしまう、そういう幻想と現実について1時間ぐらい。いろんなところで、自動組版に関するセミナーとかありますが、こういう話がまず最初に語られるべきであって、製品紹介とか事例紹介とかいらないと思います。ほとんどの場合、現場に合わない。よいツールであるとは思いますが、結局何もしてくれない。大事なのは、その仕事に関係する人たちの「考え方をまとめていくこと」であって、、、そのあたりは、前に書いた気がするのでこの辺で。

懇親会で聞いたのですが、今おいくつか忘れましたが、プログラムを書き出したのは37歳からだそうです。そこから、AppleScript、Perlなどなど自分で勉強、実践しながら、ここまで来たそうです。スゴイですね。
当日の内容は、ここにあります。後半はこの内容に沿っていろいろとエッセンスを教えてもらいました。僕は実際試しながら聞いていましたが、とっても面白かったです。スクリプトだから、動かせばその場で結果が見える。そういう手軽さはDTPにとっても必要です。設計書なんてものはないんですよね。ハハハ。ここだったか、うちが最初に仕様を書かないのは。。。確かにこの手のものは、パッケージ商品にすることは難しいんですよね。あまりにパターン（レイアウトという意味じゃなく）がありすぎる。

まとめ

お二方の作ったものを垣間見ることができましたが、どちらも「相手が思う一歩先まで考えている」ということです。たけうちさんもPsychocatも、やりたいことに対して、こういうものが必要だろうとか、こういうときはこうするべきだという、現場経験から出てくるアイディアであったりするので、現場に採用されるのだろうと思います。
「現場のものは現場で作る」という発想は、幻想ではなく当然のことだなと思いました。
Psychocatさんが懇親会でちらりと仰ってた言葉で、「もし自分が作ったプログラムで何かおかしい結果を生んでしまったら、自分で全部直す。。。プログラムでね。」という気合いと責任感。この人はプロだなと思いました。

懇親会で見た風景

居酒屋なんすけど、、、たけうちさんによるNDD（飲み屋ドリブン開発）。
いいですねえ。今度は最初からお酒ありでやってもいいかも、ですね。飲みながら何か作る。
Grailsの忘年会のときやりましたね、そういえば。面白かった。

・関係ない話
今日はお子さんのお友達のおうちがやっている中華料理のお店に行って来ました。
麻婆豆腐絶品。四川なのかな、一瞬辛いんだけど後を引かない。日進市の「八兵衛」です。行くときは声かけてください。一緒に行きます。もちろん、アンタのおごりでね、、、はい、おやすみなさい。

GC中部の広報委員になったのでした

かなり前に、写植組合みたいなのには参加していた気がします。
JP＠大阪で流れに身を任せつつ、二つ返事で入会。新参者は何でもやって目立たねばならんという家訓のもと、広報委員もやらせていただくことに。

ちなみにGC中部というのは、正式名称を「中部グラフィックコミュニケーションズ工業組合」と言います。写植・製版の会社の集まりで、印刷を主とする会社ではないのです。

チャリで10分ぐらいで委員会打ち合わせ会場へ。

うーん、たまに見るビル。ココだったのか、、、


ちゃんとありますね。。。

今まで、本拠地名古屋で業界的繋がりがない中で、そういう輪に入るのが苦手だった20代中盤からすると、オレも大人になったもんだと。しかし、リュックを背負って汗ダーダーでお腹が気になる36歳は、立派なオッサンだなとも思うのでした。

ここ最近は、自社のことを考えると、行き着くのは、もっと周りと一緒に、周りを巻き込んでいかないといけないなと思い始めたところでした。今の考えや、やりたいことが正しいのかどうか…そういうのは、もう少し行動範囲を広げて、意見を言ったり、聞いたりしないと、分からない。中途半端でほっておくと、多分、「ま、いいや」とか「どうせ」とか愚痴になってしまって、一歩下がって見ていることになる。そういうのが嫌いというか、後悔し、自己嫌悪に陥るのはイヤなのです。と言いつつ、ずっと自ら蚊帳の外であったわけですが。。。

委員会6名中、3名が同年代だったのですが、関東ではまだまだご年配の方がほとんどの組合もあるとか。中部は比較的若返りしている会社が多いとのことで、何かできるかもしれない、変えられるかもしれないという私自身期待を膨らませるのでした。

会合のあとは、ラーメン屋さんというか中華屋ですよね、で雑談。最後の「涼麺」は上手かったです。

学参のDTP・組版をどうするか〜大改訂に備える

「学参の波」は、じわじわと忍び寄ってますが、実際どうなるんだろうということで、現時点でちょっとまとめてみます。

１．「学参」とは…

「学参」は、「学習参考書」の略。多分。
教科書を元にして作られる本です。本屋さんに並んでいたり、学校で配られたりする本です。
教科書の内容は、文部科学省による学習指導要領が何年かおきに改訂されます。
それに伴って、学参書籍も改訂したり、新しく作ったりします。

２．「白表紙」について

教科書を巡る問題は度々報道されたりしていますが、その中でも白表紙問題というあります。「白表紙」とは、教科書検定に申請する申請本のことを意味しています。
参考書や問題集などは、教科書と一緒のタイミングで必要となります。
以前は、この白表紙をもとにして、学参書籍の本作りを進めて、その教科書が検定に通って、多分そこからちょこちょこと修正が入って完成するわけですが、それに合わせて、学参書籍も修正して発行すると、そういう流れだった（…らしい。出版社の人間ではないので詳細は分かりません。）のですが、この白表紙にあたる書籍の内容を検定前に公開する行為が、出版社による教科書の宣伝行為だと、いう話になってしまって、検定まで外部へ出してはダメということになりました。※その他利用もあると思います。
これによって、学参系出版社は、作りたくても、元の本が手に入らないために作ることができないという状況に陥っています。
「公開されてから作ればええやん」と思うかもしれませんが、なんせ時間がないのです。
まあしかし出てこないのは出てこないので、さてさてどうするか…

学参組版の課題・問題点（制作会社という立場から）

この辺から、制作の立場での意見になります。
最初に現在考えられる課題・問題点をまとめておくと…
１．制作期間が極端に短い
２．制作できるところ、人が減っている
多分現実ダブルパンチ（おお、懐かしい響き…）です。
学参組版にもいろんな種類があるけれども、一般書籍と違ってそれなりの技術と経験が必要とされます。なので作業は結構時間がかかります。
しかし、現実的、物理的な「時間」あるいは「コスト」という制約がある以上、次のことを考えなければいけません。

今、何をすべきか

「短い時間（短期間）で、効率よく（省力で）下版までもっていける制作フローの確立」
「省力って、手を抜くんかい」と思うかもしれませんが、そうではなく、原稿作りから、やりとりの手間、印刷工程までスムーズに流す、ということであって、決して適当にやるということではありません。
「少ない力で高い品質の組版を実現する」ということであり、今やらなければいけないことは、やるべきことは、この準備です。

「自動組版」、「XML」は解決策じゃない

「省力化」というと、ついついこういう発想にいきがちです。
「自動組版」は、頭からおしりまで、すっぽりと収まらないと意味がありません。
ちなみにWPS（情報誌の自動組版システム）は、すっぽり収まってますが、多種多様、組版の性質からして、これに当てはまるとは言えません。まして「XML」なんていうのは、何かに使うときに考えることであって、使える状態でデータが揃っていないという今、考えるべきことではありません。

まずは情報を整理してデータを集めましょう

改訂本にいたっては、製版以降で修正している可能性もあって、DTPデータと最終データがイコールであることも疑わしい状況です。ちゃんと管理しているようでも、実際のところできていないところが多いと思いますが、これには理由があります。
「環境が変わりすぎ」なのです。組版が専用機で行われていたときは、外部環境との関係が、悪く言うと「孤立型」「親和性がない」、よく言うと「依存しない関係」にありましたが、現在はどこでも買えるPC上で動くので、OS、ソフトウェアなどなど依存する部分が多い。
こういう環境下では、どう管理するかも変わってきてしまうので、だったら、とりあえずデータをここに置いておこう、という程度しかできないのです。
整理できていないという前提のもと、一度ちゃんと表に出してみて、整理し直すのが第一歩だと思います。

失敗や苦労を繰り返さないために〜コンテンツを無駄にしない

学参のコンテンツは、使い捨てのものではありません。編集者の方たちが一生懸命原稿として仕上げた知識のかたまりです。
しかし、そのコンテンツが収められている場所は、DTPデータの中です。
DTPデータは、その先の行き場を失ったデータ、言いたくないですが、「ゴミデータ」であることが大半です。DTP化によって「他アプリケーション（データ）との親和性の向上」「デジタル化による印刷コスト削減」というのがまるで恩恵のように謳われていましたが、なんのなんのそれによって引き起こされた問題は、この業界の将来性をも削っています。
一昔前のアナログ→DTP化では成し得なかった、このデータを生きたデータにして使えるようにするということも、今回は重要な課題です。

組版側として考えなければいけないこと

印刷は機械の性能の向上によって、時間短縮、ミスの軽減など図れると思いますが、制作作業は、機械やソフトウェアがやってくれるわけではなく、「人」がするものです。これは昔から変わりません。しかし、その重要性が、印刷の付加価値、効率化などなど、そのようなうわものの方へ考えがいってしまって、忘れられたのは、我々にも責任があると思います。もともと立場の弱く、表舞台にたてない、スポットライトのあたらない場所であるという諦めから、悪い流れに対して、堰き止めることができなかった。
組版側＝作り手側として、そういう反省をしたうえで、まず以下のような後々問題を引き起こす可能性があるものへの考え方を改めなければいけません。
・ソフトウェアやそのバージョンへの依存
・フォントへの依存
・作った人（作り方）への依存
・印刷工程への依存
これらを解決していかなければ、またまた「ただ作るだけ」に陥ります。

「作り方（制作手法）」の重要性

品質を高めることに対して、無限の力（時間）が使えるなら別ですが、往々にしてそうではないのが現実です。であれば、品質とコストのバランスを考えた作り方をしていかなければいけません。基本的に「人が手を加えるべきところを極力減らす」ことができればよく、元来組版は、すべてオペレーションによって完成まで持ち込むものではありません。そんな非効率な手法はありません。組版のルール、本作りのルールの上に成り立つものです。人が手を加えればいいものができるかというのも、現状のレベルを考えると、今ではもうなく、「手を加えれば加えるほどおかしくなる」というのが現実でしょう。作り手が考えることは、いかに手をいれずに作るか、いかに手を入れやすい作り方をするか、これがポイントです。

「乗り換えありき」で考える

さあ、学参組版にはどんなソフトが一番いいんでしょうか。InDesign？MC-B2？EdianWing？Quark？写研？その他いろいろあって、それぞれにメリットデメリットがありますね。
・InDesign
メリット＞安い（CS買うとついてくるおまけ）、QXからの乗り換えとかもあって普及している。スクリプトを使いこなせれば強力なツールになる。データの出し入れはそれによって吉。
デメリット＞学参でも細かいものになると手数（人もそうだけど、操作ステップ）が必要。ちょっと不安定っぽい。やっていて「うっそ〜ん。。。」とかよくある。
・MC-B2
メリット＞「組版」には向いている（「DTP」には向いていない）。数年前と比べて格段に良くなっている。タグやマクロを使いこなせばかなりよい。
デメリット＞ちょと高い（セットで150万円ぐらい？）。ちょと不安定。
・EdianWing
メリット＞DTP的、組版的両方に使える機能がモリモリ。オールラウンドで使えて安定もしている。
デメリット＞かなり高い（ハード込みで350万円）。対応とかこれからが微妙。
・Quark
メリット＞往年のQX使いは多い。なんだかんだでQX3.3ユーザはまだまだ多い。いろんなツールが出ている。
デメリット＞ちょっとInDesignに押されすぎで影が薄くなった。最新の情報（メーカーではなくユーザの）が少ない。
・写研（最近使ってないので、聞いた話と見た話で）
メリット＞専用機なだけあって、組版を考えつくされている。書体（あえてフォントではなく）の良さは、なんともいいようがない。
デメリット＞いろんな意味で減っている。
と、まあ総合すると、InDesignを頑張って使いこなすか、B2やEdianのようなものの機能を使いきって人手を減らすかというような感じです。多分トータルコストは同じなはずです。違うところといえば、日本語組版というちょっとやっぱり海外の組版とは違う要素を、米国産（だっけ？）のInDesignがどこまで吸収してくれるか、じゃないかと。

どんなソフトウェアでも、寿命があります。今までの経験、これからを考えたら、「乗り換え」を視野にいれなければいけません。乗り換えとは、DTP・組版ソフトでもあるし、そのコンテンツが使われる場所もそうです。汎用的でなければいけないということです。もう誌面に掲載されて終わり、という時代はとっくに通り過ぎていて、そこにあるデータをどう使うか、どう作るか、ということの方がはるかに重要なのです。

という感じでどこかで頼まれたときのための原稿の元にしときます。

デジパブに行ってきた

いかんいかん、つい他ごとに頭がいっちゃって。。。

7月9〜12日に東京国際展示場（ビッグサイト）で開催されていた「国際ブックフェア＋デジタルパブリッシングフェア（略してデジパブ）」に行って参りました。


2回ほど？出展社として出したこともある展示会です。
なかなか展示会費用もかかるので、PAGEは外せないので、デジパブは今回は見送り。

学参系の動向調査がメインです。

金曜の夜に出発し、東名で4時間ぐらい？。横浜志賀家にお世話になり、朝食までいただいて会場へ。
（出発した当日は、私、お腹か胃の調子を崩して、朝からずっとくたばってました。正直終わったかと思いました・・・が翌日はなんとか。皆さん拾い食いは止めましょう）

どれか一つにマルを付けてくれと言われたのです。




写植屋という業種カテゴリは昔あったんだろうか・・・ま、いいや。

朝イチは、さすがにまだ空いてましたが、時間がたつにつれ、図書部門は、
歩くのもちょっと大変なぐらいでした。
＜before＞


＜after＞


全部紹介できないですが、あまり基準もなくピックアップします。

PDFを活用した「パラパラめくりではない」デジタルカタログ

一見、よくあるPDFをJPEG化してFLASHでパラパラ見せるやつかなと。
説明を聞いてみると、情報を吸い上げて検索キーワードみたいなのを抜いて、
その誌面上のインデックスを作って、さらにそこにいろんな付加機能が付いている。
うーん、なるほど。山本さんが言ってたな、できるって。またやられちゃったねえ。
あんまりデータベースとか考えずにやるこういう発想、個人的には好きですね。

裏の組版エンジンはInDesignだそうです

凸版さんのブースで、辞書作りのための入稿用インターフェースを紹介してました。
実際本が出来てました。でもやっぱり製品というよりは事例であって、このためにスクラッチで作り込んでるそうです。お客さんの要望にマッチしてるんだろうなと、まとまった画面でした。ルビとかはタグを埋めてもらう了承を得ているらしく、テキストエリアの隣にHTMLのビューが付いてました。現実的でよかったです。

文書を構造化する難問にチャレンジしている企業があった！！

「いやー、これ大変っすよね」、やりたかったんだよなーと見てました。こうすればできるっていう理論はあっても、ここまでよくやったなと言う感じの出来具合。構造化するって、こういうことなんですよね。今はもっとユーザーフレンドリーなインターフェースも沢山あるから、技術的にはかなり現実的。あとは、あんまり複雑怪奇になって、結局誰も分からなくならないようにしないと、本末転倒になってしまいますよね。しかし、構造化できる文書であれば、マッチしますね。組版エンジンはFormatterっていってたかな。確かに向いてます。

InDesignで数式を組む

竹田印刷さんの出展製品です。
ワードで作った数式入り文書をTeX経由で、InDesignに、編集可能な状態で持って行くものでした。InDesignには数式機能が当然のようにデフォルトではないので、InDesignで数式入りの組版をする場合、こういう選択肢もある、ということでした。
InDesignが判断組っぽく、カタカタと組版するところも見ていると、シンプルさんのWAVEを彷彿させる感じです。これもよくやったよなあと感心しました。
課題は、InDesignで編集できるにせよ、Wordからの完全原稿入稿でないと力を発揮しにくいところです。完全自動組なら可能性として有りです。
写真OKだということでぱちり。

AdobeScene7

えーと、、、うーんと、、、Adobeさんのサービス？で、印刷で使った高解像度の画像をWEBその他に適したデータで返してくれるらしいです。
見せてもらったのは、例えば商品カタログであるメーカーの靴があったとして、それの色をブラウザ経由というかFlash経由で変更できるとか、下の写真のように、パーツを組み合わせて、色柄とかコーディネイトできるとか、、、このサービスを使うと、そういうインターフェースを使うことができるらしいです。海外の事例が中心でした。面白そうなんだけど、こういうのをスイスイ作れて、スイスイ使える方法が出てくるまで待ちだなと。でも、印刷物で使った高解像度の写真をうまく使おうよ、というコンセプトならそれはそれで良い発想だなと思いました。

ノリが良い神戸の粋な会社（と見た）

神戸の印刷会社さんで、Metaworksを使ってるそうなので、
ユーザの視点から見た感想を聞いてみたりしました。
やっぱりアプリの善し悪しは別として、実際案件で使おうと思うと、
どう使うかねえ、もしくはどう使えるかねえ、ということを考えないといけない。
当然のことを当然のようにやっている企業さんですが、
アプリを買えばなんとかなると思っている企業も沢山あって、
使わずにほかってあるのもよく聞きます。
そういう「どう使うか」という部分まで、しっかりコーディネイトできるような
企業になりたいなと、ことある度に思うのです。
世の中には良い製品、良いアイディアが沢山あるのに、
うまーく使えていない。そう思うのは僕だけなのかしら。

ちなみにこの腰巻きは、全社員に以前配られたもので、ここぞとばかり持ってきたそうです。
なんか、「っらっしゃいっ!!」って感じで、元気が伝わってきていいですよね。

InDesignでラウンド罫囲みプラグイン

京都の会社さんでした。InDesignで結構ネックになるのがラウンド罫囲み。
スクリプトを使えばなんとかなりそうですが、それをプラグインにして提供しています。

説明される方の話口調が、「ああ、この人はずっとこの世界でやってきたんだろうな、いろんな事にチャレンジして形にしてきたんだろうな」と感じさせ、敬意を持って拝聴しました。
「できるだろう」から「やってみよう」、そして「やり遂げる」。周りからは分からないと思いますが、雲を掴むような意外と大変な作業なんですよ。

モリサワさんを覗く

山本さんの各ブース立ち寄り時間は非常に長いので、ふらっとひとり旅に。
お、学参って書いてある、ああ、モリサワさんだ。。。
MC-B2の導入結構多いでしょ、と質問すると「かなり」と。
学参ももうほんとうに大改訂が近づいていて、準備しておかないとやれるところがなくなるんですよね。我々もまだ見ぬ世界ですが、大変なことになるんだろうなと不安と期待で過ごしてます。それまではなんとか頑張ろうと。今のうちに仕込めるものは仕込んどけと。
とと、あ、やっぱりNasse置いてるんですね。。。

塾などの教室でプロジェクタと合わせて使うデジタルな黒板

「天気予報」なんかで使われているアレとよく似てます。
しかし、先生方コレを使い切るのか？という素朴な疑問。
使えてる姿はカッコイイんだけど、なんか勉強を教える前に、
また覚える事増えちゃってみたいな意見が出てきそうな。
しかし、コンテンツのデジタル化が図れればこういうところでも使えるんだよなと。
コンテンツとしては供給もしやすくなるし、受けもしやすいのは確か。


下は日本地図をネタからひっぱてきてその上に何か書いているところ。

今回何が一番印象に残ったか3人でアンケート調査したところ、↑が一番でした。
なんか夢がある。多分そこです。

おまけ：ガンダム見てきました！

だって、会場からすぐなんだもの。。。
歩いて会場に入っていくと、期待をじらすかのようにまずは後ろ姿がちらり。

そこで、おーっとなるわけです。
横向きから見て、前面を見る。あーっ、でけー、、、ぽかーんですわ。



しかーし、限定本とか限定プラモとか、2時間待ちの長蛇ですよ。さすがに帰りました。
帰り際、BGMが消えたと思ったら、プシューっと蒸気がガンダムから。
クビを左右にゆっくりと振り、そして最後には上向きですよ、
さすがに観客から「おーっ」と歓声があがったのでした。
クビまで動くから、全体的に動き出すのもそう遠くないですね。きっと。

最後に・・・
息子に小学館の図鑑NEOシリーズ「宇宙」と「昆虫」を買って帰りました。
なんと20％引きなのです！！

個人的には「宇宙」の方が好きなんですが、6歳坊主には「昆虫」がかなり興味があるらしく、
重たい本を寝床に持って行って、一生懸命見てるんです。


「本作り」に携わる企業として、こういう光景をいつも思い出してやっていかないといけないなと、もう寝るよ、と言いながら思ったのでした。