外字は、使用頻度の少ない文字の配置場所、あるいは、その字形の表し方をいう。漢字のような図形に意味を持たせる文字では外字は常に大きな問題である。活版の時代、文字コードのサイズが小さい時代、現在のように大規模文字コードが使われる時代で外字の問題は変質している。活版印刷の時代には漢字は活字として用意され、文撰職人が原稿を見ながら文撰用の棚に並んだなかから活字を拾った。外字として分類し、棚に並べるにあたりその配置を工夫していた。大出張は使用頻度の多い文字なので、中央のかなの上部で拾いやすい位置に配置し、外字は使用頻度が少ない文字なので活字を拾うのに背を伸ばしたり、かがんだりしなければならない位置に置かれた。文撰用の棚が沢山ある場合は、さらに使用頻度の少ない外字は工場の一角に別の棚を設けることもあった。併せて6802文字が規定された。1、2などの丸付数字や、(株)、(有)を初めとして利用頻度の多い文字で規定されないものがあった。情報機器のメーカはJIS漢字コード表に規定されていない文字を独自に選定し外字として独自の文字コードを割りあてた。JIS漢字コード表は、第一バイト21~7E(94区)、第二バイト21~7E(94点)の矩形領域に文字種を割り当てるものであったが、一部の区、点は文字が割り当てられていなかった。そこで外字コードの割り当て方法としては、1JISコード表の区点範囲で文字が割り当てられていない空き領域に独自に追加文字を割り当てる方法、2JISコード表の表外の領域に追加文字を割り当てる方法(IBM拡張文字は7F区以降に割り当て)があった。1970年代末にはワープロ専用機が登場したが、ワープロ専用機の多くはメーカーがあらかじめ空き領域に割り当てた外字(システム外字)に加えて、ユーザーが文字の字形をデザインするツールを用意し、ユーザーがデザインした外字(ユーザー外字)も使用可能とした。パソコンのMS-DOS、初期のWindowsやMacintoshも独自にシステム外字を定義した。このようにシステムで定義する外字は機種依存文字とも呼ばれ、システム間で非互換の文字が多かったため、JISコード外の文字を正しく情報交換するのが困難であった。X0213が制定された。X0213の文字がすべて使えるようになり、またUnicodeの普及など文字集合が大規模化することで、システム外字が必要という事態は少なくなった。現在は、新しい外字問題が生じている。漢字の一番大きな分類は字種である。字種とは文字の意味(字義)や文字の読み(音)、正字・俗字のように歴史的経緯から見て同じ文字であるみなされる文字である。細かい分類は目に見える文字の形である字形(デジタルフォントではグリフという)である。一つの文字に対してデザイン差までを考慮すれば字形は無数になる。これに対して、JISコード表は漢字の字体を符号化する。字体とは字形を抽象化した字の骨格であるとされている。JISコード番号には抽象的な字体が割り当てられており、そのコード番号の文字は字形(グリフ)を通じてしか可視化できない。印刷されたJISコード表に記載されているのは字形であるが、これは例示とされている。現在、外字が使われるのは次の2つのケースがあるだろう。X0213:2004で規定する字体であるが、グリフが使用するフォントにない場合もしくは使いたいグリフをフォントに依存することなく指定したいときである。1は1970年代から継続する伝統的な外字問題である。文字集合にない文字は外字画像化」するとされている。外字画像方式では外字には文字コードを使用しないで、外字を画像で表し、その画像を文字と同じ大きさで行中にインライン配置する。外字画像を利用すると、文字コードがないので検索ができなくなったり、音声読み上げができないなとの不都合が生じてしまう。基準とする文字コードの枠組みで表せない文字は画像などで表すことになるのはやむをえない。外字画像を使わないようにするには基準とする文字コードをより大規模な文字集合にするしかない。2に属する問題は解決方法がある。X0213:2004に対応するフォントで使えるグリフが外字画像化されているケースもあることが、facebookなどのSNSなどで報告されている。これは制作時の環境のフォントではグリフがないところで、文字の形を優先したいという趣旨かもしれない。このような問題が予想される時はフォント埋め込みが一つの解決策となる。使用したいフォントが埋め込みできない場合は当該の文字だけのフォントを制作してEPUBにフォントを埋め込むことを推奨したい。cas-support返信EPUBのリーダに搭載されているフォントで表示できない文字があったとき、これを表示するための一番単純なやり方は、その文字をイメージ画像(外字画像と仮に呼びます[1])で表すことです。EPUBではリーダで読むときに文字の大きさを変更できます。そこで外字画像の大きさも文字の大きさ変更に追随して変化することが必要です。このために一般には外字画像(img要素)の大きさを1em(emは文字の大きさを示す相対単位)になるように指定します。ReadiumやKindleはそれで問題ないようです[2]。iBooksでインラインの外字画像の大きさを文字サイズに追随させる方法はやや複雑です。いくつか方法が分かっていますので、ここに整理しておきます。方法1.外字画像(img要素)をラップするspanタグにイメージのサイズを1emで指定して、imgタグには100%サイズを指定する[3]。これはiBooksでブロックの画像の大きさを設定する方法と同じ考えです。ブロック画像はだいぶ前に自分で調べてブログを書いたことがあります[4]。opfに特殊なメタデータを設定する[5]。property=”ebpaj:guide-version”>1.1</meta>があると、外字画像が文字サイズと連動する。1」(2013年3月版)に次のようにドキュメント化されています。・dc:languageでjaを指定すること。property=”ebpaj:guide-version”>1.1</meta>・イメージ要素に”gaiji”または”gaiji-“を含むクラス名を付与して、CSSでそのクラスに1emの大きさを指定する。《注意》なお、方法1と2を同時に指定すると外字画像の大きさが1emになりません。ebpaj:guide-versionのプロパティがあると、imgに指定したサイズだけを見てしまうようです。Guide」には方法2の代わりとして’gaiji’をカスタムプロパティとして宣言する方法も規定されています。property="ibooks:respect-image-size-class">gaiji</meta>どうやら、’gaiji’がiBooksの世界で市民権を得たようです。《注意》文字を外字画像として表現したときは、アクセシビリティの観点からaltテキストに適切な文字列をセットしておかなければなりません。X0208などに規定されていない文字をワープロなどで独自に定義して使う(システム外字)やユーザ自身が字形をデザインした文字(ユーザー外字)を示す言葉として使われていました。X0213など)も普及し始めていますし、Unicodeで大量の文字が標準化されており、さらにUnicodeはバージョンがあがるごとに収録文字数が増えています。外字という言葉の意味が曖昧または不明になっています。廃止(Obsolete)して別の言葉を探す方が適切になっています。