[99] 現在、情報機器で文字を扱うには、 抽象化された文字を表す文字コード層と字形を記述したフォント層が分離された体系によることが多いです。 しかし Unicode が普及するまでは、 両者が渾然一体となったシステムが世界各地で多数使われていました。 現在も Unicode に存在しない文字や Unicode で扱いにくい文字などでそうした手法が使われ続けています。 本稿ではそうした手法群をフォント依存符号化と総称します。
[100] 本稿では総称してフォント依存符号化としています。
[101] 8ビット符号系フォント依存符号化手法のフォントの類やその符号化は 8-bit font, font-specific encoding, legacy font, legacy encoding などと呼ばれることがあります。
[97]
印度方面では8ビット符号系フォント依存符号化手法のフォントの類を
clip font
ということがあります。
[131] 鍵盤入力の便宜を中心に設計したものを鍵盤符号化, keyboard encoding, 鍵盤配置, keyboard layout などということがあります。
[132] 日本では、当時 JIS になかった文字や JIS で区別されない異体字を提供するフォントの類を外字フォントなどということがあります。
[80] 8ビット符号系フォント依存符号化手法のフォントの類を ANSI, 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の実体参照でも文中に表示することができる。ただし、どちらも検索や置換といったテキスト操作はできない。
[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
- フォント切り替え(裏フォント方式)
- 同じコードポイントに異体字を収録したフォントを複数(異体字の種類分)用意し、それによって字体の切り替えを行う。
[187] 平成時代初期頃に作られた今昔文字鏡は嘘字方式と呼んでいました。
[188] 「いわゆる「嘘字方式」」としていること >>185 から、 当時はある程度使われていた言葉かもしれませんが、 現在Web検索で確認できる用例は今昔文字鏡関係のものだけです。
[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が表示されるべき符号にあの文字図形を割り当てたフォントを用意することで、
プログラムを改変せずにラテン文字対応システムを仮名対応システムに出来ます。
容易に導入できるという利点と引き換えに、表示以外の処理を悉く諦める必要があります。
使えないだけでなく壊れることもあります。
プログラムが大文字と小文字の違いを自動的に無視する検索機能を持っていれば、
A と a のかわりにあと他の文字を同一視する機能に化けてしまいます。
[105] フォント依存符号化は、他の文字符号化との関係で3種類に分類できます。
[109] このうち >>106, >>107 が狭義のフォント依存符号化というべきもので、 >>108 は Unicode の PUA や Windows の EUDC を含むいわゆる外字の仕組みとして区別することもできますが、 >>107 と >>108 の区別が明確ではない文字符号化もありますし、 >>106 や >>107 のフォントも外字と呼ばれることがあるなど、 厳密に区別しづらいこともあります。
[153] 当初 >>107 だったものが、他の文字符号化の改定による拡張と衝突して >>106 となる事例もままあります。
[133] 日本のように早くから公的標準が確立された地域では、そこから漏れた文字 (外字) を併用するために、少数なら >>108 や >>107 の手法を使い、 それでは収容しきれない大量の外字の表示に >>106 が使われることになりがちです。
[134] アジアその他の基本文字の標準も確立されていなかった地域では、 8ビット符号で文字数が限られている場合がほとんどであることもあって、 はじめから >>106 が有力な選択肢となってきます。
[98]
印度方面ではフォント依存符号化手法のフォントの類のうち、
主に
ASCII文字を置換したものを monolingual、
ASCII文字を温存して主にLatin-1文字を置換したものを bilingual
と区分することがあります。
[152] DTP ソフトウェアには、文字コード的文字を介さずフォントのグリフIDを直接指定して貼り込む機能を有するものもあります。 このような使われ方のフォントは >>108 に類するものといえますが、 利用形態が限定的ですから、一般的なフォント依存符号化のフォントほど相互運用性上の有害性はありません。
[150]
なお、 >>107 や >>108 に当たるもので計算機システムの提供者が予め組み込んで製品化していたものを日本では機種依存文字と呼び、
外字の一類型としていました。機種依存文字は >>102 の性質を持たないという点に於いて本項でいうフォント依存符号化とは異なりますが、
製品によっては内字よりも機能的支援が限定的だったり、
組み込まれたフォントごとに対応、未対応の違いがあったりと、
フォント依存符号化的性格を持つこともあります。
例えば Mac OS ではフォントごとに異なる外字 (機種依存文字)
を実装している場合がありました。
のようなパターンがあります。 >>136 はアジアや各国少数民族に多く、 >>137 は東アジアに多いです。 >>138 は欧米の研究者に多く、 母語として使う現地とは異なる慣習が成立していた場合もあります。 「母語として使う現地」のない古代文字の場合もあります。
[140] >>139 は専門分野の図記号など Unicode に追加されそうにないものも多く、 狭い範囲で現在も使われ続けていることがあります。 Unicode にあっても入力しづらいなどの理由で独自符号が使われ続ける事例もあります。 >>139 ないし >>138 に該当する使われ方としてはその他に、 娯楽や装飾や宗教を目的として使われるもの、 人工文字であるものなどがあります。
[110] フォント依存符号化のほとんどは、フォントの開発者の独自の符号化です。 当該フォント以外との互換性は一切ありません。
[111] 場合によっては同じ開発元の他のフォントと互換性があり、 異なる見た目の別の書体に切り替えられる場合もあります。
[112] 時には特定のフォント依存符号化が地域や言語コミュニティーの事実上の標準の地位を得るほどに普及した場合もあります。 そうなると異なる開発元からいくつも互換性のあるフォントが出現することになります。
[113] 国家標準等のフォントと分離された文字コード規格がありながら、 それがフォント依存符号化として運用されていることもあります。 欧米の計算機業界があまり重視していない地域だと、 プラットフォームや重要アプリケーションが国家規格が制定されても対応しないためにそうなってしまいます。
[114] ASCII を拡張した形の8ビット符号は通常の文字符号化としても非常に広く使われていますが、 フォント依存符号化に属するものの大部分もこの類型です。
[115] 20世紀のものの多くは真の意味で8ビット符号です。 PostScript / PDF や TeX での利用を想定したフォントや単純なビットマップフォントの多くはこれに該当します。
[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 が使えないことでこれまで以上に不便になることはありません。
むしろ後方互換性を保った優れた移行策という評価すら可能です。
[143] 8ビット符号型のフォント依存符号化を使うと、 欧米の8ビット符号前提の計算機でもフォントの差し替え・指定だけで任意の文字を表示させられます。 しかし、 ただ単に使わない文字を置き換えるだけだと、 どのように置き換えた文字を入力するかが問題となります。
[144] 基本的な文字とは別の頻度が低い文字を補助する目的のフォントなら、 コピペや特殊な打鍵操作でもいいかもしれませんが、 常用する基本的な文字がそれでは困ります。 そこで専用のワープロやエディターを開発したり、 入寮補助用ソフトウェアを開発したりされてきました。
[145] そうしたソフトウェアすら不要で入力したいという要求から作られたのが、 鍵盤符号化 (keyboard encoding)、鍵盤配置 (keyboard layout) などと呼ばれる類のフォント依存符号化系フォント群です。
[146] 鍵盤符号化は、打鍵操作でプラットフォームが入力する文字を、 その打鍵操作に割り当てたい文字に差し替えるものです。
[147] 置き換え元となる文字はプラットフォームが元々対応しているものであり、 プラットフォームごとに異なりますが、多くの場合は ASCII文字です。 旧ソ連などではロシア語用キリル文字のこともあります。
[148]
書き換え先、つまりフォント依存符号化に属する文字は、
書き換え元の文字と同じような音価とする、つまり翻字のような関係とすることもあります
(例えば A にあを割り当てるものです)。
逆に書き換え元の英語鍵盤やロシア語鍵盤とはまったく無関係に、
対象言語の入力に適して設計された鍵盤配置に基づいて割り当てられることも多いです。
その鍵盤配置はまったく新しく設計されることもあれば、
タイプライター時代の伝統を受け継いだものもあります。
[149] 鍵盤符号化は入力も出力も簡単に実装できるという特徴があり、 地域によってはよく使われていました。 鍵盤配置の好みに合わせたカスタマイズが文字コードレベルの変更に発展してしまうのが難点です。
[17] フォント依存符号化が Windows-1252 前提で実装されていることは、 世界中でよくみられます。
[127] Windows-1252 を使ったフォント依存符号化は、 Windows-1252 としての処理とフォントが割り当てた文字の性質が整合しないと不都合が生じます。
[128]
最も問題となるのは 0xAD SOFT HYPHEN で、
ここにグリフを割り当てても改行次第で表示されたりされなかったりします。
>>9
[129]
世界各地のフォント依存符号化の事例でも、
古いソフトウェアは単純に表示しているだけで 0xAD
に割り当てていても支障は無かったものが、
新しい版のソフトウェアが SOFT HYPHEN
を実装したことで壊れてしまい、
他の符号位置に割り当て直す羽目になったりしています。
[130]
入力された " を “, ” に自動変換する smart quotes
機能も意図せず動作してデータを破壊しがちで、
変換器や入力補助ソフトウェアなどがこれへの対処を実装している事例がよくみられます。
通常、SOFT HYPHEN (U+00AD) は、行分割しなかったときは表示せず、行分割した場合は表示される。しかし、この処理では、絵文字のようなフォントを使用した場合、U+00AD に割り当てられているグリフが印字されない場合が発生してしまう。axf:soft-hyphen-treatment プロパティを使用することで、この問題を回避することができる。
[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 9x
は
CharSet
を無視していました。
>>311
[83]
Adobe は
Encoding が StandardEncoding でない Type1 フォントから変換された
OpenType フォントにおいて
cmap platformID 4
を使います。
>>311
[84]
platformID 4
の
encodingID
は、
元の Type 1 フォントの .PFM
ファイルの
Windows charset 値 [ 0, 255 ]
に設定しなければなりません。
>>311
[85]
platformID 4 encodingID [ 0, 255 ]
が
CFF アウトラインの OpenType フォントで使われた場合、
Windows NT の OTF フォントドライバーは、
次のように動作します。
>>311
CharSet 0) をフォントが対応する
CharSet の一覧に追加します。encodingID を Windows CharSet 値とみなし、
フォントが対応する CharSet の一覧に追加します。[90]
cmap の符号化は、
CFF の符号化と同一でなければなりません。
>>311
[80]
platformID 4
は、現在広くは用いられていません。
新しいフォントでは使うべきではありません。
>>311
[89]
cmap 部分表の format は 0, 6
でなければなりません。
>>311
[16] フォント依存符号化が MacRoman 前提で実装されることは、 Mac OS 利用者の間でしばしば見られました。
[18] ただ、 Mac OS の利用者数がそこまで多くないことや Mac OS X への移行のため、 実際に利用されたとみられる事例数はそこまで多くはありません。
[19]
TrueType フォントの cmap (文字コードとグリフIDの対応表)
には複数の文字コード体系のデータを格納できます。
現在は Unicode を用いる場合がほとんどすべてですが、
フォント生成ソフトウェアは後方互換性のために MacRoman
(など Mac OS 用の文字符号化) 用の表を生成する場合が未だにあり、
MacRoman (など) 用の表が入った TrueType / OpenType
フォントをよく見かけます。
[20] そうした表はフォント生成ソフトウェアが Windows-1252 や Unicode と MacRoman (など) の対応関係から自動的に生成しただけの場合が大部分と思われ、 表示用のフォントとして実利用されたことがどれだけあるかは大変疑わしいです。
[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ビット符号系フォント依存符号化
[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]
まじか! そんなことできたのか! シフトJISとEUC-KRが混在していても適切に
font で括っておけばそれぞれのフォント + ANSIコードページでレンダリングされたってこと?
[76] フォント依存符号化の利用のためのフォント選択の手法はいくつかあります。
x-user-defined) のような特殊な文字符号化を文字コード指定メニューから選ぶことができ、
利用者は設定画面でその表示に使うフォントを指定できました。
アジア等の諸地域で地域用のフォント依存符号化を利用する手法としてよく用いられました。[163] >>77 >>78 は単一のフォント依存符号化で用が足りる場合に用いられた方法です。
[164] 文字数が多くて単一のフォントで収容しきれない場合は >>162 が必須となります。 基本的な文字集合が標準搭載されていて追加分にフォント依存符号化系の手法を用いる場合も >>162 や >>161 によることになります。
[42] 記述方法としては、
<font face> で指定する。フォントを利用者がインストールしておく。font-family も使われるようになったfont-family で指定する。 Webフォントを使う。rel=fontdef + PFR で指定するもの、
IE 用の @font-face + EOT で指定するもの@font-face + TrueType や OpenType (含む WOFF)があります。なお CSS は style 要素、 style="" 属性で
HTML文書中に指定する方法の他に、外部CSSで指定する方法も使われます。
x-user-defined [173] 8ビット符号系フォント依存符号化の文字は、 そのまま8ビット符号のバイトとして記述される場合もあれば、 名前文字参照や数値文字参照で記述される場合もあります。 名前文字参照はLatin-1の文字に合わせて命名されていますが、 フォント依存符号化はそれを独自の文字に読み替えて使っていますから、 HTML 構文上の名前と実際に表示される文字が食い違うことになります。
[174] 文字参照が使われていると、実際上は8ビット符号であるにも関わらず、 表面的には7ビット符号のテキストファイルに見えることとなります。 HTML を理解しないエディターや変換器では処理できないことになります。
[175]
HTML や CSS
では部分文字列ごとにフォントを指定できますから、
複雑な指定も可能で、現に用いられています。
漢字 (外字)
やエチオピア文字やチベット文字のように単一のフォントですべての文字を収容しきれない場合には、
複数のフォント依存符号化のフォントを組合せて
font 要素や font-family
で切り替えながら併用することになります。
また、フォント依存符号化に存在しない Unicode文字を数値文字参照で埋め込むこともできます。
[181]
HTML3 時代の font 要素はその後不適切とされ CSS
への移行が進みました。フォント依存符号化の観点では、
フォント名を毎回指定する手間とデータ量を節約できるメリットもあるものの、
事実上の文字コード切り替えの指示が文字データから離れた位置に分離される
(特に外部CSSの場合は別ファイルにまで分離される)
というのはデータの複雑性を増しただけであり、
他の文字コードへの変換などの処理の難易度が高まりました。
[182] Webフォントは日本では平成時代後期頃にようやく普及が始まりましたが、 フォント依存符号化が使われたアジア諸国等では実装初期から使われていました。 地域によっては Webサイトごとに異なるフォントが使われ、 初回訪問時に利用者に手動でダウンロードとインストールを求めているような状況でしたから、 Webフォントによってその手間が無くなりました。 初期のものは Netscape Navigator 対応で、 その後 Internet Explorer と両対応のものが出現し、 やがて Internet Explorer のみ対応のものも出現するという、 世界的な Webブラウザー市場の動向と同じような経過をたどっているようです。
[183] Webフォントとして指定された当時の Netscape Navigator や Internet Explorer 用のフォントは現在の Webブラウザーが対応していない形式で、 Internet Archive に残る当時の Webサイトは正常に表示されなくなっていることが多いです。 フォントファイル自体は Internet Archive に保存されている場合が多いので、現行 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
[1] RTF の通常の方法によりフォント名を指定することになります。
[172] RTF は文字をバイト列として記述する方法の他に、 escape により記述する方法も用意しています。 8ビット符号系フォント依存符号化の文字も escape されていることがあります。 あくまで本来の Windows-1252 等の escape が流用されているにすぎませんから、 HTMLの名前文字参照と同様、構文上の名前と実際にフォントで表現される文字が食い違うことがあります。
[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
[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/
[176] フォント依存符号化系の手法群は、個別のフォントや符号化がその地域や言語の文字記述の手法として研究対象になることこそ多少はあれど、 技術体系として総合的に研究の対象となったり、技術史の観点から検討されたりした事例はほとんど見当たりません。
[177] 文字コード技術の専門家からは Unicode に置き換えられるべき幼稚な手法とみなされてほとんどその存在を無視されているように見受けられます。 フォント技術の専門家や文書記述形式の専門家からも、 自然言語処理等の専門家からも、自分達の分野の守備範囲とみなされていないように思われます。
[178] 今後は情報技術の発展史的な視点の文字コード技術の研究や、 デジタルアーカイブ的観点の Webプラットフォーム技術史研究の分野などで調査研究の進展が期待されるところです。