規格のアンチテーゼとしての「字体化け」

ここ数日『基本日本語活字見本集成本』のことを書き継いでいます。本当はJIS X 0212のことを書く予定でしたが、予定を変更して今日はこの原稿を書いた後、ずっと引っかかっていた「字体化け」について書くことにします。

あ、その前に誠文堂新光社の編集さんから誤植について早速直した由メールをいただきました。感謝。ネット書店で売っていないのは、広告を入れられる雑誌コードにしたからだそうです。もっとも、これほど取り扱わないとは幾分想定外だった様子。今までのエントリでは書きませんでしたが、この本の真価はぼくなどの原稿にはなく、見本帳部分にあります。おそらくこれほど組見本が充実した類書はなかったはず。デザイナー諸氏はぜひぜひ手にとり、そのすばらしさをお確かめください。編集を担当したデジクリの柴田忠男さんが紹介文と内容が分かる写真を公開されているので、リンクを張っておきます。

では本題に入りましょう。ぼくは、この本の中で、以下のようなことを書きました。

　フォントを製作する場合、包摂の範囲から任意の文字の形を選びデザインすることになる。その結果フォントによって文字の形は微妙に異なることになるが、包摂の範囲が社会的に「同じ文字」とする範囲と一致している限り、たとえ情報交換により文字の形が変わっても意識されず混乱はおきない。（p.519）

一方、違うページでこういうことも書いています。

（2000年のJIS X 0213初版――2000JIS制定直後に表外漢字字体表が答申され、これに対応するため、2004年に2004JISとして改正されたことを説明した上で）

ではこの2004JISの変更は実装に、そして私達ユーザーにどのような影響を与えるのだろうか。

Mac OS Xが実装するのは2000JISだ。一方で2006年末から出荷を開始したWindows Vistaは2004JISだ。したがってMac OS XのヒラギノフォントとWindows VistaのMSフォントの間で、包摂の範囲で文字が化ける（これを字体化けとよぶ）。のみならず、Windows Vistaより前のバージョンとの間で同様に字体化けが発生する。本稿執筆時点の2007年2月現在、変更された例示字体を地名に持つ自治体や会社の間で戸惑いが拡がっているとの報道がつづいている。今後こうした混乱の拡大が懸念される。（p.522）

なんか矛盾していませんか？　〈包摂の範囲が社会的に「同じ文字」とする範囲と一致している限り、たとえ情報交換により文字の形が変わっても意識されず混乱はおきない〉というのが本当なら、「字体化け」などないはずですよね？　もしも真実「字体化け」が問題なら、それは包摂範囲の設定が間違っていた、つまり社会的に「同じ字」と認識されていない字体を包摂してしまっていたということになる。つまり「字体化け」とは文字コード規格のアンチテーゼに他ならないように思うのです*1。

――というようなことを、書きながら思ったものの、1,200字という字数の制限ではここまで書くことはできませんでした。というより、これは書く前から考え続けていたことなのです。Windows Vista発売により、もしも「おれの字と違う」という声が津々浦々で澎湃として巻き起こるとしたら……それは2004JISの包摂範囲が間違っていたことになるだろう、と。その意味で、発売直後になされた各種報道は、そういう暗い予感を裏付けるものでした。以下はその一例。

ウィンドウズ・ビスタ――漢字字体で戸惑い『NHKニュース7』（2007年2月10日）（yasuokaの日記、漢字の古来の形より。番組中の安岡さんのコメントは、取材を受けた当人の意には染まないもののようです）

さて、Windows Vista発売から4ヵ月余りをすぎた今、この問題をどう考えるべきでしょうか。次回に続きます。

Permalink | コメント(25) | トラックバック(0)

*1：ついでながら、包摂のない文字コードはありません。どんな文字コードでも符号位置による情報交換をする以上は包摂は不可避です。仮に包摂のない文字コード規格があるとすれば、それは特定のフォント以外の使用を禁止した規格ということでしょう。寡聞にしてぼくはそのような規格を知りません。

コメントを書く

小熊善之 2007/04/24 09:55 結局のところ、規格で定めた包摂基準が、社会が暗黙として持つ包摂基準と合致していなかった、って結論にしかなりようがないような。

ogwata 2007/04/24 10:26 まあまあ、そう結論をいそがずに。

Taro 2007/04/24 11:27 グリフ（または具体的字形）の相互可換に対する意識・心理的な事柄、それと、情報交換における文字の包摂基準の妥当性の評価、というのは、別個の課題ではないかと思うのですが、いかがでしょう。

ogwata 2007/04/24 13:38 そうでしょうか？　一致するとまで思いませんが、完全に別個というのも違うように思います。分けて考えることは文字コード規格を現実社会から遊離させることにつながるのでは？

えむけい 2007/04/24 20:19 > 寡聞にしてぼくはそのような規格を知りません。
JIS X 9052とか。文字コード規格じゃありませんけど。
それはともかく包摂という用語の使い方がJIS X 0208やJIS X 0213のそれとはずいぶん異なるようですが、ここでの定義はどこかで読めるでしょうか。

ogwata 2007/04/24 21:06 えむけいさんはJIS X 9052を情報交換に使われるのですか？　また、JIS X 0208とJIS X 0213の包摂規準に、なにかここでの議論に関わるような違いがあるのでしょうか？

KoichiYasuoka 2007/04/24 22:37 うーむ、包摂のない文字コード…。GB 2312-80ってのは、かなりそのセンに近かったんですけど、廃止されちゃいましたね。ANSI/NISO Z39.64-1989ってのは、入力時の包摂は許してるけど、出力時の包摂は許してない(と言えなくもない)ので、さてどうなんでしょ？

ogwata 2007/04/24 23:24 自己レスですが、ブログにうつつを抜かしている間に本業が押し迫ってきたので、このエントリの続きは明日以降にさせてください。

ogwata 2007/04/24 23:35 安岡さん、ANSI/NISO Z39.64-1989という規格は知りませんでした。図書館における東アジアの言語コードを決めたもののようですが、「入力時の包摂は許してるけど、出力時の包摂は許してない」というのは、どのような規定によって可能になるんですか？

yanok 2007/04/24 23:44 Vistaのフォントについていえば、漢字の字体なぞよりも、MSゴシックの9ポイントの「2」の形だとか、小さめのフォントの見た目が全般に変わったとかの方が遥かに問題視されているような気がします。

ogwata 2007/04/25 00:49 yanokさん、そのとおりですね。つまり発売当初の報道に反して、一般での受け止められ方はどうやら違ったようです。ただ、まだ十分に普及していない現段階での即断は禁物でしょうけれど。

KoichiYasuoka 2007/04/25 09:27 ANSI/NISO Z39.64はCCCIIの親戚にあたる文字コードで、「異体字」に通し番号を振った文字コードです。全く同じ字形であっても違う「意味」であれば、違う文字コードになります。しかも、基本的にはMARC上での運用が前提です。で、こういう文字コードをどう運用するかなんですけど。
たとえば「芸」という字を入力する場合に、入力者が「藝」の異体字だと感じたなら4B5631を、「蕓」の異体字だと感じたなら29454Dを、どちらでもないと感じたなら227C37を、入力することになります。4B5631と29454Dと227C37の出力字形は、どれも確かに「芸」なんですけど、実は微妙に字形が変えてあって、見る人が見れば「見分け」がつくようになっています。逆に言えば、もし出力字形を変えてしまうと、同じ字体の異体字の「見分け」がつかなくなってしまうので、運用上、出力字形を変えるわけにはいかないようになっているのです。
ま、そこまで規格に規定されてるわけではないんですけど、そういう運用が想定されていて、で、図書館に対してはフォントまで配布されているので、まあ「出力時の包摂は許していない」と考えていいんじゃないかと。

えむけい 2007/04/25 09:40 「文字コード規格じゃない」ってわざわざ断ってるのに。<これはエイプリルフールです></これはエイプリルフールです>くらいのマークアップをしないと通じないんでしょうか。
で、私は小形さんの用法がJIS X 0208ともJIS X 0213ともだいぶ異なると書いたつもりで、JIS X 0208とJIS X 0213の違いに触れた覚えはないんですけど。
もっと具体的に書くと、JIS X 0208やJIS X 0213の4.や6.6.2を見れば自明なように、JIS X 0208やJIS X 0213では「字形デザインの違い」とか「書体の違い」に対して包摂という用語は使っていません。
小形さんがそれを知らないとかぶっちゃけありえないので何か意図があってそういう使い方をしてるに違いないと昨日までは確信していたのですが、ここまで見当はずれな返事をされると自信がなくなってきました。

ogwata 2007/04/25 17:54 安岡さん、ご親切に詳細な解説ありがとうございました。考えてみれば「グリフをある程度指定した文字コード規格」という流れはありましたね。たしかGB18030でも明朝・ゴシック・ビットマップ3種類のフォント・デザインを別に示してあり、この規格に適合しようとするフォントは、国家機関がこのデザインに基づき審査する仕組みだったように記憶します。ただし、この場合でも「デザインのゆれ」は最小限度になりますが、それでも発生します。つまり、やはり包摂は避けえない。
もっとも、ご説明のANSI/NISO Z39.64のように、フォントそのものを添付すれば、たしかに「出力時の包摂は許してない」となりますね。なるほど。どうもありがとうございました。

ogwata 2007/04/25 18:08 えむけいさん、気を悪くされたら謝ります。どうか怒らないで。もしよろしければ、ぼくの文章のどの部分がJIS X 0208ともJIS X 0213とも違う定義なのか、もう少し詳しくご説明願えませんか。

koikek 2007/04/25 23:53 あれあれ、尾形くん。

koikek 2007/04/25 23:54 誤植。小形くん。

豊島正之 2007/04/26 05:54 >JIS X 0208やJIS X 0213では「字形デザインの違い」とか「書体の違い」に対して包摂という用語は使っていません。
「字体」は、字形を抽象的した概念上の存在で、「字体の包摂」は、それらの概念同士に対する操作と考えられます。その意味で「字形の包摂」は変です。しかし、「字形デザイン」が、同じく概念同士として扱える程に抽象されているのであれば、別に「包摂」を論ずる事に問題は無い様にも思われますが、如何でしょうか。
それより、私には「出力時の包摂」という概念が分りません。グリフの規格への適合性の事ですか ?
仮にその適合性が規定されたとしても、実際に出力されて仕舞った字形は既に概念上の存在ではないので、そこに「包摂」があり得るとは思われません。

えむけい 2007/04/26 09:23 GB 2312-80に(このエントリの意味での)包摂がないということは、第二級漢字で部首が変わる最初の文字だけはゴシック体で実装しないと不適合になったりするのでしょうか。
http://www.itscj.ipsj.or.jp/ISO-IR/058.pdf
知ってるとは思いますが実際の規格票もこうなってます。

えむけい 2007/04/26 09:38 そういえば、やはり文字コードではありませんが http://10036ra.org/ には
> they provide a minimal level of interchangeability.
と書かれていて日本政府も(対応JIS規格を)情報交換に使うつもりであるらしいところのISO/IEC 10036の登録機関は、文字鏡によるグリフ「修正」の申し出を却下したりしてますね。
http://www.y-adagio.com/public/sc34wg2/doc_201-250/wg2n207.htm
文字鏡が置き換えてもかまわないと考えるということは相当微細な差だったはずですが。

えむけい 2007/04/26 10:00 JISの委員だった皆さんには、思うだけではなく規格にそう書いてくださいとお願いしたいです。思っただけでは規格を読んでる人には伝わりませんしブログのコメントに書き捨てただけでは検証可能なソースとはとても言えません。
そんなにマイクロソフトにShift_JIS-2004を実装させたいならなんで規定にしなかったんだとか。GB18030は実装されましたから規定にできていれば実装される可能性はあったと思われます。

Taro 2007/04/26 10:41 どうも論理が飛躍しているように感じるのは私の主観でしょうか。
「もしも「おれの字と違う」という声が津々浦々で澎湃として巻き起こるとしたら……それは2004JISの包摂範囲が間違っていたことになるだろう、と」
そうではなくて、今まで使っていて主観的に慣れ親しんでいたグリフ（およびその具体的な実現としてのフォント、明朝の活字書体）と異なるグリフを、自発的・主体的に選択してもいないのに使うしかなくなる、あるいは字形が期待したものと変わってしまう場合がある（特に同一フォントのグリフを変更した場合）、ことに対する主観的な違和感・不都合が、全体として非互換性として意識されるのであって、包摂された範囲内で異なるグリフをもつ、異なるフォントの実装が存在すること自体には何ら問題はないのでは？　それが問題なら楷書体にも之繞の点を２つ付けることになってしまいます。
　つまり、実装上のグリフの安定性と一貫性が議論されているのではないのでしょうか。問題にすべきは、例示字形の変更であって、包摂基準ではないと思うのですが。あまり自信がないので、間違っていたらお教えください。

ogwata 2007/04/26 17:53 豊島さん、ご指摘、ありがとうございました。たしかに包摂が対象としているのは概念でしたね。うかうかと忘れるところでした。

山本さん、ありがとうございます。なんとなく山本さんが持たれていた違和感が分かってきました。しかし、社会的に「図形概念として区別が困難なもの＝同じ字」を同一面区点に割り当てるのが包摂であるとするなら（4-(w)）、たとえ「今まで使っていて主観的に慣れ親しんでいたグリフ」が包摂の範囲内で変化したとしても、ユーザーは区別しないので混乱も起きえないのではないでしょうか？

Taro 2007/04/26 20:51 「たとえ「今まで使っていて主観的に慣れ親しんでいたグリフ」が包摂の範囲内で変化したとしても、ユーザーは区別しないので混乱も起きえないのではないでしょうか」
　いや、私はこの問題は基本的に文字のレベルではなく、グリフレベルの問題だと思っているのですが（間違っているかもしれませんが）。
　例えば、字体よりも、より具体的な書体レベルの例で考えましょう。吉田茂ではありませんが、ずっと何十年間も新聞はThe Timesを購読していた人がいるとしましょう。本文はTimes New Romanが当たり前になっていることと思います。これが、もしある日突然、Helveticaで本文が組まれたら、違和感を感じる人も多いでしょう。そういう人の数が多ければ、それをある種の非互換性と意識されることもあるでしょう。本当に変えてしまったら、読者は苦情を言わないでしょうか。それは、突然慣れ親しんだ書体を変えたことが原因になっていると言えるでしょう。書体のレベルでもこういうことが（現実に起こるかどうかはともかく）推測できるのですから、それよりも抽象度の高いグリフのレベルで変化があれば、それに対する違和感が生じたとしても不自然はないでしょう。Helveticaに変わるのではなく、ゴシック体のFrakturに変わった場合を考えると、その＊書体差＊における違和感は、JIS2004で言われている違和感の比ではないかも知れません。では、そういう違和感があるからといって、サン・セリフ書体の”A”とローマン体の”A”を異なるコードポイントに割り当てるべきでしょうか。ローマン体の”A”とゴシックのFrakturの”A”を異なるコードポイントに割り当てるべきでしょうか。
　同じことが日本語にも言えるでしょう。よくJIS2004のはなしで出てくる「辻本さん」の例で言うと、明朝体の之繞が二点だからといって、楷書の之繞も二点にすべきでしょうか？　一点の之繞の文字とそれに正確に対応する二点の之繞の文字とを異なるコードポイントに割り当てるべきでしょうか。
　違和感や非互換性に対する感覚は、いろいろなレベルと程度の差異に対して、ありうるわけです。しかしこのような感覚は、必ずしも文字の「区別」を考える場合に、包摂を排除するものではないでしょう。辻本さんの場合、包摂されないとしたら、之繞が二点の（皆無とはいえないですがかなり珍しい）楷書体フォントが日本ではどんどん作られることになって、中国や台湾の人々の失笑を買うことになるかもしれません。
　文字であれ、グリフ（≒字体）であれ、どのレベルでも、区別しないということはないのです。差異がある限り。そのような差異を区別しないとみなすこと、抽象化することによって、文字の情報交換上の機能を効率的に満たそうとするのが文字のレベルであれば、違和感があったから、即包摂基準が間違っている、ということにはならないでしょう。「図形概念」というのは、「この形とこの形は違う形だよなあ？」というような、具体的図形と具体的図形のあいだの類似性や識別ではなく、図形の概念的な理解における識別でしょう。特に漢字について言えば、漢字の図形の概念的な理解における差異と識別、というのは、単なる具体図形の差異だけでなく、漢字としての等価性を理解する文化的な文脈が前提となっているはずです。明朝体の二点の之繞の文字と、それを楷書体で表現した一点の之繞の文字とを等しいものとみなすためには、文化的な背景に対する理解が不可欠なわけです。「包摂基準が間違っている」というためには、単にグリフや具体的なフォントの実装における非互換性や違和感があるからというだけでは不十分でしょう。というか、むしろ、そのような実装上の比互換性を増幅させたのは、むしろ意図的な例示字形の変更に原因があると考えるのですが。

ogwata 2007/04/27 00:14 山本さん、詳細なご説明ありがとうございます。読んでいくにつれ、山本さんとぼくの考え方の違いは同じ現象から出発した違うものの見方であるように思えてきました。ただし、ぼくの考えていることと重なる部分も多い様子。そこで提案ですが、性急にここで結論を出すことはせず、エントリを進めながら議論を継続していきませんか。大変面白くなってきました。

スパム対策のためのダミーです。もし見えても何も入力しないでください

画像認証

トラックバック - http://d.hatena.ne.jp/ogwata/20070423/p1

idトラックバック

http://d.hatena.ne.jp/ogwata/20070426

リンク元

もじのなまえ

2007-04-23

規格のアンチテーゼとしての「字体化け」

		2007/04
日	月	火	水	木	金	土
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30