最終版はこちらに公開されています：解像度とは

デジタル画像は明るさや色の情報を持った画素（ピクセルまたはドット）単位で表現する。解像度は画像をどの位まで詳細に表現できるかを表す用語であるが、いろいろな使い方がある。例えば、スキャナーやプリンターのように、アナログの紙を対象として画像を入出力する機器ではドット密度を解像度という。それに対して、デジタルカメラ、ディスプレイ、デジタル画像ファイルでは、縦×横のピクセル数を解像度という。

アナログ機器の解像度と分解能
望遠鏡では遠くの物体をどの程度まで分解して鮮明に見れるか、という意味で解像度を使い、分解能ともいう。光学式望遠鏡の解像度はレンズの口径に比例する。顕微鏡や銀塩（アナログ）カメラでも、接近した二つの点をどの程度まで区別できるかを分解能または解像度という。

スキャナーやプリンターの解像度
スキャナーやプリンターはインチ当たりの画素数（dpi、ドット・パー・インチ）で解像度を表すのが一般である。スキャナーではdpiが大きいほど詳細に読み取ることができ、プリンターではdpiが大きいほど印字精度が高くなる。スキャナーやプリンターは紙という寸法をもつアナログ媒体を対象にしているため、解像度を望遠鏡や顕微鏡と同じような意味合いで使うのだろう。

デジタルカメラやスマホの解像度
デジタルカメラやスマホは撮像素子（CCDやCMOSなど）の総画素数（縦方向の画素数×横方向の画素数）を解像度という。これらの機器では、レンズなどの光学系や受光してから記録するまでの画像処理によって、分解能に相当する解像度は大幅に異なる。

ディスプレイの解像度
スマホやタブレットを始め、電子書籍端末、パソコンなどのディスプレイは、画面の物理的なピクセル数（縦ピクセル数×横ピクセル数）を画面解像度という。また、画面のインチあたりピクセル数（ppi、ピクセル・パー・インチ）を解像度ということもあるが、ppiは画素密度という方が分かりやすいだろう。

デジタル画像ファイル
スマホで撮影したデジタル画像はJPEGで保存されることが多い。また、デジタル画像の形式としてはPNGやGIFなども普及している。これらのデジタル画像は、横ピクセル数×縦ピクセル数が画像のサイズであり、これを画像解像度という。また、JEPG画像には、画素密度（ppi）を指定できるが、これを解像度ということもある。画素密度は指定されていない画像も多く、アプリケーションがppiを常に参照するとは限らない。ブラウザは画像ファイルのppi値を参照しないようだ。

画像の表示におけるサイズ
デジタル画像はプリンターに出力したり、ディスプレイに表示するときに物理的なサイズが決まる。例えば、横600ピクセル×縦1200ピクセルの画像を600dpiのプリンターに出力すれば、横1インチ（2.54cm）×縦2インチ（5.08cm）の大きさとなる。また、400ppiのタブレットに表示すれば、横1.25インチ（3.17cm）×縦3インチ（7.62cm）のサイズとなる。しかし、スタイルシートなどで版面や表示領域の幅に対して画像の占める幅の比率を指定することも多い。このとき、画像は指定領域にフィットするように拡大・縮小される。

肉眼でみる画像の解像度
画像をプリンタやディスプレイに表示するとき、肉眼の解像度よりもはるかに低い場合は、画像がぼけて見える。逆に、肉眼の解像度よりもはるかに高い解像度で表示しても、肉眼で識別できないので無駄である。従って、肉眼の解像度よりも少し高い解像度で表示するのが効率的である。

肉眼の解像度は視力で表す。視力1.5の場合、5mの距離でランドル氏環というC字型の指標の1mmの幅を識別できる。実際に実験すると明視距離(25cm)では約360dpiまで識別できるそうである。従って、印刷や表示時の画像解像度は360dpiよりも多少大きいのが適切となる。

最新のスマホのディスプレイは400ppiに達している。例えばiPhone6Plusは401ppiである。iPhone6Plusの画面解像度は1,920 x 1,080ピクセルなので、フルスクリーンの画像ファイルであれば1,920 x 1,080ピクセル程度のサイズで作成し、拡大・縮小なしで表示すると効率的だろう。

最終版：外　字

外字は、使用頻度の少ない文字の配置場所、あるいは、その字形の表し方をいう。漢字のような図形に意味を持たせる文字では外字は常に大きな問題である。しかし、活版の時代、文字コードのサイズが小さい時代、現在のように大規模文字コードが使われる時代で外字の問題は変質している。

活版印刷の時代には漢字は活字として用意され、文撰職人が原稿を見ながら文撰用の棚に並んだなかから活字を拾った。この作業を効率化するため、印刷会社では漢字を使用頻度の多い順から、大出張、第一出張、第二出張など、外字として分類し、棚に並べるにあたりその配置を工夫していた。大出張は使用頻度の多い文字なので、中央のかなの上部で拾いやすい位置に配置し、外字は使用頻度が少ない文字なので活字を拾うのに背を伸ばしたり、かがんだりしなければならない位置に置かれた。文撰用の棚が沢山ある場合は、さらに使用頻度の少ない外字は工場の一角に別の棚を設けることもあった。

1970年代末にJIS漢字コード表が制定されたが、初期のJIS漢字コード（JIS C 6226:1978）では、第一水準漢字、第二水準漢字、非漢字を併せて6802文字が規定された。しかし、①、②などの丸付数字や、㈱、㈲を初めとして利用頻度の多い文字で規定されないものがあった。情報機器のメーカはJIS漢字コード表に規定されていない文字を独自に選定し外字として独自の文字コードを割りあてた。JIS漢字コード表は、第一バイト21～7E（94区）、第二バイト21～7E（94点）の矩形領域に文字種を割り当てるものであったが、一部の区、点は文字が割り当てられていなかった。そこで外字コードの割り当て方法としては、①JISコード表の区点範囲で文字が割り当てられていない空き領域に独自に追加文字を割り当てる方法、②JISコード表の表外の領域に追加文字を割り当てる方法（IBM拡張文字は7F区以降に割り当て）があった。

1970年代末にはワープロ専用機が登場したが、ワープロ専用機の多くはメーカーがあらかじめ空き領域に割り当てた外字（システム外字）に加えて、ユーザーが文字の字形をデザインするツールを用意し、ユーザーがデザインした外字（ユーザー外字）も使用可能とした。パソコンのMS-DOS、初期のWindowsやMacintoshも独自にシステム外字を定義した。このようにシステムで定義する外字は機種依存文字とも呼ばれ、システム間で非互換の文字が多かったため、JISコード外の文字を正しく情報交換するのが困難であった。

JIS C6226は、その後JIS X0208になり、さらにJIS X0208を包含し、1万文字を超える文字を規定するJIS X0213が制定された。そしてWindowsやMacOSでJIS X0213の文字がすべて使えるようになり、またUnicodeの普及など文字集合が大規模化することで、システム外字が必要という事態は少なくなった。しかし、現在は、新しい外字問題が生じている。

漢字の一番大きな分類は字種である。字種とは文字の意味（字義）や文字の読み（音）、正字・俗字のように歴史的経緯から見て同じ文字であるみなされる文字である。一方、一番細かい分類は目に見える文字の形である字形（デジタルフォントではグリフという）である。一つの文字に対してデザイン差までを考慮すれば字形は無数になる。これに対して、JISコード表は漢字の字体を符号化する。字体とは字形を抽象化した字の骨格であるとされている。JISコード番号には抽象的な字体が割り当てられており、そのコード番号の文字は字形（グリフ）を通じてしか可視化できない。印刷されたJISコード表に記載されているのは字形であるが、これは例示とされている。

現在、外字が使われるのは次の2つのケースがあるだろう。使用する文字コードの枠組みを、例えば、JIS X0213:2004と決めたとき、①JIS X0213:2004で規定する字体の範囲外の字体を使いたいとき、②JIS X0213:2004で規定する字体であるが、グリフが使用するフォントにない場合もしくは使いたいグリフをフォントに依存することなく指定したいときである。①は1970年代から継続する伝統的な外字問題である。

例えば、EPUB3の制作ガイドである電書協ガイドでは、「JIS X 0213:2004 の文字集合にない文字は外字画像化」するとされている。外字画像方式では外字には文字コードを使用しないで、外字を画像で表し、その画像を文字と同じ大きさで行中にインライン配置する。しかし、外字画像を利用すると、文字コードがないので検索ができなくなったり、音声読み上げができないなとの不都合が生じてしまう。

基準とする文字コードの枠組みで表せない文字は画像などで表すことになるのはやむをえない。外字画像を使わないようにするには基準とする文字コードをより大規模な文字集合にするしかない。

一方、②に属する問題は解決方法がある。市販のEPUB電子書籍にはJIS X 0213:2004 の文字集合で規定されている文字で、JIS X0213:2004に対応するフォントで使えるグリフが外字画像化されているケースもあることが、facebookなどのSNSなどで報告されている。これは制作時の環境のフォントではグリフがないところで、文字の形を優先したいという趣旨かもしれない。もし、このような問題が予想される時はフォント埋め込みが一つの解決策となる。使用したいフォントが埋め込みできない場合は当該の文字だけのフォントを制作してEPUBにフォントを埋め込むことを推奨したい。

JEPAの「いまさら聞けない電子書籍のABC ~ebookpedia~」の下書きです。最終版は、JEPAのページをご参照ください。

電子ドキュメント内の文字情報は文字コードを使って表されるが、文字コードだけでは文字の形は分からない。文字コードをもとに文字の形を描画するにはフォントを使う。電子ドキュメント作成時にフォントのデータを内部に含めることを「フォント埋め込み」という。フォントを埋め込んだ電子ドキュメントを配布すれば、受け手は埋め込まれたフォントを使って文字を可視化できるので、例えば太字、丸文字など、ドキュメント作成者の意図した形で文字を表現できる。

フォントの所在
モバイル機器、PCなどの機器（デバイス）で、電子ドキュメントを可視化するにはデバイス・OS・リーダアプリなどに装備されているフォントのデータを使うのが普通である。Webフォントという、インターネット上のフォントサーバーからフォントのデータを入手して表示する技術も普及し始めた。

アウトラインフォント
デジタルフォントでは文字の形をグリフという。フォントは、一定のデザインのもとに作成した多数のグリフの集合である。一つの文字コードに対して複数のグリフが用意されている文字も沢山ある。もっとも成功したデジタルフォントであるアウトラインフォントはグリフを曲線で描画する。この描画パラメータをグリフデータという。OpenTypeのようなインテリジェントなフォントは、グリフデータに加えて、文字コードからグリフデータへの対応表、縦書・横書などでのグリフの切替表、ある文字を表示したとき、次の文字をどこに表示するか決めるためのグリフの各種寸法、配置すべき位置に関するデータ（フォントメトリックス）などの付随データをひとつにまとめて提供している。

電子ドキュメント作成時のグリフの扱い
電子ドキュメントを作成するとき、グリフの扱いを大きく分けると次の3通りになる。
① 電子ドキュメントに文字コードのみを含め、グリフデータは含めない（フォント埋め込みなし）
② 電子ドキュメントに、グリフデータを含める（フォント埋め込み）。
③ フォントからグリフデータを取り出し、グリフを描画する線画データに変換してから電子ドキュメントに埋め込む（アウトライン化）。
アウトライン化は特殊な用途なので除外し、以下では、①フォント埋め込みなしと②フォント埋め込みについて、a. 表示の違い、b. PDFとEPUBの埋め込み方法を比較しながら説明する。

フォント埋め込みの有無による表示の違い
受け手が電子ドキュメントを表示するとき、フォント埋め込みがないときとあるときでの相違を簡単に説明する。

(1) フォント埋め込みなし電子ドキュメントの表示
電子ドキュメントの表示アプリケーションは、デバイスやアプリなどがもつフォントを使う。電子ドキュメントの中で指定されているのと同じフォントが使えないときは、類似のフォントを使う。表示に使うフォントが文字コードに対応するグリフをもっていないとき、持っていてもグリフの形がオリジナルを作成したフォントと違うときは文字を正しく表示できない。また、多くの場合、フォントが違うとフォントメトリックスが異なるので作成時と文字の配置が変わり、レイアウトが崩れてしまう。

(2) フォント埋め込みあり電子ドキュメントの表示
フォントを埋め込んだ電子ドキュメントは、埋め込まれたフォントを使って表示すれば、文字の形や配置が変わることなく、作成時のレイアウトを再現できる。但し、表示アプリケーションによっては正しく再現できない。これはアプリケーションの責任である。

PDFとEPUBのフォント埋め込み方法の比較
PDFとEPUBでは、フォント埋め込みの技術的な仕組みは相当に異なる。次にそれぞれの仕組みを簡単に説明する。

(1) PDF
PDFは文字の位置を正確に指定する機能を備えている。そこでPDF作成ソフトがPDFにフォントを埋め込むとき、PDF作成ソフトはテキスト中の文字コードからレイアウトされたグリフIDにする。必要なグリフデータはPDF中の共有リソースとして保存される。そしてグリフIDから文字コードへの対応表（ToUnicodeCMAP）も作成する。中には、ToUnicodeCMAPを作成しないPDF作成ソフトもあるが、このようなPDFでは文字を検索したり、テキストの読み上げ、テキスト取り出しができない。このようにPDFのフォント埋め込みではフォントの中のグリフデータだけを使うので、それをPDF以外に転用するのは困難である。

(2) EPUB
EPUBのコンテンツ文書はXHTMLであり、テキストは文字コードで表される。EPUBのリーダーはフォントを使ってコンテンツを可視化する。このためEPUBのフォント埋め込みはフォントファイルの形式で埋め込む必要がある。具体的にはWebフォントと同じ方式で、CSS3の@font-face規則でフォントの属性とフォントのパスを記述する。Webフォントとの相違は、EPUBのフォント埋め込みではフォントファイルを自分のパッケージ内に含めるのに対して、Webフォントはフォントの存在をURLで示す点である。

サブセット化・難読化
フォント埋め込みのオプションについて説明する。

(1) サブセット埋め込み
電子ドキュメント作成時にフォントを埋め込むとき、フォントの中の全ての文字ではなく、その電子ドキュメントで使われている文字のみに絞ってグリフデータを埋め込むことをサブセット埋め込みという。日本語は文字数が多いのでフォントのサイズが大きい。サブセット化するとサイズを大幅に圧縮できるので、日本語のフォント埋め込みではサブセット化が重要である。PDFのサブセット埋め込みでは使われているグリフデータだけ集めれば良いが、EPUBのサブセット埋め込みはEPUB作成の度にサブセットフォントを作成する必要がある。Webフォントでも指定されたフォントファイルを丸ごとダウンロードするのではなく、フォントサーバーでダイナミックにサブセット化するのが普通なので、技術的には同じである。

(2) 難読化
EPUBのフォント埋め込みではフォントファイルの形式で埋め込むため、フォントを取り出してEPUB表示以外の目的につかうことも難しくない。目的外利用を抑制するため、フォントファイルの内部を解読し難くすることを難読化という。EPUB作成時にフォントが難読化されると、EPUBリーダーではそれを解読して読む必要がある。このため難読化に関しては作り手と消費側で合意が必要であり、EPUB3.0の仕様書には難読化のアルゴリズムやキーの使い方を規定している。

埋め込みとフォントの権利
フォントはプログラムとして著作者の権利が認められている。フォントを埋め込んだ電子ドキュメントの作成・頒布は、フォントの一部または全部の複製と再配布に該当するので、原則として著作権者の許諾が必要である。

PDFが登場したのは1990年代の後半であるが、当初はフォントを埋め込まないPDFは読み手の環境によっては正しく表示できないという問題による誤解や混乱が見られた。フォント・ベンダーによってはライセンス契約に埋め込み許諾・制限・不許可を記載している。しかし、PDFを作成するにあたって、ユーザーがいちいちフォント・ベンダーの許可を確認するのは面倒である。そこでOpenTypeにはフォントファイルに「埋め込み許可フラグ」が設定されており、PDF作成ソフトがそのフラグをみて埋め込みできるかどうか判断するという枠組ができている。また、1998年には日本タイポグラフィ協会は「電子ドキュメントデータへのフォント埋込み機能に対する タイプフェイス／フォントの権利保護に関する声明書」[1]で秩序ある埋め込みを許容する方向を示すなど、フォント埋め込みが幅広く使えるようになっている。この結果、どこでも、だれでもPDFを正しく表示できるようになった。このようにPDFの普及にあたってフォント埋め込みが果たした役割は大きい。

EPUBへのフォント埋め込みを許諾するかどうかはフォント・ベンダーによって方針が異なるようだ。またフォントファイルの「埋め込み許可フラグ」がEPUBを想定しているかどうかも不明である。こうしたことでEPUBのフォント埋め込みはまだ普及していない。フォント埋め込みが普及すれば、特殊な文字や外字などをイメージファイルとして表す必要がなくなるし、さらに文字による表現力が豊かになる。フォント埋め込みの普及を期待したい。

[1] 電子ドキュメントデータへのフォント埋込み機能に対する タイプフェイス／フォントの権利保護に関する声明書

〇Facebookで頂いたコメント