タグ

ブックマーク / moji-memo.hatenablog.jp (100)

  • グリフ(glyph)という言葉の定義をめぐって - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    『基語活字見集成 OpenType版』に含まれる「デジタル活字の基礎知識」では、小形さんが用語の定義を担当されているが、「グリフ」の定義がわたしの用語法と違っているので、そのあたりの事情について書いておこうと思う。 JIS X 0208:1997は、「字形」を「字体を、手書き、印字、画面表示などによって実際に図形として実現したもの」、「字体」を「図形文字の図形表現としての形状についての抽象的概念」と定義している。 「グリフ」という用語は、「字形」的な意味で使われる場合と「字体」的な意味で使われる場合がある。以下、仮に前者を「字形派」、後者を「字体派」と呼ぶ。 『集成』518ページで、小形さんは以下のように記している。つまり、「字形派」の定義を採用している。 フォントにある文字の形そのものを「グリフ」と呼ぶ。 「字形派」の代表と言えるのはUnicodeだろう。Unicode Sta

    グリフ(glyph)という言葉の定義をめぐって - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • リュウミンのCID版とOTF版では漢字の形はどれくらい違うのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    CIDフォント版のリュウミンの字形は、JIS83の例示字体を参照して設計されたものである。一方、OpenTypeフォント版のリュウミンでは、標準の字形はAdobe-Japan1経由でJIS90の例示字体を参照したものとなっている。そしてOpenType版では、'jp83'タグによるグリフ置換が可能だ。 モリサワのサイトの「よくある質問」のページでは、「NewCIDをOpenTypeに置き換えたらどうなる?」という質問への回答の一部として、「JIS83年版からJIS90年版の変更」6例を挙げ、「上記は代表例で、6文字以外も数多くあります」という注釈を付けている(http://news.morisawa.co.jp/support/ts_otf3.html#22)。 第1の素朴な問い。「6文字以外も数多くあります」の「数多く」って、何文字なのだろう。第2の素朴な問い。OpenType版の'jp

    リュウミンのCID版とOTF版では漢字の形はどれくらい違うのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • JIS2004とJIS90との文字の形の対照表 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Adobeのサイトで「Windows Vista上のJIS2004基準のフォントについて」という文書が公開されており、そこから「JIS2004とJIS90との文字の形の対照表」というPDFファイルを入手することができる。 この資料に含まれる目新しい情報は、下図ピンク地の部分。現行の「小塚明朝 Pro-VI」の'jp04'テーブル(「モリサワPr5と小塚Pro-VIの'jp04'」を参照)は、これらの置換をサポートしていない。 ところで、JIS X 0208:1990に含まれていない(補助漢字をソースとする)文字のグリフを「JIS90字形」と呼ぶのはどうかと思う。まあ、補助漢字も「90年」の「JIS」には違いないけど。

    JIS2004とJIS90との文字の形の対照表 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • リュウミンの'jp83'実装 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    前回のエントリの続き。'jp83'用のグリフ集合229文字のすべてについて、リュウミンの実装字形をAdobe-Japan1の例示フォントである小塚明朝と比較した。以下の図では、(JIS90の規格票例示字体を参照する)標準グリフを青で、'jp83'グリフを赤で表示して重ね合わせ、共通部分を黒で示した。このサイズでは判別しにくい例もあるので、'jp83'タグを付けても字形の変わらないものは黄色地で示した。

    リュウミンの'jp83'実装 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 'jp83'の実装字形 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Adobe-Japan1は細かな違いを区別する体系だが、そのグリフ集合を規定しているTechNote #5078(http://partners.adobe.com/public/developer/en/font/5078.Adobe-Japan1-6.pdf)の例示グリフをどこまで忠実に再現するかの判断は、最終的には実装者に委ねられている。 そこで「標準グリフとほとんど変わらないグリフ」を数多く参照する'jp83'タグを用いて、Adobe-Japan1の例示フォントである小塚明朝(厳密にはTecNote #5078で用いられているのは「Pro-VI L」だが「Pro-VI R」で代用)と、ヒラギノ明朝、リュウミンの実装字形を比較してみた。 下図では、'jp83'用のグリフ集合229文字のうちCID順で先頭の9文字に対して、(JIS90の規格票例示字体を参照する)標準グリフを青で、'jp

    'jp83'の実装字形 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Adobe Illustrator CS2のグリフ置換の問題(「JIS83字形」編) - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Adobe Illustrator CS2で「松」と入力して選択し、字形パレット右上のオプション・メニューで「JIS83字形」を指定すると「枩」に置換される。この動作は、もちろん正しくない。 'jp83'タグ用のグリフ集合は229文字からなるが、このなかに(「松」と「枩」のように)異体字のペアが存在する場合、Illustrator CS2は'jp83'タグを適用された文字を、「その異体字のほうのJIS83字形」に置換してしまうようだ。 「JIS83字形」を適用することで不正なグリフに置換されるのは、以下の5組10文字。それぞれ左が標準グリフ、中が正しい'jp83'グリフ、右がIllustrator CS2の「JIS83字形」。 Illustrator CS2では、'jp83'だけでなく'jp78'や'expt'など、そのグリフ集合内に異体字を含むタグで同様の問題が発生するが、今回はとりあえ

    Adobe Illustrator CS2のグリフ置換の問題(「JIS83字形」編) - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Adobe Illustrator CS2のグリフ置換の問題(総論) - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    昨日のエントリで、わたしは以下のように書いた。 'jp83'タグ用のグリフ集合は229文字からなるが、このなかに(「松」と「枩」のように)異体字のペアが存在する場合、Illustrator CS2は'jp83'タグを適用された文字を、「その異体字のほうのJIS83字形」に置換してしまうようだ。 この記述は間違いではないが、事態の一部しか言い当てていない。より包括的に言うと、「Illustrator CS2では、あるフィーチャー・タグ'xxxx'用のグリフを含む『全異体字(aalt)』グループ内の文字に'xxxx'タグを適用すると、'xxxx'タグの影響を受けないはずの文字まで'xxxx'グリフに置換される」というようなことになっているようだ。という説明ではあまりにもわかりにくいので、以下、例を挙げてみる。 たとえばウマヤという文字には、文字コードのレベルでは「厩」と「廐」と「廏」の3種類が

    Adobe Illustrator CS2のグリフ置換の問題(総論) - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • カメの書き順とか画数とかをめぐって - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    「龜」(人名用漢字「亀」の旧字体)の書き順が気になったのでウェブで検索してみると、「漢字の正しい書き順」というサイトで紹介されていた(http://kakijun.main.jp/page/kame16200.html)。 ところで、「龜」には3種類のパターンが存在する。実際にはそれ以外にも考えられるが、今回は下図において赤で示した部分のみに着目する。下図右の「突き抜けているけれどズレている形」は「龜」単独ではAdobe-Japan1-6に存在しないので、「龝」の旁で示した(「小塚明朝 Pro-VI」で表示)。これらの3種類の「龜」を、左から「龜A」「龜B」「龜C」と呼ぶこととする。 このうち書き順サイトで紹介されているとおりに書けるのは「龜A」のみ。「龜B」と「龜C」の画数は、「龜A」よりも2画多くなるものと思われる。つまり「龜C」は、見た目では「龜A」に近いが、構造的には「龜B」に近い

    カメの書き順とか画数とかをめぐって - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • JIS X 0208:1983が第1水準・第2水準間で文字を入れ替えた22組 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    前回のエントリ(OpenTypeフォントの'nlck'タグについて詳しく書いてみる)のために「JIS X 0208:1983が第1水準・第2水準間で文字を入れ替えた22組」についての図を作成したところ、意外に複雑になってしまった上、誤りを含んだままアップしてしまったりして(現在は修正済み)けっこう落とし穴があるので、改めてこの問題についてメモしておく。 下図は入れ替えの対象のうち、第1水準側の22の区点である。no change欄がOpenTypeフォントのデフォルトのグリフ(JIS90の例示字体を参照したグリフ)であり、それ以外の欄はそれぞれ'jp78'タグ、'jp83'タグ、'jp04'タグを適用した場合の結果を示している。no change欄がいちばん上ではなく中途半端な位置にあるのは、上から時系列順にJIS78→JIS83→JIS90(no change)→JIS04と並ぶようにし

    JIS X 0208:1983が第1水準・第2水準間で文字を入れ替えた22組 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • OpenTypeフォントの'nlck'タグについて詳しく書いてみる - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    最初にクイズ。下図左の16文字は、いずれも字典などでは略字あるいは俗字とされているものであり、表外漢字字体表には、これらと異体字関係にある印刷標準字体が含まれている(下図右)。さて、下図左の16文字すべてに'nlck'(InDesignの日語表記では「印刷標準字形」)タグを適用した場合、このうち何文字が右に示した印刷標準グリフに置換されるだろう? クイズの答え。'nlck'タグを適用した結果が下図。印刷標準グリフに置換されたのは、水色バックの4文字。なぜこれしか置換されないのかについては、以下、遠回りをするかもしれないが、順を追って説明する。 2000年12月、第22期国語審議会は「表外漢字字体表(http://www.bunka.go.jp/kokugo/main.asp?fl=list&id=1000000518&clc=1000000500)」を答申した。表外漢字字体表は、「一般の

    OpenTypeフォントの'nlck'タグについて詳しく書いてみる - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • モリサワPr5と小塚Pro-VIの'jp04' - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    'jp04'は、JIS X 0213:2004の例示グリフを参照するためのOpenTypeフィーチャー・タグである。「リュウミン Pr5 R-KL」と「小塚明朝 Pro-VI」の'jp04'用グリフ集合は、以下のとおり。 下図の3文字は小塚Pro-VIのみに見られるが、これらはAdobe-Japan1-6で追加されたグリフなので、(Adobe-Japan1-5フォントである)リュウミンPr5に含まれないのは当然。リュウミンPr5と小塚Pro-VIは、共通の('jp04'用の)変換テーブルを使っていると考えてよいだろう。 両者の'jp04'用グリフのうち、余計なものは下図(「リュウミン Pr5 R-KL」で表示)赤字の5文字。前回および前々回のエントリで触れた'nlck'の問題では、「余計なグリフ」も表外漢字字体表に関するものであったため若干話がややこしかったが、下図の5つのグリフはいずれも

    モリサワPr5と小塚Pro-VIの'jp04' - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • モリサワPr5フォントの'nlck' - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    前回のエントリ(「小塚明朝 Pro-VI」の'nlck'タグの謎)では「小塚明朝 Pro-VI」の'nlck'用グリフ集合が変だということを述べたが、コメント欄でモリサワのPr5フォントも同様だという情報をいただいたので、さっそく「リュウミン Pr5 R-KL」を購入し検証してみた。確かに「小塚明朝 Pro-VI」と同じである。 字形デザインのレベルでは、CID=20289(Adobeのテクニカル・ノートの例示グリフは筆押さえのない「斧」)を、CID=3538と同じ筆押さえのある「斧」とするなどの主張が見られるが、'nlck'用のテーブル自体は「小塚明朝 Pro-VI」と変わらない。 というわけで、現在、'nlck'用のテーブルには、「ヒラギノ式」と「小塚=モリサワ式」の2種類が存在するようだ。前回のエントリで指摘したとおり、後者はグダグダである。

    モリサワPr5フォントの'nlck' - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 「小塚明朝 Pro-VI」の'nlck'タグの謎 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    OpenTypeフォントのフィーチャー・タグ'nlck'は、「一般の社会生活において表外漢字を使用する場合の字体選択のよりどころ」を示した国語審議会(National Language Committee Council)答申「表外漢字字体表(http://www.bunka.go.jp/kokugo/main.asp?fl=list&id=1000000518&clc=1000000500)」のグリフを呼び出すものである。追記:コメント欄でのご指摘により「Committee」を「Council」に訂正。 'nlck'用のグリフ集合は、表外漢字字体表のグリフ(印刷標準字体および簡易慣用字体)のうち「JIS X 0213:2000の例示グリフとは違うもの」を抽出したものであり、以下の172文字であると思われる(「ヒラギノ丸ゴ Pro」で表示)。 が、Adobe-Japan1-6フォントである

    「小塚明朝 Pro-VI」の'nlck'タグの謎 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 朝日新聞の字体変更の中身 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    今日15日、朝日新聞の字体が変わった。そこで、ざっと見て気付いた点など。 Microsoftの場合、表外漢字字体表が「デザイン差」としている差異であっても、基的に字体表の例示字形に合わせる方針であると思われる。一方、朝日新聞は、「デザイン差」に該当する部分の変更は行っていないことが多い(下図の上の行は、今日の朝日新聞朝刊から拾った文字。下の行は字体表のグリフを小塚明朝で示したもの)。 ただし、「デザイン差」を直している例も発見(下図)。 下図は、今日の朝日新聞朝刊で見つけた非・印刷標準字体。何か理由があるのか単なるミスなのかは不明。 今回の字体の変更について解説している記事中に「『辻』は表外漢字だが、社では例外として1点しんにょうのまま」という記述がある。なぜ「辻」だけが例外なのだろう。「『辻』は国字だから康煕字典体は存在しない」というような理屈なのだとは考えにくいが、かといって他の理

    朝日新聞の字体変更の中身 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Mac OS Xの文字コード問題に関するメモ - 朝日新聞の字体変更

    朝日新聞の1月9日朝刊で次のような告知を目にしたので雑感をメモ。 「約900字」のリスト希望。と思って朝日新聞に電話してみたところ、公開する予定はないらしい。というか、そもそもそのような文書は朝日新聞社内でも出回っていないという。 なぜ今なのか。国語審議会による表外漢字字体表の答申は2000年12月。それからすでに6年以上が経過している。Windows VistaにおけるMS書体の字形変更は朝日新聞の変更とほぼ同時期ではあるが、Microsoftの場合、JIS X 0213の改正(2004年2月)を待った上での変更だから、この時期になったのは理解できる。しかし朝日新聞の場合、単純に表外漢字字体表のサポートと考えるには、タイミング的に遅すぎる気がする。わたしはこれまでずっと、朝日新聞は(答申されたが内閣告示にはならなかった)表外漢字字体表をサポートする気がないのだと思っていた。 システム上、

    Mac OS Xの文字コード問題に関するメモ - 朝日新聞の字体変更
  • MS書体の字形変更でダメージを受けるのは誰か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Windows Vistaにおける字形の変更が話題となっているが、これをInDesign CS2などが提供しているグリフ置換機能と結びつけた論点はまだ出ていない気がするので、軽くメモ。 Windows(Unicode)は、しんにょうの点の数を区別しない体系である。だからこそWindows Vistaでは「辻」の字体を一点しんにょうから二点しんにょうへと変更することが可能だったと言えるだろう。 一方、Adobe-Japan1-xは、しんにょうの点の数を区別する体系であり、一点しんにょうの「辻」は、常に一点しんにょうである必要がある。 Adobe-Japan1-xではグリフはユニークな番号(CID)が振られている。しかし、たとえばInDesign CS2の場合、グリフの識別には基的にはUnicodeの符号値が用いられ、それでは表現できないグリフに関してのみ別の表現方法が用いられる。つまり、I

    MS書体の字形変更でダメージを受けるのは誰か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Unicodeにマルバツのバツはあるのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    以前のエントリ(ヒラギノでは全角でデザインされていない文字)で、わたしは以下のように書いた。 たとえば「○か×か」というテキストをヒラギノで表示した際、「×」だけが小さく見えて困惑したといった経験を、多くのMac OS Xユーザが持っていると思う。これは、ヒラギノがU+00D7 MULTIPLICATION SIGN(乗算記号)をプロポーショナルでデザインしているためである。 では、「マルバツのバツ」を表現したいとき、より適切な方法は用意されているのだろうか。Unicodeには、明示的な「マルバツのバツ」は含まれていない。U+2573 BOX DRAWINGS LIGHT DIAGONAL CROSSはバツと言えなくもないが、「BOX DRAWINGS」は罫線素片であってセマンティクス的にもバツ印とはやや遠いし、形もUnicodeの符号表例示字形を見る限りでは「○」と釣り合うようなものでは

    Unicodeにマルバツのバツはあるのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Mac OS XのJIS X 0213:2004サポート - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    JIS X 0213:2004では、「表外漢字UCS互換の文字」として以下の10文字が追加された。 Mac OS Xは、JIS X 0213の(符号化方法ではなく)レパートリを採用しているのだから、この10文字についても「JIS X 0213:2004の規格票が発行される以前から対応済み」と言えなくもない(http://internet.watch.impress.co.jp/www/column/ogata/sp26.htm)。 が、やっぱり「対応」と言うなら、たとえばシステムの文字パレットの「X0213 面区点」の1-14-01には「倶」の異体字(上図参照)を表示してほしい(下図はMac OS X 10.4.8の文字パレット)。

    Mac OS XのJIS X 0213:2004サポート - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Windows Vistaのjp90タグにおける「喩」の問題 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Microsoftのサイト(JIS X 0213:2004 対応と新日フォント「メイリオ」について)から入手できる資料には、Windows VistaのMSゴシックおよびMS明朝について、以下のような記述がある。 字形セットとしては、Windows XPで利用可能だった122文字のJIS90字形に、'jp90' OpenType feature tagによりアクセスができるようになっています。 この122文字のリストには、「喩」が含まれている*1。そして、「喩」については、「JIS90字形」欄のグリフ(「人」形)は、「JIS90字形」ではない。逆に、「JIS2004字形」欄のグリフ(「入」形)のほうが「JIS90字形」である。 JIS X 0208の規格票における「喩」の例示字体は、JIS78とJIS83では「人」形、JIS90以降は「入」形。つまり、JIS78もJIS83も略字風の字

    Windows Vistaのjp90タグにおける「喩」の問題 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 表外漢字字体表のヒゲ政策がダメな理由 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    明朝体の筆押さえ(ヒゲ)には、「分」や「公」などの上部の「八」に付くものと「父」や「延」などの右払いに付くものがある。 以下、便宜的に前者を「ハチヒゲ」、後者を「チチヒゲ」と呼ぶ。図は写研の蘭明朝、ヒゲありモード。 多くの書体あるいはシステムは、「常用漢字(と以前からの人名用漢字)なしなし、表外字ありあり」というルールを採用している。写研の石井明朝・蘭明朝のヒゲなしモード、大日の秀英明朝、凸版の凸版明朝など。ヒラギノ明朝や小塚明朝もこのグループである(下図はヒラギノ明朝W3)。 これに対して、写研のヒゲありモードは、「常用漢字ありあり、表外字ありあり」。 また、モリサワのリュウミンの場合、「常用漢字ハチヒゲありチチヒゲなし、表外字ありあり」である(下図はリュウミンR)。 ヒゲのつけ方に関しては、このようにいくつかの流儀が存在するが、それぞれに思想があるのだと思う。たとえばリュウミンの

    表外漢字字体表のヒゲ政策がダメな理由 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ