‘InDesign’ タグのついている投稿

先頭文字/行/正規表現スタイルの処理を考える

2012/07/09

正規表現スタイル

正規表現スタイル

 InDesignには、「段落スタイル」設定内の「ドロップキャップと先頭文字スタイル」から設定できる「先頭文字スタイル」および「行スタイル」、同じく「段落スタイル」設定内で使用できる「正規表現スタイル」といった便利な機能があります。これらは全て、段落スタイルの適用されている行内の文字のうち、設定した特定の条件に適合する文字に自動的に指定した文字スタイルを適用する機能です。例えば「先頭文字スタイル」であれば、文中の数字だけを自動的に斜体にする、「行スタイル」であれば1行目だけを太字にするといったような、通常長時間の反復処理が必要になる作業を段落スタイルの設定のみで処理できます。「正規表現スタイル」はさらに自由度が高く、正規表現を用いて適合する文字列を指定できます。例えば「A」「B」「C」だけを太字にする、いったような処理も簡単に行うことができます。ここでは正規表現そのものについては触れませんのでこちらをご参照ください。
 これら特殊スタイルはInDesign内では「段落スタイル」のみが適用されており、文字スタイルは「なし」になっているように見えるため、電子書籍制作時にきちんとした処理がされるのかどうかちょっと気になるところです。

 そこで、実際の電子書籍制作時の流れの中で、これら特殊スタイル類がどのように処理されるのか試してみました。

「スタイルをタグにマップ」で正常にタグが付加されないパターンがある

行スタイルのタグに問題が出る

行スタイルのタグに問題が出る

 最初に、私がこちらのブログ内で紹介しているあらかじめ各文字に段落スタイル・文字スタイルを適用しておき、「タグ」パレットの「スタイルをタグにマップ」でタグを付加してXML書き出しを行う方法をテストしました。

 まずはシンプルに「先頭文字スタイル」「行スタイル」「正規表現スタイル」を単体で適用してみます。「先頭文字スタイル」および「正規表現スタイル」についてはきちんとタグが付加されているようですが、「行スタイル」に関しては、最後の一文字に正常なタグ付加がされていないようです。

重ねがけで正常にタグが付加されない

重ねがけで正常にタグが付加されない

 次にこれら特殊スタイル類の重ねがけを試してみます。「行スタイル」を含んだ段落のタグが全て1文字ずつずれて適用されている他、「先頭文字スタイル」と「正規表現スタイル」との重ねがけに関しても、「先頭文字スタイル」のみがタグ付加され、「正規表現スタイル」の部分にはタグが付加されていません。これではちょっと危なくてタグの自動付加はできません
 なお、「行スタイル」の最後の1文字にタグが付加されないのは、バグの類ではないかと思われます。

IDMLには文字スタイルが書き出されない

XMDFビルダーに文字スタイルが取り込まれない

文字スタイルが取り込まれない

 次にIDML(InDesign Markup Language)形式でデータを書き出し、XMDFビルダーに取り込んでみます。これは緊デジのXMDF制作ガイドラインで想定されている制作方法です。

 どうやら、特殊文字スタイル類は完全に無視され、段落スタイルのみが取り込まれるようです。つまり、XMDFビルダー内で全ての文字スタイルを再割り当てすることになってしまいます。これはちょっと作業量的に避けたい流れです。

文字カラーを変更し、検索置換パレットを使用して文字スタイルを再適用する

 さて、結局どちらにしても文字スタイルの再適用は避けられそうにありませんので、出来るだけ楽をしてスタイル再適用の作業を行いたいところです。とりあえず以下のようなワークフローを考案してみました。なお、このワークフローを使用したことに伴うトラブルに関して、私として一切の責任は負いかねますので、こちらの作業を行う前には必ず元データをバックアップしておき、コピーしたデータで作業を行うことをおすすめします。

1 文字スタイルの「文字カラー」を変更する

文字スタイルの「文字カラー」を変更する

文字スタイルの「文字カラー」を変更する

 まず、先頭文字/先頭行/正規表現スタイル内で使用されている文字スタイルの「文字カラー」を変更します。多色刷りなどのデータの場合には、登録済みのスウォッチカラーがドキュメント内のいずれかの箇所に使われている可能性を考慮し、トラブルを避けるためにもスウォッチを新規作成して割り当てることをおすすめします。

2 先頭行スタイル内の先頭文字/正規表現スタイルを手動で処理

先頭行スタイル内の先頭文字/正規表現スタイルを手動で処理

先頭文字/正規表現スタイルを手動処理

 先頭行スタイルと先頭文字/正規表現スタイルが混在している場合は、まず先頭行スタイル内の先頭文字/正規表現スタイルに手動で通常の文字スタイルを再適用します。これは、3の検索置換処理で先頭行スタイル内の先頭文字/正規表現スタイルが検索にヒットしないためです。

3 パラメータを設定し、検索置換を実行

検索置換パラメータを設定

検索置換パラメータを設定

 検索置換パレットの「検索形式」に1で設定したカラーを、「置換形式」に1で文字カラーを変更した文字スタイルをそれぞれ指定し、ドキュメント全体に対して置換を実行します。全ての文字スタイルに関して同様の置換を実行します。

 これでとりあえず文字スタイルの再適用はできます。「行スタイル」内の先頭文字/正規表現スタイルを手動処理しなければならない問題はありますが、幸い「行スタイル」はそれほど頻繁に使用されているわけではないように思えますので、実作業的にそこまでの問題はないかと思います。
 また、「タグ」パレットの「スタイルをタグにマップ」でタグを付加する際のトラブルを防ぐため、文字スタイルの再適用を行った後に「スタイルをタグにマップ」を使用する場合には、全ての特殊スタイル類をあらかじめ削除しておいた方が良いでしょう。

 なお、「正規表現スタイル」の通常文字スタイルへの置換に関しましては、市川せうぞーさんが「正規表現スタイル由来の文字スタイルをリアル文字スタイルとして適用する」というエントリーで自動処理スクリプトを発表されておられますので、そちらを利用されるのも良いかと思います。

(2012.7.9)

市川せうぞーさんより、「正規表現スタイル」2つ以上を重ねがけしている場合でも「スタイルをタグにマップ」で正常にタグが付加されないとの情報をいただきました。例え「正規表現スタイル」だけしか使われていない場合でも、文字スタイルの再適用が必須になると考えておいた方がよさそうです。

(2012.7.9追記)

「代替字形」チェックボックスで要外字化文字を見分ける

2012/06/18

 以前のエントリーで、Unicodeにコード位置を与えられており、1文字で表現できる合字(U+2668「♨」など)をInDesign内で入力する際に方法が2通りあり、字形が全く同じであるために目視確認による校正作業ができない、といったことを書かせていただきました。「旧字体」「印刷標準字形」等に関しても同じ状況で、かなり困った状態だったのですが、InDesign環境設定の「代替字形」チェックボックスを使うことで、とりあえず合字などをどちらの方法で入力したものなのか見分けることはできそうですので、お知らせしておきたく思います。「すべての異体字」などで字形置換が行われている文字もこちらで見分けられそうです。ただし以下はあくまで一時しのぎの「対処療法」で、外字対策が必要な全ての文字が見分けられるわけではなく、使う上で十分な注意も必要になることをあらかじめご留意ください。

注意が必要だが、「代替字形」チェックボックスで置換字形のチェックが可能

InDesign環境設定「代替字形」チェックボックス

環境設定「代替字形」チェックボックス

 InDesignには環境設定メニューの「組版」タブ内に「代替字形」というチェックボックスがあります。本来の字形とは違う字形に置換して表示されている文字をInDesign内でハイライト表示するためのものです。このInDesign環境設定の「代替字形」チェックボックス自体ははるか以前からあり、確認した限りではCS2の時代から機能自体は存在していたようです。そんな機能があるなら以前のエントリーは何だったんだと言われそうなのですが、実はこの機能には重大な欠点があり、日本語組版で無条件に使用できる機能ではありませんでした。

句読点等までハイライトしてしまう

句読点等までハイライトしてしまう

 この「欠点」というのは「縦組み時の自動字形切り替え(vert)まで全てハイライト表示してしまう」というものです。これにより、句読点や括弧類、拗促音などまで全てがハイライト表示されてしまい、本来の対象文字以外が大量にピックアップされてしまいますので、縦組みで字形置換をチェックする目的ではまともに使えません(そして、印刷標準字形等の字形置換を使用している書籍は文芸書等に多く、そうした書籍は縦組みで制作されている場合が多いことは容易に想像できます)。

 ただ、今回は最終目的が「電子書籍にすること」ですので、縦組みで作成されたDTPデータであっても「組み方向を横組みに切り替える」ことでこの機能を有効に生かせるのではないかと思い、テストをしてみました。

横組み切り替え時の注意点

改行位置で合字が泣き別れ

改行位置で合字が泣き別れ

 組み方向切り替えには、注意しなければならない点がいくつかあるようです。まず、テキストボックスが「フレームグリッド」ではなく「テキストフレーム」になっている場合、改行位置に合字が来ていた場合に文字が泣き別れになってしまう可能性があるようです。テキストボックスが「フレームグリッド」になっている場合は、今回テストした限りではこの問題は出なかったのですが、データの状態次第では同様の問題が出てくる可能性はあります(ちょっとテストしきれません)。
 また、縦中横に設定されていた数字やアルファベット類、縦組みで表示することを前提として挿入されていたインライン画像類などのチェックにも影響が出そうです。

グリフ置換文字のみをハイライト

グリフ置換文字のみをハイライト

 こうした問題を考えると、「もとの縦組みドキュメントをコピーし、横組みに切り替えてあくまで代替文字のチェック用として使う」あたりが無難な利用法ではないかと思います。ドキュメントを2つ並べて横組みの文字のハイライト表示を参考に縦組みドキュメントを修正していくイメージです。

 テストしてみた限りでは、文字パレットの機能を用いて字形置換された合字や、字形パレットで字形置換された旧字体(つまり文字化けを起こすもの)のみがきちんとハイライトされますので、チェック目的に限定すれば十分役に立ちそうです。

字形パレットで合字を上書き

字形パレットで合字を上書き

 ちなみに例えば「温泉」で入力されて合字変換されている「♨」の親字を「♨」そのものに変換するには、字形パレットの表示メニューを「選択された文字の異体字を表示」にし、文章中でハイライト表示されている該当文字「♨」を選択して、字形パレット内に表示された字形「♨」をダブルクリックし、文字を上書きすればOKです。ただ、合字の場合、構成要素の一部分のみ(「温」のみなど)を引っかけて選択してしまうことが多々ありますので、慎重に構成要素全てを選択した上で文字を上書きする必要があります。

「代替文字」でチェックできない文字

 なお、このInDesignの「代替文字」チェックボックスでチェックできる、外字対応が必要になる可能性がある文字は「合字」「印刷標準字形」「すべての異体字」など、InDesign内の機能で字形切り替えが行われているものに限られます。「CID/GID番号のみしか割り当てられていない文字」「ビブロスフォントなどの外字フォントを用いて表示されている文字」「JIS規格の例示字形の変化の影響で字形の変わる可能性のある文字」などは、InDesign側で行われている字形切替ではないため、このチェックボックスではハイライト表示されませんので注意が必要です。「インラインで埋め込まれた外字画像」ももちろん同様です。こうした文字類は、別途チェックが必要ですのでご注意ください※1

※1 チェックした限りで「代替字形」でのハイライト表示対象は以下の通りです

合字:○(「♨」などUnicode1文字で入力できる文字のうち、文字パレットの「任意の合字」を用いて変換せずに入力された文字(=合字ではない)を除く)

旧字体・エキスパート字形(GlyphForm):○(字形置換が行われた文字のみハイライト)

すべての異体字(aalt):○ CID番号しか持たない文字:× 箇条書きリスト:×

スモールキャップス:× オールキャップス:○ 外字フォント:×

JIS例示字形の変化の影響で字形の変わる可能性のある文字:×

(2012.6.18)

電子書籍で外字を使うということについて

2012/06/06

 以前のエントリーで印刷用DTPデータを電子書籍化する際に発生する外字問題に関して書かせていただきました。緊デジの事業開始も迫っていますので、今回はそもそも電子書籍で「外字」を使うということがどういうことなのか、ごく一般的な注意点について書かせていただきます。なおこれは、主に出版社サイドの方に対してのエントリーのつもりで書いております。過去のエントリーとの表記の重複等があるかとは思いますが、あらかじめご了承ください。制作サイドの方向けには、別途出版デジタル機構さまより詳細な資料が提示されるかと思いますので、そちらをご参照ください。

現在電子書籍で使用できる文字数は、印刷物のそれよりかなり少ない

電子書籍で使用可能な文字の数

電子書籍で使用可能な文字の数

 さまざまな種類の「外字」そのものの定義については、こちらのWikipedia項目に詳細な説明がありますので、ここでは今回問題になりそうな電子書籍での「外字」について簡単に述べるに留めておきたく思います。

 上記Wikipedia項目の表記のうち今回問題となる「外字」は、「文字コードなどの特定の文字集合に含まれない文字」を指します。より詳細には、印刷用文字集合規格であるAdobe-Japan1※1に含まれていながら、UnicodeやShift_JISに含まれておらず、テキストファイル内でそのまま表示できない文字のことです。

 一例として「小塚Pr6N」の場合を見てみますと、InDesignで使用できる文字数は23058文字、うちEPUB等で使用できるUnicodeで表現できる文字数は15393文字です。XMDF/ドットブックで使用できるShift_JISの場合はさらに少なくなり、約7000文字です。UnicodeやShift_JISで表現できない文字は、外字画像として表現するか、もしくはInDesignがバックグラウンドで保持している親字への変化を容認するかといった対処が必要となります。

合字/CIDのみの文字の文字化けの例

合字/CIDのみの文字の文字化けの例

 つまり、現状電子書籍で使用できる文字数が、印刷用データの作成環境で使用できる文字数よりかなり少ないために、外字での対策が必要となります。この「UnicodeやShift_JISで表現できない文字」のうち、以前のエントリーでも書いたように「複数の文字コードで構成された合字」や「CID/GID番号のみしか割り当てられていない文字」等のテキストで表現できない文字については、そのままテキストで表現はできないため、基本的に制作会社サイドの責任で外字画像にすることになります※2

親字への字形変化の例

親字への字形変化の例

 一方で、出版社サイドでXMDF・ドットブック/EPUBで表現できる文字に変化することを許容するか、外字にして対応するかの判断が必要となりそうなのは、「印刷標準字体」「エキスパート字形」「JIS90字形」などの微細な字形変化に関する部分です。厳密に印刷物と同じ字形の再現を求めた場合、かなりの文字を外字にすることになりますが、現状、電子書籍(およびWeb)の外字表現には、以下のような問題点があり、通常の紙印刷物と同じような外字の表現は技術的にできません。ご一読いただければ幸いです。

印刷物と電子書籍での「外字」表現の違い

 通常、印刷用DTPデータの制作で外字を挿入する場合には、

1 Illustrator等で外字画像を作り、InDesignの文中に画像をインラインで挿入する
2 フォント作成ソフトを使ってフォントを作り、InDesign内からそのフォントを指定する
3 Biblosなど市販の外字フォントを使用し、InDesign内からそのフォントを指定する

外字がはっきりと確認できてしまう

外字がはっきりと確認できてしまう

 などの手順が考えられますが、いずれもきちんと制作されていれば、実際に印刷した際には周囲の文字とほとんど区別がつきません。しかし、現状の電子書籍での「外字」は、テキスト内にPNG等の形式で制作した「画像」を挿入する形になるため、文章の流れの中ではっきりと「外字」であることがわかってしまうことがしばしばあります

 また、現状電子書籍ではテキストを表示するフォントについても制作サイドで指定することはできず、読者が選んだビューアーに依存することが多いため、外字にした文字が通常テキスト部分とはっきりと違ってしまうといった問題が起きてきます。

フォントを変更しても外字はそのまま

フォントを変更しても外字はそのまま

 さらに、読者の好みで本文フォントを切り替えられるビューアーも存在するため、読者がこうしたビューアーを選択した場合、なおさら「外字」がはっきりと目立ってしまう可能性が高くなります。本文をゴシック体に切り替えても外字部分だけは明朝体のまま、といった状況が起こり得ます

 参考画像は、緊デジで制作されたものではありませんが、実際に現在市販されているXMDF電子書籍内での外字表示の例です。外字がはっきりと見分けられる状態がご確認いただけるかと思います。

 加えて、例えばEPUB3で「外字にルビを振る」といった処理をした場合に、一部のビューアでルビが表示されないといった現象も確認できています。EPUB3の日本語表現に関してビューア側の実装がまだ定まっていないため、このビューアを問題視できるような状況ではありませんが、こうした状況も存在していることをご理解いただければ幸いです。外字は通常のテキスト表示とは異なる「例外的な処理」になり、電子書籍は紙印刷物とは違って読者サイドの閲覧環境の対応も必要になるため、こうした状況は今後も出てくることが考えられます。

 あくまで個人的な意見ですが、コンテンツの最終的な完成度を考慮した場合、現状の電子書籍での外字対応は固有名詞等に限定し、最小限に留めたほうがコンテンツの相対的な品質は上がるのではないかと考えております。

将来的にはテキストの一部として異体字を表現できる可能性がある

 なお、こうした状況は、漢字の異体字に関しては将来的にUnicode IVSが普及し、異体字を画像としてではなくテキストの一部として(つまり外字ではない形で)表現できるようになれば相当改善されるかもしれません。ただし、前述したように従来の紙印刷物とは異なり最終生成物は紙ではありませんので、IVSに関しても制作環境側だけではなく読者の閲覧環境側での対応も必要となります。従って、順当にIVSが普及するとしても実際にコンテンツ内でIVS異体字を使用できるのはまだ当分先の話になりそうです。

 今回の例でもわかるように、電子書籍はあらゆる意味で黎明期であり、紙書籍と同様の表現力を持つにはまだまだ時間がかかります。各出版社のみなさま、制作会社のみなさま、書店のみなさまのご理解・ご協力をいただき、共に新たな文化を健全に育成していければ良いと考えております。

 なお、以下に以前の記事をもとにPDF化した、外字化が必要となりそうな文字の簡単な資料を用意させていただきました。ご参照いただければ幸いです。

 

 今回お世話になりました方々は以下の通りです(50音順/順不同)。私一人ではこの資料を整えることは到底不可能でした。みなさまの深い知識・技術にあらためて尊敬の念を感じるとともに、ご協力に心からお礼を申し上げます。

 ありがとうございました。

※1 Adobe-Japan1コレクションには1-6/1-5/1-4などがありますが、ここでは現在最もグリフ数の多い1-6を例として取り上げています。各文字集合規格の詳細につきましては、こちらのページが参考になります。

※2 単位などは通常の文字列に置き換えるといった対応も考えられますが、いずれにせよ一定のルール策定が必要と思います。また、各種字形変化に関しましては、市川せうぞーさんに制作していただいたムービー群が参考になります。あわせてご参照ください。

・Unicodeポイントを持たず、CID番号しか持たない文字は「1A」という文字に化ける

・「箇条書きリスト」の機能を用いて入力したリストの頭につく番号/記号が消える

・「スモールキャップス」「オールキャップス」の大文字が小文字に変わる

・ビブロスフォントセットは元の文字に変わる

・SINGグリフレット機能を利用して入力した異体字・外字は基底文字に戻ってしまう

(2012.6.6)

 EPUB3での外字ルビに関する部分につきまして、実際には存在しない「日本語EPUB3」という規格が存在しているかのような誤解を与えてしまうのではないか、とのご指摘をいただきましたので、表記を「日本語EPUB3自体規格策定が済んでいるとは言い難いため」から「EPUB3の日本語表現に関してビューア側の実装がまだ定まっていないため」に訂正させていただきました。

(2012.6.8追記)

プロフィール
Jun Tajima

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

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