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

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

この「雌」の字、IPAmj明朝では区別してるんだけど、どこが違うかわかる？ んー。無理に違いを探すなら、右上のあたりですかねー。 確かに、右側の「雌」のほうが、おっぱいが小さい。 おっぱい？　字源的にそうなんですか？ いや、ノリでそう呼んでみただけだが。 ……はあ。 で、このおっぱいの小さい「雌」がどこから来たかというと、戸籍統一文字なんだけどね。 あー、戸籍統一文字の時点で、すでにおっぱいのサイズが違いますね。 ところがこれ、画数の情報を見ると、左は14画で、右は13画なんだよ。 ん？ そもそも、おっぱい差は字体差ではなくデザイン差だから、そんな違いで戸籍統一文字に登録されるわけがない。 おっぱい差？ おっぱい差はサイズの差であって、骨格の差じゃないってこと。ポイントは、実はおっぱいじゃなく偏のほうで、3画目がそのままハネるかどうかの違いだな。 うーん。そう言われて見直してみても、右側の

だれかにメールを出すとき、どんな宛名で届いてるのか、不安になることってないですか？ ん、なんで？ MacやiPhoneのメールって、表示されてる差出人や宛先を見ただけじゃ、本当はそこに何が書いてあるかわからないじゃないですか。で、気付かないうちに本人に見られたくない名前が送られちゃたりしないかな、と。 あー、たとえば「ほげ山」さんのメールアドレスを自分の連絡先には「バカ先生」って名前で登録してますみたいなこと？　そういうの（下図）は危険だぞ。 こっちで「バカ先生」って表示されてるメールに返信すると、相手にも「バカ先生」で届くんですか？ いや、そうとは限らなくて、けっこう複雑なんだよね。たとえば、連絡先に「バカ先生」が登録されている環境で、ほげ山さんからFrom欄に「ほげ山 」と書いてあるメールを受け取ったとすると、山ライオンやiOSのメールアプリでは、こんなふうに見える（下図）*1。リスト

（2013年10月追記1）iOS 7の登場以来、このエントリへのアクセスが増えているので、情報を追加。iSO 7では、以前はauのiPhoneなどでしか発生しなかった「送信したcharset=CP932のメールが、Android端末で化ける」現象が、SoftBank iPhoneでも発生するようになった。詳しくは「iOS 7にしたら送信したメッセージが化けるようになった」を参照。 （2013年10月追記2）実際に確認できてはいないのだが、iOS 7の仕様変更により、iPhoneのメールアプリからSoftBankのケータイに絵文字を含むメールを送った場合、メッセージ全体が化けるのではないかと思われる（これに該当する経験をお持ちの方、コメント欄などで情報をいただけるとありがたいです）。 （2013年10月追記3）iOS 7がらみで（メッセージ全体が化けるのではなく）絵文字が表示されない問題につ

Appleカラー絵文字が変わった。OS X Lion 10.7.3では、一気に300以上の絵文字が、新たに追加されたり、カラー化されたりした。 これらは、現時点では文字ビューアの「絵文字」からは入力することができないので、見つけにくく、あまり話題になっていないようだが、大きいサイズで表示されうることを前提とした気合いの入った描き込みがすごい*1。 入力は、文字ビューアの「Unicode」から。今回掲載した絵文字は、U+1F301 FOGGY、U+1F30B VOLCANO、U+1F30C MILKY WAY、U+1F402 OX、U+1F404 COW、U+1F405 TIGER、U+1F406 LEOPARD、U+1F408 CAT、U+1F409 DRAGON、U+1F40A CROCODILE、U+1F40B WHALE、U+1F415 DOG。 *1:そのぶん、以前からある絵文字と

ここに2匹のプードルがいるんだけどね。 間違い探しですか？　ズバリ、左にだけ眉毛がありますね。 うん。眉毛があるほうが、iPhoneやLionに入ってる絵文字フォントのプードル。眉毛のないほうが、Unicodeのコードチャートに載ってるプードル。 えっ、どういうことですか？ そもそもUnicodeにケータイ絵文字を入れようって提案したのがGoogleとAppleだからね。提案書のための絵文字をAppleが用意して、それがUnicodeに収録された。そのあとで、iPhone絵文字に含まれていなかった文字については、データを流用して絵文字フォントに追加したってことじゃないかな。 だからほとんど同じなんですね。でも、眉毛はどうなりました？ ケータイ絵文字をUnicodeに収録する過程では、いろいろあってさ。たとえば、日本の絵文字のマンガっぽさをめぐる戦いとか。ほら、アイルランド・ドイツ修正案って

前回は新しいCMapの中身を見たが、今回は、CMapと各フォントの関係について。以前「日本語OpenTypeフォントの分裂の歴史」に載せた図の2011年版を作ってみた。図が大きくなりすぎても見にくいので、今回はAPGSは省いた。 小塚明朝については、バージョン番号だけではAdobe CSのバージョンとの関係がわかりにくいので、別の図を作った。小塚はこれまで、新しいCMapをいち早く採用する傾向があったが、2011年にリリースされたCS5.5では、付属する小塚書体が採用しているCMapのバージョンはCS5と変わっていない。

InDesign CS2とCS4には、aalt属性を持つ文字の直後にプレーン・テキストをペーストした場合、その文字にaalt属性が伝染してしまうバグがあった（InDesign CS4で異体字のあとにテキストをペーストしたときの文字化け）。 このようにして伝染したaalt属性は、潜伏していることがいる。たとえば「圧」という文字に「aalt 1」という属性が付けばグリフは「壓」に置換されるのですぐに気付くだろうが、「aalt 5」という属性が付いた場合、（「圧」にはaalt 1の「壓」以外には異体字は存在しないので、親字である「圧」が表示されたままとなり）その異体字属性は顕在化しない。 ところがInDesign CS5には、「異体字を1つだけ持つ文字に“2”以上のaalt番号が付いていた場合、番号1（aalt 1）のグリフを表示してしまうというバグ（だと思う）があるようだ。つまりInDesig

文字コードについて説明しようとする場合、「例外を無視して単純化すると、厳密にはウソになってしまう」という罠に陥りやすい。矢野啓介『プログラマのための文字コード技術入門』は、平易な文章でありながら、そのような落とし穴を慎重に回避することに成功していると思う。 プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ) 作者: 矢野啓介出版社/メーカー: 技術評論社発売日: 2010/02/18メディア: 単行本（ソフトカバー）購入: 34人 クリック: 578回この商品を含むブログ (129件) を見る カバー・本文デザインはn-yujiさん（遠近法ノート）*1なので、組版に関しても安心。 この本には、「文字コードはなぜ複雑になるのか」という節が用意されており、著者は「文字コードを複雑化させる二つの理由」として、「過去の経緯の

Spotlightの検索がダメで、先日ハードディスクを初期化し、システムを再インストールした。移行アシスタントで以前の環境を引き継いでしまっては元の木阿弥なので、各種の設定やアプリケーションのインストールは新たに行い、ドキュメント類のみ、バックアップ先の外付けハードディスクから内蔵ハードディスクに手動でコピーした。 が、やはりSpotlightで内蔵ハードディスクの検索ができない。具体的には、Spotlight用の索引作成プロセス（mds）がCPUをほぼ100%占有したまま、いつまで待っても終了しない。この状態に陥ると、Time Machineによるバックアップもできなくなってしまう。 わざわざ初期化までした以上、バックアップ先から持ってきたファイルに問題がある可能性が高い。そこで、内蔵ハードディスク内のファイルを「システム環境設定＞Spotlight＞プライバシー」に入れたり出したりして

前回のエントリで見たように、Adobe-Japan1フォントでは、欧文約物形状のダッシュ（CID+138）がU+2014 EM DASHに、和文約物形状のダッシュ（CID+661）がU+2015 HORIZONTAL BARに対応している（下図）。しかし、U+2015 HORIZONTAL BARがもともと「日本語組版のための全角ダッシュ」としてUnicodeに収録されたものだとは考えにくい。では、これは何なのか。わかっているいることを以下にメモするが、あらかじめ言っておくと、あまりまとまりはない。 Unicode Standardの「6.1 Writing Systems」には、「U+2015 HORIZONTAL BARは、ある種のタイポグラフィのスタイルで、引用文の導入に用いられる」と記されている。 U+2015 HORIZONTAL BAR is used to introduce

あさうすさん（実験る〜む）の「和文としてのダーシが変」を読んで、Adobe-Japan1フォントの全角ダッシュが和文約物形状ではなく欧文約物形状で表示される理由について考えてみた。このエントリでは、JIS X 0208の1区29点「ダッシュ（全角）」を「全角ダッシュ」と呼ぶこととする。 昔は、全角ダッシュの実装グリフは和文約物形状だった。今ではたいていの場合、欧文約物形状。どちらになるかは、「文字コードがUnicodeか否か」による。たとえば小塚明朝Pr6Nのような新しいフォントでも、Shift-JISアプリでは全角ダッシュは和文約物となる。また、（試していないけれど）CIDフォントでもUnicodeアプリでは全角ダッシュは欧文約物となるはず。 Shift-JISとUnicodeでグリフが変わるのは、全角ダッシュだけではない。たとえば、セント記号について見てみよう。JIS X 0208は、

InDesignやIllustratorの合成フォント機能では、文字種（漢字／かな／全角約物／全角記号／半角欧文／半角数字）ごとに各種の設定ができる。では、それぞれの文字種には、具体的にどのような字が含まれるのだろう。答えは合成フォントのファイルに書いてあるのだが、そのままではわかりにくいので図にしてみた。図に用いたフォントは、ヒラギノ丸ゴProとMinion Pro。 「かな」は下図のとおり。小書きの「か」（U+3095）と「け」（U+3096）が入っている点からするとAdobe-Japan1-5以降のcmapを想定しているようなのだが、JIS X 0213で追加されたカタカナ（小書きの「ク」など）は入っていない。 「全角約物」は下図のとおり。フォントによっては全角でない文字も含まれる。引用符（シングルとダブル）は「全角約物」に分類されているので、引用符に「半角欧文」のフォントを利用した

1989年、Appleは漢字Talk 6をリリースし、また、初の日本語対応PostScriptプリンタであるApple LaserWriter II NTX-Jを発売した。NTX-Jに搭載されていた日本語フォントは、モリサワのリュウミンL-KLと中ゴシックBBB。 プリンタ・フォントであるリュウミンL-KLと中ゴシックBBBの文字セットとエンコーディングは、Adobeによって83pv-RKSJ（以下単に「83pv」と呼ぶ）*1として定義されており、その外字部分（下図・左）は、NECのPC98外字のサブセットとなっていた。 リュウミンL-KLと中ゴシックBBBに対応するスクリーン・フォントとしてAppleから提供されたのが、細明朝体と中ゴシック体。漢字Talk 6.0.7でForeign System Fontをインストールすると、上図青地部分を画面表示することができた。 上図ピンク地部分の

ケータイの絵文字について、各キャリアの「他社用変換表」を見ると、ゲタにするよりはマシだろうということなのだろうが、けっこう強引というか、感覚的な対応も多く、ラウンドトリップの互換性は保証されない。 つまり、絵文字入りのメールを他社ケータイに送信し、さらにそれを引用して送信するというプロセスを繰り返した場合、伝言ゲームのように少しずつ絵文字の意味がズレていく可能性がある。 というわけで下図は、適当に拾った例で、絵文字がどんなふうに変化していくのかシミュレートしたもの（16進数はShift-JISコード）。文脈によっては、キケンなニュアンスに変わったりすることもあるかも。

似たようなグリフが数多く入っているAdobe-Japan1のなかでも、二重引用符の仲間はかなり多く、InDesignの字形パネルなどを見ただけでは、その全容を把握するのが難しい。たとえば下図では26のグリフが表示されている。これだけでもややこしいが、実際はもっと多い。図に用いたフォントはリュウミンPr6（以下同）。 そこで下図では、二重引用符用のすべてのグリフを、体系的に整理しようと試みた。まず、起こしと受けでグリフが異なるグループ（上）と共通のグループ（下）に大別し、次にプロポーショナル、イタリック、全角、半角に分類した。黄色地は横組み（地の幅はグリフの幅を表す）、それ以外は縦組み用のグリフ。 グレー地の縦組み用グリフは、全グリフを網羅するために入れておいたが、これらは一部の処理系が必要とする縦組み用の回転済みグリフであり、ユーザは通常意識する必要がない（このエントリでも、以後無視する）

InDesign CS2以降には、「環境設定：組版」に「CIDベースの文字組みを使用」というオプションがある。が、わたしはこれが何だったのか定期的にわからなくなって調べ直すハメになるので、今回はややしつこくメモしてみることとした。ヘルプには、輝かしい火星語で次のように記されている。 Unicodeの代わりに使用されているフォントの字形を使用する正確なJIS X 4051文字組みクラスを決定するには、「CIDベースの文字組みを使用」を選択します。OpenTypeフォントを使用している場合に、このオプションが便利です。この機能では、AdobeJapan1-0〜AdobeJapan1-6のすべてのCIDフォントがサポートされています。Unicodeは、他のすべてのフォントで使用されます。 要するに「CIDベースの文字組みを使用」をオンにすると、符号位置ではなくCIDに基づいて文字クラスが決定され

下図は、U+2603 SNOWMAN（CID=8218）を、リュウミン、小塚明朝、ヒラギノ明朝、MS明朝、メイリオで表示したもの。左端はUnicodeの例示字形。 各フォントの雪マークのうち、たぶん最も古くからあるのはリュウミンの白バケツ・二つボタン雪マークで、1990年にリリースされたAdobe TechNote #5031（Kanji Glyph Collections and Glyph Sets）において例示グリフとして用いられており、他の雪マークに影響を与えているものと思われる。 雪マークはJIS X 0213:2000の1-6-75に収録されており、その（平成明朝による）例示字形はMS明朝と同じ。リョービイマジクスがデザインした雪マークの字母が、平成明朝とMS明朝で共通して使われているということなのだろう。 Adobe-Japan1のTechNote（#5078）では、2000

引用符が全角かプロポーショナルかは、フォントによって異なる。Adobe-Japan1-5以降のCMapを採用しているフォントなら（レパートリはAdobe-Japan1-5でなくても）プロポーショナル、そうでなければ全角である。下図のリュウミンでは、Proが全角、Pr5がプロポーショナル。グレー地は文字幅、枠の下の数字はCIDを示す。 InDesignで引用符を縦組みにすると、全角のものは縦用グリフに置換されるが、プロポーショナルのものは置換されず、回転もしない。以下の図では、H：横組み＝グレー地、V：縦組み＝水色地とする。また、InDesignの設定はすべて「文字組み：なし」「CIDベースの文字組みを使用：オン」。 引用符はUnicodeでU+2018、U+2019、U+201C、U+201Dだが、InDesignは縦組みの際、これらを全角（和文属性）の文字だと想定して（古いCMapを想定