Leopard以前の「文字パレット」は、Snow Leopard（Mac OS X 10.6）では「文字ビューア」になった。でもファイル名は「CharacterPalette.app」。Mac OS Xにおける「パレット」と「ビューア」の定義の違いって何なのだろう。 Leopardの文字パレットは一般的なアプリケーションのウインドウと同様、Spacesにおいて単一の操作スペースに表示されるため、操作スペースを切り替えると置き去りにされてしまい不便だった。文字ビューアはすべての操作スペースに（同時に）表示される。 文字ビューアでは「説明とコード」と記された検索フィールドが追加された（括弧内追記。いま自宅のLeopardマシンで確認したら、これ、Snow Leopardの新機能じゃないですね。「説明とコード」というテキストが表示される点は新しくて、そのせいで新機能かと早とちりしました。言い換え

文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです⁠）⁠、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で

InDesign CS4はUnicodeのIVS（異体字シーケンス）をサポートしている。IVSは、親字に続けてU+E0100などの特殊な文字（異体字セレクタ）を入力することで、たとえば下図のようにグリフを指定するメカニズムである。 同様のグリフ指定は、もちろんOpenTypeタグでも可能である（下図）。 では、1つの文字にIVSとOpenTypeタグで競合する指定を行ったらどうなるのだろう。U+990C「餌」を例として試してみた結果が、下図。横軸がIVS、縦軸がOpenTypeタグ。IVSの指定が顕在化しているものを青地、OpenTypeタグの指定が顕在化しているものを緑地で示した。白地は両者の指定が一致しているもの。 この例では、異体字セレクタがU+E0101またはU+E0102ならIVS優先、そうでなければOpenTypeタグ優先、というように見える。しかしInDesign CS4は、

http://d.hatena.ne.jp/mandel59/20090904/1252071738の答え 同じ名前のファイルが存在しているように見える。 これはそれぞれ 「ほげほげ.txt」(NFD、「げ」は U+3051 U+3099 というシーケンス*1) 「ほげ​ほげ.txt」(ZERO WIDTH SPACEが含まれている*2​) 「ほげほげ.txt」(NFC、「げ」は単一のコードポイント U+3052) となっている。 Mac OS X標準のファイルシステム HFS+ ではファイル名がNFDで正規化されるが*3、Linuxのファイルシステムでは正規化は行わない。 *1:結合文字シーケンスにフォントが対応していなければ「け゛」みたく表示されるかもしれない。ここでは、IPAフォントを結合文字シーケンスも表示出来るように改造したものを使っているので、「フォントを弄った」というのも

この本が出たのはゴールデン・ウィークの頃ですから、もう3ヵ月を過ぎますか。本来であれば共著者の一人として、本書を紹介し、広く勧めるべきところでした。 活字印刷の文化史 作者: 張秀民,大内田貞郎,豊島正之,鈴木広光,小宮山博史,宮坂弥代生,佐賀一郎,劉賢国,孫明遠,内田明,小形克宏,府川充男出版社/メーカー: 勉誠出版発売日: 2009/05/04メディア: 大型本 クリック: 42回この商品を含むブログ (13件) を見る 本書の全般的な紹介は、先日公開された、編者の小宮山博史さんの文章があります。 漢字・仮名活字の世界史的位置づけ―『活字印刷の文化史』 こうして読むと、あらためてこの本の凄味といったものが分かり、またそのような本に場違いな原稿を書いてしまったのではという自責の念にとらわれます。 本書収録の原稿は、昨年INTERNET Watchで連載した“情報化時代”に追いつけるか？　

InD-Boardの「字形について」というスレッドで話題になっていた「SINGで拡張された小塚Pro」の文字化けについて、InDesign CS4と小塚明朝Pro Rで検証してみた。 再現性にあいまいさはあるが、次のように言えそうだ。SINGで拡張された小塚Pro書体において、グリフXがSING拡張分ではなく（CIDが15443以下）、なおかつグリフXの親字PがSING拡張分であり（CIDが15444以上）、なおかつ親字Pの符号位置が基本多言語面の範囲外（Unicodeスカラ値が5桁）である場合、ドキュメントを保存して閉じた後に再び開くと、グリフXが親字Pに化けることがある。 わたしの環境では、字形パネルからダブルクリックで入力して（コピー＆ペーストや書体の変更などをせずに）すぐに保存し開き直した場合、前項の条件を満たすものは100%化けた*1。 下図は、化ける文字のリスト*2。グレー枠の

「日本語OpenTypeフォントの分裂の歴史」では、CMapの差異が生まれていく流れを描いた。では、それぞれのCMapは具体的にどう違うのか。という話は、このブログのどこかに書いてはあるのだが、散在していて参照しにくい。 で、PDFにまとめてみた。 以下追記。最新版はこちら（diff_cmap_20120906.pdf）。旧版は削除した。

あまり時間がないので短くご報告。 Microsoftの「Windows 7向けJIS90互換フォントパッケージの提供と今後について」記者説明会に行ってきました。これについてはプレスリリースも出ています。 Windows(R) 7 向け JIS90 互換フォントパッケージの提供 より詳しくはINTERNET Watchの記事などをご参照ください。 マイクロソフト、JIS90互換フォントの提供はWindows 7で最後 細部は記事にゆずるとして、ぼくが重要だと思ったことは以下の点です。 Windows Vistaによるフォント変更について、同社コールセンターに対し、クレームの電話は1件もかかってきていない。 Microsoftは（今のところ）この件について、ユーザーに大きな混乱は発生しなかったと考えている。 Windows Vistaでフォント・デザインが変更されたことについては、2006年に

CMapの系統図を描いてみた。 上図左上、源流となっているUniJIS-UCS2は、Adobe-Japan1-4（AJ14）をレパートリとするCMapである。 Appleは、2001年9月リリースのMac OS X 10.1でApple Publishing Glyph Set（APGS）を投入し、JIS X 0213:2000をサポートした。APGSはレパートリとしてはAJ14のスーパーセットだが、主にJIS X 0213との整合性を高めるために、既存のマッピングに変更が加えられている。 2002年9月、AdobeはAPGSを追認する形でAdobe-Japan1-5（AJ15）を策定したが、Appleによるマッピング変更の一部（主としてプロポーショナル・グリフの採用）には追随しなかった。このためAJ15以降のCMapには、Apple用のもの（UniJISX0213系）とそれ以外（UniJ

CJKV Information Processing: Chinese, Japanese, Korean, and Vietnamese Computing 作者: Ken Lunde出版社/メーカー: O'Reilly Media発売日: 2009/01/08メディア: ペーパーバック クリック: 6回この商品を含むブログ (11件) を見る 昨年末に第2版が出た CJKV Information Processing*1 ですが、その Appendix の一部がPDFで公開されているようです。特に制限もかけられていないので、テキストのコピーも可能。 http://examples.oreilly.com/9780596514471/ ただし、PDFの頭にこう書かれているとおり、 This appendix is not included in the printed version

文字コードって何だらう。文字コードってやつが扱ってる「文字」ってモノに色々と性格が異なる「キャラクター(文字)」が混ざって集まってるおかげで、ある「キャラクター」については正しい説明であるように見えることが、他の「キャラクター」には当てはまらない、といふことが往々にして存在する。 さて、改めて、「文字コード」って何だらう。 Letter、Number、Mark、Ideograph、Symbolなど、様々な「キャラクター」を一堂に会して大きな「キャラクター」の集合をつくり、各々の差異を記述し番号と名前をつける。場合によっては一定の規則の元に、ある特徴を共有するキャラクター群にチームとしての名をつけることもある。何のためにそんな「キャラクターの集合」をつくって番号を振るか? 現代人の日常生活に必要な情報交換を円滑に行ふために。 ――ざっくり言ふと、さうして集められ名づけられ番号づけられたキャラ

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をインストールすると、上図青地部分を画面表示することができた。 上図ピンク地部分の

漢字小委員会の模様について、たくさんの皆さんに興味を示していただいたようでありがとうございます。つづきは時間を見て書きます。まだ皆さんにお知らせしなければならないことは残っている。 今回はまた別のお話。国際化の世界でよく知られているエンジニア、風間一洋さんのブログで「携帯の絵文字のUnicodeへの収録」というエントリが公開されました。これによると、Googleが携帯電話の絵文字をUnicodeに提案しようとしているそうです*1。 Emoji for Unicode: Open Source Data for the Encoding Proposal 非常に興味深い動きです。このエントリでは「もうすぐ日本語訳（？）を公開するそうである」とされていましたが、すでに公開されています。仕事が早い。 絵文字のユニコード符号化: 符号化提案用のオープンソースデータ ご存知のように、携帯電話での絵文