モリサワ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
U+2015 HORIZONTAL BARとは何か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回のエントリで見たように、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
モリサワStd・Pro・Pr5・Pr6の違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
一般にOpenTypeフォントにおけるStd、Pro、Pr5、Pr6の違いは「文字数」だが、それ以外にもマッピングの違いが存在する可能性がある。ちょっと必要があってモリサワ・フォントについて調べてみたので、メモ。ただし、網羅的に検証したわけではないので、あくまで参考程度に。また、以下煩雑になるのでいちいち断らないが、対象をモリサワ・フォントに限定した話という前提で。 StdとProのcmapテーブルのバージョンは、たぶんいずれもUniJIS-UCS2-H 12.001相当。なので、両者のあいだには互換性の問題はなさそう。 Pr5のcmapテーブルのバージョンは、たぶんUniJIS-UTF32-H 1.003相当*1。これとStd/Proのcmapとの間には、かなりの異同がある*2。 ProとPr5のマッピングの違いには、Pro（AJ14）には含まれないCID+15444以降への単純なマッピ
改訂常用漢字表試案の「龜」 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
「改定常用漢字表」に対する意見募集は、2009年の3月から4月に行われたのが1回目（http://www.bunka.go.jp/oshirase_koubo_saiyou/2009/shin_kanji_ikenboshu.html）、現在行われているのが2回目（http://search.e-gov.go.jp/servlet/Public?CLASSNAME=Pcm1050&BID=185000443）だが、1回目と2回目では「亀」の「いわゆる康熙字典体」として丸括弧内に掲示された「龜」の字体が違う（下図）。 今回（2回目）の「龜」は、JIS X 0208またはJIS X 0213の例示字体と異なっており、Adobe-Japan1-6にも入っていない。関連するエントリは「カメの書き順とか画数とかをめぐって」。
「改定常用漢字表」に関する試案の「韓」と「稽」 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
下図は、「改定常用漢字表」に関する試案の「表の見方」の12の（3）。「＊」の付いた字というのは、「彙茨淫牙葛韓嗅僅惧稽恣煎詮箋嘲捗溺賭箸蔑喩」の21字。この部分に関して疑問が2点ほどあるのだが、わたしがわかっていないだけという可能性も大いにあるので、文化庁文化部国語課にコメントする前に、ここにメモして皆さまの突っ込みを待とうと思う。 疑問の1つ目は「韓」について。下図のような違いを「字体上の差異」とするべきだろうか。 下図は、「韓」と似た部分字体を持つ「芽」の例。これらは「字体上の差異」ではなく「デザイン差」とされている。 疑問の2つ目は「稽」について。「昭和56年の制定当時から常用漢字表に入っていた字体」とは「同じ構成要素を持ちながら通用字体の扱いに字体上の差異がある」というのだけれど、その「昭和56年の制定当時から常用漢字表に入っていた」字って何だろう？
モリサワMB101-Bの「イ」のメトリクス情報が気持ち悪い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
下図はモリサワのOpenTypeフォント「ゴシックMB101-B」でプロポーショナルメトリクス組みをした例（文字組み：なし）。「イ」の左が詰まって、右が空いて見える。一般論としては、前後の文字の組み合わせによって見た目のアキにバラツキが出るのは当然なのだが、経験上、どうしてもMB101-Bの「イ」の前後が気になる。 そこで、メトリクス情報（OpenTypeの'palt'フィーチャ）を確認してみた。下図、左右のグレー地がプロポーショナルメトリクスで詰められる部分。やはり左のアキがほとんどなく、右のアキが妙に大きい。 もちろん、どんな文字でも左右のアキが等しければいいというわけではなく、たとえば「レ」や「ト」では左のアキを大きくするのがセオリーだろうし、「イ」でも（1画目の先が細くなっている）明朝体なら右のアキが相対的に大きくなるのはわかるのだが、文字を構成する線の太さがほぼ均一のゴシック体で
日本語OpenTypeフォントの分裂の歴史 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
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
Macの外字の歴史を整理してみる - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
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刑事〔デカ〕リターンズ
国語審議会報告「同音の漢字による書きかえ」（1956年）は、当用漢字以外の漢字を含む語の書き換えを定めている（http://www.bunka.go.jp/kokugo/pdf/doon.pdf）。このうち新常用漢字の影響を受けそうなのが、「臆説→憶説」「臆測→憶測」「潰滅→壊滅」「決潰→決壊」「肝腎→肝心」あたり。試案がこのまま通ると、書き換えの対象であった「臆」「潰」「腎」が常用漢字に追加されることとなる。 過去の同様の事例としては、「同音の漢字による書きかえ」のうち、「研磨→研摩」「磨滅→摩滅」「妄動→盲動」の「磨」「妄」が1981年に常用漢字に入っており、現在、朝日新聞では「研磨」「摩滅」「妄動」が使われている（括弧内3月30日追記。新聞が現在「磨滅」を使っているという記述を修正）。 「憶測」「壊滅」「肝心」などの新表記はかなり定着しており、ウェブで検索してみると、現時点での新表記
表外漢字字体表の呪い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
1998年9月に開催された国語施策懇談会で、朝日新聞社総合研究センター・メディア研究担当部長（当時）の森治郎氏は、「いわゆる康煕字典体を原則とする表外漢字字体表は、今後の常用漢字の見直しを困難にしてしまうのではないか」という意見を述べた。 この発言を受けて、第21期国語審議会第2委員会副主査の小林一仁氏は、「常用漢字の見直しは行わないというのが、表外漢字字体表の前提である。そういう縛りのなかで表外漢字について考えているのだから、前提を覆すような意見は無意味だ」という趣旨のことを述べた。比較的穏やかに進行した懇談会のなかでは珍しく、話者の感情が表に出た場面だったので印象に残っている。 それから10年。常用漢字の見直しが行われ、それが表外漢字字体表の影響でどういうことになっているかは、ご存知のとおり。だからどうだとか、誰が悪いとか言うつもりはないが、国語施策懇談会でのやりとりを記憶しているうち
「新常用漢字表（仮称）」に関する試案を入手 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
ウェブの「意見募集中案件詳細」ページ（http://search.e-gov.go.jp/servlet/Public?CLASSNAME=Pcm1010&BID=185000395）からダウンロードできるPDF書類では、すべての文字が低解像度で画像化されていて細部がよくわからないので、文化庁に行って製本された試案をもらってきた。 で、前回のコメント欄の続き。まず、試案の康煕別掲字「塡」とJIS X 0213の規格票例示字体（平成明朝体）の比較。 次に、試案の康煕別掲字のうち、JIS X 0208のレパートリに含まれない（新字体と互いに包摂関係にある）ものを頭から順に3つ拾って、JIS X 0213の規格票例示字体（平成明朝体）と比較してみた。サンプルが少ないけれど、いずれも明らかに違う。
新常用漢字表試案と常用漢字表の字体の違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
新常用漢字表（仮称）試案のパブリックコメントが始まった（http://search.e-gov.go.jp/servlet/Public?CLASSNAME=Pcm1010&BID=185000395）。試案では、いくつかの漢字の字体が、現行の常用漢字表と異なっている。 下図は、常用漢字表の基準で、デザイン差ではなく字体差であると思われる例を拾ったもの*1。この4文字はいずれも「明治以来行われてきた活字の字体とのつながりを示すために」括弧に入れて添えられた（いわゆる）康煕字典体。左右に小さく示したのは、対応するAdobe-Japan1のグリフ（小塚明朝）。 小塚明朝のCID+13356は、「目」の縦画の接触だけでなく、「匕」のデザインも常用漢字表康煕別掲字の特徴を忠実に再現している。試案で例示に用いられているフォントは（この4文字に関しては）おそらく平成明朝体であり、その結果Adobe-J
JIS04基準フォントの'jp83'サポート - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
JIS04基準フォントのGSUB（グリフ置換）テーブルは、JIS90基準フォントのそれに「建増し」したような構成となっている。*1 たとえばJIS90基準フォントでは、「訝」の標準グリフ（デフォルトのグリフ）はCID+6662であり、'jp83'置換は「CID+6662→CID+13601」である。JIS04基準フォントでは「訝」の標準グリフはCID+20268なので、'jp83'置換は「CID+20268→CID+13601」だが、これに加えて「CID+6662→CID+13601」も残っている。以下の図では、'jp83'置換を青矢印で示した。 このように、'jp04'グリフ、'jp90'グリフ、'jp83'グリフがそれぞれ異なるケースでは、JIS04基準フォントの'jp83'置換は2対1となる。同様の例は、下図のとおり。*2 また、'jp90'グリフと'jp83'グリフが異なり、'jp
'jp78'タグの「83入替え」サポートをめぐって - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
JIS83では、1981年の人名用漢字追加で略字の「尭」「槙」「遥」「瑶」が採用されたことを受けて、下図のような文字の追加と移動が行われた。 しかしOpenTypeフォントの'jp78'タグは、下図のようなグリフ置換をサポートしていない。理由は不明。 この謎の仕様は、OpenTypeフォントが登場する以前の、CIDフォントにおけるグリフ置換用の文字セット「JIS 78」にまで遡ることができる。*1 メイリオの'jp78'は、この4組だけでなく、22組の入れ替えも基本的にサポートしていない（メイリオの'jp78'サポートは間違っている）。それが「JISの包摂規準を逸脱したグリフ置換は行わない」という方針によるものだと考えれば筋が通るのだが、だとすると「邇」などがおかしい。下図青矢印は、22組の入れ替えに関するメイリオの'jp78'置換。グレー矢印は「JISの包摂規準を逸脱したグリフ置換は行わ
PC 98文字セット（Ext）固有の文字 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回の註で触れた「PC 98文字セット（Ext）固有の文字」について。CIDフォントはPC 98をサポートするために、［Ext］という文字セット（CMapテーブル）を持っていた。 システム外字を別にすれば、［Ext］は基本的にJIS78の第1刷を参照しており、「冑」に限って第4刷以降の例示字体を採用している。［Ext］固有の（Adobeが定義している他の文字セットには含まれない）グリフは、下図の8文字。このうちCIDを赤字で示した「嗤」「幤」「藜」「雎」は、JIS78の正誤表で誤とされたもの。 CIDフォントのCMapテーブルのなかでJIS78を参照するものとしては、［Ext］の他に［78］がある。［78］はJIS78の第10刷（最終刷）に基づいている。［Ext］と［78］では、前述の8文字を含めて下図の12文字が異なる。 OpenTypeのAdobe-Japan1フォント（JIS90基準
メイリオの'jp78'サポートは間違っている - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
メイリオはJIS04基準フォント（JIS X 0213:2004の例示字体を参照して設計されたフォント）だが、'jp78'タグのサポートにおいて「JIS90基準フォント用のテーブル」をベースとしているものと思われ、その結果混乱が生じている。*1 下図は、「JIS90基準フォントには不要だがJIS04基準フォントには必要な'jp78'置換」のリスト。これらすべてについて、メイリオでは'jp78'サポートが抜け落ちている（グリフは存在しても、置換テーブルに載っていない）。*2 また、「JIS X 0208:1983が第1水準・第2水準間で文字を入れ替えた22組」について、メイリオの'jp78'サポートには問題がある。 下図は、Pr6Nフォント（JIS04基準フォント）における「22組44文字」の'jp78'サポート。第1水準（L1）欄と第2水準（L2）欄がデフォルトのグリフを、青矢印が'jp7
メイリオ独自の漢字グリフ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Adobe-Japan1とメイリオの漢字を比べてみると、「メイリオ独自のグリフ」と言えそうなものが、いくつか存在する。「モリサワのメイリオ準拠フォントが区別している差異」を一応の基準として、メイリオ独自の漢字グリフを列挙したのが、下図。*1 図の左端がメイリオ、その隣の赤字はメイリオ準拠のリュウミン。図の右端が小塚明朝Pr6N、その隣の青字はリュウミンPr6N。中央は、赤リュウミン（メイリオ準拠）と青リュウミン（Adobe-Japan1準拠）を重ねたもの。 U+9A4Aについては、赤リュウミンと青リュウミンに差異がないので、重ねた画像は省いた。つまり、U+9A4Aは「モリサワのメイリオ準拠フォントが区別している」という条件を満たしていないのだが、興味深い例なのでリストに加えておいた。*2 *1:目で見てリストアップしたものなので、漏れなどがあるかもしれない。 *2:U+9A4AについてはC
InDesignの「CIDベースの文字組みを使用」と括弧類（まとめ） - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
今回のエントリは、「CIDベースの文字組みを使用」に関する話題のなかでの括弧類の総集編であり、各論へのインデックスでもある。*1 「CIDベースの文字組みを使用」のオン／オフによる文字クラスの変化を記述しようとするとき、グリフ置換を考慮すると、CIDと符号位置の関係が1対1にならないため、話が非常に複雑になる。しかし、文字の幅などを変更するためにグリフ置換を利用するケースは、かなり珍しいのではないかと思われる。そこで今回は、「グリフパネルをダブルクリックしたときに入力される（その後グリフを置換されていない）文字」のみを対象とし、CIDと符号位置の関係を1対1に固定して扱うこととした。また、概略が見通しやすくなるように、縦組み用のグリフを対象から除き、フォントはリュウミンPr6（Adobe-Japan1-5以降のcmap）に固定することで話をシンプルにした。 InDesignにおける文字クラ
山括弧と仏語引用符と不等号の混乱 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
日本語組版で用いる山括弧、フランス語の引用符、そして不等号の形は、よく似ている。フランス語の引用符を含めて「山括弧」と呼ぶこともあるが、このエントリでは、日本語組版で用いる（シングルとダブルの）山括弧のみを「山括弧」と呼ぶこととする。また、フランス語の引用符の呼称としては「ギュメ」が一般的だろうが、以下、シングルとダブルをまとめて「仏語引用符」と呼ぶ。Unicodeに含まれる（形の似た）不等号、仏語引用符、山括弧は、下図のとおり。図に用いたフォントはリュウミンPr6。 下図はAdobe-Japan1の視点から、不等号、仏語引用符、山括弧のグリフを、プロポーショナル、半角、全角に分類したもの。煩雑にならないよう、起こしの括弧（に似ている）側のグリフだけを示した。仏語引用符と山括弧は別の系統としたが、まとめて考えることも不可能ではないという意味で、補助線で結んだ。 これらのグリフとUnicod
メイリオは補助漢字をサポートしていない - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
周知のことなのかもしれないが、わたしは今日まで知らなかった。MS明朝およびMSゴシックが補助漢字（JIS X 0212）をサポートしているのに対して、メイリオのグリフセットは、漢字に限定すればAdobe-Japan1-5と同じであり、補助漢字のレパートリをカバーするものではない。*1 Microsoftは1998年のWindows 98で補助漢字をサポートし、Appleは2001年のMac OS X 10.1でJIS X 0213をサポートした。「補助漢字重視のMicrosoft、0213重視のApple」という構図があったと言ってよいと思う。 Windows VistaのJIS X 0213:2004対応にしても、0213重視というよりは、表外漢字字体表（印刷標準字体）対応という意味合いが強かったと思う。しかし、メイリオが補助漢字をサポートしていないという事実を踏まえると、Microso
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
