‘未分類’ カテゴリーのアーカイブ

Microsoft EdgeのEPUB表示チェック

2017/04/02

 Microsoftの標準ブラウザ、Edgeが4月のアップデートでEPUB表示に対応するとのニュースがあり、Insider Preview版のWindows10環境をセットアップして表示の確認を行ってみました。
 これまで、MacではiBooksによってOSレベルでのEPUB対応ができていましたが、WindowsはデフォルトアプリでのEPUB閲覧に対応しておらず、これがファイルとしてEPUBを配布する際の障害となっていたことは否定できません。今回EdgeがEPUBに対応したことで、近い将来PDFのような気軽さでEPUBを配布することができるようになったわけです。
 さて、その表示能力はどこまでのものなのか。以下、表示チェック結果です。項目名は電書ラボEPUB制作仕様のそれに準じています。

こちらをクリックすると表示結果ページに飛びます)

 なお、テストには「Windows 10 Insider Preview Build 15058」を使用しております。これは正式リリース前のベータ公開版ですので、正式公開時には仕様の修正が行われている可能性は当然あります。あらかじめご了承ください。また、表示確認用のテストEPUBファイルとして、電書ラボで公開中のチェック用epubファイルを使いました。

文字・字形

Unicode IVSの表示に対応

Unicode IVSの表示に対応

 サロゲートペア文字、Unicode IVS(異体字セレクタ)共に対応できているようです。一部の文字が化けて豆腐になっていますが、これはMSゴシックが当該文字のグリフを持っていないことが原因と思われます。Insider Preview版では日本語フォントの切り替えができませんでしたので、ここはこれ以上はわかりません。
 また、U+2014(EM DASH)が二分幅で表示される、U+005Cのバックスラッシュが円記号「¥」として表示されるなどの挙動が見られましたが、いずれもフォントに起因する問題と思われます。

組版表現(文字)

縦中横表示に対応

縦中横表示に対応

 縦中横の表示に対応しているようです。ただし、最新の正式プロパティであるtext-combine-upright:allの指定が必要で、text-combine:horizontal、epub-text-combine:horizontal等の指定では効きません。
 なお縦中横の実装方法としては何文字であっても変形させて1em幅に入れ込む方式のようです。ちょっと不満な点としまして、半角文字1文字であっても横幅1emに変形してしまうため、かなり横長に潰れて見えます。1文字の場合には両側にスペースを入れ、1emの中央に入れる形へ仕様変更して欲しいところです。
 また、文字の正立/横転指定(text-orientation)を行った場合に、文字のサイズが異常に大きくなる不具合が見られましたが、再度テストした際には確認できませんでした。何らかの条件によって症状が出るのかも知れません。
 埋め込みフォントはOTF、WOFFに対応、TTF(TrueType)は非対応ということのようで、これはEPUB3のコアメディアタイプに合致します。いずれはTTFにも対応してもらえれば嬉しいですが、現状での対応としてはまずは妥当と言えるでしょう。
 また、部分言語指定には現状非対応のようです。日本語と中国語の混じった文書での字形の正しい表示や、日本語内の英語の正確な読み上げ等に絡んできますので、将来的には対応して欲しいところです。

組版表現(段落)

縦組みの表で表示に不具合

縦組みの表で表示に不具合

 字間アキ・ツメ指定(letter-spacing)、行間アキ指定(line-height)、段落間アキ(margin)など、基本的な指定は全て問題なく働くようです。
 tableを使用した表組みでは、複数ページにまたがる表の表示で罫線(border)が表示されない挙動が見られた他、縦組みの表が複数ページにまたがった場合に項目が重なって表示されてしまう不具合が見られました。

組版表現(ページ)

縦組み時に写真が下にはみ出す

縦組み時に写真が下にはみ出す

 page-break指定による改ページには対応しているようです。
 改丁/見開き指定(opf内spine項目でのpage-spread指定)は非対応のようで、章扉を見開きの左ページに必ず配置する、等の指定は現状効きません。
 また、本扉などで用いられる文字の左右中央指定も現状中央に文字が表示されないようです(電書協ガイドP40での記述方法でチェック)。これは電書協ガイドの参照記法自体が割とピーキーなのは否定できないので無理は言えませんが、多くのビューアで対応済みではあるので対応を期待したいです。
 囲み罫の表現ですが、通常のケースではほぼ問題がないものの、縦組み時にカコミ内に画像を配置した際に画像が下方向のpadding指定を無視してはみ出るという挙動が見られました。これはKindleのiOS版で見られるのと同じ不具合ですが、Edgeの場合は縦組みの場合のみ見られるようです。

組版表現(注・索引・コラム)

注のポップアップに対応

注のポップアップに対応

 なんと、注がポップアップされるようです(epub:type=”noteref”指定箇所のポップアップ表示対応)。ただし、注と本文が同一のXHTML内にある場合のみに限られるようで、ファイルが分かれている場合には通常のリンクとして動作します。現状注のポップアップができるビューアはEdge以外ではiBooksとKoboのiOS版のみと思いますので、ここはなかなか尖った実装かと思います。

画像

画像のサイズ指定が効かない

画像のサイズ指定が効かない

 現状透過PNG形式、透過GIF形式に非対応の模様で、全て背景色が白として表示されます。
 SVGは通常の画像として挿入する限りにおいてはほぼ表示できるようですが、複雑なパターンの部分は表示できず、黒になるようなケースもありました。
 また、現状縦組みでの画像のサイズ指定が効きません。横組みでもかなり効くケースが限られるようです。個人的な希望としましては、他のビューアとの互換性を考えるとimg要素への%指定が効くようになると嬉しいところかなと思っています。

外字画像

外字画像が異常に大きく表示される

外字画像が異常に大きく表示される

 外字画像は異常に大きなサイズで表示されてしまいます。これは明らかな不具合ですので、早急な修正が待たれます。絶対に外字が入らないと言い切れるコンテンツは日本語の電子書籍ではほぼないのが現状ですので。

目次

論理目次の階層表示に対応

論理目次の階層表示に対応

 論理目次の階層表示に対応しているようです。ルビは表示できないようですが、これは現状表示できないビューアの方が多いので仕方ないところかなと思います。

 以上ですが、最後にちょっと感心したポイントを挙げておくと、EdgeのEPUBビューアは簡単に音声読み上げができるようになっており、画面右上の読み上げボタンでEPUBの音声読み上げを体験できます。かなりアクセシビリティを意識したつくりと言えるでしょう。
 EdgeのEPUB閲覧機能は正直現時点で相当いいところまで到達しているものと思いますので、今後の継続的な改定・機能向上を望みたいところです。個人的には、スクロールモードでの表示はあってよいのではないかと思っています。

(2017.4.3)

6/8 JEPAセミナーでの調査結果を踏まえ、縦中横の挙動に関する部分の表記を修正しました。

(2017.6.9追記)

「Kindle パブリッシングガイドライン 2017.1」更新内容チェック

2017/02/21

Amazon Kindle向けコンテンツ作成の仕様書、「Amazon Kindle パブリッシングガイドライン」が更新されていたようですので、更新部分を含めてリフロー型電子書籍作成に関する部分をざっくりとチェックしました。英語版はこちら。以下、見出しは元文書の見出し項目そのまま、赤字はリジェクトの可能性があるなど特に重要と思われる箇所です。電書協ガイドとの互換性についての考察も入れています。ご一読ください。

“4.1 マーケティング用表紙画像は必須です”

Amazonの商品ページやアファリエイトリンクなどに表示される書影画像(マーケティングカバー画像)についての規定です。最低サイズ2700×1600px以上、解像度300ppi以上、サイズ5MB以下のJPEG画像が必要とあります。また、「価格やその他の一時的な販売促進の提供に言及する」表紙画像は使用できないとの文言があり、例えばオビに価格やキャンペーン情報を書いてあるケースに注意が必要そうです。

“4.2 内部コンテンツ表紙画像は必須です”

電子書籍の中に入れるカバー画像についての規定です。サイズに関してはここには特に指定はありません。なお、表紙画像のOPFでの指定方法に関しての記述がありますが、現状ではもう電書協ガイド準拠で大丈夫な模様です。過去には表紙画像が2回表示されたりしていました(Kindle側がEPUB3の標準的な記述に対応したために直ったと思われます)。

“5 ナビゲーションのガイドライン”

「すべての Kindle 本には、論理目次を含める必要があります」との記述があります。入っていないとリジェクトされる可能性があると捉えるべきでしょう。まあこれは電書協ガイドに最低限の論理目次は最初から入っていますので、それに沿ってデータを作っていれば問題はないです。

“5.1 HTML 目次のガイドライン”

コンテンツ内に通常のページとして表示される目次ページについての規定です。<table>タグを使ってのレイアウトはするな、元の本のページ番号は記述するなというような内容です。これはまあごく常識的と思います。

“5.2.1 toc nav 要素を使用して論理目次を作成する”

toc nav 要素を使用した論理目次の記述方法についてのガイダンスです。電書協ガイド含むEPUB3での一般的な論理目次はこのtoc navを使って作ることになっています。なお、リストのネストによる目次の階層表示のサンプルが載っていますが、これは以前チェックした時点では正常に表示できないRSが多数ありましたので、Kindle以外のストアでも販売することを前提としたEPUB3の中で使うのであれば、対象ストアのRSでの事前表示チェックは必要になるでしょう。

“5.2.2 NCX を使用して論理目次を作成する”

EPUB2の仕様であったNCX文書での論理目次の記述方法についてのガイダンスです。以前はKindleではこちらの方法で記述しないと論理目次が表示されませんでしたが、現在ではtoc nav 要素の記述だけで問題ありません。

“5.3 ガイド アイテム”

目次とは別に、コンテンツ内の論理的な構造を規定するためのガイドの記述方法です。Kindle内の目次(論理目次)に表示される「表紙」「目次」「最初のページ」などのリンクページ指定と思ってください。
今回新しく「読み始め開始位置は定義する必要なし」との記述が加わっています。また、以前にはあった読み始め開始位置の指定方法の項目が消えている模様です。おそらく以前にちょっと話題になっていたKindle Unlimitedでの読み始め開始位置を後ろに持って行き、読まれたとKindleに認識させることでKENPCを稼ぐ(アメリカでの)Kindle Unlimitedの悪質ハック対策としての対応でしょう。
つまり制作側での「最初のページ」指定の有無にかかわらず、販売時のAmazonサーバ側の処理で自動的に「最初のページ」の部分が決定されるようになったと思ってよいと思います。販売前に端末にサイドロードしてのチェックと表示結果が変わってくるケースもありそうですので、注意が必要です。

“6.3 スクリプトを避ける”

Javascript非対応。元ソースに含まれていても自動で削除されるとのこと。

“6.4 ファイル参照は、ソースのスペルと大文字と小文字の区別を一致させる”

大文字・小文字を区別するので注意との記述。ハマったことが一度あります。

“6.6 サポートされる文字とスペースの使用”

サポートされているスペースは、通常のスペース、改行なしスペース (&nbsp;)、ゼロ幅の非結合子 (&zwnj;)です」という記述があります。英語コンテンツなどで使われることのある4分スペースなどは保証外なので注意が必要そうです。
また、「問題を起こす可能性があるため、Unicode 形式の文字は使用しないでください。」という一見意味のわからない記述があります
直前に「文字を書き表すときは、プレーンテキストの UTF-8 の文字を使用します」との記述もあるわけなのですが、Unicodeは本来符号化文字集合の国際規格で、UTF-8はUnicodeをコンピュータで使うための符号化方式のひとつですので、文字通りに取ると使える文字がひとつもなくなります。誤訳を疑って原文も見てみたのですが、「Do NOT use Unicode format characters, as they may cause problems.」とあり、原文の時点で意味が通りません。
おそらくここで「Unicode」と呼んでいるのはWindowsのメモ帳などで保存する際に出てくる(MSの呼称としての)「Unicode」形式の話ではないかと思います。つまり実際に指しているのはUTF-16エンコーディング非対応ということでしょう。となるとEPUB3は仕様上UTF-16も文字コードとして認めているようなので、AmazonとしてはUTF-8のみを用いるということで話はわからなくもないです。ただ、これは技術仕様文書なので技術用語は正確に扱って欲しいです。ちょっとこれを思い出してしまいました。

“6.7 電子書籍での読みやすさを重視する」を追加”

見出しの意味がちょっとわからないのですが(混入しているカギ括弧もママ)、原文は「6.7 Design for a Good eBook Experience」なので、まあ電子書籍制作の一般的注意として、原本のレイアウト再現にこだわりすぎるなという文言かと思います。レイアウトにこだわってフィックスで出すのではなくてリフローで出しましょう、と。

“7 外部リンクのガイドライン”

外部Webページへのリンクに関する規定です。「性的コンテンツへのリンク」「顧客情報の入力を要求する Web フォームへのリンク」「違法、有害、不正、不快なコンテンツへのリンク」はまあわかります。注意すべきは「Amazon 以外の電子書籍ストアへのリンク」でしょうか。これに引っかかるとリジェクトの対象になります。

“8.1 Kindle 本のテスト”

出版前の品質チェック方法に関しての記述です。まあ特に問題はないんですが、iOS版のKindleアプリでのチェックには.azk形式に変換してからiTunesで同期しないとダメ、みたいな話は書いておいて欲しいです。

“9.3.1 本文では必ずデフォルトを使用する”

リフロー型書籍の本文全体に対して文字サイズ(font-size)や行高(line-height)、文字色(color)は指定するなという規定です。部分的にはもちろんOKです。本文全体に対する地色(background-color)の指定もNG。まあこれはKindleに限らずダメですが。
要注意なのは、この規約に沿っていなかった場合、アップロード時にサーバ側で強制変換されるとの記述が追加されていることです。サイドロードしての表示チェックではOKだったものが、実際に販売されると内容が変わってしまう可能性があるため、注意が必要そうです。以下該当部分をそのまま引用します。

  • コンテンツの大部分に使用されているフォントサイズは 1em に正規化されます。
  • コンテンツの大部分に使用されている font-family はルートタグ (本文) に変更されます。
  • 本文に使用されている強制フォントカラーが削除され、テキストの色を変更できるようになります。
“9.3.3 大半の要素に固定値を使用しない”

ピクセル数指定などの相対値で値を記述せよとの規定です。Webサイトと同じ感覚で電子書籍を作るとハマりかねない落とし穴ですので注意は必要ですが、一般的な話です。なお、「改ページを確実にするために、Kindle ソフトウェアでは 1.2 em または 120% 以下の line-height 値の使用はお勧めしません。」との記述があり、ここは注意が必要そうです。

“9.3.7 埋め込みフォントを使用する”

埋め込みフォントの使用規定です。対応形式としてOpenType (OTF) およびTrueType (TTF) の形式が挙げられています。ただ、埋め込みフォントに関しては以前にOTFを埋め込んで作成したコンテンツが、販売時にはサーバ側処理でフォントが削除されて表示されていなかったという経験があり、現在まだ調査中です。日本語フォントはTrueTypeのみという話なのかも知れません。その場合、EPUB3の仕様での標準Core Media TypeにTrueTypeは含まれていないとの話(参考)もあり、いろいろと問題が出てくる可能性が捨てきれません。
また、等幅フォントのサポートについての記述があります。<pre>、<code>、<samp>、<kbd>、<tt>、<font face="courier">、<font face="monospace">のタグで記述すれば等幅で表示するとのこと。コンピュータ技術書などでは必要になりそうです。

“9.3.10 脚注のガイドライン”

脚注の相互リンクが推奨から要件に変わっています。これは影響が大きそうです。電子書籍では確かに現状リンクを貼らないと注が参照しにくいのですが、全ての本での対応となると工数がかなり増えそうな点が心配です。また、Kindle専用端末での脚注ポップアップ仕様は以前にテストした際にはだいぶ不安定でしたので、ちゃんとepubの標準仕様に沿った形で仕様改訂して欲しいところです。

“9.4.1 サポートされている入力形式を使用する”

対応画像形式についての規定です。、「GIF、BMP、JPEG、不透過 PNG、SVG 画像」とあります。透過PNGに相変わらず非対応なのは残念ですが、SVGに対応を公式に謳っているのですね。
なお、注記に「画像ファイルのカラープロファイルには RGB を指定してください。 Kindle は sRGB と CMYK をサポートしていません。」との表記があります。「sRGBをサポートしない」という文言はだいぶ意味がわかりません。CMYKカラーモデル非サポートの話とRGBカラーモデル内規格であるsRGBの対応の話を併記されても困ります。RGB色空間に関する規格にはsRGBの他にAdobeRGBがありますが、これはカメラマンが撮影した画像をきっちりカラーキャリブレーションを取ったモニタ環境で色補正する際などに使うもので、この場合に出てくる話とも思えません。タブレットやスマートフォンなど一般的な機器向けのコンテンツなら画像のカラーは通常sRGBになるはず。
詳しい方に確認を取った感じでは「カラープロファイル指定に非対応なので付けられてもそのままパススルーで出力するよ」くらいの意味だろうという話なのですが、それであればそういう表記が欲しいところです。

“9.4.2 画像のサイズおよび品質の基準”

画像のサイズに関しての規定です。なおここはリフロー型電子書籍内の画像に関しての記述なので、hon.jpのこの記事は誤報です。通常写真集はフィックス型で作ると考えられますので。どうも元記事内に「写真集」という記述も見当たらないようで、どこから出てきたのか謎です。あとこれはそもそもKDPのガイドラインではなくて、KDP以外の出版社からのコンテンツにも影響が及ぶ「Amazon Kindle パブリッシング・ガイドライン」の改訂ですしね。元記事にはしっかり “Amazon Kindle Publishing Guidelines” の表記があります。
肝心の画像サイズに関しては、全ページに表示する場合で「300 ppi で 1200 x 1800 ピクセル以上」との記述があり、この数値自体にそう無理はないと思います。ただ、「9.4.5 写真は高解像度の端末用に最適化する」に「端末の画面いっぱいに表示する画像ならば、画像の幅を 3,200 ピクセル (最高解像度の端末である Kindle Fire HDX 8.9" の画面幅の 2 倍) にします。」との記述があり、これは相当な高解像度です。素直にこれに従って作ってしまいますと、Appleのガイドライン文書、iBooks Asset Guide「画像のサイズは400万画素以下」という規約を簡単に超過し、iBookStoreでは販売できないEPUBが出来上がりそうです。注意が必要でしょう。上記の数値はあくまでAmazonの推奨に過ぎないので、現実的には現状では長辺2000px程度に止めた方が良いと思います。

“9.4.3 レスポンシブ レイアウトの画像サイズ”

「width スタイル属性でパーセンテージの値を使用して、ブロック画像とフロート画像をスタイル化することをお勧めします。 これにより、端末の解像度に関係なく、画像が画面の大きさに対して同じパーセンテージで表示されます。」との文言があります。こちらでテストした限りでは、現状まだKindle iOS版ではサイズの%指定が効きません。仕様として推奨するのであれば、RSの改訂もそれに準じて進めて欲しいところです。

“9.5.1 大きな表を避ける”

「表形式のコンテンツには、表を画像として表示するのではなく、HTML の <table> レイアウトを使用することをお勧めします」との文言があります。アクセシビリティの観点からテキスト検索できる形で表を挿入すべきという話はわかりますが、iOS版Kindleでセル幅の%指定が効かないという問題が現状ありますので、そこは直して欲しいところです。
また、「すべてのサイズの端末に最適となるように、表の大きさを 100 行 x10 列以内にすることをお勧めします。」との文言もあるのですが、元データにある列の数を勝手に弄れるなら苦労はありません。

“9.5.3 必要に応じて表を分割する”

画像としての表を分割する場合のガイドラインです。ヘッダを両方の表につけるようにという記述があります。ちょっと手間はかかりそうです。

“9.5.4 タイプセッティングの改善による表機能”

これはKindle専用端末のアップデート 5.8.2で追加された「タイプセッティングの改善」機能に準じてのテーブル作成ガイドライン文書のようです。<thead><tbody><tfoot>タグで論理構造をしっかり書くようにとの記述があります。この機能はまだちゃんと試していないのですが、iBooksでのテーブル組みの表ポップアップ表示的な機能かと思います。

リフローに関してはこんなところかなと思います。正直、制作仕様の規定文書としては粗い記述が目立ち、またこちらで推奨されている方法でコンテンツを作成してもRS側の実装が追いついていないためにレイアウト等が乱れるケースが出てきそうです。十分な注意は必要でしょう。

(2017.2.21)

EPUBの外字画像の使用事例について

2016/11/10

 JEPAの村田真さんよりEPUB Accessibility 1.0絡みで現状のEPUBでの「外字画像」の使用事例を知りたいとのお話をいただきましたので、私の知る限りで書いてみます。何人かの方にもお話をお聞きし、参考とさせていただきました。

 どういった種類の外字かをわかりやすくするために、各種文字集合規格のマップを作成し、各外字がどこに位置するかを以下に図示しました。解説の番号に対応しています。併せてご参照ください。

外字の分布

画像内で使用している文字関連の専門用語をまとめて記述しておきます。

  • Unicode:1991年にバージョン1.0が出版された国際的な符号化文字集合の規格。世界中の文字を単一の文字集合で表記することを目的としている。2016年6月にUnicode9.0が出版されている。詳しくはこちら
  • JIS X 0208:1978年に最初に制定された日本の符号化文字集合の規格。改訂年度によって「JIS78」「JIS83」「JIS90」などと呼称される。JIS第2水準までの漢字をサポートしている。詳しくはこちら。これとセットで運用された符号化方式がShift_JIS
  • JIS X 0213:2000年に最初に制定された日本の符号化文字集合の規格。改訂年度によって「JIS2000」「JIS2004」などと呼称される。最新版は「JIS2013」。JIS第4水準までの漢字をサポートしている。詳しくはこちら
  • Adobe-Japan1-6:アドビシステムズ社によって制定された符号化文字集合の規格。商用日本語OpenTypeフォントの採用している文字集合規格のデファクトスタンダードである。実際に販売されているフォントのうち、「Pr6」「Pr6N」という名前が付いているものがこの規格のもの。「N」はデフォルトの字形をJIS2004の例示字形に対応させたものを指す。内包する文字数の異なる下位規格としてAdobe-Japan1-5(Pr5/Pr5N)、Adobe-Japan1-4(Pro/ProN)、Adobe-Japan1-3(Std/StdN)などがある。詳しくはこちら
  • Unicode IVS:異体字セレクタ。親文字(漢字)と、Unicodeの第14面(追加特殊用途面)に収録された異体字表示文字を組み合わせることで、漢字の微細な字形差を表現できるようにするためのもの。これにより例えばAdobe-Japan1-6の包含している字形の再現が電子書籍やWebで期待できるようになる。詳しくはこちら
  • 基本多言語面:Unicodeの0面。もともとはここに全ての文字を収録する計画だったが、足りなくなったために桁(面)を増やした経緯がある。詳しくはこちら
  • 追加漢字面:Unicodeの2面。CJK統合漢字拡張や補助漢字などの文字が収録されている。詳しくはこちら

特定の文字集合規格で表現できない文字を「外字画像」にしているもの

❶ Adobe-Japan1-6にしかない文字の外字化

Adobe-Japan1-6にしかない文字の例

Adobe-Japan1-6にしかない文字の例

 Adobe-Japan1-6の文字は、そのほとんどがCMapによってUnicodeと紐付けられていますが、ごく一部Adobe-Japan1-6にしか収録されておらず、Unicodeと紐付いていないために実質的にInDesign等のDTPアプリ内でしか使えない文字(参照:CID/GID番号のみしか割り当てられていない記号類)があります。これは外字画像にする以外の方策はありません。

(追記)事例画像には一部既にUnicode符号化済の文字を含んでいます。

❷ 中国語の人名など日本語フォントで現状表示できない字形を表示するための外字化

日本語と中国語のフォントで字形が違う例

日本語と中国語のフォントで字形が違う例

 簡体/繁体中国語の人名など、現状日本語フォントで表現できない字形を表現するために外字画像を使用しているケースです。これはUnicodeの符号位置としてはAdobe-Japan1-6内のものが多数含まれると思われますが、その場合でも日本語と中国語では符合位置が同じでも割り当てられている字形(グリフ)が微妙に違うことがあるため、外字画像にせざるを得ない場合があります。学術書などでは厳密な字形の再現が要求されるケースも当然出てくるため、そういったケースでは現状では外字画像にすることになります。

 将来的にEPUB内での部分言語指定を各RSがサポートし、デバイスが対応する各国語のフォントを搭載すればテキスト化できるかと思われます。

❸ Adobe-Japan1-6内の異体字の字形を保つための外字化

 InDesignなどのDTPアプリ内では使用できるものの、テキスト化するとGSUBの情報が消えてしまうために字形を維持できなくなる文字の字形を保持するために外字画像としているケースです。

 典型的なのはJIS90字形を保持するために外字画像としているケースです(参照:JIS90字形とJIS2004字形で変化する文字の一覧)。この問題は古くはJIS78→JIS83の字形変化の問題、いわゆる「新JIS旧JIS問題」にまで遡る話ですので、割に根は深いと思います。

段落スタイルで印刷標準字体を指定

段落スタイルで印刷標準字体を指定

 また、EPUBのビューアに搭載されているフォントは現状ほとんどがJIS2004字形の「Pr6N」などのフォントであるにも関わらず、JIS2004字形を外字化してしまっているケースもあるようです。おそらく元の印刷データでJIS90字形基準のフォント(Pro/Pr5/Pr6)が使用されており、InDesignなどDTPアプリの機能でJIS2004字形のグリフを割り当てていた(「印刷標準字体」を段落スタイルで割り当てるなど)ケースで電子化の際に字形の維持を図ったものと思われますが、これは明白に意味がないためやめた方がよいと思われます。

 将来的にUnicode IVSが標準的に使用できるようになれば微細な字形の再現はテキストで可能になるはずですが、まだIVSを付加した文字が縦組み時に横転してしまう実装のビューアがあったりするなどRS側の状況が不安定なこと、InDesignデータから字形情報を保持したままUnicode IVSのテキスト化することが技術的に難しいことなどから、厳密に字形を保持するには当分は外字画像化が必要になるでしょう。

 ただ、このあたりの文字はもともとがJISの「包摂」範囲で、本来は規格内に双方の字形を含んでおり、JIS2000からJIS2004では「例示字形」が変わっただけです。微細な字形差に留まるケースが大半ですので、人名などどうしてもやむを得ない場合以外はテキスト化を許容した方がよいと考えています。

 なお、このあたりの話は以前に私のブログで書いておりますので、併せてご参照ください。Unicode IVSに関してはこちら。WindowsやMacも既にOSレベルでのUnicode IVS対応は済んでいますので、あとはInDesignなどDTPアプリの対応待ちという印象です。

❹ JIS X 0213内だがUnicodeの基本多言語面外の文字の外字化

 JIS X 0213内の文字で、少数ですがUnicodeで基本多言語面(BMP)外のCJK統合漢字拡張Bのエリアに割り振られた漢字が存在します。特に注意が必要なのは「𠮟」(U+20B9F)および「𠮷」(U+20BB7)です。
 「𠮟」はJIS第3水準漢字ですが、類似の文字にJIS第1水準の「叱」(U+53F1)があるため、通常はこちらで代用可能でしょう。ただ、「𠮟」の方が常用漢字とされたため(参照)、厳密に常用漢字の使用を求めた結果、外字画像となっているケースはあるかも知れません。

 また「𠮷」は人名に用いられる漢字ですので、厳密な字形の再現が求められるケースはそれなりにありそうに思います。例えば元首相の「𠮷田茂」氏の「𠮷」がこの字形です。通称「ツチヨシ」と呼ばれる、割に一般的な人名の異体字です。

 基本多言語面(BMP)外の文字は、展開するために内部的に2つの符号位置を必要とする処理となる(サロゲートペア)ため、長く表示に問題のある状態が続いていました。具体的にはついこの間までWebkit系のエンジンを用いるRSで縦書き時に正常に文字が表示されないなどの問題がありましたので、現状市場に出ているEPUBにはこれを回避するための外字画像を含むものが多数あるものと思われます。

 2016年11月現在では、EPUBのサイドロードに対応しているメジャーどころのRSで正常に表示ができておりますのでほぼ問題は無くなったと考えていますが、サイドロード非対応のRSも数多く存在しますので、完全な確認は私も取れておりません。

❺ JIS X 0213外だがAdobe-Japan1-6内の文字の外字化

 そう数は多くありませんが、Adobe-Japan1-6には含まれるものの、JIS X 0213には含まれない文字が存在します。漢字では例えば「髙」(U+9AD9)がそれに当たります。通称「ハシゴダカ」と呼ばれるかなり一般的な人名の異体字です。この文字はJIS X 0213としては通常の「高」に包摂されると見なされたため、独自の符号位置を与えられませんでしたが、Unicodeでは日本以外からの要望によって収録され、結果的に使えるようになったために広く使われているという経緯があるようです。

 また、記号類が多く含まれ、例えば「㈠」「㈳」「㈪」「⑴」「⒜」などがあります。これらはかなり一般的に印刷物で使用されている文字です。特に縦書きの文章でよく見かけます。

 「髙」や「㈠」「㈳」「㈪」「⑴」「⒜」といったような文字に関しては、現状メジャーどころのほぼ全てのビューアで文字の表示が可能になっているようですので、現状そこまで神経質に外字画像にする必要はないと考えています。

 (追記)一部、日本語フォントとしてIPAフォントを採用しているRSがあり、IPAフォントにはJIS X 0213までのグリフしか収録されていないため、外字化せざるを得なくなるという話もあるようです。

❻ XMDF/.bookのデータを変換した影響での外字化

 過去に作られたXMDFや.bookをEPUBに変換したケースで、XMDFや.bookが符号化方式としてShift_JIS(文字集合はJIS X 0208)を用いていたために、使用できなかったJIS第3水準、第4水準の漢字が外字画像になっているケースがあります(正確にはXMDFはバージョン3でUnicodeに対応したが、ほとんど普及していない)。XMDF/.book由来以外にも、処理プログラムの一部にShift_JISベースのものを用いているケースで同様の事例はありそうです。

 文字としては既にテキスト化可能であっても、過去に制作して既に市場流通しているものに再度手を加えるには当然ながら相応のコストが見込まれますので、まだしばらくはこういったものも市場に残りそうです。

縦書き絡みの「外字画像」

❼ 縦書き時に3桁以上の英文字/4桁以上の数字を縦中横で挿入するための外字化

InDesignでは等幅4分字形が使える

InDesignでは等幅4分字形が使える

 現状、EPUBで縦中横指定で表示対応可能な英文字/数字の桁数はRSによって大きな差がありますが(参考:項目3-1)、各RSの最小公倍数としては英文字2桁、数字3桁が最大値で、それ以上は外字としないと横転表示されてしまうRSが出てしまいます。このため、3桁以上の英文字/4桁以上の数字の縦中横組版の再現のために外字としているケースがあります。

 通常例えば数字なら3桁あればほとんど組版の問題はなく、4桁の縦中横は相当なレアケースではありますが、Adobe-Japan1-6には等幅4分字形のグリフが収録されていたりもしますので、まったくのゼロではありません。そういったケースでは外字画像を利用することになります。

 将来的にRSが3桁以上の英文字/4桁以上の数字の縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❽ 化学式のようなものを縦中横で挿入するための外字化

 化学式のように上付き/下付き文字を含むものを縦中横で挿入するために外字画像としているケースがあります。「H2O」のように3桁以上になるケースも多くあるため、複合的な要因で外字化せざるを得ません。

 将来的にRSがこういったものの縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❾ 一部記号類の正立/横転指定にRSが対応していないための回避措置としての外字化

Kindleでは時計数字は必ず正立する

Kindleでは時計数字は必ず正立する

 一部記号類の正立/横転指定にRSが対応していないために縦書き時に外字にせざるを得ないケースがあります。一例としてはKindleでの時計数字(Ⅰ、Ⅱ、Ⅲ・・・)の挙動があります。Kindleでは時計数字は必ず縦書きで正立する文字として扱われ、明示的に横転の指定(text-orientation: sideways)を行っても正立してしまいます。このため、例えば欧文との混植を行って欧文内に時計数字を含めるようなケースでは、横転させて表示するために外字とせざるを得ません。こういった文字は時計数字以外にも複数あります。(参考:KADOKAWA-EPUB PORTALでダウンロードできる資料内の「20150123-文字の向き確認用【全頁版】.pdf」)

 EPUB/Webにおける縦書き時の文字の向きの挙動のデフォルト値については、UTR #50で一応の標準化がされ決着がついているのですが、まだRSレベルでの差異はあり、また(過去のドキュメントとの互換性を考えれば簡単に変えられないのは当然ですが)InDesignやWordのデフォルト値とUTR #50の間にも差があります(参考)。このため、当分ある程度RSの挙動に差異が残るのは仕方ない部分はあると考えています。

 ただ、デフォルト値はともかく明示的に横転を指定しても正立してしまう挙動はちょっと困ります。Kindleは他の記号類を見る限りtext-orientationの指定自体には対応しているので、一部の文字のみ指定が効かない挙動を早く修正して欲しいところです。

❿ Kindleが縦書き時に一部文字の字形を誤って置換表示してしまうため回避措置としての外字化

右:Kindle/左:iBooksの表示結果

右:Kindle/左:iBooksの表示結果

 Kindleで縦書き時にダブルクォート(「“」U+201C 「”」U+201D)をダブルミニュート(ノノカギ/「〝」U+301D 「〟」U+301F)に強制置換して表示する挙動があるため、回避措置として外字としているケースがあります。行頭字下げなどの挙動を見る限りでは、どうやら字形のみを置き換えて表示しているようです。

 縦書きでダブルクォートの代わりにダブルミニュートを用いるというのは組版のルールとしては間違っていませんが、あくまで制作者が判断して行うべき措置で、RSが勝手に強制置換をしてしまうのは困ります。例えば縦書きの文中に欧文をダブルクォートで包んで表示したいようなケースでは、ダブルクォートは欧文の一部なので横転したダブルクォートとして表示させたいのですが、Kindleはこれも強制的にダブルミニュートにしてしまいます。このため、外字画像にせざるを得なくなります。

 なお、二重引用符には他にU+0022の「"」があり、こちらは問題なく表示できます。外字とせずこちらを使用しているケースもあるでしょう。

文字を分離禁止にするための「外字画像」

⓫ 一部記号を分離禁止で表示させるための外字化

繰り返し記号の使用例

繰り返し記号の使用例

 二倍ダーシ(U+2014「—」/U+2015「―」/U+2500「─」)や連続する三点リーダー(U+2026「…」)などを改行による分離を禁止して表示させるために、あえて外字画像としているケースがあります。個人的にはこれはやや神経質すぎだと思っていますが、二倍ダーシなどについてはもともと活版印刷の時代には通常のダーシとは違う約物として存在していたなどという話もあるようですので、そういった影響がずっと尾を引いているのかも知れません。

 このほか、古い文献で多く見られる繰り返し記号にも2つの文字を組み合わせて用いる前提のものがあり(U+3033「〳」+ U+3035「〵」/U+3034「〴」+ U+3035「〵」)、これを確実に分離させずに表示させるために画像とするケースがあるようです。
 現状多くの出版社は一般的にはそこまで厳密な記号類の分離禁止を求めていないと思われますが、学術書などで厳密な組版の再現を求められるケースでは外字にせざるを得ないという判断はあり得るでしょう。

 これらはいずれCSSでの特定の文字の分離禁止指定がほぼ全てのRSで効くようになればテキストで表現できるものと思います。

RS側の組版再現が現状不完全なための「外字画像」

⓬ 合字の組版再現のための外字化

InDesignで使える合字の例

InDesignで使える合字の例

 現状、多くのRSではまだ、DTPアプリ内では合字(リガチャ)として表示できるものが分離して表示されてしまう挙動が見られます。このため、組版再現のために外字とせざるを得ないケースがあります。

 具体的には通常濁点や半濁点を付けないカナ文字にU+309Bの合成用濁点やU+309Cの合成用半濁点を付けて特殊な表現を行うケース(例:「あ゛あ゛あ゛あ゛あ゛」)や、英語以外の欧文でアクセント組み合わせ済みのグリフを持たない文字へアクセント類を付加したいケースが考えられます。

 これらのケースはいずれほぼ全てのRSで合字の組版再現が可能になってくればテキストで表現できるものと思います。

⓭ 数式組版の再現のための外字化

 現状、多くのRSではまだ、MathMLによる数式の表示再現はできていません。また、MathJaxなどもJavaScriptを使用できないRSが多数ありますので使用できません。このため、数式の組版を再現するために外字もしくは画像として挿入しているケースがあります。

 いずれほぼ全てのRSがMathML等に対応すればテキストで表現できるようになっていくものと思われます。

⓮ 日本語での斜体を再現するための外字化

InDesignの斜体機能

InDesignの斜体機能

 EPUBでは文字に対して「font-style:italic」を指定することでイタリック体として表示されますが、日本語の部分に対する指定は斜体になるRSとならないRSがあります。

 日本語にはイタリック体はないからこれが正しいという意見もあるようなのですが、斜体自体は写植の時代からあった機能であり、DTPでもこれを引き継いで実際の印刷物の中で使われている以上、場合によってはどうしても再現しなければならないケースは出てきます。このため、外字もしくはブロックごと画像としています。

 いずれほぼ全てのRSが日本語の斜体指定に対応すればテキストで表現できるようになっていくものと思われます。

⓯ 特定のフォントデザインを保持するための外字化

 特定のフォントのデザインをEPUB内で保持するために、外字もしくはブロックごと画像とするケースがあります。これはどちらかと言えば見出しなどをブロックごと画像とするケースの方が多いでしょう。

 現状、日本語のEPUBではゴシック体と明朝体のそれぞれ平体と太字、合計4種類の書体バリエーションしか使えません。モリサワパスポートのようなサブスクリプション契約をもとに多種多様なフォントを自由に使って表現できるDTPの世界とは雲泥の差があります。フォント埋め込みで対処できればよいのですが、現状まだフォント埋め込みに対応していないRSが存在し、また商用フォントのEPUBでの使用ライセンスに目処が立っていません。このため、外字とせざるを得ないケースが出てきます。

 いずれほぼ全てのRSがフォント埋め込みに対応し、商用フォントのライセンスに目処が立ってDTPに近い形で自由にフォントを使えるようになればテキストで表現できるようになっていくものと思われます。

その他

⓰ アイコンなどもともと文字でないものをインライン表示させるための外字化

 その他、もともと文字ではないアイコン類をインラインで表示させるために技術的手段として外字としているケースがあります。これは実用書などでは多々あります。これらはDTPのデータ内でも画像として挿入されていたケースが大半ですので、将来的にも外字として残るものと思います。こういった類のものは「もともと文字ではない」ので仕方がないものと思われます。

 以上、さまざまな外字画像のパターンを挙げてみました。誤解や過剰なこだわりによって外字にしないでもよい文字を外字としてしまっているケースもありますが、多くは現状のEPUBの技術的制約や、印刷物の表現にまだまだ遠く及ばないEPUBの表現力の中でどうにか印刷物に近い表現を実現するためにやむなく外字としていることがおわかりいただけると思います。

 将来を考えればバッドティップスとなりかねない外字はできるだけ使用を控えるべきという意見には私も賛成なのですが、とはいえ「今」電子書籍を購入してくれた読者に不満を持たせるわけにはいきませんので、そこはどうしてもせめぎ合いにはなるかと思います。

 また、書籍の場合、権利そのものは当然著者のものであり、本来的には出版社や制作会社がたとえテキストの細部であれ勝手に改変するわけにはいきません。何らかの形で承諾が必要になります。これは著作権(同一性保持権)が絡む話です。このため、もとが紙の書籍を電子化するケースではどうしても外字とせざると得ないケースは出てきます。

 EPUBの表現の拡充や、RS側の実装の充実によって少しでもテキストで表現できるケースが増えることを願っております。

(2016.11.14)

 コメントをいただき、IPAフォントに関する部分などを追記いたしました。

(2016.11.14)

プロフィール
Jun Tajima

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

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

最近のコメント