次代を担う印刷会社の後継者・経営幹部を育成する「印刷後継者・経営幹部ゼミナール」。2013年に修了した方の生の声をお伝えします。
「協会情報」カテゴリーアーカイブ
ギフトカタログのWeb to printと電子版制作
DTPによる印刷物制作とWeb用のHTML制作を別々に進行することは、校正やチェックが2重となり、時間・コスト的にもさまざまな無駄が発生する。コンテンツを一元化し、DTPソフトに依存せずにPDFデータ作成とHTML展開を行うことが出来ないか。
共同印刷の藤森良成氏にギフトカタログのWeb to printに取り組んだ経緯を聞いた。
■DTPによるカタログ制作の問題点
ギフトカタログは定型レイアウトがほとんどで、基本パターンとして1つのページに商品単位の小組をレイアウトする。自動化しやすいケースではあるが、さまざまな要因から自動化されていないことも多い。DTPでフルに制作している場合、商品ごとに製造元や生産者に原稿(データ)と掲載内容に関してアナログなやり取りが発生し、たいへんな手間・コストがかかる。また、DTP上の修正はデータベースに反映することはできないため、次年度のトラブルの種になってしまうという問題があった。
■CatalogPackerの構成と機能
CatalogPackerは、ネットワーク上で定型カタログを制作するためのWeb to Printであり、自動組版システムである。Webブラウザ上で動作するため、OSに依存せず、各PCにDTPソフトウェアをインストールすることも不要である。
商品DBをメンテナンスするユニットとそのデータを組版し割り付けるユニットで構成されている。DBの内容はクライアントや商品のサプライヤーに直接直してもらうことを想定している。DBを修正した後、小組単位で自動組版してPDFを作成し、校了まで進める。
ページアップした後の校正は行わない。実際にはバックグラウンドでXSL-FOを生成し、AH Formatterで組版レイアウトを行っている。
例えば旅行のカタログを作る場合、通常のRDBなら朝昼夕の食事回数を0,0,1と記号化して入力し、印刷物にする際に「朝食0回、昼食0回、夕食1回」という文字列に変換している。
食料品の通販であれば、チルド、冷凍などの区分を文字ではなくマークや画像で表現してほしいとなる。
このような印刷物上のルールを、全部印刷会社側で管理すると校正漏れやミスも多くなる。
そこで、価格・スペックなどを格納する商品DBと、印刷物上の文字列などをXML形式で記述する体裁情報DBに分けた。価格・スペックの修正は、常に体裁情報DBに同期されるようになっている。
小組のレイアウト指示は簡易設定画面から行う。小組の縦横サイズやどの位置にデータベースのどの項目を配置するか、その条件などを設定する。プレビューボタンを押すと、作ったレイアウトにデータベースの1件目が流し込まれて、結果を確認することができる。裏側ではXSL-FOで動作しているが、DTPや組版の専門的な知識は必要ない。簡単なトレーニングでWebオペレーターでも対応できるレベルである。
InDesignなどのDTPでカタログを制作する際、難しいとされているのが爪(インデックス)の自動発生である。例えば、北海道とか東北とか海鮮品なのか野菜果物なのか、フラグによって爪の色や文字、位置を変更する。DTPではオペレーターが手作業で配置するしかないが、XMLなので自動生成することができる。
レイアウト後にデータ修正をする際、画面をクリックすると「データを修正しますか。それともレイアウトを修正しますか」と選択できるようになっている。価格データを修正すると、連動して小組に修正が反映され、PDFが自動で作成される。
また、「今回だけこの価格を特別値引きにしたので、色を変えてほしい」といった修正であれば、レイアウトの情報だけを変更すればいい。
このような形でデータと体裁を分離し、管理しているためコンテンツの一元化を実現することができる。
■今後の課題
実際に運用してみると、一番の問題は商品のサプライヤーが画面上でのデータ修正に慣れていないことであった。
また、この仕組みは定型カタログが対象である。定型カタログはカタログの12~13%でしかない。大量部数であるため仕事としては重要だが、頻度は少ないというのが実態である。
今後は、CSS組版による印刷データ制作にトライしたいと考えている。CSS組版ができれば、Webと共通のラインで紙でも電子でも制作することができる。このような形でコンテンツの一元管理を進めていくことで、印刷会社がシステムインテグレーターやWeb制作会社と差別化することが可能になる。
(JAGAT 研究調査部 千葉 弘幸)
XMLを活用した製品マニュアルとHTMLの同時制作
三和印刷工業では、主にAV機器、デジタル製品の取扱説明書やサービスマニュアル等を制作している。XML技術を活用したコンテンツ管理と自動組版、HTML自動生成など、製品マニュアルのワンソースマルチユースを実現し、多言語対応にも効果を上げている。
同社代表取締役の竹内栄司に話を聞いた。
■XML技術を導入した背景と方法
顧客は電機メーカーで、テレビ、DVDレコーダー、ビデオカメラ、デジカメなどのマニュアルを制作している。仕事量は年々減っているが、競合も多く品質や納期面の要求はより厳しくなっている。DTPなど従来の方法では限界があり、大幅な原価削減や差別化を模索していた。
XMLはタグ付きテキストデータであり、1つのデータからスタイルシートを変えることでレイアウト変更や印刷用PDFを書き出し、自動でHTMLを生成することができる。DTPを自動化し、Webマニュアルも同時に自動生成できることから、XML方式を導入することを決定した。XMLの生成方法は、WordやInDesign、XMLエディタも検討したが、オペレータにXML知識が不要で、ワンソースマルチユースが可能なCMSを自社開発することに決定した。データベースのサーバーにテキストやイラスト、スタイルシート等が格納され、そこからXMLが自動出力される。XSLTスタイルシートを経由してアンテナハウスのAH Formatterという変換エンジンでPDFに書き出す。HTMLもCSSを組み合わせて自動でアップする仕組になっている。
■システム開発の経過と成果
初期の段階で、テキストとイラストを多言語も含めて全部データベース化し、PDFとWebマニュアルを同時に作ることができ、また取説の固有名詞を管理するシステムを2年かけて開発した。最初からいろいろな仕組みを一遍に立ち上げたため、安定もせず、効率化もできていなかった。しかし値段だけは安くできたので、顧客も許容してくれた。その後、約3年かけてシステムを強化した。1つのモデルの取説を複数の人間で編集できるようにした。また、例えば5モデルくらいを一度に作り、最小限の修正作業で各ファイルに反映できるようにした。PDFとHTMLも同時に作ることを実現した。DTPに追いつき、追い越したというところである。
さらに、XMLと翻訳システムを連動させた。検査機能や自動メンテ機能を付加し、作業を大幅に削減することができた。システム的に品質向上する仕組みを実現することができた。現在、6年が経過し、編集システムiTrexと翻訳管理システムiTosに加え、PettssというGUIの用語データベースが連動している。
システム導入の効果として、以前の体制よりDTPオペレータと校正者を削減し、執筆者を増やすことができた。XSLTというスタイルシートの設計は、当初外注していたが現在は内製化している。納期面でも、多言語版を含めると大きな効果が出ている。レイアウトも翻訳準備も自動化したため、InDesignで約20日間かかっていた業務が約10日でできるようになった。顧客からも高い評価を受けている。
■今後の展開
Web化することで取扱説明書の付加価値を上げたいと考えている。通常の取説は、目次と索引で必要な事項を探す必要がある。目次にできることを並べているだけなので、どの機能を使って良いかわからない。デジカメなどでは、目次だけで100項目くらいあるので全部は読まれていない。
Webマニュアルであれば、「初めて使うときは」をクリックすると、初めて使うときの手順をエンドユーザーにナビゲートすることができる。「めざまし時計代わりに音楽を再生したい」とか、「プレイリスト風に使いたいときはどうするか」等、事例を挟みながら説明することができる。また、ネットワーク接続は他メーカーの機器と接続するため、取説で説明することは非常に厄介だったが、Webなら条件を選ぶことによって絞り込むことができる。
使い方がわからないとエンドユーザーはメーカーに電話するが、そのサポートもコストになる。Webマニュアルを提案することで、メーカーではコスト削減になり、印刷会社の付加価値にもなる。しかも、手間や費用をかけて制作するのではなく、紙を作ったついでにHTMLにすることを選ぶだけである。これがPDFとHTMLを同時に印刷するという事例である。
(JAGAT 研究調査部 千葉 弘幸)
「印刷会社のフリーペーパー展」page2015特別企画報告
page2015では、JAGAT会員企業が企画・編集・制作などに参加するフリーペーパー・フリーマガジンを募集、 会場内に特設ブースを設け、展示を行った。そこから見えた印刷会社のフリーペーパーについて報告する。 続きを読む
ムダな会議はもうやめる! 【大阪開催】
~効果的な会議デザインと運営方法の技術を学ぶ~
意見やアイデアが出ない非効率な会議に時間を費やしてはいませんか?
そもそも会議とは、関係者が集まり「相談」をしたり、「情報伝達・共有」をしたり、物事を「決定」する重要な場です。お互いに意見交換をして、最良の施策、結果を出すために意見をまとめ集約するため時間を費やすものなのです。ところが、本来の目的を見失った会議(業務報告のみ、延々と資料を棒読みするだけ)も多いのが現状です。
「なぜうちの会議は長いんだ」
「無駄な会議が多すぎる」
「どうせ意見を言っても変わらない」
環境が厳しく、変化の激しい現在だからこそ社員それぞれが持つアイデアや情報、提案、率直な意見などを引き出し、さらに上手く組み合わせ、力を合わせて経営課題の発見や解決をしていく必要があります。
効果的な会議デザインと運営方法の技術は必須のスキルです。
日常的に会議運営に関わるチームリーダー、管理職の方にはぜひ学んでいただきたい講座です。
講 師
福原美砂氏 (オフィス福原 C&D HR Lab.代表)
印刷関連商社にて顧客と関わる技術職(インストラクター等)を10数年。顧客感動を目指す中で、コミュニケーションの重要性を痛感し、心理学(TA 交流分析)を経て、コーアクティブ・コーチングと出会う。2004年春より国際コーチ連盟認定のコーチ養成機関「CTIジャパン」にてコーチングを学ぶ。
2006年9月CPCC 資格取得、印刷業界他、多方面で活躍中。
開催日時
2015年6月24日(水) 13:00-18:00
内 容
(1)オリエンテーション
~今日の進め方とルールについて
(2)会議ファシリテーションの重要性
・うまくいかない会議のあるあるパターン
・会議チェックシートで日常の会議を診断する
・「場」とは何か
・効果的な会議を運営するための5つのポイント
・話し合いを進める技法
・意思決定の技法
・場の学びを促進する技法
(3)模擬会議
【グループ演習】
(4)研修のまとめ
ね ら い
1.「場」(グループプロセス)とその診断方法を知る
2.会議ファシリテーションのスキルを身につける
3. 模擬会議で学んだことを試してみる
対 象
リーダー、管理職など
定 員
16名(最少催行人数6名)
参加費(税込)
JAGAT会員・大印工組合員 14,040円
一 般 18,360円
会 場
大阪印刷会館 (大阪府大阪市都島区中野町4-4-2)
セミナールーム
大阪環状線桜ノ宮駅より 徒歩5分
申込要項(FAX申込み)
お申込書に必要事項をご記入のうえ、
03-3384-3216までFAXにてお送りください。
■参加費振込先
参加費は、下記口座に開催日の2日前までに振り込み願います。
なお、お申し込み後の取り消しはお受けできません。代理の方のご出席をお願いします。
口座名:シャ)ニホンインサツギジュツキョウカイ
口座番号:みずほ銀行中野支店(普)202430
■内容の問合わせは下記へご連絡ください.
公益社団法人日本印刷技術協会
西部支社
TEL. 06-6352-6845/FAX. 06-6353-5020
お申し込み及びお支払に関して
管理部(販売管理担当) 電話:03-5385-7185(直通)
どのように印刷業の未来を創るのか
印刷会社が明るい未来を創り出すためにやるべきことは何か。そのヒントとなるキーワードは何だろうか。
3/24「広告ビジネス最新動向―広告手法の変化と実際」
画像データのトラブルと望ましい画像処理ワークフロー
近年では撮影データを印刷以外のメディアへ展開することが一般的になった。適切な容量、カラーマネジメントなど、多メディア展開を前提にした画像入稿とワークフローが求められている。
画像データのトラブルと望ましい画像処理ワークフローについて、エコーインテックの庄司正幸氏に伺った。
画像データのトラブルと望ましい画像処理ワークフロー
エコ―インテックは、DTP制作の会社で、いろいろな仕事がお客様から入って来る。その中で、画像を中心にした入稿に関してのさまざまな問題とか、エコ―インテックでやっている画像ワークフローについて話をしたい。
入稿形態という意味では、エコ―インテックの制作現場は日本ではなく中国である。東京は営業部署しかなくて、実際の現場は中国でやっている。そういう環境もあって、画像に関してはCMYK支給が非常に多い。RGBを支給されるときもあるが、主なるものはCMYKで支給されてそれを貼り込むということがメインになっている。
また、画像の補正は、難易度の低いものに関してはよく受けるが、本当にうるさいものに関しては、プルーフ環境が、中国から送るわけにはいかないので、現場ではなかなかその辺の部分ができていない。
カタログの製版などでいろいろ合成処理をするときは、全部CMYKのレタッチでやっている。私は現場の人間にRGBレタッチを教える立場にいて、現場の人間はできるが、実際お客様のほうがCMYK原稿なので、CMYKでのレタッチという話になる。
最近、入稿に関して感じるのは、InDesignなりIllustratorにリンクされている画像の画素数が大きすぎるということが1つある。また、色の定義に関して、カラースペースに関してのいろいろなトラブルも起きている。
アナログ時代、私も昔は製版会社にいたので、倍率測定器でものを測ってからスキャニングするとか、実際に貼る原稿をそのサイズにして原寸にするというのが鉄則という世界で長くいたが、現在は撮影したものがそのまま来ている。
実際、Photoshopでいろいろな画像を開いてみると、ほとんど生のものをそのまま持ってきている。CMYKにはなっているが、ちょっとした補正はしているにしても、画素数とか、倍率を合わせてうまくコントロールするということはないまま支給される。
それをやるのに、最終的にはアウトプットというか、PDFを制作する時点で解像度をコントロールするというのがAdobeのテクノロジーの中にあるが、そういうところをやるにしても、お客様の要望によっては非常に高画質なまま、オーバークオリティなままPDFを作らざるを得ないといったことがある。
まず、定期折込における画像フォーマットと配置倍率と書いたが、折込といっても新聞のチラシ等ではなく、例えば日本橋にはコレド室町というのがあって、そういうところの入り口にはいろいろなイベントの冊子というか、8ページくらいのものがある。そのデータを見せていただいた中での話である。
おもしろいのは、クリエイティブをやっている制作会社からデータを受け取って、それをもう少し仕上げていくという仕事に入るが、基本的に最初の制作会社の使い勝手の良さでフォーマットとかそういうものが全部変わってしまう。
例えばIllustratorしか使えないオペレータがいるデザイン会社と、InDesignを使っているデザイン会社というのは、本当に極端に違う。そういう会社が同じような仕事の中にある。その統計的なもので、倍率を見てもらうとわかるが、ほとんどリンクされているものに関しては50%以下、半分以下で、画像がオーバーな状態である。
こちらもほとんどPhotoshopフォーマットで、InDesignだと画像フォーマットとしてPhotoshopフォーマットを使う人が多いが、それでも配置している部分を見ると約8割が縮小している。
InDesignの中にはそういうインフォメーションを見るところがあり、これはカメラの情報だが、それを見ると、Photoshopで開いたときは400dpiベースにして280×187mmの画像になっている。これは撮影時の画像だが、InDesignに貼ったときは34×23しか使っていない。
つまり、dpi相当でいくと、400dpiが原寸だとすれば3,333dpiの画像が貼ってあるという話になってしまう。これは完全にオーバークオリティである。こういう画像が1紙面に50点とか貼ってある。
当然、例えばネットを通してデータのやり取りとか、実際にそれを開いて処理して戻すといった作業だけでも、実はパソコンが、Mac等が高性能になったとはいえ、相当負荷の高い仕事をしているというのが現状だろう。
もう1つ、書き出しプリセットの違いということがある。左側はAdobe推奨の設定で、先ほどの3,333dpiの写真が貼ってあったとしても、左側でやった場合にはリサイズがかかって300dpi相当の画像に縮小した状態でPDFができる。
ところが、右側のほうはリサンプルをしない。ということは、でき上がったPDFは3,333dpiのままPDFの中に貼り込まれた状態になる。これも、お客様の印刷会社から「これでやれ」という指示でこういうジョブオプションをもらうので、変更するわけにいかないのでこのままやるしかない。
昔は確かに画素数が足りなかったので、「変にサンプリングして画質を悪くするのなら、しないほうがいい」という設定モードはあったかもしれない。ところが、今の現状でいくと、先ほど見てもらったとおり、もう半分以上が50%以下で貼ってあるような、相当圧縮率のかかった画素数の部分で、これをやって本当にいいのか、作業しながら疑問にちょっと感じているところではある。
これでやったからといって、それほどそれが後工程の印刷で品質のいいものに取って代わるとは決して思えない。その辺が、なかなか我々のほうで決められない値なので、お客様とのやり取りでなかなか辛い仕事のフェーズである。
実際にそれをベースにしてやってみると、ネイティブデータのパッケージの中で画像の容量を見ると580MBと、非常に高いが、それをダウンサンプリングして、要するに300dpiに落とした形でPDFを作った場合、PDFのデータ量が4.1MBになる。それでも300dpiの画像なのでクオリティ的には保持している。ZIPでも6.9MBである。ところが、それをネイティブのサンプリングしない場合だと43MBと、極端にデータ容量が違う。
データ容量が違うということは、作業自体で考えれば基本的には作業の長さに依存することになるので、本来はこういうふうな形にするか、それとも最初の段階で適切な画像サイズで作業するということを本当はお勧めしたい。
それから印刷物の種類によって画素数が違う。月刊誌の場合は、縮小ではあるが、それほど極端な縮小率というのはない。ほとんど貼って出すというような感じで、エコ―インテックに入って来る仕事の中でも実はRGBで、それもJPEG入稿されて、印刷会社のほうからバッチ処理のような形でPhotoshopのアクションツールのようなものを支給されていて、もうルーティンでやる仕事になる。それの支給されているものは、調べた結果でいくと64%、半分以上がsRGBである。商品撮影など、私の知り合いのカメラマンはほとんどAdobeRGBがデフォルトだが、取材などで使われているものだとほとんどsRGBで撮っている。
カメラも見ていただくと、これは少し古いデータなのでiPhone4が載っているが、この辺だとCOOLPIXといったコンシューマカメラで取材したりするので、どうしてもこれはsRGBの世界での画質として入稿されることが多い。
それを支給されているので、印刷仕上がりの条件であればOKということでPhotoshopのアクションでバッチ処理してレイアウトしていく。赤字に関しては、初校段階で赤が入ればまた画像をレタッチする。それ以外はどんどんルーティンのままやってしまう。雑誌だと、こういう画像の扱い方が多いと思う。
次に製品カタログの場合だが、この製品カタログが非常に重い。例えば2,000ページといったカタログなどを仕事でやるが、その中でも大体半分くらいはもう50%以下にされていて、なおかつPhotoshopが多い。
紙面の片面見開きの画像となるとお客様もうるさいので、そういうところだとPhotoshopでレタッチしたままのレイヤー付きの画像が支給されたりする。後で校正を出して赤が入ったらすぐ直せるという感じだが、それをそのまま貼らなくてはいけなので、それだけで膨大になって、この画像だけで200MBだとか、そんなものが飛んでくる。
カタログの場合、半面見開きで扱うような写真などで、それも補正のパラメータ付きで入稿されたりすることが非常に多い。ここでも40%の人はほとんどがそういう大きいサイズで、なおかついろいろレイヤーを使ってレイヤー調整して合成しているようなものの、そのレイヤー付きのまま作業として使わざるを得ないといったような入り方をしているものが多い。
製品カタログとか、そういうものの中では、最近とみにUSMの部分の問題が大きいと感じている部分がある。これは実際に画像を輪切りにした状態である。100%でUSMをかけた画像を25%に配置してやった場合、その画像を縦切りに切ってみると、シャープネス効果、エッジ効果というのを見ることができる。これを25%にすると、差は出るにしてもほとんどエッジ効果が消えている。要するに、シャープネスがかかっていないという状況になっている。
最初の段階で、原寸で、例えば先ほどお見せしたもので言えば最初の400dpiの画像の状態でシャープネスをかければ、300とかいう形でUSMをかけたとしても、実際にそれがInDesign上で25%に下げるということはUSMを消しているということになる。そういう形のものが最近多いと思う。
下の画像はPhotoshopでシャープネスをかけていて、上の画像はかけていないが、見てもらうと、やはりエッジの効果があることがわかると思う。下のほうがやはりくっきり見える。シャープさがあるが、上のほうはぼけたような形になっている。
これは実際の商品撮影のCMYK画像だが、40~50点全部調べてみたところ、全部USMがかかっていなかった。これは校了までのデータだったので、完全にUSMかからずに印刷されている。
データは私のほうで加工していなくて受け取ったデータだが、ほとんど最近は商品データはまず画素が大きくて縮小して貼ってあって、CMYKだけれどもシャープネスもない。こういう画像を非常に多く見かける。エッジ効果をかければそれなりに見えるのに、ちょっとシャープな感じのしない印刷物ができ上がってしまう状態のまま進行されているのではないかと思うことがよくある。
もう1つはカラースペースの話である。ものによって、カラースペースを切り替えなくてはいけない部分がある。基本的なものとしては「Japan ColorでCMYKにしなさい」という指示が飛んで来る場合と、お客様から支給された「オリジナルプロファイルで変換しなさい」という2種類ある。
よくトラブルになるのは、現場の技術のほうからは「これでやりなさい」という指令が来るが、何かの問い合わせで印刷会社の営業の人などにメールなどで質問すると、「Japan Colorでやっておいて」と言われたりする。「本当はこれなのだろう、でもこっちでやっていいのか」というような曖昧さが最近多いと思う。
本来は最初のカラースペースの設定というのが大事だが、なかなか意思統一されていなくて、エコ―インテックの現場のほうが戸惑ってしまうというのが最近多いと思う。後から「これにしてなかったから」という形でクレームとして言われることもあるが、現場自体考えると「こっちでもいいよ」という指示がいろいろな部署から回ってきたりしてトラブルになることがある。
実際に見てもらうと、ここで比較しているのはJapan Color2001というAdobeのプロファイルのガモット域とJapan Color2011という認証制度で使われているホームページからダウンロードできるプロファイルだが、この2つを比較すると、ほとんどガモット領域は同じで、ちょっとの違いはあるにしてもさほど変わらない。
ところが、今ある印刷会社からいただいているデータだと、赤とか黄色方面、緑方面に相当ガモット域が違ってくる。そうすると当然、印刷したときの結果も、例えばJapan Colorでプロファイル変換したもので考えるとガモットが小さくなっているので、余計印刷に行くとちょっとくすんだような上がりになってしまう。そういったことの違いみたいなことに最近無頓着になってきているのではないか。
これはエコ―インテックと一緒に協力してやっている画像レタッチ専門の会社の例である。真ん中を中心にして、左と右でちょっと色が違って見えると思う。これはPhotoshopで色相をいじって動かしているが、ΔEで2だけである。Labのa方向のaチャンネルをΔE2動かした。
デバイスによって再現性が違うが、本当はこちらのほうが少し赤く見えて、こちらのほうが少し青く見えるはずである。なかなかデバイスの違いで出ないこともあるが、実際ちょっと違うふうに見えると思う。
私が昔関わった仕事で言うと、こういうふうなメーカーもそういうことをやっていた。それを事例にすると、これも、こちらとこちらでΔE2くらいしか動かしていないが、ちょっと違って見える。
これは、あるメーカーがカメラマンと一緒に画像をやって、画像コンテンツを、自分たちの画像自体をライブラリ化している。そこで画質の安定というか、印刷の品質を安定させたいということで、Japan Color2011を採用して、その基準でやろうという話になって、いろいろ印刷会社とテストしたらしい。
上がってきたのを見ると、例えばAさんとBさんで色が違っている。印刷会社に聞くと、プルーフ認証だとΔE6くらいの範囲内に入っていれば認証合格のはずなので、「その範囲に入っている」と言われてしまう。しかし本当は色を統一したいので、クライアントが困った挙句、友人の会社のところに相談に来た。
今やっていることは、その会社の中で、色を安定させるための指針としてプルーフ見本を付けて、「この色に近づけてもらいたい」というワークフローに変えたいということでやっている。
言い方からすると、この流れはJapan Colorと言われるような認証制度の話になるが、こちらはどちらかというとプルーフで合わせてその色に近づけてもらうということである。昔で言うとJMPA、雑誌広告基準の考え方というのは、まさにプルーフで校正を出して、その色にみんなで合わせようという動きである。そういう形のものに近いワークフローを、今組もうとしている。
これがどうなったか、最近メンバーと会っていないのでわからないが、色というのは、実際印刷物を使っていろいろなことを展開しているような企業にとっては、この辺の基準化というのは非常に考えなくてはいけない世界のようだ。その部分を、画像だけの内校のような形で一生懸命構築しているという話もある。
これは通販系のカタログで、実際に我々が中国で普通にやっている仕事の内容である。ここはもう少し画像などのワークフローをうまくコントロールしてやっている仕事になる。エコ―インテックのオペレーションは、ディレクションとオペレーションとあって、画像をここからもらってきて、会社の中でストックして、向こうのほうからデータをもらってきて、ここで作ったものをパッケージ化してアップする。
エコ―インテックは中国でやっているので、中国を経由してオンラインでやっているので、なかなかトラフィックはあると思うが、実際にそういうふうなことがやれるのでやらせてもらっている事例である。
ここの部分で言うと、画像を常にこちらで、ディレクションをやっている印刷会社のほうで画像処理したものを、エコ―インテックのほうに、ある一定の期間でサーバ同士で通信してストックしてきている。
こちらのほうは文字とかInDesignのネイティブをコントロールするサーバの仕組みがあって、ここからInDesignをダウンロードしてきて、こちらの画像と、中に文字を組んだり、いろいろなことのレイアウトしたものをパッケージ化して、ここにアップすると、それがサーバ上でまたコンテンツ管理されるといった仕組みをやってみた形のものである。これは海外の外資系の通販カタログの仕事で、こういうワークフローを組んでやってみたことがある。
RGBワークフローの基本の話をしたい。基本的にはRGBの最適化、画像変換してRGBやCMYKに変える。これは昔からいろいろな形でやろうといって提唱してきたことである。実際にこういうものは、エコ―インテックのワークフローの中で言うと皆無に等しい。やはりCMYKベースで動いているものが多い。
私の仕事自体、自社の開発の人間とプログラムをしていきながらやることも多いが、例えばカタログ系だと、印刷の状態が終わって校了になってからWeb用のデータ構築みたいなものがあったりする。
CMYKのカタログのInDesignのデータから、必要なスペック情報をプログラム的に抜きだし、なおかつここに貼ってある例えばEPSなりPSDのデータをベースにしてWebで使うJPEGファイルに変換するというような流れがある。
カタログだと、いまだにCMYKからRGB変換とか、どちらかというとJapan ColorからsRGB変換してそれをWebで使うという流れの方がまだまだ多い感じがある。というより、ほとんど「こういう形で作業をやってくれ」という形態がまだ今も多い。
実際には違う方法もあるのではないかと考えて、これは出版社と私と著者と3人で相談してやったワークフローである。撮影された画像をRGBで補正しながら自分でデザインして本を作っていくという流れである。この流れの中はすべてRGBで進行するという流れのやり方をした。
その中で私がサポートしたのは、実はここの部分である。たまたま紙質がマット系の紙だったため、Japan Colorのプロファイルをそのまま使うことはできなかったので、この本を印刷してくれる印刷会社にお願いしてICCプロファイルを作成した。
それをベースにして、印刷会社に初校を出してもらうとき、デザインをやった人間がPhotoshopのCMYKのシャープネスを何段階か自分でかけてみて、どういう効果が出るのか、初校の段階でテスト刷りをやらせてもらった。
そのときには実際に変換してシャープネスもかけてということだが、そのとき私のほうで用意したのは、変換をバッチ処理するツールである。デザイナーはカメラのデータを縮小して貼っているが、印刷会社に入れる前の段階で全部InDesign上に原寸で貼って、なおかつPhotoshopで決めたシャープネス効果が得られるようなバッチ処理のツールを間にかませて初校を出した。それでOKになった段階でそのまま最終まで行ってしまう。
ここで作業している著者は、もうRGBだけで処理するという話である。それに対して、ここに行くときだけこういう仕組みをうまくかませて、CMYKでPDFにして印刷会社に入稿するという流れを作った。
ここで作ったものは、逆にリサイズをうまくかけてやればそのままEPUBのような電子書籍に変換できるし、印刷の条件、紙質を変えるのであれば、ここの部分をコントロールすることによってすんなりといくようなワークフローが組めるという形になる。
少しお見せすると、InDesignを自動的にバッチで呼んできて、中にどんなスタイルがどうリンクされているかを全部データベースに登録するためのボタンが付いている。2番目は、データベースに入っている情報をもとにして、例えばそれにUSMまでかけてCMYKにして戻すといった処理を行う。最後はInDesignに再リンクしてPDF/X-1aで保存する。こういったところをルーティンとしてやらせるような、ボタン1つ押せば何とかそこまで行くようなものを提供した。
これ1つ作っておくと、実は他の仕事にも全部応用できる。これは3年くらい前のもので、今のOSで動かないのでデモは難しいが、こういう形でちょっとしたことを補助することによってワークフロー自体はそのままRDBのマシンなりワークフローとしてはまとまって、必要なデバイスのところにそういうサポートができればものが作れるといったようなこともありえるのではないか。
そう考えると、CMYKから、例えばRGBのWebのオペレーションをするということではなく、適切な、CMYKはCMYK、RGBはRGBという流れがあってもいいのではないかというふうに思うこともある。
これは画像とは直接関係ないが、今エコ―インテックのある部隊でやっているのは、HTMLとCSSをベースにしてDTPの組版をしてしまう。それの基礎的な仕組みを作るというようなことをやっている仕事がある。
これはある大手出版社と絡んでやっているものだが、今までのようにCMYKありきで何かのデータを作って、それをRGBに展開するという話ではなく、逆にRGBでやったものから展開するということもありうるのではないか。そういう流れが少しずつできてきているように思っている。
これはアメリカのPrinceという、HTMLとCSSからPDFを生成するためのモジュールである。これはHTMLである。何ページか分をHTMLとCSSで組まれたホームページの状態のものである。実際にPrinceのホームページに載っていて、ソースコードもあるので、興味がある人はダウンロードしてみてもらいたい。中は、当然だがいろいろリンクされているJPEG画像がある。
ここにCSSと呼ばれるものがある。CSSというのはスタイルシートと呼ばれるが、中身は完全にテキストで、フォントは何を使うとか、ページサイズはいくつといったようなことが書かれているだけである。
これがPrinceのデモ版のライブラリだが、味もそっけもない、コマンドラインで打ちこむためのモジュールである。それをプログラムに仕込んだものがあるので、ここにドラッグする。そうすると、今PDFが1つ増えた。フォント環境が違うので化けるが、実は先ほどのホームページと同じ内容のものがPDF化されている。
こういう形で、ホームページのHTMLと同レベルのものが印刷用のPDFとしても使えるというふうな、逆の発想である。今までのDTPでやってHTML書き出しとかEPUB書き出しとかいうInDesignにする流れとは逆だが、HTMLの一般的なオープンソースで作った内容からCSSを変えて逆にPDFを作成させるようなことも、動きとして最近出てきている。この辺に関しても、基本的にはWeb系なので、最初のデフォルトになるデータとしては当然RGBのデータがベースになっていく。
そういう意味では、最初のRGB自体、撮影されたものとか、いろいろなコンテンツ自体、体系化したものがあって、それがいろいろな用途によって枝分かれしていって、必要なところで必要なサイズの用途として、解像度の問題とかシャープネスの問題等がコントロールされたものが行って印刷になったりWeb系になったりという形の流れが理想的なのではないか。
2014年6月3日TG研究会「デジタル入稿の新常識とワークフロー」より(文責編集)
HTMLBookとCSSを利用した書籍組版の可能性
現在の電子書籍は、まず印刷の本を作り、そのデータを加工してEPUBを作るというやり方が多い。しかし、この方法ではマスターが2つになるため、管理面やコスト面でもムダが多い。
未来の書籍出版では、コンテンツを一元管理し、そこから印刷の本の組版と電子書籍を同時に作るというワンソースマルチユースが可能になる。
アンテナハウス取締役の村上真雄氏にそのための技術、HTMLBookとCSS組版について話を伺った。
■書籍出版のワンソースマルチユース
Webも電子書籍もHTMLというマークアップ言語で作られている。このHTMLをマスターデータにするという考えがHTMLBookである。
EPUB・Kindle・Web・PDF(印刷データ)など各媒体向けにCSSというスタイルシートでレイアウト指定し組版することをCSS組版と言う。CSSを使えば、マスターのHTMLからEPUB、Kindle、Webへと展開することができる。
ただし、現時点ではCSS仕様が未完成であり、PDF(印刷データ)を生成するには不十分なところもある。
現時点でCSS組版エンジンを提供、または公開しているのは、世界で3社だけである。
アンテナハウスのAHフォーマッターは日本語組版、縦書き、多言語にも対応しており、アメリカのオライリー社でも採用されている。
YesLogic社(オーストラリア)のPrinceは、アメリカの有名な出版社のアシェットブックグループ(HBG)等で採用されている。Princeは、CSSの生みの親であるホーコン・リー氏が関わっている。
オライリー社はブラウザ上で編集環境を共有し多媒体向けに組版する仕組み、Booktypeという書籍制作サービスを提供している。
■CSS組版のユーザー動向
日本のW3C関係者と有志がまとめた「W3C技術ノート 日本語組版処理の要件」(通称:JLreq)というドキュメントがある。XHTMLで作られ、W3Cのサイトで英語と日本語で公開されている。日本語版は書籍としても出版されているが、その際にAHフォーマッターでCSS組版を行い、PDF 出力している。
アシェット社は、世界的に巨大な出版社グループである。米国のアシェット社では多くの書籍において印刷版と電子版を同時制作するために、CSS組版に取り組んでいる。
アシェット社では、著者と編集者はMS Wordで編集作業をおこなっている。構造化を施して制作システムにインポートすると、その時点でHTMLに変換され、それ以降はHTMLでマスター管理する。制作システムはIGP:Digital Publisherというソフトで、CSSでレイアウトし、PDFを書き出す仕組みである。マスターが完成次第、電子書籍用のEPUBも生成することができる。
コンピュータ関連の書籍で世界的に有名なオライリー社では、以前からHTMLとAHフォーマッターのCSS組版で印刷用PDFが作られており、電子書籍用のEPUBも同時生成していた。
新しいバージョンが「Atlas」というシステムで、HTMLBookに対応する予定となっている。
HTMLBookとは、オライリー社が定義したHTML5で本の内容をマークアップする方法である。HTML5に書籍用のタグを追加している。また、XMLの文書変換技術であるXSLTを利用して目次や索引ページを自動生成することができる。
HTMLBookの一番の特徴はオープンソースで仕様やツールが公開されていることである。
■CSSの標準化動向とHTMLBookとCSS組版の可能性
CSSで本を組版する仕様の基本が「CSS3 Page」である。
「CSS3 GCPM」はその一部で、柱、脚注、相互参照など書籍組版に必要な機能を定義する。 現時点のCSSは未完成のドラフトである。CSSの標準化に向けた動きとして、WHATWGグループのCSSBooksという仕様やW3C内での標準化も進められている。
CSS組版の実用化が進むと、DTPに依存しないワンソースマルチユースなど、いろいろな可能性が大きくなる。Web ブラウザ上でCSS組版も可能になる。リフロー型の電子書籍でもページのレイアウトが色々できるようになるだろう。
(JAGAT 研究調査部 千葉 弘幸)
行間の選択
日本語組版とつきあう その41