日本語フォントのグリフ置換（GSUB）機能についてはこれまでに何度も取り上げてきたが、欧文フォントのそれについてはあまりよく知らなかったので、ちょっと調べてまとめてみることにした。 下図は、InDesignの文字パネルメニュー。ブラケット付きで表示されている項目は、指定されたフォントではサポートされていないことを意味する。以下、番号を振ったものについて見ていく。 任意の合字（dlig）は、日本語フォントでは主に「㍑」のような組文字用だが、欧文フォントではその名のとおりオプショナルなリガチャを表現するために用いられる。 スラッシュを用いた分数（frac）は、今回調べた欧文フォントではいずれも「1/234」のような例に対応できる連鎖文脈置換（chaining contextual substitution）。日本語フォントでもPr6Nなどはこのタイプを採用している（詳しくは「「スラッシュを用い

フォント制作ソフトのGlyphsが話題ですねー。 うん。エントリ版のGlyphs MiniのほうをApp Storeで買ってみたぞ。 買ったんだー。どうでしたか？ オリジナルフォントを設計したいならフルバージョンのほうがいいんだろうけど、「Illustratorで作った外字をフォント化する」っていう用途なら、Miniでも十分いけるかんじ。やってみようか？ やりましょう！ じゃあまず、［File＞New］で新規ファイルを作って、と。 わあ、心ときめく画面ですね。ウインドウの左下の素敵にカラフルな部分は何なんですか？*1 知らん。 ええっ？ そんなことより、［File＞Save］でファイル名を付けて保存するぞ。ファイル名は「GAIJI」とでもしておこうか。これはフォント名とは別ね。 ……はあ。 次に、［Glyph＞New Glyph］で新しいグリフを登録しよう。これで「Other」のところに空

ところで、モリサワの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明朝側には問題がありそう。メリー・クリスマス。

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

半年くらい前にツイートした件なのだけれど、より詳しい情報も含めてまとめておく。発端は@tree3yamaさんの、この発言。 えっ？と思ってjp90タグのターゲットとなる160字（Adobe-Japan1フォントではjp90グリフとjp04グリフが異なる字）について調べてみたところ、下図のようにjp90グリフだったりjp04グリフだったりバラバラの結果だった*1。「mj」欄がIPAmj明朝002.01、「Koz」欄は比較用の小塚明朝Pr6N。ピンク地がjp90グリフ、白地はjp04グリフ。 IPAmj明朝の実装方針についての資料を探したところ、第3回文字情報基盤推進委員会配布資料（http://ossipedia.ipa.go.jp/doc/476/）の資料4「文字情報検討状況について」における「4. IPAmj明朝での符号化実装の優先順位について」に、次のような記述があった。 1) 常用漢

皆さんこんにちは、片づけコンサルタントのこんまり先生です。 いきなりの個人名詐称……。 今日は、Windows 8のIVS実装について説明するわよ。 「わよ」？ 最初に結論を言っちゃうと、Windows 8のMS明朝・MSゴシックがIVSでサポートしているのは、MS122から「筵」を引いて「濹」を足した122文字ね。 ん？ 以前のエントリでも言ったように、Windows Vistaで変更された文字のうち、jp90タグやJIS90互換フォントパッケージによって昔のグリフに戻せる122字を、MS122と呼ぶんだけどね。 MS122はいいんですけど、そこからまた引いたり足したりするんですか？ うん。 じぁあまず、マイナス分の「筵」は、何なんですか？ MS122のうち「喩」と「筵」については、XPグリフがJIS90の例示と一致しないんだよね。 ホントだー。 だから「喩」と「筵」のXPグリフ（JIS

今日はWindows 8のMS明朝における122字のIVS実装について説明しようと思ってたんだけど……。 気が変わったんですか？ 話が長くなりそうなんで、詳しいことは後日に回して、今回は説明のカギになる「MS122」という文字集合に焦点を絞って語ってみようかと。 「MS122」ですか？　トラック野郎が荷台に貼ってるお茶目なステッカーの「人妻110」と、ちょっとだけ似てますね。 あー、こないだそれ貼ってるトラック見た見た！　正確には「美人妻110番の車」な。って、「MS122」と、ひとかけらも似てないだろが！ まさかのノリツッコミ。 まず、基本を押さえておくとWindows Vistaでは…… 強引な軌道修正。 ……JIS X 0213:2004の例示にあわせる方向で、MS明朝の字形を変更したわけだ。 はいはい。それが122字だったんですね？ まあ、落ち着こうぜ。変更された字は、漢字だけでも

『Unicode IVS/IVD入門』（田丸健三郎、小林龍生）を読んでいたら、いくつか気になる点があったので、まとめてみることにした。とりあえず、第4章（37ページ分）だけ。時間と気力があれば、今後、他も追加していくかも*1。組版上の突っ込みは（ひどい例以外は）省いた*2。 p.103 ISO/IEC 8859は《中略》パート16まで定義されています（パート15は破棄）。 破棄されたのはパート12。 p.104 「ISO-10646」の文字集合 「ISO-10646」→「ISO/IEC 10646」。 たとえば、1面19区75点を符号位置とする文字をシフトJISで8ビット符号化した場合0x8A6Bとなる文字を例に見てみましょう。この文字は、葛飾区の「葛」という文字ですが 「葛」はシフトJISで「0x8A6B」ではなく「0x8A8B」。 p.106 「U+000000」→「U+0000」（U

「Unicode IVS Add-in for Microsoft Office」（http://ivsaddin.codeplex.com）をインストールしてみた。環境は、Vista + Office 2007*1。インストール後、用意されているサンプルファイルをWordで開いてみると、最初はアドインなしの環境と変らない表示だったが、カーソルがぶるぶる震えながら、徐々に異体字に置き換わっていった。 これらの異体字は、アドインが生成した外字フォントのPUA（私用領域）に割り当てられている。オリジナルのフォント（この例ではipamjm.ttf）をまるごと（すべてのグリフデータを含めて）コピーして外字フォント（IPAmjMincho_EUDC.ttf）を作り、符号位置とグリフの対応表（cmap）を一度白紙にした上で、PUAの符号位置とGID（グリフID）の対応を順次追加しているかんじ。 PUA

前回に続き、InDesignの「文字揃え」と「行送りの基準位置」と「グリッド揃え」の関係について。今回は、段落パネルメニューの「グリッド揃え」を導入する。が、フレームグリッドは使わず、プレーンテキストフレームのままで、カスタムベースライングリッドを使うこととする。理由は、（作業効率的にはフレームグリッドを使ったほうがスムーズかもしれないが）ベースライングリッドのほうがロジックがプリミティブだからだ。 下図はプレーンテキストフレームにおける「グリッド揃え」のイメージ。オレンジ色の線がベースライングリッド（以下単に「グリッド」と呼ぶ）。行中で最も大きい文字の基準点（「グリッド揃え」で指定した位置）が、グリッド上にくる。 下図は、前回取り上げた「文字のサイズがときどき大きくなる行送り一定の箱組み」の例（いちばん左が目指す組み）。「文字揃え：平均字面の下/左」を使いたい場合、「行送りの基準位置」に

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

（ホー先生）Macの画面で「●▲■」の「●」と「■」だけが小さく見えることがあるのはなぜじゃ*1。 「●」と「■」が欧文フォントで表示されているからだよ。たとえばMacのFinderでは、ファイル名は「Lucida Grande優先」で表示される。Lucida Grandeは「●（U+25CF）」や「■（U+25A0）」のグリフを持っているけれど、「▲（U+25B2）」のグリフを持っていない。だから「▲」はヒラギノで表示されて、「●」と「■」だけが小さく見えるんだ。同じ理由で起きる現象としては、三点リーダの位置が下にズレたりすることも、よくあるよね。 Finder以外でもよくあるんじゃが。 Appleのソフトは世界共通の仕様なので、デフォルトは欧文フォントだよ（下図）。 日本語フォントを指定すれば、この問題は避けられるのか。 うん。Finderでは基本的にフォントの変更はできないけどね。そ

DTPの勉強会でしゃべったことをブログに書いておくシリーズ第1弾（ただし、第2弾以降があるかどうか不明）。モリサワの改定常用漢字表対応学参フォントのしんにょうのデザインがおかしなことになっている件。 下図は、モリサワの学参ではない明朝体と教科書体（いちばん下の行は比較用。改定常用漢字表の例示フォントであるIPAex明朝）。明朝体には一点しんにょう（グレー地）と二点しんにょう（白地）があり、教科書体はすべて一点で二度揺らす形（黄色地）。 モリサワの学参フォントは、常用漢字の範囲内に限って、手書きに近いデザインを採用している。下図、学参リュウミンProの「道」のしんにょうは、教科書体のそれに近い形となっている。このデザインが気に入らないという人も多いかと思うが、これは学参フォント一般の特徴であって、今回指摘したい問題ではない。 下図は、モリサワの改定常用漢字表対応学参フォント。常改教科書の「遡

日本語EUC（EUC-JP）にはいろいろあって頭がこんがらがってきたので、サルにもわかるように（つまり、自分があとから見て理解できるように）まとめてみた*1。まず、EUC-JPにはどんな種類があるのだろうということで、わたしの環境で実装例を確認できるものをピックアップしてみた。下図のうちeucJP-openとIANAのEUC-JPについては身近な実装例を思いつかなかったが、これを外すわけにはいかないだろうと思って入れておいた。 各EUC-JPのレパートリをまとめたのが、下図。eucJP-openには上図に示したようなバリエーションがあるが、レパートリは共通。「JIS X 0208の国際基準版・漢字用8ビット符号 + JIS X 0201片仮名」については、これを一言で表現できる呼称を思いつかないので、以下の図では仮に「TextEdit」と表記する。 下図は、各EUC-JPのレパートリと符号

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

先日のエントリ（InDesignのグリフ置換の挙動がMac OS Xのバージョンによって変わる）で触れた問題について、Adobeのサポートから回答があったので、まとめ直しておく。 InDesign CS3/CS4のグリフパネルから漢字のexpt/jp04/jp78/jp83/jp90/nlck/tradグリフをダブルクリックで入力し、これをInDesignタグで書き出した場合、Mac OS X 10.4ではGlyphFormとなり、Mac OS X 10.5/10.6ではOTFeatureListとなる。この現象はAdobeでも確認された。 Adobeの意図した動作はGlyphFormのほう（Mac OS X 10.4のほう）であり、Mac OS X 10.5/10.6でOTFeatureListとなるのは想定外*1。Windows版では一貫してGlyphFormとなっている。Mac版の将

前回のエントリで見たように、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 CS4で「※」や「×」などの文字が、「和字」であるように振る舞ったり、「欧文用文字」であるように振る舞ったりする。Adobeに問い合わせ中の事例で、再現性が環境に依存する可能性があるのだけれど、とりあえず、わたしの環境における挙動をメモ。 InDesign CS4で「環境設定＞組版＞CIDベースの文字組みを使用」をオフ、「段落＞文字組み」は「行末約物半角」とし、テキストフレームに以下のようなテキストを入力する。 あ±1 あ×1 あ÷1 あ§1 あ※1 あÅ1 あ†1 あ‡1 あ¶1 これを一度保存して開き直したものが下図。「あ」の後ろに和欧間のアキが入っており、「※」などの記号類は欧文用文字として扱われている。 これだけでもCS3との非互換性が問題なのだが、さらに面倒なことに、テキストを編集することによって記号類の属性が変化することがある。下図は、1行目の「±」の前の「あ