投稿者「Hiroyuki Chiba」のアーカイブ

■澤田善彦略歴

1930年7月15日生まれ東京都出身

【学歴】千葉大学中退
【職歴】 1945年大日本印刷（株）入社
ベントン彫刻母型による「秀英体」の改刻、全自動モノタイプの実用化および活版、オフセット関連の生産管理部門の管理職歴任。

1967年～75年香港勤務後、(株)CTS大日本の工場長に就任。
1985年同社退社。リョービイマジクス（株）に入社。取締役情報システム部長を経て顧問に就任。 1995年ダイナラブジャパン（株）に入社し取締役副社長就任。
1998年1月同社退社その後リョービイマジクス（株）顧問。
1994年以降、JAGAT DTPエキスパート認証制度に認証委員として参画。
2014年7月没

【著書】 MONZキーワード／ページネーションのすべて／変わるプリプレス技術／この一冊でDTPがわかる’98版／DTPエキスパート用語1200／ほか著書多数

【JAGATのサイトに執筆したコラム】 ● DTP玉手箱 ● フォント千夜一夜物語 ● 印刷100年の変革

【DTP玉手箱】【フォント千夜一夜物語】澤田善彦コラム集

sawada2 澤田善彦

★ DTP玉手箱 ★

●DTPはコンパクトカメラと違う（1999/8/2）
●組版ルールは何のためにある（1999/8/16）
●組版ルールと可読性（1999/9/3）
●組版の良し悪しの物差し（1999/9/20）
●かな漢字変換のミス（1999/10/18）
●原稿は正確に書き，文字は正しく入力（1999/11/1）
●直しはサービスではない。コストがかかる（1999/11/15）
●DTP時代の校正ワークフロー（1999/11/29）
●フォントデザインとつめ組みの功罪（1）（1999/12/8）
●フォントデザインとつめ組みの功罪（2）（2000/1/21）

●文字の特性とフォント（2000/1/24）
●印刷メカニズムとフォント（2000/2/6）
●和文フォントデザインの基本（1）（2000/2/18）
●和文フォントデザインの基本（2）（2000/3/5）
●和文フォントデザインの基本（3）（2000/3/19）
●和文フォントデザインの基本（4）（2000/4/2）
●欧文フォントデザインの基本（1）（2000/4/16）
●欧文フォントデザインの基本（2）（2000/5/5）

●欧文書体の歴史（2000/5/21）
●ポイント・システムの由来（2000/6/4）
●ジャスティフィケーションとハイフネーション（2000/6/19）
●和欧混植の問題点（2000/7/1）
●ポイント・システムの由来（2000/7/15）
●ポイント・システムの由来（2000/8/12）
●紙とインキの科学─知らないと損をする印刷の知識（1）（2000/9/1）
●紙とインキの科学─知らないと損をする印刷の知識（2）（2000/9/25）
●水を使うオフと水なしオフ─知らないと損をする印刷の知識（3）（2000/10/8）
●版なし印刷と紙なし印刷─知らないと損をする印刷の知識（4）（2000/10/23）
●印刷に関する雑学─知らないと損をする印刷の知識（5）（2000/11/05）
●製本の知識が必要なDTP─知って得する製本の知識（1）（2000/11/18）
●製本工程と様式─知って得する製本の知識（2）（2000/12/4）
●製本様式と面付け─知って得する製本の知識（3）（2000/12/18）
●製本様式とノドあき─知って得する製本の知識（4）（2001/01/05）
●製本のトラブルと表面加工─知って得する製本の知識（5）（2001/01/19）

★ 印刷100年の変革 ★

★ フォント千夜一夜物語 ★

【澤田善彦：プロフィール】

1930年7月15日生まれ東京都出身

【学歴】千葉大学中退
【職歴】 1945年大日本印刷（株）入社
ベントン彫刻母型による「秀英体」の改刻、全自動モノタイプの実用化に携わる。活版、オフセット関連の生産管理部門の管理職を歴任。
1967年～75年香港勤務後、（株）CTS大日本の工場長に就任。

1985年同社退社。リョービイマジクス（株）に入社。取締役情報システム部長を経て顧問に就任。 1995年ダイナラブジャパン（株）に入社し取締役副社長就任。

1998年1月同社退社その後リョービイマジクス（株）顧問。
1994年以降、JAGAT DTPエキスパート制度に認証委員として参画。印刷業界の人材育成に貢献。

2014年7月没

【著書】 MONZキーワード／ページネーションのすべて／変わるプリプレス技術／この一冊でDTPがわかる’98版／DTPエキスパート用語1200／ほか著書多数。

画像データのトラブルと望ましい画像処理ワークフロー

近年では撮影データを印刷以外のメディアへ展開することが一般的になった。適切な容量、カラーマネジメントなど、多メディア展開を前提にした画像入稿とワークフローが求められている。

画像データのトラブルと望ましい画像処理ワークフローについて、エコーインテックの庄司正幸氏に伺った。

画像データのトラブルと望ましい画像処理ワークフロー

エコ―インテックは、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から印刷とEPUB変換する方法

教育や法令、学術論文など構造的な文書を組版する手法として、XML技術は根強く利用されている。近年では、Webや電子書籍と印刷向けにコンテンツの一元化とマルチユースを実現する手法としても、注目されている。

XMLによる出版・制作を独自に調査しているXMLパブリッシング研究会の活動について、株式会社ウェブインパクトの西河貴史氏に聞いた。

■XMLオーサリングと組版・EPUBツールの開発

XMLパブリッシング研究会は、2010年4月に発足し、XMLコンテンツのオーサリング、自動組版、電子出版などのサンプル制作やツール開発を通じて、情報交換やスキルアップを目指す有志の集まりである。
実際のメンバーは20数名で出版社や印刷会社・制作会社、IT会社など多方面からの参加がある。

主な活動は、サンプル制作やワークフローを検討するワークフロー・グループとツール開発をおこなう技術グループがある。技術グループは、当初、XML技術を詳しく理解するため、仕様を限定したXML変換ツールを開発した。それがXMLオーサリングツールと、XML組版ツールである。
その後、機能を拡張してEPUB変換にも対応している。

日常的にSNSやFacebookで情報交換しているほか、月1回JAGATに集まってミーティングをおこなっている。
これまでに、これらのツールを使用して盲学校の教科書をXML化し、視覚障がい者向けの大活字本や背景色を反転させたPDFを制作し、全日本盲学校教育研究大会での発表したこともある。

DAISY（アクセシブル情報システム）のセミナーでは、DAISY4からXML経由でPDFを生成するという発表もおこなった。

また、減災行動手帳というコンテンツのXML化に取り組み、スマホやPCで利用できるための手法を検討した。

このようなワンソースマルチユースによる電子化、アクセシビリティ対応などを目的とした勉強会をおこなっている。

XMLオーサリングツールの「Jepasspo」とXMLからPDFやEPUBを作成するツール「FANTaStIKK」は、Vectorで無償公開している。
機能限定のため業務用に使うのは難しいが、ワンソースマルチユースのトライアル用としては十分である。
動作環境としてはJAVAが必要で、MacでもWindowsでもLinuxでも動作する。

「Jepasspo」は、日本電子出版協会が規定したJepaXに限定したオーサリングツールである。
GUIベースでXMLオーサリングが可能であり、ボタンを押すとタグが出るような方式である。JepaXのコンテンツに対して、版型や書体、サイズなどの組版指定を設定し、組版データ（XSL-FO）、またはEPUBに変換するツールが「FANTaStIKK」である。
XSL-FOは、Apache FOPやAH Formatterというツールを経由して印刷用のPDFを生成することができる。

組版指定はユーザーがGUIで変更することができる。例えば、本文とタイトル、目次・前書・後書きなどの単位で設定する。版型やページサイズ、余白などや書体・文字サイズ、インデント、段落間なども設定可能である。
組版指示はユーザーが一から設定することもできるが、プリセットの仕組みもある。プリセットをカスタマイズして、自分用のセットとして保存することもできる。
EPUBに変換する場合、EPUBは版型の設定がないし、文字サイズも相対的となる。

■HTMLBook対応

HTMLBookはXHTML5のサブセットであり、コンピュータ関連の専門書出版で著名な米国オライリー社が提唱し、XHTML5ベースで書籍を執筆・制作するための規格である。

XMLパブリッシング研究会では、現在HTMLBook規格の調査・習得とツール開発、サンプル制作を計画している。
HTMLBookの詳しい内容はWebで公開されており、その日本語訳を作成して公開した。今後のツール開発は、XHTML5の入力対応とDAISY対応、ユーザーインタフェースの多言語対応もおこなう。現時点のHTMLBookへの対応状況は9割方完成しているが、一部に未対応の部分が残っている。

（JAGAT 研究調査部千葉弘幸）

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 研究調査部千葉弘幸）