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

日本語表現(組版)での文字の問題について簡単なまとめ

2020/08/24

 文字の規格に関して改訂の議論が始まっているので、現在技術的な問題を残していそうな文字のリストを出して欲しいというボールを投げられましたので簡単にまとめてみました。なおどのレベルにどういう形で投げるべき問題なのかはこちらでは細かな分類はしていません。ざっくりとしたリストとして見ていただければと思います。

「全角ダーシ」の問題

 主にDTPデータからの電子化での問題です。私の把握している限りで、DTP等のデータで「ダーシ」として使われている文字は以下のものがあります。

 U+2014(EM DASH)
 U+2015(HORIZONTAL BAR)
 U+FE31(PRESENTATION FORM FOR VERTICAL EM DASH)
 U+2500(罫線素片)

 このうち、U+2014は、フォントによって縦書きで中央に来ないケースが多くあるため、DTPではこれを嫌ってU+2015を使用しているケースが多く見られるようです。
 U+FE31は中央に来るようですが、電子化に際して書き出すと自動で横棒にならず、縦棒のまま残ってしまうため別の文字に置換する必要があります。

さまざまな文字が「ダーシ」として使われている


さまざまな文字が「ダーシ」として使われている

 また、ダーシは1文字幅で使うだけではなく、2文字幅の「二倍ダーシ」として使用するケースが多く見られます。二倍ダーシとして連続入力した場合、U+2014/U+2015ともに文字間に隙間ができるデザインのフォントが多く、これを避けるために本来はダーシとして使うべきでないU+2500の罫線素片を使っているケースがあるようです。これは実質的に現状フォントの指定ができない電子書籍では通常の対応となっているのではないかと思います。
 DTPではU+2015を使い、縦200%の変倍をかけているケースが多く見られるようですが、これは電子化のためにそのままテキスト化すれば変倍の情報が飛んで1倍ダーシになります。このため置換処理が必要となります。さらにU+2015はJIS X 0213外の文字であり、厳密にJIS X 0213内での電子化対応を求める場合※1には何らかの文字に置換しなければならないという問題もあります。

(参考:https://www.youtube.com/watch?v=p9YUx_AeypA

波ダッシュと全角チルダの問題

 Webを含めさまざまな場面で起きている問題です。過去のさまざまな経緯により以下の文字が混用されています。
 U+301C(WAVE DASH)
 U+FF5E(FULLWIDTH TILDE)

 現在多くの商用フォントではグリフで見分けがつきません。このためDTP的には問題は顕在化していませんが、U+FF5EはJIS X 0213外の文字のため、電子化では置換処理が必要になることがあります。なおこれ以外の文字混用問題も別項目で取り上げていますが、このケースはUnicodeの規格のミスなども絡んでいてだいぶ根が深いので単独で挙げておきます。参考リンク先の記述がかなり詳細ですので、この問題の概要はそちらをご覧ください。

波ダッシュと全角チルダはグリフでは見分けがつかない

波ダッシュと全角チルダはグリフでは見分けがつかない

(参考:https://qiita.com/kasei-san/items/3ce2249f0a1c1af1cbd2

和文引用符の問題

 DTPデータからの電子化での問題です。U+201C/U+201Dのダブルクォートは、InDesignの機能によってダブルミニュート※2として表示させることができます。ただし、バックグラウンドで持っている文字情報はU+201C/U+201Dのままなので、電子化に際してテキスト化するとグリフが変わってしまいます。このため置換処理が必要となります。U+301D/U+301Fのダブルミニュートをそのまま使えばこの問題はクリアできますが、これはInDesignの禁則文字に入っていない文字のため、InDesignで禁則文字のカスタマイズが必要となります。

InDesingからテキスト化するとグリフが変わってしまう

InDesingからテキスト化するとグリフが変わってしまう

(参考:https://www.youtube.com/watch?v=p9YUx_AeypA

和文中の欧文引用符の問題

 DTPデータからの電子化での問題です。和文組版では通常、和文中の欧文であっても引用符にU+0022を使わず、U+201C/U+201Dをダブルクォートとして使うケースが多く見られます。同様に、アポストロフィとしてU+2019を使い、U+0027を使わないことも慣例となっているようです。
 これはU+0022/U+0027の字形が「間抜け引用符」などと呼ばれてデザイン的に嫌われたために起きたものですが、U+201C/U+201D/U+2019はUnicode上では全角幅/半角幅で異なるコードポイントを与えられてはいないため、テキストとして書き出した際に不自然なアキが引用符の前後に入るケースがあります。このため、電子化に際してはU+0022/U+0027に適宜置換して対応したりします。これはまた、Kindleが縦組み時にU+201C/U+201Dを強制的にU+301D/U+301Fのグリフで表示してしまうことへの対応策でもあります※3

Kindleでは縦組みでのダブルクォートはダブルミニュートとして表示される

Kindleでは縦組みでのダブルクォートはダブルミニュートとして表示される

グリフで見分けが付かないが使うべきでない文字の混用問題

 Webを含めさまざまな場面で起きている問題です。よく見られるのが「康熙部首」としてUnicodeに収録されている文字(U+2F00〜U+2FD5)を、通常の漢字と混用しているケースや、キリル文字の「А」「В」「С」「Е」「О」「Р」などを通常のアルファベットの文字と混用しているケースです。また、漢字の「二」とカタカナの「ニ」の混用も時々見られます。
 これらはおそらくOCRの誤認識などが混入の原因と思われますが、グリフを目視で見分けて修正することが極めて困難であるため、何らかの機械的な処理で混用を防ぐことが期待されます。康熙部首などは特殊なケース以外では使用されない文字であるため、機械的な1対1の置換でかなりの場合カバーできるかと思います。

康熙部首と通常の文字は見分けがつかない

康熙部首と通常の文字は見分けがつかない

絵文字の異体字表示文字の混入問題

 現在、Web等で絵文字が日常的に使われるようになってきており、それに伴って絵文字の異体字表示文字がDTPの元データや電子書籍のテキストに混入し、意図しない表示結果を引き起こすケースがあるようです。符号位置としてはU+FE00〜U+FE0Fがそれに当たります。

時計数字や丸数字などかつての機種依存文字対応の残滓

 現在、時計数字や丸数字などはその多くがUnicodeに独自のコードポイントが与えられており、テキストとして扱えるようになっていますが、かつて機種依存文字として扱われた経緯があるため、現在でも例えば時計数字の「Ⅳ」をアルファベットの組み合わせの「IV」で入力する等の対応をしているケースがあります。少なくともDTPデータや電子書籍では、アクセシビリティへの正しい対応のために本来のUnicodeの文字を使うべきと思います※4。また、丸数字の外字での対応等も極力控えた方がよいと考えています。

その他問題がありそうな文字

 一部の文字が電子化の際に縦組みで左右中央に来ないため、別の文字に置換したり、場合によっては外字化しているケースがあるようです。確認できている文字は以下の通りです。こういったものはフォントのグリフに依存するため、まだ同種のものがあるかもしれません。
 「•」(U+2022/BULLET)
 「…」(U+2026/三点リーダー)

 以上になります。当然他にも問題のある文字はあるかもしれません。今なら規格側での修正の可能性もあるようですので、どんどん意見を上げましょう。

※1 電書協ガイドでは現在、使用する文字の範囲をJIS X 0213の範囲内とすることを規定している。一部のリーディングシステムが厳密にJIS X 0213内のグリフしか持たないフォントを表示フォントとして採用しているため。

※2 「ノノカギ」「チョンチョン」などと呼ばれることもある約物。

※3 Kindleのみの将来解決されうる問題であるとして許容する解釈もある。

※4 例えば音声読み上げ時に「フォー」ではなく「アイブイ」と読み上げられてしまうため、アクセシビリティ的には問題。

(2020.8.24)

 コメントでご指摘いただいた点に関して修正しました。

(2020.8.25)

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

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

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