『Unicode IVS/IVD入門』（田丸健三郎、小林龍生）のなかでは、この章は比較的ラク（突っ込みどころが少ない）かと思っていたら、そんなことなかった*1。 pp.141-142 人名用漢字の文字数として常用漢字までカウントしている。 戸籍法・戸籍法施行規則における常用漢字・人名用漢字の情報が古い（常用漢字改定以前）。常用漢字は「1,945字」ではなく「2,136字」。漢字の表（一）は「776字」ではなく「649字」。漢字の表（二）は「209字」ではなく「212字」。常用漢字と人名用漢字の合計（子の名に使える字）は「2,930字」ではなく「2,997字」。 「使われている漢字の種類」というタイトルの図だが、Adobe-Japan1-6の「23,058字」は漢字以外の字を多数含んでいる。 日本語漢字能力検定の情報が古い（常用漢字改定以前）。2級の範囲は常用漢字なので「約1,945字」では

'nlck'タグが使用するテーブルには4種類のバージョンが存在し、このうちヒラギノProNや改定後のモリサワPr5フォントで用いられているものが最も新しい。今回は、このテーブルの動作についてまとめてみようと思う。 以下、ヒラギノProNおよび改定後のモリサワPr5フォントの'nlck'テーブルの置換対象を、5つのグループに分けて図示する。「表外漢字字体表における印刷標準字体欄の例示字形を参照しているグリフ」を「印刷標準グリフ」と呼び、図では水色地で示す。「簡易慣用グリフ」（ビンク地）、「備考欄グリフ」（黄色地）も同様。 JIS X 0213:2004で例示字形を変更された168文字のうち、「Adobe-Japan1では変更前・変更後の違いが区別されない8文字」および「印刷標準字体以外に関する変更1文字（芦）」を除いた159文字のグリフを置換（下図）。 JIS X 0213:2004で追加さ

『基本 日本語活字見本集成 OpenType版』に含まれる「デジタル活字の基礎知識」では、小形さんが用語の定義を担当されているが、「グリフ」の定義がわたしの用語法と違っているので、そのあたりの事情について書いておこうと思う。 JIS X 0208:1997は、「字形」を「字体を、手書き、印字、画面表示などによって実際に図形として実現したもの」、「字体」を「図形文字の図形表現としての形状についての抽象的概念」と定義している。 「グリフ」という用語は、「字形」的な意味で使われる場合と「字体」的な意味で使われる場合がある。以下、仮に前者を「字形派」、後者を「字体派」と呼ぶ。 『集成』518ページで、小形さんは以下のように記している。つまり、「字形派」の定義を採用している。 フォントにある文字の形そのものを「グリフ」と呼ぶ。 「字形派」の代表と言えるのはUnicodeだろう。Unicode Sta

CMap（UniJIS-UCS2、UniJIS-UTF32、UniJIS2004-UTF32、UniJISX0213-UTF32、UniJISX02132004-UTF32）の具体的な違いについての資料をアップデートした。 変えたのは「Adobe-Japan1-5以降のCMapのバージョンによる差異」だけで、それ以外は図が古いままだったりするが、気にしない方向で。 以下追記。最新版はこちら（diff_cmap_20120906.pdf）。

UTS #37とその改訂版のドラフトによれば、あるコレクションに含まれるシーケンス識別子は、IVD_Collections.txtに記述された正規表現にマッチしなければならない。 IVD_Collections.txtにおける汎用電子の正規表現は、次のようになっている。 [A-Z][A-Z][0-9A-F]+S* この正規表現だと、汎用電子のシーケンス識別子のうち「KS369240s」と「KS382970s」の最後の小文字のsにマッチしないのだが、これでいいのだろうか*1。 *1:ところで、汎用電子のシーケンス識別子（グリフ名）における大文字のSと小文字のsの意味の違いって何だっけ？

前回のエントリで公開した平成明朝とIPAmj明朝による汎用電子IVSのリストを、一通りざっと眺めてみた。IPAmj明朝（Ver.000.01）のバグかなと思われるものについて、メモしておく。 下図に掲げたIPAmj明朝の実装字形のうち、「U+6FA0 U+E0101」と「U+9C76 U+E0101」は、単独では平成明朝の実装字形とそれほど大きな差があるわけではないが、いずれもE0102との関係に混乱があるように見える。 6月13日追記。「U+771F U+E0104」と「U+7DCB U+E0103」を追加。「U+7DCB U+E0103」は微妙な違い（突き出るかどうか）ではあるが、これ以外に「U+7DCB U+E0103」の存在する意味が発見できないので。

Adobe-Japan1と汎用電子に同じグリフがある場合、IVSを共有したほうがよいのではないかという議論がある。もちろんそうすることによるメリットもあるのだが、同時にやっかいな問題も存在する。 見た目や出自の点で「同じグリフ」であっても、Adobe-Japan1と汎用電子では、その包摂範囲が同じであるとは限らない。このため、一方のIVSに正規化すると、グリフの同一性が損われるおそれがある。 たとえば「次」のE0100（Adobe-Japan1）とE0103（汎用電子）は、いずれもJIS X 0208:1990の例示字形を参照しており、明らかに同じ字であると考えられる。しかし、Adobe-Japan1にはE0100とE0102の区別があるのに対して、汎用電子ではどちらの形もE0103に包摂されている（下図）。 このため、水色地のグリフであることを明示的に表現するための（Adobe-Japa

iPhoneや携帯における絵文字の扱いに関して、SoftBankへの要望がいくつかあるので（それから、先日コメント欄でお願いされたので）、メモ。 その1・受信側サーバでUnicode絵文字→SoftBank絵文字の変換をサポートしてほしい 現在、iPhoneの（メッセージアプリで）@softbank.ne.jpから携帯の@softbank.ne.jp宛に絵文字を送ると、空白になってしまう（下図）。 また、（これは以前からの仕様だが）iPhoneのメールアプリで@icloud.comなどから携帯の@softbank.ne.jp宛に絵文字を送った場合も同様（下図）。 受信側サーバがUnicode絵文字の変換をサポートすれば、この問題は解決する（下図）。ドコモiPhoneの登場により、ドコモの受信側サーバもUnicode絵文字の変換をサポートするようになった。auの受信側サーバは、以前からこれを

ところで、モリサワのPr6Nフォントがやばいらしいですね。 twitterで話題になってたね。 まとめを読んでも、ちょっとわかりにくかったんですけど、どういうことなんですか？ リュウミンとかのPr6/Pr6Nには複数のバージョンが存在して、新バージョンで作ったデータを旧バージョンの環境で開くと、豆腐になっちゃう文字があるんだよね。 うー、それはかなりイヤですね。 だよね。新バージョンのほうは、IVS（異体字シーケンス）対応版なんだけど、cmapも新しいのになってるから。 しーまっぷ？ cmapっていうのは、符号位置とグリフの対応表。DTP用の日本語OpenTypeフォント（Adobe-Japan1フォント）には、Unicodeに入ってないグリフもたくさん入ってるでしょ。 入ってますね。 「Unicodeに入ってない字」はcmapには載ってない。でも、そういう字が後からUnicodeに収録さ

欠字を意味するいわゆる「豆腐」の表示には、フォントのGID=0に割り当てられているグリフが用いられる*1。 こんなかんじ。まあ、XP以前のMSフォントが表示するような「・」は「豆腐」とは呼ばないだろうけど。 *1:このエントリの最初のバージョンには「ヒラギノなどのAdobe-Japan1フォントではGID=0にグリフが割り当てられていないので、OS X上のInDesignでよく見かける豆腐は、フォールバックで表示されるAquaKanaのGID=0だと思う」と書きましたが、それは勘違いでした。Adobe-Japan1フォントも豆腐（nofdef）グリフを持っています。@monokanoさん、ご指摘ありがとうございます！

IPAmj明朝を含むPDFを、iOSのメールアプリやiBooksで表示すると、特定のグリフが爆発する。 爆発前というか、爆発しない環境での表示は、こんなかんじ。 爆発するグリフをOTMaster Lightというツールで見てみた。爆発していた。 「Gridfit」のチェックを外したら、普通に表示された。 GridfitというのはTrueTypeフォントのヒンティング処理（の一部）だと思うが、そこから先はよくわからない。ただ、まったく別系統のアプリ（OTMasterとAppleのiOSアプリ）で同じ現象が見られるということは、たぶん（少なくとも）IPAmj明朝側には問題がありそう。メリー・クリスマス。

Mavericksでは、文字ビューアの「絵文字」から一部の絵文字を入力すると、「これは絵文字ですよ」ということを示す符号（U+FE0F）が自動的に付加されるようになった。また、文字ビューアの「矢印」「囲み文字」「象形文字」「標識／標準記号」などから一部の文字を入力すると、「これは絵文字ではありません」ということを示す符号（U+FE0E）が付く。 このような特殊な符号（VS: Sariation Selector）によって、文字を「絵文字スタイル」で表示するか否かを区別するしくみが、絵文字バリエーション・シーケンス。入力した文字にVSが付くかどうかは、文字ビューアの表示で確認できる。 文字ビューアのチャートが「Unicode」の場合は、VSが付かない。 そのようなわけで、親字は同じU+2600であっても、「素のU+2600」「非絵文字スタイルのU+2600 U+FE0E」「絵文字スタイルのU

日本がCJK統合漢字拡張F1/F2に提案している文字には、すでにUCSに入っている漢字と見分けがつかない例がいくつもある。これらは、提案書*1に「Similar and Variation」として既存の文字の符号位置が記載されているものの一部であり、つまり、似ている漢字の存在は百も承知で提案しているわけだ。 以下、そのような例を拾ってみた。左右に並べた文字のうち「UCS」欄に符号位置が入っているほうが、既存のもの。個々の文字について述べることはしないが、要するに「別字の衝突であれば、形が同じでも別の符号を与える」ということだろう。 だが、ちょっと待ってほしい。それって実はものすごく根本的な方針転換じゃないですか？　「機」の簡体字の「机」も「つくえ」の「机」も、形が同じである以上、同じ符号位置（U+673A）に包摂・統合するというのがCJK統合漢字の大原則であったはず*2。ここでいきなりそれ

iPhone間の新しい文字化けパターンが発見されたのでメモ*1。この少なくとも3つのダメな仕様が重なって発生する文字化けは、発見者によって「兄化け」と命名された*2。 「兄化け」は、兄がSoftBankまたはauのiPhoneでメッセージアプリを、妹がiPhoneのメールアプリでdocomo.ne.jpアドレスを使っている場合に発生する。兄が絵文字入りのメールを送信すると、妹の環境では絵文字が豆腐に化け、それを引用して返信すると、今度は兄の側でメッセージ全文が化ける。 以下、この文字化けの理屈について。兄のメッセージアプリは、絵文字入りのメッセージをUTF-8で送信。キャリアの送信側のサーバが、これをドコモのShift_JISに変換する。しかし、妹のiPhoneのメールアプリはドコモのShift_JISに対応していないので、ドコモの絵文字を単に「Shift_JISの未定義領域の文字」として

この項10月28日追記。iOS 7.0.3でSoftBank iPhoneのメールアプリの仕様が修正され、charset=Shift_JISのSoftBank絵文字が表示されるようになった。 昨日のエントリの続き。iOS 6のSoftBank iPhoneでは、メールアプリはShift_JISのSoftBank絵文字（下図、黄色字の領域）をテーブル変換していたが、iOS 7ではこのプロセスが落ちていて、0xF040以降は機械的にUnicodeの私用領域の文字に変換されるようになった。このため、charset=Shift_JISで送られてきた絵文字は、大半が豆腐に化ける。 ただしiOSは、Unicodeの私用領域にSoftBank絵文字を収録している。このため、「機械的に私用領域の符号位置に変換された絵文字が、たまたま別の絵文字と衝突する」（つまり、別の絵文字に化ける）というケースもある。下

この項10月28日追記。iOS 7.0.3でSoftBank iPhoneのメールアプリの仕様が修正された。 「iOS 7にしてから文字化けするようになった」という話には、知る限りにおいて2つのパターンがある。1つ目は「SoftBank iPhoneで受信したメールの絵文字が表示されない」というもの。その原因については、前回と前々回に述べた。2つ目は「送信したメールのすべての文字が相手先で化ける」というもの。今回は、こちらについて述べる。 この現象も、前回・前々回の話とつながっている。簡単に言うと、iOS 7のメールアプリは「SoftBank独自」の処理を行っていないように見える。このため、「これまでは（au iPhoneなどではcharset=CP932になるが）SoftBank iPhoneではcharset=Shift_JISになっていた」というケースで、charset=CP932に

iOS 7では、ある種の絵文字を入力したとき、「これは絵文字ですよ」ということを示す符号（U+FE0F）が自動的にくっつくようになった。 これまで、「♥」のように絵文字と普通の文字が同じ符号位置を共有している例では、環境によってカラー絵文字で表示されたり、普通の文字として表示されたりした。たとえば、iOS 6のメールからMacに「赤いハートの絵文字」を送ると、Macのメールでは「黒いハート記号」が表示される。 このような表示のズレを解消するために、Appleが提案してUnicodeに導入されたしくみが、絵文字バリエーション・シーケンス（詳しくは「絵文字バリエーション・シーケンスとは何か」を参照）。iOS 7は、これを利用する。U+FE0Fの付いた「赤いハートの絵文字」は、Macのメールでも黒くならない。 ただしもちろん、絵文字バリエーション・シーケンスに対応していない環境（たとえば初代iP

改定前の常用漢字表では、「闘」の旧字体（康熙別掲字）がつぶれていて、字体が判別できない。この字を、JIS X 0213は下図のような例示字体で収録した。そして改定常用漢字表も、おそらくそれに倣っている。以下、「どうしてこれがこれになるの？」という素朴な疑問を出発点として調べてみた*1ことをメモしておくが、あらかじめ断っておくと、特におもしろい新事実が明らかになったりするわけではない。 「闘」の康熙別掲字の可能性があるのは、Unicodeの符号位置でいえばU+9B2CまたはU+9B2D。汎用電子（Hanyo-Denshi）のIVDには5種類、Adobe-Japan1のIVDには3種類の異体字が登録されている。 また、わたしのMacに入っている中文フォント（Songti SC）の字体、『明朝体活字字形一覧』（文化庁文化部国語課）に掲載されている字体なども含めると、「鬥」の中の「斲」の左の部分（

2001年以降に日本が国際提案した漢字について、どのような経緯で規格化されたか、規格化されようとしているのかを、おおざっぱな図にしてみた。細かいことを言い出すとキリがないので、それは言わない方向で。下図、グレー地はドラフト段階のもの。 2001年に提案された謎の国字集合（今昔文字鏡ソース）は、その後、典拠の発見できない漢字については提案を取り下げられたりしたが、一部が2009年のUnicode 5.2でCJK統合漢字拡張Cとして規格化された。文字鏡ソースで拡張Cに入った367字のうち320字は汎用電子にも含まれる。 拡張Cに提案された文字のうち後回しにされたものは、拡張C2と呼ばれ、その後拡張Dと呼ばれることとなった。拡張Dは量があって審議に時間がかかるので、緊急に必要な漢字を少数に絞って先に入れましょうというのがUNC（Urgently Needed Characters）で、UNCは2