欧文フォントの異体字にはどんなものがあるのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
日本語フォントのグリフ置換（GSUB）機能についてはこれまでに何度も取り上げてきたが、欧文フォントのそれについてはあまりよく知らなかったので、ちょっと調べてまとめてみることにした。 下図は、InDesignの文字パネルメニュー。ブラケット付きで表示されている項目は、指定されたフォントではサポートされていないことを意味する。以下、番号を振ったものについて見ていく。 任意の合字（dlig）は、日本語フォントでは主に「㍑」のような組文字用だが、欧文フォントではその名のとおりオプショナルなリガチャを表現するために用いられる。 スラッシュを用いた分数（frac）は、今回調べた欧文フォントではいずれも「1/234」のような例に対応できる連鎖文脈置換（chaining contextual substitution）。日本語フォントでもPr6Nなどはこのタイプを採用している（詳しくは「「スラッシュを用い
サルでもわかるグリッド揃え - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回に続き、InDesignの「文字揃え」と「行送りの基準位置」と「グリッド揃え」の関係について。今回は、段落パネルメニューの「グリッド揃え」を導入する。が、フレームグリッドは使わず、プレーンテキストフレームのままで、カスタムベースライングリッドを使うこととする。理由は、（作業効率的にはフレームグリッドを使ったほうがスムーズかもしれないが）ベースライングリッドのほうがロジックがプリミティブだからだ。 下図はプレーンテキストフレームにおける「グリッド揃え」のイメージ。オレンジ色の線がベースライングリッド（以下単に「グリッド」と呼ぶ）。行中で最も大きい文字の基準点（「グリッド揃え」で指定した位置）が、グリッド上にくる。 下図は、前回取り上げた「文字のサイズがときどき大きくなる行送り一定の箱組み」の例（いちばん左が目指す組み）。「文字揃え：平均字面の下/左」を使いたい場合、「行送りの基準位置」に
IVSとGSUBはどう違うのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
異体字シーケンス（IVS）の特徴について、OpenTypeフィーチャのグリフ置換（GSUB）と比較しながら考えてみた。重要だと思われる点をメモしたものであり、IVSの体系的な説明ではない。 IVSは文字コードのレベルの枠組みなので、異体字の情報をプレーンテキストで交換できる。この最大の特徴に加え、GSUBよりも新しい分、よりすっきりとした論理的な仕組みになっている*1。 IVSの概念は、下図のようなかんじ。符号位置に包摂される複数のグリフ（集合）のなかから、ある特定のグリフ（集合）をVSによって指定する、というイメージ*2。 上図はUnicodeの視点から描いたものだが、Adobe-Japan1フォントではデフォルトのグリフはcmapで指定されているので、実装としては下図のようなかんじ。IVSでは、原則として基底文字（親字）の包摂範囲を超えたグリフは指定できないので、VSを付けることによっ
サルでもわかる行送りの基準位置 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesignの「文字揃え」と「行送りの基準位置」と「グリッド揃え」の関係とかについては、たまに必要があって調べると*1、そのときはいくらかわかった気になるのだけれど、3日後くらいには、またすっかり忘れている。そんなわけで、今後の自分のために、「これだけ読めば一応わかる」という程度のことをメモしておこうと思う。 まず、文字パネルメニューの「文字揃え」。これは、1行の中に異なるサイズの文字が混在するときの、文字の位置の基準を指定するものだ。単独で見るぶんには、特に複雑ではない。下図は、仮想ボディを示すブロック要素（█）、ラテン文字の「T」、漢字の「十」を、サイズを変えて並べたもの。ブルーの線が文字揃えの基準。 文字の下のラインを揃えたい場合、主に仮名や漢字からなる文章を組むなら、「文字揃え」は「平均字面の下/左」としておくのがベストだろう。 次に、段落パネルメニューの「行送りの基準位置」。
「●」が小さく見えることがあるのはどうして？ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
（ホー先生）Macの画面で「●▲■」の「●」と「■」だけが小さく見えることがあるのはなぜじゃ*1。 「●」と「■」が欧文フォントで表示されているからだよ。たとえばMacのFinderでは、ファイル名は「Lucida Grande優先」で表示される。Lucida Grandeは「●（U+25CF）」や「■（U+25A0）」のグリフを持っているけれど、「▲（U+25B2）」のグリフを持っていない。だから「▲」はヒラギノで表示されて、「●」と「■」だけが小さく見えるんだ。同じ理由で起きる現象としては、三点リーダの位置が下にズレたりすることも、よくあるよね。 Finder以外でもよくあるんじゃが。 Appleのソフトは世界共通の仕様なので、デフォルトは欧文フォントだよ（下図）。 日本語フォントを指定すれば、この問題は避けられるのか。 うん。Finderでは基本的にフォントの変更はできないけどね。そ
OpenTypeフォント環境における改定常用漢字表対応を考える - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
2010年11月に改定常用漢字表が告示されたが、これはDTPの現場にどのような影響を与えるのか。OpenTypeフォントとの関係について考えてみる*1。以前は特に意識しなくても、常用漢字表の字体（通用字体）が表示・印刷されるのは当たり前だった。今は違う。 まず、「常用漢字表とJIS90のグリフが異なる例」に注意が必要である。以下の図では、赤枠が常用漢字表のグリフ。JIS90基準フォント（名前にNの付いていないフォント）をシフトJIS環境で使った場合、下図「常用漢字表とJIS90のグリフが異なる例」の文字は、基本的にグレー枠のグリフで出力される。また、常用漢字の通用字体と印刷標準字体が一致しない例にも注意。改定常用漢字表で新たに追加された文字は、原則としていわゆる康熙字典体を採用しているが、「曽痩麺」の3文字は例外。 名前にNの付いているフォント（JIS04基準フォント）では、下図青地のグリ
InDesign CS4で異体字のあとにテキストをペーストしたときの文字化け - Mac OS Xの文字コード問題に関するメモ
InDesign CS4では、「aaltフィーチャによってグリフを置換されている文字」の直後にプレーン・テキストをペーストした場合（あるいはテキストを「フォーマットなしでペースト」した場合）、ペーストした文字にaalt属性が伝染してしまう*1。 たとえば、小塚ゴシックProで字形パネルからCID+12123の小鍵（U+FE41の4番目の異体字）を入力し、その直後に「二」（U+4E8C）を「フォーマットなしでペースト」すると、「貮」（U+4E8Cの4番目の異体字）に化ける。 これはInDesign CS2に見られた問題で、CS3では直っていたが、CS4で再発している。この問題は、InDesign CS2、CS3でも見られる。（twitterでの@akatsuki_pocketさん、@monokanoさんのご教示により訂正。ご指摘ありがとうございました） *1:「aaltフィーチャによってグリ
ヒラギノProとProNの違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
ヒラギノProのデフォルトのグリフは、JIS X 0208:1990/1997およびJIS X 0213:2000の例示字形を参照している。ヒラギノProNのデフォルトのグリフは、JIS X 0213:2004の例示字形を経由して表外漢字字体表の例示字形を参照している。 どの字の形がどう違うのかは、さまざまな資料から知ることができるが、ヒラギノそのものによるリストは見たことがなかったので作ってみた。使用したフォントは「ヒラギノ角ゴ Pro W3」と「ヒラギノ角ゴ ProN W3」。 図のいちばん最初のU+2F5Bは、Unicodeの康煕部首ブロックに属する文字。これとは別にCJK統合漢字のU+7259（牙）もあるので、Unicodeの符号位置とCIDの対応は2対1となる。 ProN欄の文字がグレーになっている例は、（CIDでは区別されるけれど）ヒラギノの実装字形では区別されないもの。
異体字属性あるいは痛い持続性 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS2とCS4には、aalt属性を持つ文字の直後にプレーン・テキストをペーストした場合、その文字にaalt属性が伝染してしまうバグがあった（InDesign CS4で異体字のあとにテキストをペーストしたときの文字化け）。 このようにして伝染したaalt属性は、潜伏していることがいる。たとえば「圧」という文字に「aalt 1」という属性が付けばグリフは「壓」に置換されるのですぐに気付くだろうが、「aalt 5」という属性が付いた場合、（「圧」にはaalt 1の「壓」以外には異体字は存在しないので、親字である「圧」が表示されたままとなり）その異体字属性は顕在化しない。 ところがInDesign CS5には、「異体字を1つだけ持つ文字に“2”以上のaalt番号が付いていた場合、番号1（aalt 1）のグリフを表示してしまうというバグ（だと思う）があるようだ。つまりInDesig
InDesign CS5で線の長さを変えると位置がズレる - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS5では、変形パネルに数値を入力して（ドラッグではなく）オブジェクトのサイズを変更すると、基準点まで動いてしまうことがある*1。これでは使い物にならないので、問題の全体像を把握しようと試み、回避方法を探ってみたい*2。 下図は、InDesign CS4で長さ100pt・幅10ptの線を選択し、基準点を変化させながら、変形パネルで線の長さ（L）を200ptに変更した結果を示す（以下の図では、黒が変更前、グレーが変更後）。ズレは見られない。 InDesign CS5で同じことをしたものが、下図。InDesign CS5では、変形パネルメニューの「境界線の線幅を含む」のチェックの有無によって結果が変わってくるが（CS4なら、線オブジェクトに関してはどちらでもズレない）、下図はチェックのある場合。ヨコ線なら基準点が上（左上、中央上、右上のいずれか）、タテ線なら基準点が左（左上、
なぜ円記号はメールで化けるのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
多くのMacユーザはもうすっかり慣れてしまったと思われる円記号の文字化けついて、以前にも書いたことがあるのだけれど（Apple Mailで円記号がバックスラッシュに化けて見える件）、今回はもう少し詳しく検討してみよう。 ISO-2022-JPには、ISO/IEC 646 IRV（国際基準版）に切り替えるエスケープ・シーケンス（1B 28 42）とJIS X 0201ラテン文字集合に切り替えるエスケープ・シーケンス（1B 28 4A）が用意されている。ISO/IEC 646 IRV（ASCII）の5Cはバックスラッシュ、JIS X 0201ラテン文字集合の5Cは円記号である*1。 Shift-JIS（CP932やMacJapanese）の時代には、バックスラッシュと円記号の違いを制御するのは困難だったため、「1B 28 42」と「1B 28 4A」の使い分けは一般化しなかった。しかし、現在使
InDesignにおける引用符の謎の挙動についての文字コード的なまとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
引用符が全角かプロポーショナルかは、フォントによって異なる。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を想定
フレームグリッドの設定がテキストフレームでよみがえる - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
あまり一般的でない条件下でしか顕在化しないバグ（だと思う）なのだけれど、再現手順をメモしておく。作業環境はInDesign CS4（6.0.4）。 フレームグリッドを作成する。現象を把握しやすくするために、適当な文字を入力しておく（下図）。 これを「オブジェクト＞フレームの種類」でテキストフレームに変更する（A）。現象を把握しやすくするために、テキストのフォントとサイズを変更しておく（下図）。 他のテキストフレームを作成し（B）、段落スタイルパネルメニューで「スタイルとのリンクを切断」して段落スタイルを「なし」にし、適当な文字を入力する。この文字のフォントやサイズはいじらない（下図）。 テキストフレームBのテキストをコピーし、テキストフレームAにペーストする。と、フォントやサイズが忘れたはずの（フレームグリッドのときの）設定になってしまう（下図）。 他人の作ったデータを加工する仕事の多いデ
InDesign CS3にCJK互換漢字をペーストしたときの文字化け - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CSには、「エディタなどからクリップボード経由で標準テキストをペーストすると、互換漢字が統合漢字に化けてしまう」というバグ（またはタコな仕様）があった。これは、InDesign CS2で修正された。 ところがInDesign CS3では、以前の仕様にもどってしまっている。下図は、左上のウインドウ（Jedit Xの標準テキスト・モード）のCJK互換漢字をコピーし、右下のウインドウ（InDesign CS3）にペーストしたもの。 これらの互換漢字と統合漢字はUnicode的には正規等価（canonical equivalent）であるから正規化（統合漢字に統一）されても仕方がないという理屈も世の中にはないではないのだが、日本語ユーザにとって互換漢字は数多くの人名用漢字を含むものであり、それを無言で「正規化」するような振る舞いが（特にDTP用のアプリケーションでは）危険であるこ
なぜUnicodeには分数の「0/3」が入っているのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Adobe-Japan1の分数は（特にUnicodeとの関係において）けっこうぐしゃぐしゃなので、ちょっと整理してみよう。下図は、横棒を使う分数のリスト*1。Proフォントでは「分数（afrc）」フィーチャで用いられる。分母が2から12までの約分できない真分数と「0/3」と「1/100」。 上図と同じ字種について、数字を斜めに配置するグリフも用意されている（下図）。これらはProフォントでは「スラッシュを用いる分数（frac）」フィーチャで用いられる*2。 上図のグリフはすべて全角だが、斜めに配置する分数の一部には、プロポーショナル・グリフも用意されている（下図）。 下図は、Unicodeに含まれる分数を、Mac OS Xの文字ビューアからInDesignに入力したもの。Adobe-Japan1ではプロポーショナル（黄色地）優先のマッピングであるため、「2/5」などの全角グリフ（グレー地）
InDesignに付いてくる小塚フォントのバージョンのまとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回のエントリでは「仕様を変えないモリサワ」について取り上げた。小塚フォントは逆に、頻繁に仕様が変わり、非常にややこしい。この話題についてはAdobeのTechNote「小塚フォントのアップデートにおけるデータ受け渡しの注意点」が基本文献だが、2004年のドキュメントなのでCS以前の情報しか載っていない。そこで、InDesignに付属する小塚フォントについて、フォントのバージョン、cmapのバージョン、'nlck'および'jp04'のサポート（テーブルのバージョン）、標準でインストールされる場所を、表にまとめてみた。以下、すべてMac OS Xの話。 InDesign 1.0/2.0に付属する小塚フォントは、cmapがUniJIS-UCS2系統（図、黄色地）であり、CS以降のUniJIS-UTF系統とは大きな違いがある（http://kb2.adobe.com/jp/cps/224/224
モリサワProフォントと互換性のジレンマ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
たとえばリュウミンPro Rでチルダ付きE（U+1EBC LATIN CAPITAL LETTER E WITH TILDE）を入力し、フォントをリュウミンPro Lに変更すると、ゲタに化ける*1。ベンダもレパートリも共通の、現在提供されているフォント間で、このような化け方をする例は珍しい。 原因は、cmapのバージョンの違い。モリサワには「フォント名が変わる場合以外はcmapを変更しない」という原則があるようだ。この方針は、同一の書類を複数の環境で開く際の互換性において最強である。その一方で、リリース済みのフォントのcmapを更新することができないため、かなり古いcmapもそのまま残ることとなり、リリース時期が異なるフォント間の互換性は犠牲にならざるをえない。 モリサワOpenTypeのファーストリリース（2002年3月）基本7書体に含まれるリュウミンPro Lのcmapは、UniJIS
文字コードはなぜ複雑になるのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
文字コードについて説明しようとする場合、「例外を無視して単純化すると、厳密にはウソになってしまう」という罠に陥りやすい。矢野啓介『プログラマのための文字コード技術入門』は、平易な文章でありながら、そのような落とし穴を慎重に回避することに成功していると思う。 プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ) 作者: 矢野啓介出版社/メーカー: 技術評論社発売日: 2010/02/18メディア: 単行本（ソフトカバー）購入: 34人 クリック: 578回この商品を含むブログ (129件) を見る カバー・本文デザインはn-yujiさん（遠近法ノート）*1なので、組版に関しても安心。 この本には、「文字コードはなぜ複雑になるのか」という節が用意されており、著者は「文字コードを複雑化させる二つの理由」として、「過去の経緯の
暴走するmds - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Spotlightの検索がダメで、先日ハードディスクを初期化し、システムを再インストールした。移行アシスタントで以前の環境を引き継いでしまっては元の木阿弥なので、各種の設定やアプリケーションのインストールは新たに行い、ドキュメント類のみ、バックアップ先の外付けハードディスクから内蔵ハードディスクに手動でコピーした。 が、やはりSpotlightで内蔵ハードディスクの検索ができない。具体的には、Spotlight用の索引作成プロセス（mds）がCPUをほぼ100%占有したまま、いつまで待っても終了しない。この状態に陥ると、Time Machineによるバックアップもできなくなってしまう。 わざわざ初期化までした以上、バックアップ先から持ってきたファイルに問題がある可能性が高い。そこで、内蔵ハードディスク内のファイルを「システム環境設定＞Spotlight＞プライバシー」に入れたり出したりして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Safariがバックスラッシュを円記号に置き換える理由がわからない - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
