その文字はなぜInDesignでロックされてしまうのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesignでテキストを選択して書体を変更しようとしたとき、下図のような火星語のアラートが表示されることがある。選択範囲内に「変更後のフォントにはないグリフ」が使われていた場合、ロックがかかるのは納得できるが、「あるはずのグリフなのに書体が変更できない」ということも珍しくない。今回は、その原因について書いてみようと思う。 InDesignにおける'aalt'を利用したグリフ指定は、一言で言えば、「親字のUnicode値」プラス「異体字番号」でグリフを特定する仕組みである。 たとえば「ヒラギノ角ゴシック Pro W3」で「返」と入力して選択し、InDesignの字形パレットで「選択された文字の異体字を表示」とすると、下図のようになる。 この5つのグリフが「返」を含む'aalt'グループだが、このうちInDesignが「親字」として利用するのは直接Unicode値と対応している文字のみであ
平均字面とは何か - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesignでは「文字揃え」と「グリッド揃え」で、平均字面に揃えるオプションが用意されている。この平均字面（ICF：Ideographic Character Face）は、OpenTypeフォントのBASEテーブルで、icfb（ICFのbottom）とicft（ICFのtop）の値として定義されている。下図、赤枠が平均字面。ideoは仮想ボディ（グレー枠）、romnは欧文ベースライン（青線）の位置。 平均字面はフォントによって違う。下図の数値は、小塚ゴシックの各ウエイトの平均字面を、仮想ボディに対する割合（長さ比）で表したもの。 平均字面が大きいフォント（小塚ゴシックH）と小さいフォント（モリサワのMB1）では、かなり差がある（下図）。 「文字揃え：平均字面の下/左」を使うと、同じフォントでサイズの異なる漢字や仮名を、きれいに揃えることができる（下図）。 その一方で、サイズが等しくフ
サルでもわかるグリッド揃え - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回に続き、InDesignの「文字揃え」と「行送りの基準位置」と「グリッド揃え」の関係について。今回は、段落パネルメニューの「グリッド揃え」を導入する。が、フレームグリッドは使わず、プレーンテキストフレームのままで、カスタムベースライングリッドを使うこととする。理由は、（作業効率的にはフレームグリッドを使ったほうがスムーズかもしれないが）ベースライングリッドのほうがロジックがプリミティブだからだ。 下図はプレーンテキストフレームにおける「グリッド揃え」のイメージ。オレンジ色の線がベースライングリッド（以下単に「グリッド」と呼ぶ）。行中で最も大きい文字の基準点（「グリッド揃え」で指定した位置）が、グリッド上にくる。 下図は、前回取り上げた「文字のサイズがときどき大きくなる行送り一定の箱組み」の例（いちばん左が目指す組み）。「文字揃え：平均字面の下/左」を使いたい場合、「行送りの基準位置」に
InDesign CS5でフォントを変えようとすると - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
2011年4月27日追記。このバグはInDesign CS5 7.0.4で修正されたようです。 InDesign CS5でaalt属性を持つ文字のフォントを変更しようとすると、ロックされて変更できない、あるいは変更後に化けることがある。このトラブルは、「変更前のフォント」が、モリサワPro、ヒラギノPro/ProNなどの場合に発生する*1。 下図はCS4とCS5の比較。CS5、モリサワPro（またはヒラギノなど）、aaltという条件が重なると、フォントを変更しようとしても、ほとんど場合、ロックされる。下図青字は、フォントの変更の際に（文字化けを防ぐために）異体字属性が調整されているケース。 このようなロックは「不要なはずのロック」だが、Cmd+Optionで強制的にフォントを変更（オーバーライド）すると、異体字属性の調整が行われないので、文字化けする可能性がある（下図）。オーバーライドとい
InDesign CS4/CS5で回転させた線の長さを変える冴えたやりかた - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
ねえねえ、さっきはついうっかり言いくるめられちゃったけどさ……。 はい？ InDesignで線を回転させたときの挙動ってやっぱりおかしくない？ そうですか？ たとえばこう、ヨコ線を引いてさ、反時計回りに90°回転させるとタテになるじゃん。 なります。 で、下端を基準点にして長さを半分にすると、ほら、上下に縮まっちゃうよね。 だから、それはですね、「回転前の位置」を基準に考えないとダメなんです。 でもさ、この場合、回転後の「下」は、回転前は「左」だよね。 そうです。 で、「左」を基準にして長さを半分にすると、ほら、今度は上に縮むんだぜ。 あれ、逆？ 左なら上で右なら下？ いや、その覚え方は回転方向が時計回りの場合に通用しないな。「線の長さを変えるときの基準点は回転させる前のその点の逆の位置」って覚えておくと、わかりやすくて作業がぐんぐんはかどるぞ！*1 *1:InDesign CS4/CS5
フレームグリッドの設定がテキストフレームでよみがえる - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
あまり一般的でない条件下でしか顕在化しないバグ（だと思う）なのだけれど、再現手順をメモしておく。作業環境はInDesign CS4（6.0.4）。 フレームグリッドを作成する。現象を把握しやすくするために、適当な文字を入力しておく（下図）。 これを「オブジェクト＞フレームの種類」でテキストフレームに変更する（A）。現象を把握しやすくするために、テキストのフォントとサイズを変更しておく（下図）。 他のテキストフレームを作成し（B）、段落スタイルパネルメニューで「スタイルとのリンクを切断」して段落スタイルを「なし」にし、適当な文字を入力する。この文字のフォントやサイズはいじらない（下図）。 テキストフレームBのテキストをコピーし、テキストフレームAにペーストする。と、フォントやサイズが忘れたはずの（フレームグリッドのときの）設定になってしまう（下図）。 他人の作ったデータを加工する仕事の多いデ
「InDesignのグリフ置換とOSのバージョン」についてのAdobeからの回答 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
先日のエントリ（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版の将
InDesignのグリフ置換の挙動がMac OS Xのバージョンによって変わる - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
works014さん（なんでやねんDTP）とのやり取り（「InDesign CS3における漢字の表現方法の優先順位」と「小塚明朝Rの問題_JIS04字形の適用された「靭」」）のなかで気付いたこと。InDesign CS3/CS4は、Mac OS Xのバージョンによって、グリフ置換の挙動が変わるようだ。 たとえば「靭のJIS78グリフ」を指定したいとき、InDesignタグでは「靭」という書き方と「靭」という書き方がある。GlyphFormとOTFeatureListは、単なる記述方法の違いではなく、InDesignでは互いに異なる属性として、異なる振る舞いをする。 InDesignのグリフパレット（CS/CS2）またはグリフパネル（CS3/CS4）から漢字のexpt/jp04/jp78/jp83/jp90/nlck/tradグリフをダブルクリックで入力し、これをInDesignタグで書き出
InDesign CS4で「※」や「×」が恐い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4で「※」や「×」などの文字が、「和字」であるように振る舞ったり、「欧文用文字」であるように振る舞ったりする。Adobeに問い合わせ中の事例で、再現性が環境に依存する可能性があるのだけれど、とりあえず、わたしの環境における挙動をメモ。 InDesign CS4で「環境設定＞組版＞CIDベースの文字組みを使用」をオフ、「段落＞文字組み」は「行末約物半角」とし、テキストフレームに以下のようなテキストを入力する。 あ±1 あ×1 あ÷1 あ§1 あ※1 あÅ1 あ†1 あ‡1 あ¶1 これを一度保存して開き直したものが下図。「あ」の後ろに和欧間のアキが入っており、「※」などの記号類は欧文用文字として扱われている。 これだけでもCS3との非互換性が問題なのだが、さらに面倒なことに、テキストを編集することによって記号類の属性が変化することがある。下図は、1行目の「±」の前の「あ
InDesignでIVSが扱いにくい理由 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
異体字セレクタ（Variation Selector）は、人から渡されたプレーン・テキストの原稿に含まれている可能性がある。 異体字セレクタは、見えない。 異体字セレクタの効果は、フォントに依存する。 親字と異体字セレクタの並び（IVS）は、テキストエディットやJedit Xでは1文字として扱われるが、InDesignでは2文字として扱われるため、親字と異体字セレクタの間に文字を挿入できてしまう。 InDesignでは異体字セレクタは「幅のない文字」として扱われるため、カーソルが異体字セレクタの前（IVSの中）にあるのか後（IVSの外）にあるのかは、見ただけではわからない。 InDesignでテキスト中に漢字を挿入したとき、潜在していた異体字セレクタと結びついてIVSを構成し、字体が変わる可能性がある。 異体字セレクタとOpenTypeタグによるグリフ指定が競合あるいは重複した場合、挙動を
InDesignにおけるJIS04基準フォントのウマヤ化け問題 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4で「厩」を入力・選択し、字形パネルをダブルクリックしてCID+13647に置換。フォントは（たとえば）小塚明朝Pr6N。そのウェイトを変更してみる。と、CID+13412に化ける（下図）。 このグリフ化けのおもしろい点は、cmapテーブルもaaltテーブルも共通だと思われるフォント間で（ウェイトの違いのみで）化けていること。以下、化ける理屈（推測）について、大雑把に述べる。 InDesignにおけるaalt（すべての異体字）タグを利用したグリフ置換のメカニズムは、cmapテーブルまたはaaltテーブルが異なるフォント間では、基本的にうまく機能しない。実際、InDesign 2では、いろいろ化けていた。 CS以降のInDesignでは、Adobe-Japan1-4とAdobe-Japan1-5のcmapテーブルの違いおよび2系統存在するaaltテーブルの違いへの対策が
IVSとaaltタグの競合や重複 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4で、IVS（異体字シーケンス）によるグリフ指定とOpenTypeのaaltタグによるグリフ指定が競合あるいは重複した場合の挙動について。 U+7953「祓」を例にすると、IVSとaaltタグは下図のように機能する。 では、これらが競合・重複した場合は、どうなるのか。下図は横軸が異体字セレクタ、縦軸がaaltタグ。左の列（青地）は異体字セレクタのみを適用したもの、緑地はaaltタグの指定にしたがったグリフが表示されているもの、赤地はIVSによる指定ともaaltタグによる指定とも異なるグリフが表示されているもの。 前回のエントリで見たように、aalt以外のタグがIVSと競合した場合、結果的にどちらか一方の指定が顕在化する。しかしaaltタグとIVSが競合あるいは重複した場合、どちらの指定とも異なるグリフに「化ける」場合がある。 ロジックとしては（前回のエントリで取り上げ
InDesign CS4におけるIVSとOpenTypeタグのあやしい関係 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4はUnicodeのIVS（異体字シーケンス）をサポートしている。IVSは、親字に続けてU+E0100などの特殊な文字（異体字セレクタ）を入力することで、たとえば下図のようにグリフを指定するメカニズムである。 同様のグリフ指定は、もちろんOpenTypeタグでも可能である（下図）。 では、1つの文字にIVSとOpenTypeタグで競合する指定を行ったらどうなるのだろう。U+990C「餌」を例として試してみた結果が、下図。横軸がIVS、縦軸がOpenTypeタグ。IVSの指定が顕在化しているものを青地、OpenTypeタグの指定が顕在化しているものを緑地で示した。白地は両者の指定が一致しているもの。 この例では、異体字セレクタがU+E0101またはU+E0102ならIVS優先、そうでなければOpenTypeタグ優先、というように見える。しかしInDesign CS4は、
小塚ProのSING拡張がらみの文字化け - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InD-Boardの「字形について」というスレッドで話題になっていた「SINGで拡張された小塚Pro」の文字化けについて、InDesign CS4と小塚明朝Pro Rで検証してみた。 再現性にあいまいさはあるが、次のように言えそうだ。SINGで拡張された小塚Pro書体において、グリフXがSING拡張分ではなく（CIDが15443以下）、なおかつグリフXの親字PがSING拡張分であり（CIDが15444以上）、なおかつ親字Pの符号位置が基本多言語面の範囲外（Unicodeスカラ値が5桁）である場合、ドキュメントを保存して閉じた後に再び開くと、グリフXが親字Pに化けることがある。 わたしの環境では、字形パネルからダブルクリックで入力して（コピー＆ペーストや書体の変更などをせずに）すぐに保存し開き直した場合、前項の条件を満たすものは100%化けた*1。 下図は、化ける文字のリスト*2。グレー枠の
InDesignのオプティカル・カーニング - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回のエントリでは触れなかった「オプティカル」について。Adobeの「文字組み設定の手引き」（http://www.adobe.com/jp/products/indesign/pdfs/mojikumi.pdf）には、次のように記されている。 この機能は現在欧文だけを想定しており、和文には対応していません。欧文の場合、自動的に文字と文字との間隔を調整します。 ということを前提とした上で、以下あえて、和文組版における「オプティカル」についてメモ。 まず、基本の確認。プロポーショナルの欧文の場合、「メトリクス」はフォントが内部的に保持しているペアカーニング情報（'kern'テーブル）に基づいて文字間を調整する。下図の「Type」の例では「Ty」の組み合わせのみが、メトリクス・カーニングの対象となる。一方「オプティカル」は、フォント内部の数値を参照するのではなく、文字の形に基づいて、InDes
InDesignの「文字ツメ」と「プロポーショナルメトリクス」 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesignで日本語の詰め組みをする場合、「文字ツメ」を使う方法と、OpenType機能の「プロポーショナルメトリクス」（またはカーニングの「メトリクス」）を使う方法がある*1。その基本的なロジックの違いをメモ。 「文字ツメ」は、文字左右のサイドベアリング（下図ピンク地）を、指定した数値に応じて削るものと考えればよいだろう。もともとプロポーショナルで設計されているアルファベットのサイドベアリングも、削られてしまう。図に用いたフォントはリュウミンR。 「プロポーショナルメトリクス」は、OpenTypeフォントがあるかじめ持っている詰め情報（'palt'フィーチャ）に基づいて詰める（下図、水色地がリュウミンRで詰められる部分）。詰め加減はフォントに依存するが、プロポーショナルで設計されているアルファベットのサイドベアリングが削られるようなことはないだろう。また、「鬱」のように幅のある漢字は
InDesign CS3における漢字の表現方法の優先順位 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS3で字形パネルのダブルクリックによって漢字を入力したとき、そのグリフは文字コード的にどのような扱いになるのか。 入力されるグリフが、フォント内部のcmapテーブルでUnicodeの符号位置と直接対応付けられている場合。そのグリフはUnicodeの符号位置のみで表現される。下図はその例。可能な表現のうち、採用されるものを1行目に、そうでないものをグレーで示した（以下同）。図に用いたフォントは、ヒラギノ角ゴPro。 前項に該当せず、入力されるグリフが'aalt'以外の漢字系のタグを用いて表現可能な場合。そのグリフは、親字の符号位置、タグ、異体字番号の組み合わせにより表現される。では、「'aalt'以外の漢字系のタグ」を用いた表現が、1つのグリフに複数存在する場合は何が優先されるかというと、単純に「タグのアルファベット順」となるようだ。たとえば「珊」の異体字のCID+769
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
