ＩｎＤｅｓｉｇｎでＪａｖａＳｃｒｉｐｔ その12。

これとそれで書いたお仕事用のJavaScript。
公開するのをちょっと迷ったんだけど、こんな事やってます的な意味でアップしておきます。
（もしかしたら消去するかも…）
一応著作権は私にあるわけで、特に問題もないかなーということで。
これぐらいならちょっとかじれば誰でも書けるでしょ。

具体的な仕様については先日の日記をみてください。
念のため細かいことは説明を控えさせていただきます。

続きを読む

お仕事雑記。

InDesignCSのJavaScriptでEPSをばかばか作りながら、今後の展開について考えている。

今回の仕事については前回流用データからすんなりXMLが抜き出せて、かつ思ったよりも簡単にJavaScriptが書けたので、システム制作的にはそんなに負荷がなく進める事が出来ている。
コマの面付け自体も顧客から台割のエクセルがもらえれば、小一時間で終わるはず。
面付けするEPSファイルもいま作り終わったところ。
これぐらいならすんなり書けるようになった。

で、いま会社的に今後どうしようか、と相談されている。
ProDIXのような名の通ったプラグインを買うか、JavaScriptで気合いでカバーしていくか。
弊社の場合はっきりいって弱小企業なのでProDIXの出費は正直痛いところ。
業務的にもカタログなんて年一回もやらないし、やったとして今回のようなコマ作成の業務が関の山の状態。
まぁこれは今後営業が仕事をとってくるかどうかで大きく左右されるところだとは思うけど。
この手の業務をたくさんとってくる方針なら、いざというときのためにProDIXに限らずその手のプラグインなどを購入しておくべきだし、今回のような規模の単発仕事が隔月程度で動くならJavaScriptとFileMakerなんかの連携でいけないこともないと思う。

なんせJavaScript書けるのが私だけなので、決定権は私にゆだねられていたりするわけで、ちょっと悩み中。
私がいなくなったら頓挫するようなフローを作るべきではないと思うんだけどね、ホントは。

DTP全般。

いまやっている仕事の昨年度データと今年度用のフォーマットの文字組がひどい。
なんで本文の行末を揃えない？
行末そろえるのは組版の常識だと思うのは私の勘違いですか〜？

原因はね、本文中の文字すべてが文字前後のアキ量ベタなのよ。
詰めたいなら文字アキ量設定で作ればいいでしょうに。
もう気になってしょうがない。
素人ですか？

ま、うちの会社でもそんなの気にするのって私を含め数人しかいないと思うけどさ。
でもそういうところがなっていないと本として汚いんだよね。

どうやらなんちゃってデザイナーの増加に伴い、なんちゃってオペレーターも増加した模様。
というか、そこら辺適当なDTPオペレーターなんて存在価値あるのか？
時間＞品質、な業界だからしかたないんだろうけど。

XML＆自動組版。

先日の日記で書いた改版のお仕事のコマ作成の大体の仕様が決まった。

やることを順序立てて書くと
●コマフォーマットを開く
●XMLデータを読み込み、写真をセンター配置
●表組部分の列数に応じて幅を変更
●オーバーフローを解消（表組と文章はとりあえず除外）
●表組のフレームのサイズを変更
●上記にあわせてその下にあるフレームの位置を変更
●各指定色に変更
●コマをコピー
●台紙にペーストして面付け
こんな感じ。

とりあえず現状は色を変えるあたりまでJavaScriptで書けた。
結構穴があるけど、納品まで時間がないからしかたないか。
むしろ「こんなの私にできるのかよ？」と思っていたわりに、結構形にできてラッキーなぐらい。
正味二日でなんとか書けた。
これというのも各サイトで情報を公開されている方々やいろいろアドバイスをくださる方々のおかげだと、感謝感謝です。

問題は昨年Illustratorで作成されたコマが100コマ近くあって、それは手で流さないといけないから、ちょっと憂鬱。
表組部分も結合とかたくさんしないとできなそうなので、自動でどうこうはちょっとやりづらいかなぁ。
やるとしたら、タブ区切りにして流し込んでから表組の設定を変えるぐらいしか思いつかないな。

あとは昨年のデータから抜き出したXMLデータを今回用に整形するだけだったりするんだけど、そこは上司にお願いしているので、無事できることを祈るばかり(^^;

XML＆自動組版。

えっと、XMLXMLと騒いでいたので罰が当たったのか、いきなりお仕事がきちゃいました（汗）
いや〜ん。

XMLでタグつけされた過去データを元に新フォーマットに流し込むというお仕事。
納期は1週間ちょっと。
とりあえず本気モードでイジリ倒しています(^^;
表組の処理が難しいなぁ。
自動的に行と列が増えるのはいいんだけど、JavaScriptかなんかで手を加えてあげる必要があるね、これ。
例によって古籏さんのサイトにかぶりつき、ホントお世話になります。

まぁ打ち合わせの時点で大体のフローはできたので、それを形にできればわりとうまくいくのではないか？と楽観的観測を持っていたり。

大変だ！と騒いでいても仕事が進むわけでもない。
なら置かれた状況を楽しむしかないよね〜。

InDesignでJavaScript。

先日の日記の案件について、いろいろお試し中。
今日のノルマは流し込んだテキストをオーバーフローがなくなるまで長体処理するというもの。
while文でイケそう。

もうなんでもかんでも手当たり次第select()してから処理をかけてみる仕様だったりする。
いい仕様かはわからないけど、ね。

あと今号と前号のツメの数が同じ場合そのまま使おうと思ったけれど長体を戻したりオブジェクトの属性を変えたりスタイル変えたり色々手間なので、ざくっと消しちゃう仕様に変更しようかと。

あとは20版分のつながったテキストからどうやって処理するべき版を判別させるか、という問題が残っている。
テキストにキーを入れておいて判別させるのが一番シンプルなんだろうか。

3月末には業務として稼働するようだから、それまでに完成させなければ。

あ、XMLは毎号ツメの数が違ったりすることを考えて、今回は導入を見送りました。
というか、そこまで手を伸ばすと私の頭では収集がつかなそう（苦笑）

InDesignでJavaScript。

「その00」ってのは完成したスクリプトを配布するときだけにしようと決めた。

で、本題。
moveの挙動がよくわからんです。

---

docObj = app.activeDocument;
imgObj = docObj.textFrames.add();
imgObj.contentType = ContentType.graphicType;
imgObj.place("System:Users:hoge:Desktop:age.eps");
imgObj.fit(FitOptions.frameToContent);
imgObj.move("to",["5cm","10cm"]);

---

と

---

var mydocument = app.activeDocument;
var myobj = mydocument.pages[0].textFrames[0];
myobj.move("to",["5cm","10cm"]);

---

だと全然違う結果になる。
前者はtoの意味するところのページに対する絶対値で移動するんだけど、後者はtoなのに相対値で移動してしまう。
どちらも親属性はpageだから同じ挙動になってくれないと困るんだけど。
たぶん私が致命的な勘違いをしている気もするのだが…。

いちいちvisibleBoundsで計算するのも面倒なんだよね。
そういえばvisibleBoundsとgeometricBoundsって取得できる数値は細かいところで違うみたい。
visibleBoundsのほうが実際の座標値に近いような気がする。
プロパティを書き出してみると下記のような感じ。

---

geometricBounds:[80.0014282239408,-4.00192029454953,222.004021625702,35.9576405537591],
visibleBounds:[80.0026388888889,-3.99866666666666,222.000916666667,35.9571666666667],

---

XML＆自動組版。

InDesign関連のプログラムをしようかと、ネット探索中。

4月ぐらいにQuarkXpress4.1→InDesignCS2に移行する某フリーペーパーの自動組版について、アレコレ検討中。

まず現状決まっていることを洗い出してみる。
●制作環境はWindowsXPのInDesignCS2、OTF環境
●20拠点分の表紙とインデックスを作成
●ベースは顧客から支給
●基本となるベースは各版共通だが、版ごとにツメ部分のデザインが変わる（横位置のツメに縦に帯がつく場合がある）
●毎号ツメの数が違い、もちろん版ごとでも違う。また個数によってツメの帯のサイズが変動する
●支給されるテキストデータはエクセルで、20版分が1つのシートに縦に並んでいる。また組版に必要のない要素も多数含まれている（システムで抜き出しているから？）
●毎号イラストが変わる。貼り込まれる位置はツメのサイズによって変動する
今のところ思いつくのはこんな感じかな。

続きを読む