文字情報処理 文字コード フォント

.mjtの個人的メモ＆某チャンネルのメモ。テンポラリ。

要点

  • 文字コードXに対して、どういう画像を表示するのかという問題。
  • 主に正字と略字が対立する。
    • JIS2004ではそうだが、基本的には異体字かなぁ。
↑

前提

  • このページでは単語の定義はJISに従う。
    • 字体:「図形文字の図形表現としての形状についての抽象的概念」
    • 包摂:「複数の字体を区別せずに、それらに同一の面区点位置を与えることをいう」
    • 字形:「字体を、手書き、印字、画面表示などによって実際に図形として表現したもの」
  • 一般的には、JISの「字形」が「字体」に対応し、「字体」に対応する言葉は「文字コード(面区点位置)」？
    • 一般には字形と字体が混同されている感はある
    • 「字体」はabstract character、文字概念だろう。
    • 面句点位置 = code point = 符号化文字 は 包摂された一つ以上の字体 に一つ割り当てられる。言い換えれば、ある基準で重ねあわされた一つ以上の字体への参照が code point。
  • 「包摂」の意味合いも微妙に違う。
    • 字形レベルでの揺らぎを包摂するのか、字体レベルでの揺らぎを包摂するのか
  • 以下、単にJISと書いた場合は、X0213とそれに含まれるX0208(JIS基本漢字)とX0212(JIS補助漢字)の規格を示すって事で。
↑

経緯

  • JISの漢字符号定義には色々なバージョンが有り、その時々に従ったいろんなバージョンがある。
  • また、JISの漢字表の空きにメーカーが独自の拡張を施したいわゆる機種依存文字問題も有る　　が、ここではあんまり触れない。
  • JISxx
    • JIS78 - 最初のバージョン(JIS的には第1次規格。いわゆる旧JIS。ナンバリングの差異によりC6226-1978)
      • 78 - オリジナル
      • 78誤 - 4字の誤字訂正
      • 78 1刷 - 78/11月
      • 〜78 4刷？、5刷
    • JIS83 - (第2次規格C6226。いわゆる新JIS。X0208-1983)
    • JIS90 - 現在のX0208(の例示字体の字形。第3次規格X0208-1990)
    • (現在のX0208は1997年制定。例示字体の字形に変化は無い)
    • JIS2000 - 最初のX0213。いわゆる第3水準と第4水準。
      • JIS2004 - 現在のX0213。例示字体の字形が表外漢字字体表に合うように変更

JISxxに準拠といったときは、大抵例示字体に合わせたフォントを搭載していると考えていいのでは無いだろうか。(歴史的に)

  • いや、字体（というか字形）について「準拠」と称したのはおそらくJIS2004でのMicrosoftが初めてだと思う。
    • たしかに、それまでは必要な所には外字も納入して要件を満たしていた筈だからなぁ。。要調査。 - .mjt
    • ただ、(JIShoge水準対応のような書き方をして、)例示字体の字形から外れた字形を示すフォントってのは知らないです。要は、以前から例示字体が字形のde facto standardとなってる現実。(それが正しい、正しくないは置いといて) - .mjt
  • みんな同じに見えるのはちゃんと見ていないからじゃありません？例えば「ぞ」の濁点の位置とかは結構有意に差があるかと。あとは「さ」や「き」の上部と下部がくっついているか離れているか、「$」の縦棒の本数なんかものによってはばらつきがありますよ。（メジャーなのは「JIS例示字体化」しちゃってますけれど）
    • メジャーなもので有意に異なるものを挙げると、MS ゴシックとヒラギノ角ゴでは「"'IQ¢」とか。また、MS 明朝とヒラギノ明朝だと「ゆ市芒樣」あたりが気づいた限りでは異なってますかね。「殩」なんかは派手に違ってたり。
    • なお、とめるかはねるかは結構差異が出ますね。これは字形レベルの話で、面句点位置でなく字体での字形包摂に入ってしまいますが。 - naruse
  • そういう現実があるときに、「字形を意図」するためにはその時代のJIS例示字体の字形が使われていて、そこで字形の意図とJIS例示字体の字形の変遷がリンクする(している)　　　だからJIS年代の切替え機能をWinFXなりなんなりで提供しているんじゃいかなと。 - .mjt
    • まぁ、新JISと旧JISをそうやって区別するのは理解できるけれど、JIS2004での例示字体の変更をそうやって追いかけるのはスッキリしたモデルで無いかな。。 - .mjt
  • 83JISの時は、字体レベルでなく、文字レベルで変わっているから。
  • 例示自体は、code pointが何を参照しているかの助けとなるものであって、code point の presentationのリファレンス実装ではないことに注意すべき。
  • 「久」をvistaのMS明朝ではJIS例示字体から離れるほうへ変更したのに、世間では騒がれていないようです。「殩」はJIS X 0212とJIS X 0213の差ですね。JIS X 0213で包摂出来ない字がUnicodeで統合されていて、しかもAdobeJapan1-6でも区別できないという…
↑

字形切り替え

↑

JISと字形

  • 需要
    • (正字は書くのに、認識するのに不便→常用漢字表では略字が利用されている)
    • 人名漢字等固有名詞はちゃんとした字体(≒正字？)で出ないと困る
      • ちゃんとした字体とは、戸籍に書いてある字体のこと。それは略字体かもしれないし、正字体かもしれない。
      • cf.葛飾区の「葛」は正字体、葛城市の「葛」は略字体
  • 戸籍で使える文字は字体レベルまで決まっています。
    • 戸籍統一文字情報
    • 上を参照すると、字体を包摂していない文字データベースが眺められるのですが、例えば「龍」について、これは「竜」とは別に番号が振られているばかりか、「龍」の一画目が「|」か「-」かでも区別されており、「子の名に使える文字」は「|」の方になってます。
    • いや、すでに名が付けられていて、しかも「龍」の一画目が点になっちゃってたりするとすごいアレなんですがね。 - naruse
    • そういや、友人の名に、戸籍統一文字番号 311230が使われているのだが、この文字ってJISやUnicodeだと310630と包摂されていて、事実上この字形って出せないのよね。 - naruse
  • JISの例示字体の変動
    • 例示字体の変動と文字の変動が混同されてる感がある。両者は問題のレイヤーが異なる
      • 包摂規準を越えて変わった( = 文字が変わった)のがJIS83で、包摂規準のなかで変わった( = 例示字体が変わった)のがJIS2004なのかな - .mjt
    • JIS83で、常用漢字表で略字になっている文字を第一水準について略字に変更
    • JIS2004で、表外漢字字体表にマッチするように変更
↑

望ましい形は？

ヒラギノProのケースを挙げる。ヒラギノProはAdobeの日本語グリフセットに適合したフォント。

http://www.apple.com/jp/pro/design/typography/05/index2.html

そんなわけでヒラギノProのうち約11,400字が文字コード化された漢字で、残りの1,200字ほどは符号化されていない漢字ということです。

ところが、「辻」の一点しんにょう形と二点しんにょう形を区別したいというニーズがある。グリフセットは、このようなニーズに応えるためのものです。文字コード規格における「文字」の区別からこぼれ落ちた差異などを「グリフ」として定義しようということですね。

グリフセットにおける「グリフ」は文字セットにおける「文字」の上位レイヤーを形成しているわけです。

http://www.apple.com/jp/pro/design/typography/05/index4.html

また83年の改正のときに、字体を変えたり、入れ替えをしたりしたことが間違いだったとはっきり批判しています。JISの立場では自己批判ですね。

そして、字体の包摂規準を明示しました。それまで「暗黙の了解」だったものを誰にでもわかる形で示したわけです。これについて「包摂はけしからん」などという人がいまだにいるんですが、そういう人はグリフと文字の関係がどうしても理解できないのでしょうね。

http://www.apple.com/jp/pro/design/typography/05/index5.html

もしも今回の追加で簡略化が行われていれば文字コード的には大騒ぎになったところなのですが、今回は簡略化はなされませんで、表外漢字字体表を尊重したというか――いや、人名用漢字が表外漢字字体表を尊重する理由はないと思うのですが――伝統的な字体を採用しています。このため、JIS X 0208の例示字体に基づいたグリフセットの範囲では表示・出力できない字体がかなりあります。

大雑把に言えば例示字体の変更されたものが多いんですが、これは包摂規準の範囲内での変更なので、規格そのものは変わらず、規格票を印刷するグリフを変えただけなんです。10字だけ追加をしているんですが、これも本来のJIS X 0213の包摂規準ではグリフの違いだけなんです。ところが、Unicodeではこれを包摂していないので、グリフを変えると対応するUnicodeのコードポイントが変わってしまって大混乱になる。それを避けるために追加をしたわけです。

ヒラギノProに関しては、もちろん表外漢字字体表も新人名用漢字もサポートしています。

http://www.apple.com/jp/pro/design/typography/05/index6.html

Mac OS 9までやWindowsの場合、グリフと文字コード（JISでもUnicodeでも）は一対一対応なんです。だから文字コードは同じなのにグリフが違うという場合は、フォントを変えるしか方法がないわけです。グリフセットの場合は同じフォントの中に同じ文字コードで複数のグリフがあってもかまわないので、こういうときは便利です。ただし、文字コードとグリフセットの両方をちゃんと使えるような仕組みがないといけないわけですが。

  • WindowsのJIS2004対応とかその辺の話をここで思い出す - .mjt

Mac OS Xでは、グリフアクセスプロトコルと呼ばれる枠組みが定められていて、これに従うことでインプットメソッドからアプリケーションへのグリフ情報の受け渡し、あるいはクリップボード経由でアプリケーション間でのグリフ情報のやり取りができるようになっています。

  • WinFXのJIS切替えは、JISの例示字体の字形をグリフセットとみなして、切替えてるって事になるのかな。 - .mjt
  • AJ15について

http://www.adobe.co.jp/products/type/info2.html

↑

WindowsVista?と文字コード、字形

にわかに盛り上がりをみせている

↑

その他

↑

Unicode

↑

TRONコード

TRONコードは包摂規準をもたず、全ての字形にコードを振る方向性。

  • 包摂規準を持たないわけでなく、その範囲が狭い。（流石に明朝体とゴシック体の差異は包摂されるだろうし）
    • 「包摂規準を持たない」ってのは坂村氏の弁　例えばhttp://www.asahi-net.or.jp/~ki4s-nkmr/wabijo07.html　の12/17。幾つかの書籍でも同様の発言があったはず。 - .mjt
    • (あと、普通「包摂規準」と言った時に書体差は含まれない気がする。運筆の違いを吸収するのが包摂と考えると。)
  • code pointが振られるのは字形ではなく字体。
  • TRONコードでは 文字≒字体 かつ 字体≒字形 である。通常は 文字は複数の字体を、字体は複数の字形を包摂する。
  • そもそも文字というものは異なる図形を同一視するかしないかの“同定”を行うことで機能している(文脈で読み分けることもあるけど)。文字にコードを振るということは無限な図形の多様性から範囲を切り出す作業に他ならず、包摂抜きにはありえない。坂村氏は文字とは何かが分かっていないということ。

TRON文字収録センター http://www2.tron.org/

  • http://www2.tron.org/set09/gt.html
    • これくらい同じだと同一の字形だとみなされるらしい。一度入れたものを消してる段階で何かおかしい気がするけれど。 - .mjt
↑

(未整理の)リンク

↑

歴史的事情

本来ここに入れるものじゃないがメモとして。
トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2008-09-11 (木) 19:55:12 (687d)