裏フォント方式

フォント依存符号化

[99] 現在、情報機器文字を扱うには、 抽象化された文字を表す文字コード層と字形を記述したフォント層が分離された体系によることが多いです。 しかし Unicode が普及するまでは、 両者が渾然一体となったシステムが世界各地で多数使われていました。 現在も Unicode に存在しない文字Unicode で扱いにくい文字などでそうした手法が使われ続けています。 本稿ではそうした手法群をフォント依存符号化と総称します。

呼称

[100] 本稿では総称してフォント依存符号化としています。

[101] 8ビット符号フォント依存符号化手法のフォントの類やその符号化8-bit font, font-specific encoding, legacy font, legacy encoding などと呼ばれることがあります。

[97] 印度方面では8ビット符号フォント依存符号化手法のフォントの類を clip font ということがあります。 clip font

[131] 鍵盤入力の便宜を中心に設計したものを鍵盤符号化, keyboard encoding, 鍵盤配置, keyboard layout などということがあります。

[132] 日本では、当時 JIS になかった文字や JIS で区別されない異体字を提供するフォントの類を外字フォントなどということがあります。

ANSI フォント

[80] 8ビット符号フォント依存符号化手法のフォントの類を ANSI, ANSIフォントなどということがあります。 語源をたどると、

  1. [81] ANSI米国標準化団体
  2. [82] ANSIASCII を制定する
  3. [83] 米国の計算機業界で ASCII が実装される
  4. [84] WindowsASCIIISO/IEC 8859 を基に独自に拡張したシステムの文字コードのことを ANSIコードページと呼ぶ (MS-DOSOEMコードページWindows NTUnicode との対比)
  5. [85] Windows での利用を想定したフォント依存符号化フォントのことが ANSI と呼ばれるようになる

で、ここでの ANSI の対義語は Unicode フォントです。

[93] もちろんこの ANSI は本来の ANSI とは無関係ですし、 対義語が Unicode フォントになっているにも関わらず、ここでいう ANSI フォントのほとんどは技術的には Unicode を実装していることになっている OpenType フォントです。

裏フォント

[92] 日本語圏では裏フォント裏フォント方式という言葉があります。 この語は平成時代初期にそれなりに使われていた痕跡がありますが、 現在では Web 上で数えるほどしか用例が見当たりません。

[94] 現存する用例をみると、 JIS X 0208 の通常のフォントのかわりに他の文字を割り当てたものを指しているようですが、 注意深く読むとその意味するところには微妙にズレが見られます。 まったく別の文字を割り当てるものを指している用例が古そうですが、 JIS X 0208文字異体字を割り当てたものや、 JIS X 0208包摂規準の範囲内の別字形を割り当てたものを指すものもあります。

[90] ほら貝:文字コード, 加藤弘一, This page was created on Nov15 1999., , http://www.horagai.com/www/moji/2000a.htm

文字コードと文字セットの違いは最初に述べたが、新しい文字コードを作ろうとすると複雑な問題がからんでくるので、符号化を棚上げし、ひとまず文字セットだけを作ろうという動きが進んでいる。コードがふられていなくては、コンピュータで使えないのではないかと思うかもしれないが、フォントが無償公開されていれば、お互いに共通のフォントを共有でき、そのフォントにおける通し番号を伝えることで、どの文字かが特定できるのである。研究者の間では諸橋轍次の『大漢和辞典』の検字番号でJIS表外字を特定する方法がかなりおこなわれていたが、そのフォント版といえる。

変則的だが、多くのCD-ROM出版物のように、JIS表外字をマッピングした「裏フォント」を使う手もあるし、XMLの実体参照でも文中に表示することができる。ただし、どちらも検索や置換といったテキスト操作はできない。

[96] 前段で指しているのは今昔文字鏡GT明朝e漢字など。

[89] 第2回 - 中国語情報処理, 09/28/2001, , https://www.rikkyo.ne.jp/univ/masutani/diannao/diannao2001/2.html

裏フォント方式の中国語入力ソフト

  • 「cWnn」(オムロンソフトウェア株式会社):8401にインストール済み
    • 独自フォントを用いて表示するため、「cWnn」で入力した中国語は同じソフトのある環境でしか読めないが、中国語変換補助、辞書などの入力支援機能が便利である。
  • 「Chinese Writer」(光電社)
    • 「cWnn」と同様のソフト。

[87] ほら貝:文字コード, 加藤弘一, This page was created on July21 2002., , http://www.horagai.com/www/moji/int/saito.htm

――20万字というと裏フォント方式ですか?

斎藤 そうではありません。

[88] *正字體フォント作成法――或いは、余は如何にして或種のフォントを作り得ざりし乎, 森洋介 MORI,Yousuke, 發行日 2007年10月14日 開板/2007年11月26日 改版, , https://web.archive.org/web/20190331114747/http://livresque.g1.xrea.com/Data/font01.htm

正字體のうちJISコード(の第一・第二水準基本漢字)が割り振られてない字種を、新字體を振り當てたコードの場所に置き換へて表示する仕組み。俗に謂ふ裏フォント方式の一種だが、JIS X 0208(97JIS)に謂ふ包攝規準からすれば、一コードに複數の新舊異體字が「包摂」されてゐるわけだから、表示字形に新字でなく舊字體を選んでも構はない理窟だ

[91] 字体 - Wikipedia, , https://ja.wikipedia.org/wiki/%E5%AD%97%E4%BD%93#%E6%96%87%E5%AD%97%E9%9B%86%E5%90%88%E3%81%A8%E7%95%B0%E4%BD%93%E5%AD%97

フォント切り替え(裏フォント方式)
同じコードポイントに異体字を収録したフォントを複数(異体字の種類分)用意し、それによって字体の切り替えを行う。

[141] >>28

嘘字方式

[187] 平成時代初期頃に作られた今昔文字鏡嘘字方式と呼んでいました。

[188] 「いわゆる「嘘字方式」」としていること >>185 から、 当時はある程度使われていた言葉かもしれませんが、 現在Web検索で確認できる用例は今昔文字鏡関係のものだけです。

[189] なお「嘘字」は同時期にいくつかの意味で使われていた言葉であり、 ビットマップフォント解像度の都合で字画を省略していることを指したり、 JIS X 0208 に含まれる文字で論者が気に食わないもの (主に拡張新字体) を貶めて言ったりする用例が見られます。

[185] 9万字を収容した今昔文字鏡, 1999/12/27 00:00:00, , https://www.jagat.or.jp/past_archives/story/836.html

実装はいわゆる「嘘字方式」である。本来JIS漢字が入っているべきところに,JISの定義とは関係ない配列で文字を定義している。このようなフォントを複数用意して,フォント名とコードポイントを指定して表示を切り替える。たとえば,文字鏡フォント101は,シフトJISでは「亜」が入っているべきところに「一」を定義している。

[186] [qa:55053] Re: 文字鏡文字の表示, 本田, 2010-06-21 10:07:04, , https://okumuralab.org/~okumura/texfaq/qa/55053.html

Mojikyo M101 亜

というような形式(これが嘘字方式)で

概略

[102] フォント依存符号化と他の文字符号化との最大の違いは、 フォント依存符号化アプリケーションプラットフォームのレベルで実装されていない、 なんなれば他の文字符号化が実装されている点にあります。

[103] 他の文字符号化の実装であれば、アプリケーションプラットフォームプログラムは多かれ少なかれ当該文字符号化の知識を実装しています。 例えばどの符号改行を表し、 どの符号間隔を表し、 どの符号数字を表し、 どの符号とどの符号大文字と小文字の関係にある、 といった知識がプログラムの機能に反映されています。 それによって折り返し位置が決められたり、 文字列として記入された整数演算を実行したり、 行頭大文字に置換したりといった処理が実現されます。 あるいは鍵盤からの入力と文字符号が関連付けられたり、 他の文字コードとの相互変換が実装されたり、 音声による読み上げや全文検索システムの自然言語処理と統合されたりしています。

[104] フォント依存符号化は、文字のこうした多角的な処理のうち、 文字図形を表示するという1点のみに特化したものです。 例えば本来Aが表示されるべき符号の文字図形を割り当てたフォントを用意することで、 プログラムを改変せずにラテン文字対応システムを仮名対応システムに出来ます。 容易に導入できるという利点と引き換えに、表示以外の処理を悉く諦める必要があります。 使えないだけでなく壊れることもあります。 プログラム大文字と小文字の違いを自動的に無視する検索機能を持っていれば、 Aa のかわりにと他の文字を同一視する機能に化けてしまいます。


[105] フォント依存符号化は、他の文字符号化との関係で3種類に分類できます。

[109] このうち >>106, >>107 が狭義のフォント依存符号化というべきもので、 >>108UnicodePUAWindowsEUDC を含むいわゆる外字の仕組みとして区別することもできますが、 >>107>>108 の区別が明確ではない文字符号化もありますし、 >>106>>107フォント外字と呼ばれることがあるなど、 厳密に区別しづらいこともあります。

[153] 当初 >>107 だったものが、他の文字符号化の改定による拡張と衝突して >>106 となる事例もままあります。

[133] 日本のように早くから公的標準が確立された地域では、そこから漏れた文字 (外字) を併用するために、少数なら >>108>>107 の手法を使い、 それでは収容しきれない大量の外字の表示に >>106 が使われることになりがちです。

[134] アジアその他の基本文字の標準も確立されていなかった地域では、 8ビット符号で文字数が限られている場合がほとんどであることもあって、 はじめから >>106 が有力な選択肢となってきます。

[98] 印度方面ではフォント依存符号化手法のフォントの類のうち、 主に ASCII文字を置換したものを monolingual、 ASCII文字を温存して主にLatin-1文字を置換したものを bilingual と区分することがあります。 インド系文字の文字コード English と地域言語の2言語の文字を共存できるかどうかを意味しています。

[152] DTP ソフトウェアには、文字コード文字を介さずフォントグリフIDを直接指定して貼り込む機能を有するものもあります。 このような使われ方のフォント>>108 に類するものといえますが、 利用形態が限定的ですから、一般的なフォント依存符号化フォントほど相互運用性上の有害性はありません。

[150] なお、 >>107>>108 に当たるもので計算機システムの提供者が予め組み込んで製品化していたものを日本では機種依存文字と呼び、 外字の一類型としていました。機種依存文字>>102 の性質を持たないという点に於いて本項でいうフォント依存符号化とは異なりますが、 製品によっては内字よりも機能的支援が限定的だったり、 組み込まれたフォントごとに対応、未対応の違いがあったりと、 フォント依存符号化的性格を持つこともあります。 例えば Mac OS ではフォントごとに異なる外字 (機種依存文字) を実装している場合がありました。 MacJapanese

[151] よく似た語で環境依存文字なるものが平成時代後期頃から一部で使われるようになっています。 これは意味が不明瞭な俗語であり、 機種の概念が不明瞭な時代の旧機種依存文字の置き換え語として使わたり、 一部のプラットフォームでシステムフォントに含まれない Unicode文字を指したりするように見受けられますが、 いずれにしても本項のフォント依存符号化とは無関係です。

[135] フォント依存符号化の主な利用の主体と方法は、

のようなパターンがあります。 >>136アジアや各国少数民族に多く、 >>137東アジアに多いです。 >>138欧米の研究者に多く、 母語として使う現地とは異なる慣習が成立していた場合もあります。 「母語として使う現地」のない古代文字の場合もあります。

[140] >>139 は専門分野の図記号など Unicode に追加されそうにないものも多く、 狭い範囲で現在も使われ続けていることがあります。 Unicode にあっても入力しづらいなどの理由で独自符号が使われ続ける事例もあります。 >>139 ないし >>138 に該当する使われ方としてはその他に、 娯楽や装飾や宗教を目的として使われるもの、 人工文字であるものなどがあります。

[110] フォント依存符号化のほとんどは、フォントの開発者の独自の符号化です。 当該フォント以外との互換性は一切ありません。

[111] 場合によっては同じ開発元の他のフォントと互換性があり、 異なる見た目の別の書体に切り替えられる場合もあります。

[112] 時には特定のフォント依存符号化が地域や言語コミュニティーの事実上の標準の地位を得るほどに普及した場合もあります。 そうなると異なる開発元からいくつも互換性のあるフォントが出現することになります。

[113] 国家標準等のフォントと分離された文字コード規格がありながら、 それがフォント依存符号化として運用されていることもあります。 欧米の計算機業界があまり重視していない地域だと、 プラットフォームや重要アプリケーション国家規格が制定されても対応しないためにそうなってしまいます。

符号化機構

8ビット符号

[114] ASCII を拡張した形の8ビット符号は通常の文字符号化としても非常に広く使われていますが、 フォント依存符号化に属するものの大部分もこの類型です。

[115] 20世紀のものの多くは真の意味で8ビット符号です。 PostScript / PDFTeX での利用を想定したフォントや単純なビットマップフォントの多くはこれに該当します。

[116] 20世紀末から少し事情が複雑になってきます。 Windows をはじめとする多くの応用TrueType / OpenType のようなフォント技術の Unicode 化が進み、たとえ文字列の入出力が8ビット符号であっても応用内部の文字列型データや表示に使うフォントUnicode であるケースが増えていきます。 すると入出力の8ビット符号Windows-1252 など当該システムの文字コードによって Unicode に変換された形でシステム内部で処理されることになります。

[117] つまり [ 0x00, 0xFF ] の8ビット符号のように見えて、 実態は U+0100 以上Unicode文字としてプログラムは扱うことになり、 フォントU+0100 以上Unicode文字グリフを割り当てることになります。

[118] これを更に発展させて本来の Unicode文字と「両対応」させたフォントも出現してきます。 例えば 0xA1文字 を割り当てていたら、 U+00A1 と本来の Unicode文字の両方にグリフを割り当てておくことで、 従来の8ビット符号文書Unicode文書も1つのフォントで表示できることになります。 もちろんこれでは本来の U+00A1 は表示できませんし、 このような使い方は Unicode に違反するのですが、元々 0xA1 を置き換えていたのですから、 U+00A1 が使えないことでこれまで以上に不便になることはありません。 むしろ後方互換性を保った優れた移行策という評価すら可能です。

[119] 事情は異なりますが、 U+005CYEN SIGN を割り当てた日本語フォントと構図は同じです。

鍵盤符号化

[143] 8ビット符号型のフォント依存符号化を使うと、 欧米の8ビット符号前提の計算機でもフォントの差し替え・指定だけで任意の文字を表示させられます。 しかし、 ただ単に使わない文字を置き換えるだけだと、 どのように置き換えた文字を入力するかが問題となります。

[144] 基本的な文字とは別の頻度が低い文字を補助する目的のフォントなら、 コピペや特殊な打鍵操作でもいいかもしれませんが、 常用する基本的な文字がそれでは困ります。 そこで専用のワープロエディターを開発したり、 入寮補助用ソフトウェアを開発したりされてきました。

[145] そうしたソフトウェアすら不要で入力したいという要求から作られたのが、 鍵盤符号化 (keyboard encoding)、鍵盤配置 (keyboard layout) などと呼ばれる類のフォント依存符号化フォント群です。

[146] 鍵盤符号化は、打鍵操作でプラットフォームが入力する文字を、 その打鍵操作に割り当てたい文字に差し替えるものです。

[147] 置き換え元となる文字プラットフォームが元々対応しているものであり、 プラットフォームごとに異なりますが、多くの場合は ASCII文字です。 旧ソ連などではロシア語キリル文字のこともあります。

[148] 書き換え先、つまりフォント依存符号化に属する文字は、 書き換え元の文字と同じような音価とする、つまり翻字のような関係とすることもあります (例えば Aを割り当てるものです)。 逆に書き換え元の英語鍵盤ロシア語鍵盤とはまったく無関係に、 対象言語の入力に適して設計された鍵盤配置に基づいて割り当てられることも多いです。 その鍵盤配置はまったく新しく設計されることもあれば、 タイプライター時代の伝統を受け継いだものもあります。

[149] 鍵盤符号化は入力も出力も簡単に実装できるという特徴があり、 地域によってはよく使われていました。 鍵盤配置の好みに合わせたカスタマイズが文字コードレベルの変更に発展してしまうのが難点です。

ジョージアの8ビット符号

Windows symbol encoding

symbol encoding

Windows-1252 としての実装

[17] フォント依存符号化Windows-1252 前提で実装されていることは、 世界中でよくみられます。

[127] Windows-1252 を使ったフォント依存符号化は、 Windows-1252 としての処理とフォントが割り当てた文字の性質が整合しないと不都合が生じます。

[128] 最も問題となるのは 0xAD SOFT HYPHEN で、 ここにグリフを割り当てても改行次第で表示されたりされなかったりします。 >>9

[129] 世界各地のフォント依存符号化の事例でも、 古いソフトウェアは単純に表示しているだけで 0xAD に割り当てていても支障は無かったものが、 新しい版のソフトウェアが SOFT HYPHEN を実装したことで壊れてしまい、 他の符号位置に割り当て直す羽目になったりしています。 インド系文字の文字コード

[130] 入力された ", に自動変換する smart quotes 機能も意図せず動作してデータを破壊しがちで、 変換器や入力補助ソフトウェアなどがこれへの対処を実装している事例がよくみられます。

[9] Antenna House によるXSL拡張仕様 (, ) https://www.antenna.co.jp/XML/axf-extension/axf-extension.htm#axf%3Asoft-hyphen-treatment

通常、SOFT HYPHEN (U+00AD) は、行分割しなかったときは表示せず、行分割した場合は表示される。しかし、この処理では、絵文字のようなフォントを使用した場合、U+00AD に割り当てられているグリフが印字されない場合が発生してしまう。axf:soft-hyphen-treatment プロパティを使用することで、この問題を回避することができる。

OTF Windows NT compatibility mapping

[79] platformID 4 (Custom) は、 encodingID [ 0, 255 ] が OTF Windows NT compatibility mapping として使われます。 >>311

[81] platformID 4 は、 Type 1 フォント由来の OpenType フォントを通じて古い応用との互換性を維持するための遺物です。 cmap platformID 4 を使って、 非Unicode 応用に対してフォントWindows ANSI符号化されているように見せかけられます。 >>311

[82] Windows ANSI符号化でない Type 1 フォント、 例えばキリル文字中欧フォントは、 過去 Adobe が出荷した際に .PFM ファイルの CharSet 欄を 0 (Windows ANSI) としていました。 ATM for Windows 9xCharSet を無視していました。 >>311

[83] AdobeEncodingStandardEncoding でない Type1 フォントから変換された OpenType フォントにおいて cmap platformID 4 を使います。 >>311

[84] platformID 4encodingID は、 元の Type 1 フォント.PFM ファイルの Windows charset 値 [ 0, 255 ] に設定しなければなりません (must) >>311

[85] platformID 4 encodingID [ 0, 255 ] が CFF アウトラインの OpenType フォントで使われた場合、 Windows NTOTF フォントドライバーは、 次のように動作します。 >>311

[90] cmap符号化は、 CFF符号化同一 (identical) でなければなりません (must) >>311

[80] platformID 4 は、現在広くは用いられていません。 新しいフォントでは使うべきではありません (should not) >>311

[89] cmap 部分表format0, 6 でなければなりません (must) >>311

MacRoman としての実装

[16] フォント依存符号化MacRoman 前提で実装されることは、 Mac OS 利用者の間でしばしば見られました。

[18] ただ、 Mac OS利用者数がそこまで多くないことや Mac OS X への移行のため、 実際に利用されたとみられる事例数はそこまで多くはありません。


[19] TrueType フォントcmap (文字コードグリフIDの対応表) には複数の文字コード体系のデータを格納できます。 現在は Unicode を用いる場合がほとんどすべてですが、 フォント生成ソフトウェアは後方互換性のために MacRoman (など Mac OS 用の文字符号化) 用の表を生成する場合が未だにあり、 MacRoman (など) 用の表が入った TrueType / OpenType フォントをよく見かけます。

[20] そうした表はフォント生成ソフトウェアが Windows-1252UnicodeMacRoman (など) の対応関係から自動的に生成しただけの場合が大部分と思われ、 表示用のフォントとして実利用されたことがどれだけあるかは大変疑わしいです。

[21] フォント依存符号化フォントにもこの事情は当てはまるので、 多くのフォント依存符号化Windows-1252 版と MacRoman 版が存在することになりますが、 MacRoman 版がどれだけ実用されたかは大いに疑問です。

多バイト符号

[23] 東アジア多バイト符号の世界では内字以外を使う場合、

といった手段が採られました。このうち >>158アプリケーションプラットフォームのプログラムの改変が必要になることが多いため、 フォント依存符号化では採用されづらい手法です。

[24] 平成時代初期頃までは >>156>>157 も含めて文字の領域を自由に使うことが可能でした。 ところがプラットフォームUnicode への移行が進むと文字列型データやフォントへのアクセスで従来の多バイト符号Unicode の変換が頻繁に発生するようになり、空き領域は Unicode に対応しない (エラーまたは代替文字への置換が発生する) こととなったために、 >>156 (や >>158) が非現実的となりました。

[3] 日本で使われるフォント依存符号化TrueType / OpenType フォントは、 シフトJISの文字を入れ替えたものと説明されることが多いですが、 実際にはシフトJISの文字に相当する Unicode フォントの形になっているのが普通です。


[142] 日本では JIS X 0208仮名音価の近い他の表音文字に置き換えた事例がまま見られます。

[159] 日本では JIS X 0208漢字外字異体字に置き換えた事例がまま見られます。 大量の追加文字のためにいくつもフォントを用意した事例もあります。

[160] 外字の需要が多い日本など東アジアでは、 外字グリフフォントのデータを転送、共有する仕組みが多数考案、利用されました。 業界標準となったものもあれば、製品独自のものもあり、 特定応用分野や組織内で使われていました。個人レベルの一般に広く普及したものはありません。 外字 こうした仕組みは文字情報の永続性、相互運用性の観点でみれば単なるフォント依存符号化より幾分安定、信頼できるものではありますが、 広く公開されるデータで用いられる手法ではありませんし、 システムの更改や外部システムとの相互接続などで常に問題となってきました。

[67] 関連: JIS X 0208, GB 2312とその拡張, Big5, EUDC, DRCS


[165] 現在では多バイト符号のデータも内部的に Unicode として解釈される場合がほとんどですが、 平成時代初期頃にはそうではない実装方法の場合がありました。 当時と今とでフォント依存符号化フォントが適切に反映されるかどうかが違うことがあります。

[22] シフトJISと混在して使われる8ビット符号フォント依存符号化 Symbolフォント

[70] Making Home Pages in Korean - EHC, , http://www.kmml.net/ehc/hhpage.html#_two

対象となるブラウザやOSを限定するのであれば、<font face=>タグによるフォント指定を利用してハングルフォントと日本語フォントを使い分け、ハングルと日本語の混在したページを作ることも可能です(たとえばWindows NT上のNetscape 3.0x。ただし<meta>タグでcharsetを決め打ちするとうまく行きませんので、外しておかなければなりません)。

ただし、指定されたフォントがなければせっかくの<font face=>の指定内容は無視されます(とくに異機種、異OSや異言語環境に対する配慮は忘れられがちです)し、ブラウザのバージョンやOSの言語仕様によっても見え方が異なります。と、いうわけで、個人的にはあまりお勧めしません。絶対やるなとまでは言いませんが、やるなら各ブラウザ(できればできる限り複数のOS、複数の言語環境)で一通り表示テストを行い、正常に表示できる環境を明記しておきましょう。

[71] まじか! そんなことできたのか! シフトJISEUC-KRが混在していても適切に font で括っておけばそれぞれのフォント + ANSIコードページでレンダリングされたってこと?

フォント選択

[76] フォント依存符号化の利用のためのフォント選択の手法はいくつかあります。

[77] プラットフォームフォントを置き換える
OSアプリケーションに組み込まれたシステムフォントを改変するものです。 プラットフォームが提供する正規の方法でフォントを指定する場合と、 通常の方法でフォントが指定できないため改造して置換する場合とがあります。 アジア等の諸地域で英語版等の OS を地域用に改変する手法としてよく用いられました。
[78] プラットフォームフォント指定機能を利用する
初期の Webブラウザーでは通常の文字コード体系に加えて 「利用者定義」 (x-user-defined) のような特殊な文字符号化文字コード指定メニューから選ぶことができ、 利用者は設定画面でその表示に使うフォントを指定できました。 アジア等の諸地域で地域用のフォント依存符号化を利用する手法としてよく用いられました。
[161] プラットフォーム外字機能を利用する
OSアプリケーションに組み込まれた外字機能を使うものです。 外字エディタのようなソフトウェアで文字単位で登録する場合と、 外字フォントを登録して一括で切り替える場合とがあります。 東アジア内字以外の文字を追加で使用する手法としてよく用いられました。
[162] ワープロマーク付け言語フォント指定機能を利用する
HTML / CSSRTF、 その他各種のワープロソフトウェアは文字列の一部又は全部のフォント名を指定できます。 更に HTMLPDF や一部のワープロでは利用するフォントを埋め込んだり、 URL で参照したりもできます。 多くのフォント依存符号化がこうした手法で利用されています。

[163] >>77 >>78 は単一のフォント依存符号化で用が足りる場合に用いられた方法です。

[164] 文字数が多くて単一のフォントで収容しきれない場合は >>162 が必須となります。 基本的な文字集合が標準搭載されていて追加分にフォント依存符号化系の手法を用いる場合も >>162>>161 によることになります。

応用との統合

Web での利用

[42] 記述方法としては、

があります。なお CSSstyle 要素style="" 属性HTML文書中に指定する方法の他に、外部CSSで指定する方法も使われます。

[49] 文字コードとしては、

[53] 文字コード指定としては、

[173] 8ビット符号フォント依存符号化文字は、 そのまま8ビット符号バイトとして記述される場合もあれば、 名前文字参照数値文字参照で記述される場合もあります。 名前文字参照Latin-1文字に合わせて命名されていますが、 フォント依存符号化はそれを独自の文字に読み替えて使っていますから、 HTML 構文上の名前と実際に表示される文字が食い違うことになります。

[174] 文字参照が使われていると、実際上は8ビット符号であるにも関わらず、 表面的には7ビット符号テキストファイルに見えることとなります。 HTML を理解しないエディターや変換器では処理できないことになります。

[175] HTMLCSS では部分文字列ごとにフォントを指定できますから、 複雑な指定も可能で、現に用いられています。 漢字 (外字) やエチオピア文字チベット文字のように単一のフォントですべての文字を収容しきれない場合には、 複数のフォント依存符号化フォントを組合せて font 要素font-family で切り替えながら併用することになります。 また、フォント依存符号化に存在しない Unicode文字数値文字参照で埋め込むこともできます。

[181] HTML3 時代の font 要素はその後不適切とされ CSS への移行が進みました。フォント依存符号化の観点では、 フォント名を毎回指定する手間とデータ量を節約できるメリットもあるものの、 事実上の文字コード切り替えの指示が文字データから離れた位置に分離される (特に外部CSSの場合は別ファイルにまで分離される) というのはデータの複雑性を増しただけであり、 他の文字コードへの変換などの処理の難易度が高まりました。

[182] Webフォント日本では平成時代後期頃にようやく普及が始まりましたが、 フォント依存符号化が使われたアジア諸国等では実装初期から使われていました。 地域によっては Webサイトごとに異なるフォントが使われ、 初回訪問時に利用者に手動でダウンロードとインストールを求めているような状況でしたから、 Webフォントによってその手間が無くなりました。 初期のものは Netscape Navigator 対応で、 その後 Internet Explorer と両対応のものが出現し、 やがて Internet Explorer のみ対応のものも出現するという、 世界的な Webブラウザー市場の動向と同じような経過をたどっているようです。

[183] Webフォントとして指定された当時の Netscape NavigatorInternet Explorer 用のフォントは現在の Webブラウザーが対応していない形式で、 Internet Archive に残る当時の Webサイトは正常に表示されなくなっていることが多いです。 フォントファイル自体は Internet Archive に保存されている場合が多いので、現行 Webブラウザーが扱える形式に変換すれば当時のように表示できると思われます。

[184] Webブラウザー事業者らは Web互換性の維持を謳ってはいますが、 Unicode への移行が進む中で需要が減少していたこうした機能に対しては冷淡で、 容赦なく切り捨てられていきました。 そのため Webフォントに依存していた過去の Webサイトは表示すら出来ない現状に追い込まれたわけです。 意識的にそうしたわけではないとしても、 米国や西欧の Webサイトは十数年前のものも正常に表示できるのに、 アジアのサイトはそうではないというのは非難されるのも致し方ないでしょう。

[179] 関連: Webにおける文字コード

[68] <FONT FACE> réputé nuisible, , https://web.archive.org/web/19990221105800/http://babel.alis.com:8080/web_ml/html/fontface.html

[69] >>68 <font face> は有害、ちゃんとした文字を使えと。最初に例示されているギリシャ文字なら確かにそう。 でも Unicode ですらまともに扱えなかった文字をこの時代に他にどうしろと? (なお平成11年は Unicode はかなり頑張ればアルファベット等は実用になるかな、くらいの時期。)

[6] 1054817 – Icon fonts don't work when "allow pages to choose their own fonts" is unchecked ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=1054817

[8] 789788 – Not allowing pages to choose their own fonts breaks with icon fonts ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=789788

[12] chardetng: A More Compact Character Encoding Detector for the Legacy Web (Henri Sivonen, , ) https://hsivonen.fi/chardetng/#fonts

RTF での利用

[1] RTF の通常の方法によりフォント名を指定することになります。

[172] RTF文字バイト列として記述する方法の他に、 escape により記述する方法も用意しています。 8ビット符号フォント依存符号化文字escape されていることがあります。 あくまで本来の Windows-1252 等の escape が流用されているにすぎませんから、 HTML名前文字参照と同様、構文上の名前と実際にフォントで表現される文字が食い違うことがあります。

ウィキ構文への組み込み

神代文字

事例

[2] フォント

[36] GitHub - MichinariNukazawa/RuneAssignMN_Series_Fonts, https://github.com/MichinariNukazawa/RuneAssignMN_Series_Fonts/

本フォントは、A〜zを入力するだけで手軽にルーン文字が使えるよう作成されました。 ルーン文字に割り当てられているユニコード領域にはグリフを置いていません。

[28] Japanese Windows and hangul, , https://ha1.seikyou.ne.jp/home/akairingosaita/hangul/hangul02.htm

"Yamada Language Center"で配布されている"Sorawin.ttf"は、 なんと1byte文字のフォントです。 初声、中声、終声を重ね打ちしてハングルを表示します。 欧文フォントの裏フォント(外字フォント)形式であり、 通常のハングルフォントとの互換性はありません。

[35] フォント (, ) http://www.yamadera.info/fonts/fonts-index.htm

[72] Release Monu Math v0.x · MY1L/Unicode · GitHub, https://github.com/MY1L/Unicode/releases/tag/Math

[73] GitHub - ShikiSuen/Yuzuri-Font: 島岡系芸大和声記号専用フォント。 // A typeface which allows easy typography of Shimaoka Roman Numerals used among conservatories in Japan.A typeface which allows easy typography of Shimaoka Roman Numerals used among conservatories in Japan., https://github.com/ShikiSuen/Yuzuri-Font

[74] 将棋プログラム「激指」のページ, , https://www.logos.t.u-tokyo.ac.jp/~gekisashi/download.html

[75] JIS X 0208 ベース

[86] The Birth of Xiis — A Guide to Font Creation - Filosofía Moderna, Arguméntame, Reflexiones de la Vida y Filosofía Moderna, , https://web.archive.org/web/20240224221836/https://argumentame.com/the-birth-of-xiis-a-guide-to-font-creation/

他の文字コードへの変換

文字コードの変換

.map

研究史

[176] フォント依存符号化系の手法群は、個別のフォント符号化がその地域や言語の文字記述の手法として研究対象になることこそ多少はあれど、 技術体系として総合的に研究の対象となったり、技術史の観点から検討されたりした事例はほとんど見当たりません。

[177] 文字コード技術の専門家からは Unicode に置き換えられるべき幼稚な手法とみなされてほとんどその存在を無視されているように見受けられます。 フォント技術の専門家や文書記述形式の専門家からも、 自然言語処理等の専門家からも、自分達の分野の守備範囲とみなされていないように思われます。

[178] 今後は情報技術の発展史的な視点の文字コード技術の研究や、 デジタルアーカイブ的観点の Webプラットフォーム技術史研究の分野などで調査研究の進展が期待されるところです。

メモ