タグ

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

  • IVSとGSUBはどう違うのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    異体字シーケンス(IVS)の特徴について、OpenTypeフィーチャのグリフ置換(GSUB)と比較しながら考えてみた。重要だと思われる点をメモしたものであり、IVSの体系的な説明ではない。 IVSは文字コードのレベルの枠組みなので、異体字の情報をプレーンテキストで交換できる。この最大の特徴に加え、GSUBよりも新しい分、よりすっきりとした論理的な仕組みになっている*1。 IVSの概念は、下図のようなかんじ。符号位置に包摂される複数のグリフ(集合)のなかから、ある特定のグリフ(集合)をVSによって指定する、というイメージ*2。 上図はUnicodeの視点から描いたものだが、Adobe-Japan1フォントではデフォルトのグリフはcmapで指定されているので、実装としては下図のようなかんじ。IVSでは、原則として基底文字(親字)の包摂範囲を超えたグリフは指定できないので、VSを付けることによっ

    IVSとGSUBはどう違うのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 「スラッシュを用いた分数」の仕様変更 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Adobe-Japan1フォントには、分数に関して4つのスタイルが用意されている。下図は「1/2」を例としたもの。3番目の「斜め型・グリフの動的合成」以外については、前回のエントリでも触れた。 OpenTypeフォントには、分数に関するフィーチャとして、'afrc'(分数)、'frac'(スラッシュを用いた分数)、'numr'(分子)、'dnom'(分母)がある。Proフォントでは、これらのフィーチャによる置換結果は、各スタイルと下図のように対応する。 一方、Mac OS X 10.5以降に付属するヒラギノProNやAdobe CS4に付属する小塚Pr6Nなどでは、'frac'(スラッシュを用いた分数)の仕様が、下図のように変更されている。常識的に考えてJISの例示字形と'frac'の仕様は関係なさそうなので、たぶん単純にヒラギノProNや小塚Pr6Nのほうが新仕様なのだろう。 旧仕様のフ

    「スラッシュを用いた分数」の仕様変更 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 絵文字バリエーション・シーケンスとは何か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    たとえば、仕事用のメールの署名に「☎」という文字を入れていたら、iPhoneではそれが絵文字の赤電話として表示されてびっくり。というような経験をしたことがある人は、たぶん少なくないと思う。こういうことが起きるのは、「絵文字じゃない文字」と「絵文字」がUnicodeでは同じ符号位置に包摂されていて、どちらが表示されるかはフォント(の優先順位)次第だからだ。 ケータイ絵文字をUnicodeに収録する際、Appleはすべての絵文字に独立した(通常の文字とは別の)符号位置を与えたかったようだが、それはかなわなかった。そこで次善の策として、「絵文字じゃない文字」と「絵文字」をプレーン・テキストで区別するメカニズムをUnicodeに提案した。それが絵文字バリエーション・シーケンス(EVS)だ*1。EVSはUnicode 6.1に入り、Mountain Lionでサポートされた。下図は、Mountain

    絵文字バリエーション・シーケンスとは何か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 平均字面とは何か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    InDesignでは「文字揃え」と「グリッド揃え」で、平均字面に揃えるオプションが用意されている。この平均字面(ICF:Ideographic Character Face)は、OpenTypeフォントのBASEテーブルで、icfb(ICFのbottom)とicft(ICFのtop)の値として定義されている。下図、赤枠が平均字面。ideoは仮想ボディ(グレー枠)、romnは欧文ベースライン(青線)の位置。 平均字面はフォントによって違う。下図の数値は、小塚ゴシックの各ウエイトの平均字面を、仮想ボディに対する割合(長さ比)で表したもの。 平均字面が大きいフォント(小塚ゴシックH)と小さいフォント(モリサワのMB1)では、かなり差がある(下図)。 「文字揃え:平均字面の下/左」を使うと、同じフォントでサイズの異なる漢字や仮名を、きれいに揃えることができる(下図)。 その一方で、サイズが等しくフ

    平均字面とは何か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 「ヒラギノ角ゴ StdN」のcmap - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Mac OS X 10.5 Leopardに付属する「ヒラギノ角ゴ StdN」のcmapがUniJISX0213系ではなくUniJIS系になっている気がするのだが、なぜだろう。 下図は違いの例。赤い数字で示したCIDが(「X0213」の付かない)UniJIS系のマッピング。 以下追記。考えてみたら残りは3文字だけだったので、下図を追加。

    「ヒラギノ角ゴ StdN」のcmap - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • ヒラギノと他のフォントの文字幅の違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    大日スクリーンの「ヒラギノOpenTypeのFAQ」のページに「ヒラギノOpenTypeのProフォントとStdフォントの互換性は?」という項目がある。その一部を引用してみる。 ヒラギノOpenTypeのProフォントとStdフォントは、収容グリフ数が倍以上も異なりますので、両者の差分のグリフ部分については互換性はありません。では、両者に共通するグリフ(Adobe-Japan1-3のグリフ)については互換かと言うと、これも完全に互換とは言えません。 これは、ProとStdで特定のUnicode符号位置に割り当てるグリフの文字幅バリエーションが異なる場合があるためで、Unicodeに依存して文字処理を行うアプリケーションでは、ProフォントからStdフォント(またはその逆)に書体変更すると、同じコードの文字でも文字幅が変わってしまうことがあります(例:Stdでは数学記号の∑や√にAdobe

    ヒラギノと他のフォントの文字幅の違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
    terkel
    terkel 2017/03/18
    +Designing #42 P36
  • Mac OS Xの文字コード問題に関するメモ - Mac OS Xでは欧文フォントで小さく表示されることのある文字

    ブラウザなどで「○」や「■」が小さく見えたり、三点リーダの位置がずれたりして困惑した経験を、多くのMac OS Xユーザが持っていると思う。これは前回のエントリ(ヒラギノでは全角でデザインされていない文字)で書いた話と似ているが、原因は別で、アプリケーションやスタイルシートの設定で欧文フォントが指定されている場合に見られる現象である。 そんなわけで、JIS X 0208の範囲内のいわゆる「全角文字」のうち、「欧文フォントで表示されうる記号類(ギリシア文字とキリール文字以外)」をピックアップしてみた。ただしこのリストは、インストールされているフォントの種類によって変動する可能性がある。リスト中、上段の文字はヒラギノ、下段の文字はSafariなどでHelveticaを指定した場合に表示されるものである。 Mac OS Xでは、欧文フォントが指定されていた場合、表示に用いられる優先順位は「そのフ

    Mac OS Xの文字コード問題に関するメモ - Mac OS Xでは欧文フォントで小さく表示されることのある文字
  • ヒラギノでは全角でデザインされていない文字 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    たとえば「○か×か」というテキストをヒラギノで表示した際、「×」だけが小さく見えて困惑したといった経験を、多くのMac OS Xユーザが持っていると思う。これは、ヒラギノがU+00D7 MULTIPLICATION SIGN(乗算記号)をプロポーショナルでデザインしているためである。そんなわけで、JIS X 0208の範囲内のいわゆる「全角文字」のうち、ヒラギノでは全角でデザインされていない文字のリスト(ヒラギノ丸ゴ Pro W4、バージョン7.11で表示)を作成してみた。目で見て拾っただけなので、漏れなどがあるかもしれない。 このうちセント記号(U+00A2 CENT SIGN)、ポンド記号(U+00A3)、否定記号(U+00AC)がプロポーショナルなのは、Unicodeの範囲内には他に全角バージョン(U+FFE0 FULLWIDTH CENT SIGN、U+FFE1 FULLWIDTH

    ヒラギノでは全角でデザインされていない文字 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 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

    U+2015 HORIZONTAL BARとは何か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 昔のグリフで出ています - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

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

    昔のグリフで出ています - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • エリプシス(ellipsis)と三点リーダ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    欧文組版で用いられる一般的なエリプシスは、3つのドットをベースライン上に配したもので、日語組版で用いられるセンターライン上の三点リーダとは位置が異なる。 しかしJIS X 0208やJIS X 0213は、(1面)1区36点の三点リーダを、U+2026 HORIZONTAL ELLIPSISと対応付けている。このため、U+2026 HORIZONTAL ELLIPSISをどちらの形状とするかは実装依存ということになり、一般に和文フォントではセンターライン形状、欧文フォントではベースライン形状となっている。 下図における長方形の枠内は、Unicode Standardのコード・チャートの画像。ただし、枠内の正方形の色地は、目安として追加したもの。 Unicodeには、U+2026 HORIZONTAL ELLIPSISの他に、センターライン形状のU+22EF MIDLINE HORIZON

    エリプシス(ellipsis)と三点リーダ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Lionのヒラギノはどこが変わったのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Lionでは、ヒラギノProNとStdNのバージョンが8.10になり(LeopardとSnow Leopardは8.00)、IVS(異体字シーケンス)に対応した。それ以外の(Nの付いていない)ヒラギノは変わっていない。 テキストエディットでフォントをヒラギノProNにして「厩」と入力し、その後ろに文字ビューアからU+E0100をドラッグ&ドロップしてみると、文字の形が変わるのを確認できると思う。Adobe-Japan1のIVD(2007-12-14)は、フルサポートするにはAdobe-Japan1-6が必要となる。先行してこれをサポートしたした小塚Pr6NやイワタPr6/Pr6Nとは異なり、ヒラギノ(ProNでも、ほぼAdobe-Japan1-5相当)では部分的なサポートとなっている。 今回のバージョンアップにともない、cmapも新しくなった。グリフの総数は変わっていないが、Unicode

    Lionのヒラギノはどこが変わったのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • AquaKanaに入っている文字 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Mac OS X 10.5 LeopardまでのAquaKanaには、その名のとおり、仮名や約物しか含まれていなかった。下図は、そのすべて。 Mac OS X 10.6 Snow Leopardで、AquaKanaはAdobe-Japan1-5をフルサポートした。ただし、Adobe-Japan1-5のレパートリは、ヒラギノ角ゴW3の字形を流用しているように見える。もともとのAquaKanaのレパートリは、GID的にはAdobe-Japan1-5の後に付け足されたような形で入っている。下図、漢字部分までがAdobe-Japan1-5。 OS X 10.7 Lionでは、漢字もAquaKanaオリジナルになった。新デザインの漢字は、GID的には、Adobe-Japan1-5の範囲内の漢字を置き換えた形になっている(下図)。 一方、Lionでも(GID的に)Adobe-Japan1-5の範囲内に

  • サルでもわかるグリッド揃え - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

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

    サルでもわかるグリッド揃え - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • ヒラギノ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では区別されるけれど)ヒラギノの実装字形では区別されないもの。

    ヒラギノProとProNの違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • 1