従来の方法で致命的にソリの合わないシチュエーションが出てきたので報告を兼ねてメモ。
たぶん手作業でも少なからずぶち当たる現象だと思うので。
【文字の線に隣の文字の塗りが食われる現象】
こういうバラ打ちテキストがあるとします。線フチがついてます。
※カッコ内の数字は愛され指数です。
縦中横の2桁の半角数字のうち、後ろの文字だけ修正するとします。
選択したところ
ァィャー、誤って全角の文字を打ち込んでしまいました。
（わざとだけど）
改めて、また1文字選択して半角数字を入力しました。
そしたらコレ。
前の文字が食われましたなあ。オーならシーに見えちゃうとこだ。
このように2文字というか文字列すべて選択して、すべて入力し直せば当然ながら回避できます。
ただし、ちょこまかカーニングをが入ってたりすると当然パーです。
…ウチは何か間違ってますでしょうか？
えーと次。
【TextStyleRangeはホイホイ増減する】
テキスト流し込みスクリプト『PlaceOptionalText』では、TextStyleRangeごとにテキスト原稿を段落単位で充てていくという方式で流し込み自動化を進めてきていたのでありますが、
↓これなんかだと、肩書き、名前、さん（美人指数）、の3スタイルかな、なんて。
でも、ぜんぜんそうじゃないわけ。
試しにこういうスクリプトでチェックしました。
TextStyleRangeを順繰りに選択していくだけの物。
スタイルその1
まずここから既に「段落の終わり」が選択されていないのに注目。
以下、赤枠囲みは前のスタイルとの差分です。
スタイルその2
肩書きの級数変更の際、段落や行ではなく単語部分を任意選択の上で変更した為と思われる。
スタイルその3
普通に大きくて太いぶん。
スタイルその4
手動カーニング。一見ブザマな作りではあるが、現場に来るデータではよく見かけます。
スタイルその5
上に同じ。カーニング値が違うだけ。
スタイルその6
まあ残りぜんぶ。篠沢教授にぜんぶ（捨て鉢の意）
実行結果は以上。
一般に「検索と置換…」や手打ち修正してても周知だと思いますが、手動カーニングが設定してある挿入点の前にある文字を打ち変えると、カーニング値はチャラになりますね。
そして、その隣の文字との差異がカーニング値だけだった場合など、これによってカーニングメソッドが一致して、同一スタイルという扱いになります。
で、そのつどTextStyleRangesのアイテム数が目減りしていきます。。
すると、狙った場所（TextStyleRangesの何番目）の番目がくり上がって見当違いの箇所にテキストがズバンバと流れ込むわけで。
なら、前もってカーニングをリセットしといちゃえばいいじゃない、
生かしておきたいカーニングもあるだろうけど、ある程度はしょうがないじゃない、
などとポジチブに考えて、目を付けたのが
コレ
ひじょうに便利で手軽なんだけど、ショートカットとクイック適用でしか実行できない（充分だろう）。
スクリプトのオブジェクト群には該当するメソッドがない。メソッドでいいんだっけ。いまだに用語が身に付かない。
ちなみにショートカットは Command + Option + Q
Windowsだと、 Ctrl + Alt + 芋、ですね（うそですね）
結局内部で何をしでかしているのかを消去法で割り出すことに。
最初に、このテキストフレームは「オプティカル」で運用しているのがおわかり。
ストーリーぜんぶ選択して、リセット。
．．和文等幅だとぅ？
これ、ただただつっけんどんに、いつでもどこでも和文等幅にするだけの代物のような．．
というのが結論。
アプリケーションのデフォルト、ドキュメントのデフォルト、いずれも無関係みたい。
つまり
selObj=app.activeDocument.selection.texts[0];
selObj.kerningMethod=”Metrics – Roman Only”;
selObj.tracking = 0;
で代用効くんじゃないか、って話。アンドゥ回数はかさむけど。
このへんをどうにかしないと、実際の現場ではドヒャーッと流し込むのは困難かと思われます。
いずれ、どうにかします。
