スクリプト構文の冒頭にある、がんじがらめの動作条件をご確認の上、
めめっと試してみておくんなさいまし。
この時点で問題があるなら早めに出て欲しいもんですねえ “^
たぶん全バージョン、全プラッポホーフ対応。たぶん。
行送り値を全部しまいこみつつ、比較してます。
実際の行送りはLines内のCharacterを1こ1こ見て一番デカいのを捕まえないとダメっぽいです。
つまり、Characters配列を全部見てます。将来的にすごく重くなるのかも。ならないのかも。
あと、間違えてParentStoryを使ってしまったので連結テキストやオーバーフローありだとワヤクチャになります。Texts[0]が正解。
おいおい様々なシチュエーションに対応していきます。師匠が（ォィォィ）
まずは簡便にテストお願いしますです。
修正版 _b
・characters配列の内容を全部見ていたところを、textStyleRangesの内容に変更。ばかだなあ。
・同様に、textSytyleRanges[-1]の居る行だけを本文として対象に。
本文の行同士を総当たり形式で比較してるけど結構ムダかも。
・ぼちぼち縦組も対応。
とりゃえず、イラッとしない程度の速さにはなりました。まだ無駄が多いというか根本的におかしい気も。。
実行後、1秒弱お待ち下さい。orz
座標を見たい行の、先頭以外の挿入点に0.01×0.01mmぐらいのインラインオブジェクトを作ってしまえば速いのだが。
座標だけ拾ったらすぐundoしちゃえばバレないかな？
修正版_c
・テキストが1行しかない時の無限ループを修正 orz
・3つ以上でもへっちゃら
．．．ぼちぼちよろしいですかね？
ほぼ最終版_d
・定規の開始位置が「スプレッド」以外の時の不具合を修正
・ver_cでユーザー入力による基準オブジェクトの指定が効かなくなった不具合を修正
・ver_cで基準オブジェクトの1行目にしか揃わなくなった不具合を修正
・手にやさしいフローラルの香り
・文字揃え=欧文ベースライン 以外はキッパリ切り捨て
・テキストの配置=上／右 以外はキッパリ諦め
いろいろとケツの穴がすぼまった仕上がりとなっておりますが 。。
教授！、うひひっ良い感じじゃないですか。
成功した条件
テキストフレーム内の1行目の文字を見出しとして、それに続く文章を本文として、
見出しは級上げしてあります。
左右に同じ内容で置きました。右のフレームのY座標を小さく（上に上がっている）。
基準左フレームで、行位置はばっちり揃いましたよ！
おっとな場合
上記右フレームが下がっていると、双方の頭が揃ってしまいますね。
考えられる配置パターン（処理前のだらしないレイアウト）は何種類かアルですね。
これは後で絵画にしてアップします。
内容テキストから考えると、ほとんど本文（同一文字サイズ行送り）、見出しの様な変則文字列が有ったとしても、フレームの頭か中程、ケツっぺたには来ないと言うことになるでしょうから、フレーム内の判断行は、最終行か？
まぁ、その最終行が隣のフレームで見出しにブチ当たったら面倒ですが。。。。
配置ぱたーん。
http://www.pictrix.jp/?attachment_id=4220
これ掛ける見出しの有り無しでしょうか。
>フレーム内の判断行は、最終行か？
いずれにしても、全ての行は調べなあかんみたいね ^^;
今のところ、行送りの基準位置が欧文ベースラインという事に決め打ちしてあって、それぞれの行のY座標の算出方法は
フレームの上辺Y座標（geome~bounds[0]）
＋1行目の文字のうち最大の文字の級数（＝1行目）
＋2行目の文字のうち最大の行送り値（＝2行目）
＋3行目の以下割愛
という感じです。
このサンプル画像、本文が新ゴRで行送り自動（175%）、見出しは新ゴDBの2Q上げってとこですかね？
まだテストの為のテストという段階なので、揃い元は「基準フレームの1行目」限定です。
promptを追加して「基準フレームの何行目に揃えるか」を加味してやればそれなりの動きを見せるとは思いますけども。
ちょっと整理しますと、
・イレギュラーな行（見出し）は整列の対象に含まず、あくまで本文のベースライン統一が主眼である
という事ですね？（いまわかった）
そんならそうと先に（言ってる言ってる orz）
＞ほとんど本文（同一文字サイズ行送り）、見出しの様な変則文字列が有ったとしても、フレームの頭か中程、ケツっぺたには来ないと言うことになる
ということで、各行の先頭文字のスタイルだけ調べておけば師匠の使用環境には堪えるみたいですね。これで重いのは解消でけます。
ただ、見出し段落だけは各文字を見とかないと、かな？段落末尾の改段文字だけスタイルが合ってないデータも多いし。
なんらかのラクズル方法で本文です、という行だけを対象として、動かす方のフレームの上か下か近い方向に移動して整列、そののち、なんかUIをポチポチするたび座標が1行分ずつシフトする（その際「ﾆｬｰ」と猫の声を発して心が和む）、という向きですね。
年賀状がおぼついたら着手しまふ ^
あ、で、A、CがOKでB、DがNGというのは、
これは現段階まだテストなので「基準フレームの1行目だけが整列対象」だからです。
もし、もう今すぐどうにかなれば、という状況でしたら
130行目の
var base=gb(keyObj, 0)+klAry[0];
のklAry内の参照アイテムをklAry[0] から書き換えてやれば見出し無視はでけます。
klAry[klAry.length-1] で最終行、
klAry[Math.floor(klAry.length/2)] で大体なんとなく中央の行になります。
それでも移動対象側の見出し行は対象範囲内なので、それとなく上にハズしてやらないとピッタンコしちゃうかも。
親記事の下にver._bを追加しました。修正内容もご一読。
教授、頂きやした。どもども。
明日ちくちくしてみます。^^
これからルビ辞書の作成！
目標3マンゴっす。
アップ後、ちょっとでもゼーニクを落としたら速くなるかな、と思って、
本文ぶんの行数を比較して少ない方は先頭行と末尾行だけ比較すれば事足りるのに気付いて組み込んでみたんですが体感的には速度変わらず。
どうにも各行の座標出しの部分が重たいようです。
さ、年賀状年賀状 ;;
うひひっ、満足満足！
アリガタや、アリガタや
欲張り爺とすれば、3フレ以上も一気にできたら、、、
欲張りでした。
3つ以上になるとキーオブジェクトの判定はともかく指定がキビシメですねえ。
そうなるといよいよUI搭載かな？
整列後に1行単位でシフトできないとまだ実用的とは言えないしなあ。
そいとも環境設定のキー移動量に1行ぶんの距離を設定した方が操作する側としても簡単かな。
他の皆さんにも、お布施しだいであなた専用の便利なスクリプトを（うそ）
>整列後に1行単位でシフトできないとまだ実用的とは言えないしなあ。
あまり考えていなかつた。
だらしなレイアウトでも、ある程度は配置して、最後に整いましたなので。。。
でも、ガツンと動いてしまった場合（自分の意図とは別方向とか）動かせたら嬉しいのは確かだけど。（使うかなぁ。。。）
今のでもゴッツウ有り難いぞ。
キーオブジェは、左右いずれかの最北端でしょうね、そう決めてしまえば、仕様仕様で！
んッ
3フレームあるとして、モノがななめ45度の直線上に等間隔に並んでいたら、どう判別．
ってフレームの組み方向で見ればいいのか。そのへん現状たぶん回りくどい事してるかも。
キーは両端のどっちか限定、次男は主導権ナシ、と。
年内には（あ、明けてんじゃん）
棟梁！
明けましておめでとうございます。
見開きでルーラー単位がページだと、基準フレームが左右逆転してしまうシチュエーションがございました事をご報告させて頂きます。
というわけで今年も吉永小百合お願いします。
＞見開きでルーラー単位がページだと
また基本の見落とし。。大仰な動きをしないスクリプトならドキュメントの設定はそのままにしといてフレーム座標を拾うときに親ページのindexを加味する方向がいいなあ。そうします。
他のやりかけが片付いたらママッとやりますです。
>フレーム座標を拾うときに親ページのindexを加味する方向
それは単に、スプレッド単位にするって事でしょうか、違うでしょうか。
一杯ヤリてぁなぁ。。。
右ページならX座標に＋ページ幅でケーサンするようなのを考えとります。
ルーラー単位をスプレッドにされっぱなしでイヤな人もいるかも（いないと思うけども）だし、処理後ルーラー単位を戻すと、その後、困+Zしても一回余計にルーラー単位ぶんかかるので、移動処理を取り消すには困+Zを2回やらないといけない、でもその状態ではルーラー単位がスプレッドのままなのでキレーに「やらなかったこと」にするには都合3回の困+Zが必要となるんですわいね。。
というわけで、あまりかっこよくないのです。
他にも流用したいスクリプトがごまんとあるので（ほんとは10るかなかいか）この機に確立させてみたいなあ、なんて。
明晩カラダだけなら空いてます orz
履歴重視ねっ、分かりました。
活躍の場は少ないけど、ちょうほう度合いは良いですよ！
>明晩カラダだけ
オイラの身体が糞詰まり。失礼、次回にっ！
次回の農閑期にやっちゃいたいとこなんですが、
もろもろの合間にルーラーの基準を触らないで仮想のスプレッド座標を出すテストしてみてたんですが
難しい。今さらだけど。
出力屋的観点からすればページ外にあるオブジェクトも処理対象としたいところで、そうなるととっかかりがなさすぎて困ったです。
そのうちまたなんか閃くでしょう。
ところで、毎月第一日曜あたりが確実にカラダもココロもサイフも安心です。
2/8 ^^
へ、平日？
お師匠，最終版アップしましたよー
あ…スプレッド対策してなかった。。
ver_d 、次週で。。
> へ、平日？
まちまえた、2/6か。
頂いて行きますっ！ _d も待ってますっ！
2/6、了解 ^
節制しときます
頂きました ^^
ところで、2点6は定例会議仕立てでしょうか。
ふれ廻っときましょうか？
おおおお任せします “^
親方っ！
これの開発は終了でしょうか。
やはりフレーム内に文字種ごちゃ混ぜが多く、揃わなくなってきました。
で、アプローチを変更してちょっとシコシコしたのが
http://www.pictrix.jp/id/BaseLiner/baseliner.mov
mojiObj.baseline で手軽に。横組み専用ですが。
おおお、なんかサクサク動いておる！
ウチ版の仕様は、
フレーム内の最後のスタイルを使う、に落ち着いたんでした（なんとなく通用する気がして）。
末尾にQ下げした注釈でもいるとアウトですねえ。
そっから先の行単位のアゲサゲをギョギョームでまかなう、と。
そこで止まってますね。ハハハ
にしても師匠版、妙に速い。。
さては動画つまんでますなッ？
>さては動画つまんでますなッ？
はははっ、いやいや。
スクリプト作動中はリアルタイムざんす。
メールでコード送ります。^^
いいもんもらったので、ウチのやつは消しとこう。。;;
モロそれのプロパティ見落としてすごくぶさいくなので orz
>ウチのやつは消しとこう。。;;
おいおいっ！
頼むよ、自動処理をっ！
「一気に選択、一気に揃えて」がよござんすからねぇ。
この baseline って、文字面より内側なのが気に入らないのですが。