たまには（？）DTPっぽいことも書いてみるよ。 InDesign互換ファイル（.inx）は、とかくバージョン間の互換を指すように使われる傾向があるけれど、まあ、完全互換ではないし「バージョン間でのやりとりができる」のはむしろ副作用と考えている。 じゃあ、お前はどんなときに使うのか？　と訊かれるなら「環境互換」と答えよう。InDesignドキュメントは、保存履歴やら環境やらを大事に持っている。別名保存してもなくなったりしない。 今日の仕事のデータは、そんなバージョンアップに伴う更新やらいくつかの事務所を経たようなドキュメントだった。 落ちる、落ちる。ちょっとスクロールすると落ちる。オブジェクトをコピーすると落ちる。画像を移動しただけでカーソルぐるぐるだ。しょっちゅうHDDにアクセスしてる。強制終了だ、返事なしだ。 再起動しても直らない。InDesign起動時にCtrl+Command+Opt

てことで前回エントリの続き。 InDesignとIllustratorの合成フォント機能の挙動から、もしかしたら、なんて推測をはじき出しました。 まあ、裏は取れたんだけど、こういう時の推測が当たってしまうのはある意味嫌なもんです。まったくもって汎用性がないのがアレ。 これを行えるというべきかどうか、っていうのは別として。 実は前回、こんな推測をしてました。 合成フォント機能は外部のCMapファイルを使って字形情報の処理をしている。 これは至極単純で、フォントに内包されたCMapを無視して出力されていることから推測したものです。で、思いっきりそれが当たってしまっていたという。 これの確認は非常に単純です。CMapの記述を直接触ればOK。 今回弄ったのは「C:\Program Files\Common Files\Adobe\Fonts\Reqrd\Cmaps」（Windows）にある、「Un

InDesignのUnicode文字の言語指定はフォント指定による スポンサードリンク Tweet 縦組の従属欧文で、ダブルクォーテーションの起し受けがどうたらっていうのは InDesign CS と、新しくなった小塚明朝でよく言われるやつですよね。 Unicode の文字って、コードだけでは、どの言語に所属する文字かっていうのを正確に示すことができない（同じコードで複数の言語に所属していることがある）とのことです。 様々な言語間にまたがって使われる文字が統合された Unicode のコードポイントでは、特に言語指定は重要。ダブルクォーテーションは、欧文組版では当然使われていますが、和文組版でも約物として使われているので、U+201C（“）、U+201D（”）として割り当てられているコードポイントの他に、現在欧文内で使われているか、和文組版で使われているか識別するための情報が必要です。 例

株式会社エル・シー・エスの川村さんのblog「lcs_kawamuraの開発記録」を拝読。 問題に対する行動が素早すぎる。 モリサワ新書体（3） Pr5書体における文字置き換えテーブル改訂にともない、影響を受ける文字のチェックツールを弊社のWebサイトでFreewareとして公開しました。 Windows版はそのうち、とのことなので、これはもう日ごろからチェックしまくるしか。 InDesign 2.0でも影響は受けるはずだけれども（アプリケーション側ではjp04/nlckに対する和文表記を持っていないが、GSUB自体は認識する、はず）、一時的にCS以降で開いてチェックすれば事は済むかも。