SoftBankの絵文字の扱いに関するお願い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
iPhoneや携帯における絵文字の扱いに関して、SoftBankへの要望がいくつかあるので（それから、先日コメント欄でお願いされたので）、メモ。 その1・受信側サーバでUnicode絵文字→SoftBank絵文字の変換をサポートしてほしい 現在、iPhoneの（メッセージアプリで）@softbank.ne.jpから携帯の@softbank.ne.jp宛に絵文字を送ると、空白になってしまう（下図）。 また、（これは以前からの仕様だが）iPhoneのメールアプリで@icloud.comなどから携帯の@softbank.ne.jp宛に絵文字を送った場合も同様（下図）。 受信側サーバがUnicode絵文字の変換をサポートすれば、この問題は解決する（下図）。ドコモiPhoneの登場により、ドコモの受信側サーバもUnicode絵文字の変換をサポートするようになった。auの受信側サーバは、以前からこれを
先生怒らないからリュウミンは手を挙げなさい - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
IVSファンの皆さん、こんにちは。 いえ、ぜんぜんファンとかじゃないですから。 『Unicode IVS/IVD入門』（田丸健三郎、小林龍生）の目玉と言えるのが、表2-7の「Windows 8におけるJIS X 0208:1990字形と異体字セレクター」だよね。 そうなんですか？ Microsoftの人が執筆しているIVS本なんだから、焦点は当然Windows 8のIVS対応。皆さんそこが知りたいわけでしょ？ なるほど。 そこで、この表2-7に突っ込んでみよう、と。 やっぱり突っ込むんだ……。 表のタイトルは大切だから、しっかり頭に入れておくといいぞ。「Windows 8におけるJIS X 0208:1990字形と異体字セレクター」だ。 はいはい。Windows 8ではIVSをどのように駆使して「Vistaで変更される以前のMS明朝のグリフ」を表示するのか……ってことですね。 でさ、「字形
Mac OS Xのフォントアイコンについてのまとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Mac OS Xでは、フォントのアイコンがどれも似たようで意味がわかりにくいので、自分用にメモ。 まず、Mac OS 9時代のフォントは、下図左側のようなかんじ。もう忘れていたが、TrueTypeも、CIDも、Type 1もスーツケースだった。このフォントスーツケース（ファイルタイプFFIL：Font File）が、（フォントフォーマットの種類を問わず）Mac OS XではFFILアイコンになる。また、Type 1フォントのアウトラインデータ（ファイルタイプLWFN：LaserWriter Font）が、Mac OS XではLWFNアイコンになる。LWFNはFFILと組み合わせなければ機能しない。 Mac OS 9のTrueType（FFIL）は、各種のリソースをリソースフォークに格納していた。これをデータフォークに移したのが、Mac OS XのDFONT（Datafork TrueTyp
「●」が小さく見えることがあるのはどうして？ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
（ホー先生）Macの画面で「●▲■」の「●」と「■」だけが小さく見えることがあるのはなぜじゃ*1。 「●」と「■」が欧文フォントで表示されているからだよ。たとえばMacのFinderでは、ファイル名は「Lucida Grande優先」で表示される。Lucida Grandeは「●（U+25CF）」や「■（U+25A0）」のグリフを持っているけれど、「▲（U+25B2）」のグリフを持っていない。だから「▲」はヒラギノで表示されて、「●」と「■」だけが小さく見えるんだ。同じ理由で起きる現象としては、三点リーダの位置が下にズレたりすることも、よくあるよね。 Finder以外でもよくあるんじゃが。 Appleのソフトは世界共通の仕様なので、デフォルトは欧文フォントだよ（下図）。 日本語フォントを指定すれば、この問題は避けられるのか。 うん。Finderでは基本的にフォントの変更はできないけどね。そ
なぜ全角ダッシュは欧文約物形状になったのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
あさうすさん（実験る〜む）の「和文としてのダーシが変」を読んで、Adobe-Japan1フォントの全角ダッシュが和文約物形状ではなく欧文約物形状で表示される理由について考えてみた。このエントリでは、JIS X 0208の1区29点「ダッシュ（全角）」を「全角ダッシュ」と呼ぶこととする。 昔は、全角ダッシュの実装グリフは和文約物形状だった。今ではたいていの場合、欧文約物形状。どちらになるかは、「文字コードがUnicodeか否か」による。たとえば小塚明朝Pr6Nのような新しいフォントでも、Shift-JISアプリでは全角ダッシュは和文約物となる。また、（試していないけれど）CIDフォントでもUnicodeアプリでは全角ダッシュは欧文約物となるはず。 Shift-JISとUnicodeでグリフが変わるのは、全角ダッシュだけではない。たとえば、セント記号について見てみよう。JIS X 0208は、
miで行われているUnicode正規化について - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
さきほどのエントリの補足。文字列をmiにペーストした際に行われているUnicode正規化がNFCだという点について。 下図右下のウインドウは、miで1行目の「オリジナル：」以降（これを「文字列A」と呼ぶ）をコピーし、2行目の「ペースト後：」以降にペーストしたもの（これを「文字列B」と呼ぶ）。下図左下のウインドウは、文字列の符号位置を比較する機能を持ったUnicodeCheckerというツール。その「Input」欄に文字列Aを、「Cpmpare with」欄に文字列Bをコピー＆ペーストして符号位置を比較した。 一度miでペーストされた文字列（文字列B）では、たとえば「グレーブアクセント付きa」を表現する結合文字列（U+0061 U+0300）が、合成済み文字（U+00E0）に置き換わっていることがわかる。NFDやNFKDは分解方向への正規化なので、結合文字列が合成済み文字に置き換わることはな
Adobe Illustratorのグリフ置換のバグがCS3で直っていない - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
以前に「Adobe Illustrator CS2のグリフ置換の問題（総論）」で指摘したIllustratorのグリフ置換のバグが、CS3でも直っていないことを確認。深刻な不具合だと思うので、そのメカニズムについて改めてメモしておく。 このバグは、ワンセンテンスで言えば「ある異体字（aalt）グループ内に、タグXによってグリフaに置換されるグリフAが含まれている場合、タグXを適用することにより、そのグループ内のA以外のグリフもaに置換されてしまう」というものである。 たとえば「帰」を含む異体字グループは、小塚明朝Proでは下図左側の4つのグリフで構成される。このうちタグ'jp83'によるグリフ置換の対象となるのがCID=1596の「帰」、置換後のグリフがCID=13429の「帰」である。当然だが、「歸」や「皈」は'jp83'タグの影響を受けない。 ところがAdobe Illustrator
「小塚明朝 Pro-VI」の'nlck'タグの謎 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
OpenTypeフォントのフィーチャー・タグ'nlck'は、「一般の社会生活において表外漢字を使用する場合の字体選択のよりどころ」を示した国語審議会（National Language Committee Council）答申「表外漢字字体表（http://www.bunka.go.jp/kokugo/main.asp?fl=list&id=1000000518&clc=1000000500）」のグリフを呼び出すものである。追記：コメント欄でのご指摘により「Committee」を「Council」に訂正。 'nlck'用のグリフ集合は、表外漢字字体表のグリフ（印刷標準字体および簡易慣用字体）のうち「JIS X 0213:2000の例示グリフとは違うもの」を抽出したものであり、以下の172文字であると思われる（「ヒラギノ丸ゴ Pro」で表示）。 が、Adobe-Japan1-6フォントである
モリサワPr5フォントの'nlck' - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回のエントリ（「小塚明朝 Pro-VI」の'nlck'タグの謎）では「小塚明朝 Pro-VI」の'nlck'用グリフ集合が変だということを述べたが、コメント欄でモリサワのPr5フォントも同様だという情報をいただいたので、さっそく「リュウミン Pr5 R-KL」を購入し検証してみた。確かに「小塚明朝 Pro-VI」と同じである。 字形デザインのレベルでは、CID=20289（Adobeのテクニカル・ノートの例示グリフは筆押さえのない「斧」）を、CID=3538と同じ筆押さえのある「斧」とするなどの主張が見られるが、'nlck'用のテーブル自体は「小塚明朝 Pro-VI」と変わらない。 というわけで、現在、'nlck'用のテーブルには、「ヒラギノ式」と「小塚＝モリサワ式」の2種類が存在するようだ。前回のエントリで指摘したとおり、後者はグダグダである。
Unicodeにマルバツのバツはあるのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
以前のエントリ（ヒラギノでは全角でデザインされていない文字）で、わたしは以下のように書いた。 たとえば「○か×か」というテキストをヒラギノで表示した際、「×」だけが小さく見えて困惑したといった経験を、多くのMac OS Xユーザが持っていると思う。これは、ヒラギノがU+00D7 MULTIPLICATION SIGN（乗算記号）をプロポーショナルでデザインしているためである。 では、「マルバツのバツ」を表現したいとき、より適切な方法は用意されているのだろうか。Unicodeには、明示的な「マルバツのバツ」は含まれていない。U+2573 BOX DRAWINGS LIGHT DIAGONAL CROSSはバツと言えなくもないが、「BOX DRAWINGS」は罫線素片であってセマンティクス的にもバツ印とはやや遠いし、形もUnicodeの符号表例示字形を見る限りでは「○」と釣り合うようなものでは
Windows Vistaのjp90タグにおける「喩」の問題 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Microsoftのサイト（JIS X 0213:2004 対応と新日本語フォント「メイリオ」について）から入手できる資料には、Windows VistaのMSゴシックおよびMS明朝について、以下のような記述がある。 字形セットとしては、Windows XPで利用可能だった122文字のJIS90字形に、'jp90' OpenType feature tagによりアクセスができるようになっています。 この122文字のリストには、「喩」が含まれている*1。そして、「喩」については、「JIS90字形」欄のグリフ（「人」形）は、「JIS90字形」ではない。逆に、「JIS2004字形」欄のグリフ（「入」形）のほうが「JIS90字形」である。 JIS X 0208の規格票における「喩」の例示字体は、JIS78とJIS83では「人」形、JIS90以降は「入」形。つまり、JIS78もJIS83も略字風の字
表外漢字字体表のヒゲ政策がダメな理由 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
明朝体の筆押さえ（ヒゲ）には、「分」や「公」などの上部の「八」に付くものと「父」や「延」などの右払いに付くものがある。 以下、便宜的に前者を「ハチヒゲ」、後者を「チチヒゲ」と呼ぶ。図は写研の本蘭明朝、ヒゲありモード。 多くの書体あるいはシステムは、「常用漢字（と以前からの人名用漢字）なしなし、表外字ありあり」というルールを採用している。写研の石井明朝・本蘭明朝のヒゲなしモード、大日本の秀英明朝、凸版の凸版明朝など。ヒラギノ明朝や小塚明朝もこのグループである（下図はヒラギノ明朝W3）。 これに対して、写研のヒゲありモードは、「常用漢字ありあり、表外字ありあり」。 また、モリサワのリュウミンの場合、「常用漢字ハチヒゲありチチヒゲなし、表外字ありあり」である（下図はリュウミンR）。 ヒゲのつけ方に関しては、このようにいくつかの流儀が存在するが、それぞれに思想があるのだと思う。たとえばリュウミンの
ヒラギノでは全角でデザインされていない文字 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
たとえば「○か×か」というテキストをヒラギノで表示した際、「×」だけが小さく見えて困惑したといった経験を、多くのMac OS Xユーザが持っていると思う。これは、ヒラギノがU+00D7 MULTIPLICATION SIGN（乗算記号）をプロポーショナルでデザインしているためである。そんなわけで、JIS X 0208の範囲内のいわゆる「全角文字」のうち、ヒラギノでは全角でデザインされていない文字のリスト（ヒラギノ丸ゴ Pro W4、バージョン7.11で表示）を作成してみた。目で見て拾っただけなので、漏れなどがあるかもしれない。 このうちセント記号（U+00A2 CENT SIGN）、ポンド記号（U+00A3）、否定記号（U+00AC）がプロポーショナルなのは、Unicodeの範囲内には他に全角バージョン（U+FFE0 FULLWIDTH CENT SIGN、U+FFE1 FULLWIDTH
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Appleカラー絵文字のナマハゲ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ