異体字セレクタ（Variation Selector）は、人から渡されたプレーン・テキストの原稿に含まれている可能性がある。 異体字セレクタは、見えない。 異体字セレクタの効果は、フォントに依存する。 親字と異体字セレクタの並び（IVS）は、テキストエディットやJedit Xでは1文字として扱われるが、InDesignでは2文字として扱われるため、親字と異体字セレクタの間に文字を挿入できてしまう。 InDesignでは異体字セレクタは「幅のない文字」として扱われるため、カーソルが異体字セレクタの前（IVSの中）にあるのか後（IVSの外）にあるのかは、見ただけではわからない。 InDesignでテキスト中に漢字を挿入したとき、潜在していた異体字セレクタと結びついてIVSを構成し、字体が変わる可能性がある。 異体字セレクタとOpenTypeタグによるグリフ指定が競合あるいは重複した場合、挙動を

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フォントを結合文字シーケンスも表示出来るように改造したものを使っているので、「フォントを弄った」というのも

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

tonan's blog: リュウミンやヒラギノ明朝の違いは「書体」の違いではない 個人的な感覚では、リュウミンやらヒラギノ明朝やら、（狭義の）「書体」（＝タイプフェイス）を「書風」と呼ぶのはなんとなく違和感がある。「書風」という言葉からはどうも抽象的で、ある程度幅のあるイメージを受けるので、それこそ solid で「紋切り型」な活字に使うとしっくりこないというか、なんというか。印刷文字が手書き文字と不可分だということは分かっているけども、ここでは無理にまとめなくてもいいような気がする。 ちなみに、このあたりの用語を日中台で比較してみると、だいたいこんな感じになる*1。 日本中国台湾tonan案例 書体（広義）字体字體書体明朝体、ゴシック体、… 書体（狭義）、タイプフェイス字型書風リュウミン、ヒラギノ明朝、… 字体字形字形 字形 とはいっても、日本では書体・字体・字形の語がよくごっちゃで使

トナンさんが「リュウミンやヒラギノ明朝の違いは「書体」の違いではない」と書かれた記事に対する感想としてしろもじさんが書かれた「印刷文字における書体・字体・字形」といふ記事を見てゐて。 以前「公有フォントの利用と制作のための参考情報」を調べてみた時に、ああ、その「字型」っていふ「Typeface」の訳語、「じかた」って訓むことにすれば日本語でも通用するんぢゃね? 感じたことば思ひだした。 このTypefaceといふヤツ、事後的に「広義の書体」と呼ばれ得る「○○○科」を一気に切り開く場合があり、しかも類似Typefaceが現れない段階では一概に広義(「○○○科」)狭義(「○○○属」)と言へないところが厄介だ――例へば、フォロワーの出現によって現在では「ミックスタイプ」といふ「書体」分類(「○○○科」)を生んだリョービ「ナウ」シリーズのデビューを想起――。 まぁ、斬新なTypefaceが登場した

83pvと90pvという用語についてのややこしい話は別の機会に譲ることとして、今回はとりあえず「どちらもMacのShift-JISのバリエーション」と大ざっぱに定義しておく。83pvと90pvでは、下図のように外字の割り当てが異なる。16進数はShift-JISの符号位置。 83pv外字は、PC98外字のサブセットである。0x86A2から0x879C（水色地）は漢字Talk 7.5以降に付属する細明朝体と中ゴシック体のスクリーン・フォントに含まれているもの。このうち0x8740から0x879CはCP932とほぼ共通（CP932では0x877Eに「平成」が追加されている）。0x8540から0x8690（ピンク地）の半角文字は、PostScriptプリンタで出力することが可能であるが細明朝体と中ゴシック体のスクリーン・フォントに含まれないもの。 アクセス・ログで「83pv 90pv 違い」とい

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

写研の正字文字盤を参考資料として掲げておく。 原典は手動機にオマケとして付いてくる「文字配列表」という、文字盤をそのままなんらかの方法で印刷したシート（最下部に画像）*1。 まず下の3点、石井細明朝体_LMの手動機用の正字文字盤で右下に1967年の刻印が見える（左上のSは正字の略）。 （当用漢字の旧字体に加えて1951年制定の人名用漢字の旧字「藤/彦/巌など」が収容されているが、76年に追加された「渚/那など」の旧字はない。20090224追記） メインプレート部の右下には1981.1改訂とあるが、直後の1981.10には下のLHMにみられるように、常用漢字や人名用漢字に則した大きな改訂が加えられた。（20090213、0217追記） 〈画像クリックで別窓に拡大表示〉 次の3点は本蘭細明朝体_LHMの手動機用の正字文字盤。刻印は1975年となっているが、こちらはシートのタイトル部に「常用・

携帯用プラットフォーム Android の開発キット（無償）というものがあって、その中に Droid という書体のファミリーが入っているらしい。 というわけで、（例によってフォントを見るためだけに）下のページから早速ダウンロードしてみる。 Download the Android SDK - Android zip を開けて、tools/lib/fonts/default/ の中にフォントファイルを発見。中身は以下のとおり。 Droid Serif Regular, Italic, Bold, Bold Italic Droid Sans Regular, Bold Droid Sans Mono Regular Droid Sans Fallback Regular この Droid ファミリーは、Ascender Corporation の Steve Matteson が制作したもの