‘2012/04’ カテゴリーのアーカイブ

「文書構造」と「視覚表現」を分離する

2012/04/25

 これから書くことは、すでにあちこちで語られていますし、おそらくWebサイドから電子書籍に行こうとされている方からしてみれば「何をいまさら」感もあるかと思うのですが(そういう方はどうぞ読み飛ばしてください)、これまでDTPソフトしか触ったことのない印刷側の人間からしてみれば「最初の壁」になる可能性のある部分ですし、実際自分もしばらく乗り越えられなかった経験もありますので、あえて重複を恐れずに書いておきたく思います。これはおそらく、今後の電子・紙書籍双方の制作に関わってくる重要な考え方のひとつです。

「文書構造」と「視覚表現」の違いとは

「見出し」と「本文」のみの文書の例

「見出し」と「本文」のみの文書の例

 例えば、InDesignのドキュメントで「見出し」に続いて「本文」が書かれており、それぞれに段落スタイルが設定されているとても単純な文書モデルを考えてみてください。この場合、「文書構造」に当たるのは「見出し」および「本文」です。一方で、「M-中ゴシックBBB12ポイント」および「リュウミンL-KL9ポイント」などは「視覚表現」に相当します。行揃え方向、行頭インデントの有無、文字カラーなども同じく視覚表現です。
 従来のDTP制作フローでは、この2つの概念は、特に意識することなく混在していました。InDesign内の段落スタイルシートの名称が「見出し」であろうが「M-中ゴシックBBB12ポイント」であろうが、最終的な印刷物の見た目は何ら変わりませんし、特定の判型・文字サイズの印刷物が最終到達点である限りにおいて、それで特に問題はありませんでした。しかし、電子書籍を制作するにあたっては、おそらく真っ先にこの部分の意識改革が求められてきます。
 電子書籍で用いられるXML構造化文書のタグ名および属性名は、可能な限り「視覚表現」ではなく「文書構造」を表すものでなくてはなりません。すなわち、「M-中ゴシックBBB12ポイント」を表すタグ/属性名ではなく、「見出し」を表すタグ/属性名で命名されなくてはならないのです。では、「視覚表現」はどうするのか。これは、別に用意したCSSやXSLといった「スタイルシート」に記述します。

読まれる環境は1パターンではない

環境ごとに最適化された視覚表現を実現

 なぜこうした考え方が必要になってくるのでしょうか。メリットは多々ありますが、わかりやすいところで説明しますと、同じ文書をタブレットと携帯電話で読むことを考えてみていただきたく思います。この2つのデバイスでは、当然ながら可能な視覚表現の幅に差があります。特定のタブレットの画面サイズに最適化した形でフォントサイズを決めてしまうと、携帯電話ではとても読みにくいことになってしまうかも知れません。また、タブレットで選べる書体が携帯電話で選べるとは限りません。タブレットでなら縦書きで読めても、携帯電話では不可能かも知れません。こうした視覚表現の幅の差の問題は、メーカーの違うタブレット同士でも起こりえますし、それどころか同じタブレット内で異なるアプリケーションで閲覧した場合でも当然起きてくる問題です。
 そこで、文書には「文書構造」のみを記述しておき、それぞれの環境ごとに用意したスタイルシートと組み合わせることで最適な「視覚表現」を得る、といった考え方が出てくるわけです。こうした考え方は、異なるPC・ブラウザで同一の文書を閲覧することが前提とされるWebではすでに馴染み深いものです。HTML4で構造と表現の混在が問題とされ、後継規格のXHTMLおよび現在主流となりつつあるHTML5では「視覚表現はCSSで記述すること」が強く推奨されている現状があります。HTML5とCSSを規格として取り込んでいるEPUB3でも、少なくともプロが作る電子書籍では当然こうした考え方をきちんと意識して作ることが求められてくるでしょう。
 もちろんメリットはそれだけではありません。きちんと構造化され、表現と切り離された簡潔な文書は、例えば「電子書店で書籍のタイトル名と見出し名だけをファイルから自動取得して表示する」といったようなことを容易にしますし、「注」をそれ専用の構造を表すタグで記述しておけば、ビューア側の実装と組み合わせてポップアップ表示するといったような表現も可能になってくるでしょう。また、将来的に次世代の電子書籍フォーマットに移行する際に、文書の流用を容易にすることにも繋がります。

既存電子書籍フォーマットの弱点

 こうした視点で見てくると、既存電子書籍フォーマットの弱点がちらちらと見えてきます。以下は既存電子書籍フォーマットの代表的な存在のひとつである「XMDF」を用いて、上記モデルと同様のものを仮制作してみた例ですが、ご覧の通り完全に文書構造と視覚表現が混在してしまっています。

<p top_line_indent="0em" top_line_indent_bracket="0em" align="justified_left" bracket="「〈《【『〔([{"><font size="110%" bold="yes" name="MS Pゴシック">見出しタイトル</font></p>
<p top_line_indent="1em" top_line_indent_bracket="0em" align="justified_left" bracket="「〈《【『〔([{">本文テキスト入る 本文テキスト入る 本文テキスト入る 本文テキスト入る 本文テキスト入る 本文テキスト入る</p>

 XMDFでも「文章構造スタイル(structureタグ)」および「文字スタイル(fontタグ)」を用いることで文書構造と視覚表現が分離した文書を作成することは可能ですが、これもHTMLで言えば全て<div>タグおよび<span>タグを用いてclass名で制御している状態に当たるため、少々不完全と言わざるを得ません。「見出し」だけを取り出したい、といったニーズに応えられる仕様ではないと思います。また、なにより文書構造に視覚表現が混在した表記を「許す」仕様になっていること自体が次世代を睨んだ構造化文書としては問題があるのではないでしょうか。

 また、いわゆる「ワープロ感覚で誰でも簡単に作れる」電子書籍作成サービスがプロ向けに使えない理由もここにあります。以下はある簡易EPUB作成ソフトの自動生成タグですが、これが可読性に欠け、後から変換する際に問題となりそうなことは一読してわかることと思います。

<body>
<div><span class="fontA13AAC48-F76C-47E3-A783-C53D961CCFEF">本文本文本文本文</span></div>
<div> </div>
<div><span class="fontF2CF1A56-85BF-4B0F-B347-F11EA7E06BAF">本文本文本文本文本文</span></div>
<div> </div>
<div><span class="fontD86BC4AF-3AED-4D5B-8398-14DEDC83DA22"> </span><ruby class="ruby7BA61523-3FDE-42E9-8944-607C7ED6B2BD"><span class="fontF8A0DA5C-A523-4E98-89C9-554A66CA705C">本</span><rt class="rtA27B8F1C-73D1-46C5-8A77-2D3F5873B756">ほん</rt></ruby><ruby class="rubyAAA4353C-CA4C-4467-AF72-1952640EDDE1"><span class="fontDADF4999-C565-4C66-A938-541DA782B8BE">ぶん</span><rt class="rt771A818A-AC30-4230-BC7D-B2ECC9062AED">ぶん</rt></ruby><span class="fontFA8A96AC-F495-4DE0-9968-5DF6C51DBA15">本文本文本文本文本文</span></div>
</body>

具体的には何を意識すれば良いのか

 最後に、EPUB3(HTML5)の文書を作成する際に、作成者側が具体的にどういった点を意識する必要があるのかについて一例をあげておきたく思います。

 まず、<h1>〜<h6>(見出し)、<p>(本文)、<blockquote>(引用文)など、あらかじめ意味づけされたタグが用意されているものに関してはできるだけそちらを使うべきでしょう。そういったタグがなく、独自に属性値を定義しなくてはならない場合、例えば本文の1行だけをゴシック体・赤文字にして強調したい場合には、

<p style="font-family:'MS Pゴシック';color:#FF0000;">本文テキスト本文テキスト本文テキスト</p>

といった形で文書内にフォント名・文字色を直書きするような記述は避けるべきと思います。「MS Pゴシック」及び文字色は「視覚表現」に相当するからで、このフォント・文字色が使えない環境では適切に表示できないことになります。また、

<p class="mspgothic">本文テキスト本文テキスト本文テキスト</p>

と記述するようなパターンも(先の例よりはマシですが)避けるべきでしょう。「MS Pゴシック」が使えない環境で混乱の元となります。

<p class="highlight">本文テキスト本文テキスト本文テキスト</p>

といったような「文書構造」に近い属性名でXHTMLのclass定義をし、CSSには

p highlight {font-family:'MS Pゴシック';color:#FF0000; }

と記述するようなパターンを選ぶのが適切かと思います(実際には p highlight {font-family:'ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ',Meiryo,'MS Pゴシック',sans-serif;} といったようにフォント名を連記することになるでしょう)。

 また、校正時のプリント出力で文字揃え等が多少狂っていたとしても、それを手直しするために「文書構造」を変えることには慎重になるべきです。実際に電子書籍を読む読者が、必ずしも作成環境と同じ表示特性のデバイスで読むわけではないことを心に留めておくべきと思います。

 なお、文章物のEPUB3文書で具体的にどういった記述をするのが適切かについては、「epubcafé」で参照できる「JBasicマークアップ指針」や、「EPUB日本語基準研究グループ」の「EPUB3日本語ベーシック基準」などが参考になります。

(2012.4.25)

「紙」は聖域ではない

2012/04/11

 電子書籍に関するニュースなどに対する反応を見ていると、「自分はこれからも紙で買うからいい」という意見が散見されます。まだまだ電子書籍の読書環境が整っているとは言いがたく、これだけ「紙の本」の環境が充実している日本ではもっともと思える意見です。ただ、「紙の本」の制作・流通形態もまた、これまでとずっと同じというわけにはいきそうにありません。すでにその変化は始まっているように感じています。
 今回は、新しい紙印刷のカタチ、「オンデマンド印刷」について書いてみたいと思います。電子書籍のブログで何故、と思われる方もおられるかも知れませんが、おそらく電子書籍とオンデマンド印刷は無縁ではなく、将来的に相互補完する形で普及していくものと思われるからです。

「オンデマンド」の意味するもの

 印刷業界の中には、「オンデマンド印刷」を「プリンタと同じトナーで印刷するオフセットやグラビアとは違う印刷方式」ととらえておられる方が多いのではないかと思います。これは現状の「オンデマンド印刷機」に対しての説明としては正しいですが、「オンデマンド印刷」そのものの説明としては必ずしも正しくありません。では「オンデマンド印刷」とは何を指すのでしょうか。これは、「注文を受けてから印刷する方式」を指しています。印刷方式がトナーを用いたものでなくても、顧客の注文を受けてから印刷する方式であれば「オンデマンド印刷」です。
 出版・印刷業界の方の中には、ここで当然の疑問を持たれる方もおられるのではないかと思います。「従来のオフセット印刷であれグラビア印刷であれ、顧客である出版社の注文を受けてから印刷をしていたことに違いはないではないか」と言う疑問です。実際、今現在各印刷会社がオンデマンド印刷機を導入している理由も、オフセット印刷よりも少部数印刷に強みを持つオンデマンド印刷機を導入し、各出版社の少部数印刷の要求に応えるためです。例え少部数であれ、印刷されたものが出版社に引き渡され、出版取次を通して全国に配本されるという形において、これは従来の印刷と何ら変わりのないものです。ですが、おそらくこれは「オンデマンド印刷」のもたらす変化の第1ステージに過ぎないものと思われます。

「読者の注文を受けてから書店で印刷する」販売モデル

 「顧客」が「出版社」である限り、「オンデマンド印刷」は従来のオフセット印刷の延長線でしかありません。しかし、最終的に書籍を手にするのは「出版社」ではなく「読者」です。もし、末端顧客である「読者」の注文を受けてから「書店の店頭で」印刷するとしたらどうでしょうか?実はすでに、この形を試験的ながら実現したモデルが存在します。
 昨年初頭、三省堂書店に導入された「エスプレッソ・ブック・マシン※1」という簡易オンデマンド印刷機をご記憶の方も多いかと思います。私も興味を持ち、試してみた一人でした。これは書店の店頭で顧客が注文した本をその場で印刷し、表紙までつけて製本するというマシンで、10分程度でコーヒーを飲んでいる間に出来上がることから「エスプレッソ」という名前を与えられたとのことです。正直1冊あたりの価格は決して安くはなく、ラインナップは少なく、印刷クオリティもまだまだ低く感じられましたが、それよりも「もうここまで出来るようになっていること」に驚きと戦慄を覚える気持ちの方が大きかったことを記憶しています。
 おそらくこれこそが、オンデマンド印刷の目指す最終ステージの「ひな形」ではないかと思います。「読者の注文に応じて1冊ずつその場で印刷する」こと、これがオンデマンド方式の最終到達点のひとつではないでしょうか。現時点での印刷品質や価格はそれほど重要ではありません。品質は、その製品の本質的なコンセプトが正しく、ニーズがありさえすれば急速に改善されるものであることは、例えばiPodの初代から以後の世代へのハードウェア的な洗練の歴史を振り返れば容易に納得できます。価格も流通量と比例して一定ラインまでは速やかに下がるでしょう。それよりも、この新方式が意味する書籍流通システムの本質的な変化にもっと目を向けるべきではないかと感じます。

流通・在庫コストがほぼゼロになり、書店が無限の在庫を持てるシステム

これまでの書籍流通システム

↑クリックでポップアップ拡大表示されます

 現在、紙書籍は私が所属している会社のような印刷会社で制作され、出版社の要求冊数に応じて印刷されて出版社の倉庫から出版取次を通して各書店に搬送されます。Amazonのようなネット書店であっても、「書店」が「Amazonの倉庫」になるだけで、基本的にこのモデルに変わりはありません。出版社はあらかじめ「売れる冊数の見込み」を立てて印刷させ、見込みを超えて売れれば増刷され、見込みよりも売れなければ一定期間を経た後、出版取次※2を通して返本されます。
 これはもともと、活版印刷のような巨大な印刷機と非オンラインの時代に成立したシステムであり、当時としてはこれが最適解であったことと思います。ただ、このやり方ですとどうしても、見込みを超えて売れすぎれば増刷までのタイムラグによる販売機会損失が起き、見込みよりも売れなければ大量の返本が発生する、といったリスクを避けられません。また、売れる見込みが一定部数に到達しなければ増刷もかからないため、本来店頭で手に入る状態なら買ってもらえたかもしれない本が、品切れになっているために買ってもらえない、といった目に見えない機会損失も生じてきます。
 また、各書店の倉庫の面積は有限ですから、結局全ての本を在庫としてストックしておける訳ではありません。さらには配送の費用や時間といった要素も当然無視はできません。現在の配送のコストは極限まで低く押さえ込まれているとは思いますが、それでも「ゼロ」にはなりません。
 「読者の注文に応じて1冊ずつその場で印刷」すれば、これら全ての問題が解決してしまいます。そもそも物理的な在庫がありませんから倉庫を圧迫することもありませんし、返本のリスクもありません。各書籍の元データは、オンライン上の大量に書籍のデータがストックされたサーバーから発注がかかった時点でダウンロードすれば良い話になりますので、実質各書店が書籍の在庫を無限に持っているのと同じことになります。オンライン維持費はかかりますから配送コストは完全なゼロではありませんが、トラックで配送する費用を考えればほぼ「ゼロ」と見なしても良い程度に押さえ込めます。出版社が何らかの方針で絶版にしていない限り、品切れのリスクもなくなります。

書籍データのコンテンツラインナップをどう揃えるか

電子/オンデマンド書籍流通システム

↑クリックでポップアップ拡大表示されます

 一見いいことずくめに思える「オンデマンド印刷」のシステムですが、これが普及するためには越えなければならない大きな「壁」があります。それは書籍の「ラインナップ」をどう揃えるか、という問題です。例えどれだけ魅力的な次世代のシステムであっても、十分な数のコンテンツが揃わなければ絵に描いた餅です。
 実は、コンテンツのラインナップを揃える見込みはすでに存在しているのです。そもそも、ここまでの文章を読んで、ある種の「既視感」を覚えた方も多いのではないでしょうか。そう、オンデマンド印刷のメリットも、現状の問題点も、「電子書籍」のそれと全く同じです。従って「ラインナップ」もまた、電子書籍用の蓄積コンテンツをそのまま共用することが期待されます。そして、出版デジタル機構が目標として掲げている「100万冊」の電子化コンテンツは、そっくりそのまま「オンデマンド印刷」に流用できる性質を持つものです。そうした可能性を見込んでの「構造化された中間データ形式での蓄積」であるのだと思います。従来型の出版エコシステムからの移行に伴うさまざまな問題・・・法整備、出版社側の決裁システムの整備などの問題も、電子書籍用コンテンツの準備と連動して解決されることと思われます。
 もしこの「100万冊」のコンテンツ化が実現し、「エスプレッソ・ブック・マシン」よりもさらに進んだ次世代の簡易オンデマンド印刷機が全国に行き渡ったらどうなるのか。すなわち「100万種類のストックを持つ書店」が、全国に誕生することになるでしょう。

従来の書店・印刷会社はどうなるのか

 さて、そうなった時、従来の書店や印刷会社はどうなるのでしょうか。
 現在、日本ではAmazonを代表格としたネット書店の台頭によって小さな書店の閉店が相次ぎ、大型書店といえども苦しい経営を強いられている状況にあります。新宿ジュンク堂の閉店が記憶に新しい方も多いことでしょう。簡易オンデマンド印刷機は、従来型の書店に何をもたらすでしょうか。
 まず、大型書店での「平積み」という現在の販売書籍のディスプレイシステムは、オンデマンド印刷の時代であってもそのまま継続されるものと思います。大型店舗のディスプレイスペースを生かし、視覚に訴える完成された展示販売システムがそう簡単にはなくなるとは思えません。ただ、平積みされる書籍の内容は、各書店が販売方針によってこれまで以上に柔軟に変えることが可能になってくるでしょう。何か大きな事件が起きたとき、これまではその事件の関連情報に関する本がストックされていなければ、増刷され、店頭に並ぶまでに一定の時間が必要でした。サーバー上にあるデータを各店舗で印刷すれば良いのであれば、事件の翌日に関連書籍を平積みできます。これは書店に「速報性」という新しい武器をもたらします。また、一般的には人気がなくても、ある特定の場所にある店舗では根強いニーズのある書籍といったものも存在すると思われますので、こうしたニーズを汲み上げて売り上げをアップさせることも可能になります。
 一方で、地方の小型書店はどうなるでしょうか。これは、簡易オンデマンド印刷機と最小限の展示スペース、といった形に変化していくのではないでしょうか。印刷には多少の時間がかかりますから、カフェのような軽飲食店やコンビニエンスストアとの融合も起きてくるでしょうし、ショッピングモールの中に組み込まれた「書店カウンター」といった業態も考えられます。

 印刷会社の印刷部門はどうなるでしょうか。これは、ハードカバーのような豪華装丁本の印刷や、多色刷り印刷といった部分に特化する方向に向かうのではないかと思います。「オンデマンド印刷」が書店で行えるようになるといっても、何も豪華装丁ハードカバーを印刷・製本できる設備が各書店に備え付けられるわけではありません。それはおそらくコスト的に割に合いません。こういった豪華本・特殊印刷本の印刷は相変わらず都市部の印刷会社の仕事となるでしょう。ただし、従来と流れが全く変わらないかといえばそうでもありません。書籍は従来自社で制作したものを自社で印刷する流れが主でしたが、今後は自社・他社を問わずオンライン上にあるデータを印刷会社がダウンロードし、高品質の印刷が可能な大型オンデマンド機で印刷する流れに変化してくるように思います。オンラインのデータがあらゆる形に変えられる「中間データ」として蓄積されていれば、印刷会社側の受け入れ・変換システムと組み合わせてあらゆる判型・文字の大きさで印刷できるようになります。また、1冊単位で高速/高品質印刷できる大型オンデマンド印刷機があれば、個々の読者が一般的には人気がなくても個人的に思い入れのある1冊をネット経由で注文し、豪華装丁ハードカバーとして印刷させて自分の書棚に並べることも可能になるでしょう。さらに、コンテンツの一部を1冊ずつ変えて印刷することも不可能ではありません。これは例えば、主人公の名前を自由に変えられる児童書、といったような形への展開が考えられます。
 こうしたきめ細かな注文への対応は各書店の簡易オンデマンド印刷機では限界がありますから、自ずと高度な技術・大型オンデマンド印刷設備を持つ印刷会社の仕事になってくるでしょう。

 さて、この流れが定着すれば、従来ひとつの印刷会社の中で行われていた「コンテンツ制作」と「印刷」という業務の関連性が徐々になくなってきます。この2つの業務を同じ屋根の下で行う必然性が失われてくるのです。その結果、「コンテンツ制作」に特化して「印刷」を廃業し、Webやデータベースといった技術と結びつきを強める「制作会社」と、さまざまなタイプの高度な「印刷」に特化して「コンテンツ制作」をしなくなる新しいタイプの「印刷会社」に2分される流れが起きてくる・・・と見るのはいささか早計でしょうか。

 こうした変化が一朝一夕に実現されるとは思いませんし、もちろん全てがこの通りにはならないかもしれません。ただ、電子書籍をめぐる動きはこうした「紙」書籍をも巻き込む形で展開されて行くことが当然予想できますし、そうした変化に柔軟に対処する心構えは、全ての出版・印刷関係者にとって必要となってくるでしょう。「紙」は聖域ではありません。

※1 参考:http://www.asahi.com/culture/news_culture/TKY201102280062.html
※2 出版取次:http://ja.wikipedia.org/wiki/出版取次

(2012.4.11)

「オンデマンド」は印刷方式ではなく、昨今では従来方式のオフセット・グラビア印刷でも小ロットが要求されている状況から、「無版を特徴とするデジタル印刷」という表記が現在では正しいのではないか、とのご指摘をいただきましたので追記させていただきます。また、最近では300〜3000部程度向けのデジタル印刷機や、大量印刷向けのデジタル印刷機も登場しているとのことです。こうした新しい技術の流れが今後どういった影響を及ぼしてくるのか、当分は目が離せません。

(2012.5.02追記)

「異体字」問題・その2 〜対策編〜

2012/04/04

前回の投稿ではInDesign等の組版ソフト内でOpentypeフォントの内包する異体字字形を使っていた場合の電子書籍化に伴う問題について書かせていただきましたが、今回は実際にどういった対策をとって異体字化が必要な文字を探し出すかを考えてみました。

外字化が必要な文字の目視確認の難しさ

字形差を目視で確認するのは難しい

字形差を目視で確認するのは難しい

InDesignはOpentypeのフォントが内部に持っているさまざまな「異体字」字形を「字形パレット」を通して呼び出し、ドキュメント内で用いることができます。ただし、そうして呼び出した異体字の中に、外字画像にしないと電子書籍で表示できない字形が多く含まれることは前回指摘した通りです。これは技術的には「Adobe1-6などの印刷用フォント規格とUNICODE(UTF-8など)のグリフ(字形)数の差異」に起因しています。(ドットブックなどのように文字コードがShift_JISの場合はさらに問題が大きくなります。)このあたりの問題を根本的に解決するためにAdobe1-6をベースに「文字図形共有基盤」を制定し、字形を統一番号で管理しようとする動きもあります※1が、いずれにしても今すぐに使用できるわけではなく、時間はかかりそうです。そしてこうした印刷用Opentypeフォントの内包する「エキスパート字形」などの異体字字形を存分に使って作り込んだInDesignデータから電子書籍を製作する際に大きな問題になってくるのが、「InDesign内のどの文字が外字にしなければならない文字なのか、目視で簡単に確認できない」ことです。

テキスト化すると付加属性が消える

テキスト化すると付加属性が消える

そもそもがほとんど変わらない字形のバリエーションだからこそ同じ文字コードが当てられ、出版社からの字形差の要求に応えることを想定したInDesignなどのプロ向け組版ソフトからのみ呼び出せるようになっていたわけで、そうした微細な字形差を目視で確認し、外字化が必要な文字を的確に判断することを全てのオペレータに求めることはちょっと難しいです。そうなると一度異体字の付加属性を捨て、あらためて外字を指定し直す前提でプレーンテキスト化したデータと原本を1文字ずつ照合することになりますが、これがコスト的に相当高くつくのは誰が見ても明らかです。

AppleScriptで対象文字をあぶり出す

さて、どうにかならないものか。少なくとも「Pr6N」などの最近のフォントを用いているドキュメント位はどうにかしたい。理屈で言えばテキストがInDesign内に存在する状態であれば付加属性は残っているわけですから、ここで何らかのマークをつけてやればいいわけです。1文字1文字人間が確認すればとんでもない時間がかかりますが、そういう「機械的」な作業はそれこそコンピュータに任せてしまえば良い。

外字化が必要な文字を自動チェック

外字化が必要な文字を自動チェック

というわけで、以前「ものかの」さんで公開されていた「異体字チェッカー」をもとに、電子書籍用異体字チェックのAppleScriptを考案してみました。「エキスパート字形」「すべての異体字」といった「異体字チェッカー」でもともとチェック機能があった異体字字形に加え、「複数の文字を組み合わせて表示している合字」および「UNICODE/Shift_JISにコードが存在せず、InDesign内の字形パレット等からしか呼び出せない字形(51以上の丸数字など)」といった外字化が必要な文字を自動チェックし、文字色を変更します。

また、出版デジタル機構の「電子書籍制作仕様書 第一次素案」では、中間形式の文字コードとして現状Shift_JISを想定しているようですので、別途「Shift_JISにコード割り当てのないUNICODEのみの文字」をチェックできるスクリプトも製作してみました。AppleScriptですので処理速度が速いとは言い難いですが、少なくとも目で追って全文字確認するよりは効率的です。どこかのソフトハウスさんがきちんとしたアプリを開発してくれることを期待しつつ、現状でのとりあえずの対策として提供させていただきます。

なお、InDesign内で外字化する文字を書き出すためのスクリプトもテスト的に作成はしてみたのですが、現状ではまだ出版デジタル機構の制作仕様書自体が「素案」の段階であり、正式仕様では画像形式・解像度等が変更される可能性がありますので、現状での公開は差し控えさせていただきます。

各スクリプトは以下のリンクからダウンロードしていただけます。Mac OS10.7/InDesign CS5にてテスト済みです。なお、スクリプトを使用したことによって発生したコンテンツの破損等に関して一切の責任を負いかねますので、あくまで自己責任でご使用ください。

InDesign内異体字/合字チェック (1166)
InDesign内UNICODEのみの文字チェック (802)

※1 「文字図形共有基盤」調査検討報告書:http://www.jepa.or.jp/material/files/20120125.pdf

(2012.4.5)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。