2009/11/29

コピペじゃなくてムーブ

通常indesignで組む前に元データを整形する。
学術書籍の場合、章タイトル→執筆者→本文→文献→本文で使用する図表のタイトル・説明、という形に元データがなっていることが多い。
整形の際に、本文中の図表を挿入する箇所(元データの出力紙に指定されている)に、図表のタイトル・説明をカットアンドペーストして移動させているのだが、それが面倒になってきた。図表10点ぐらいのタイトル・説明をいちいちカットアンドペーストする気にもならんというか。

てことで挿入箇所に制御文字列を書き、挿入すべき文字列をタグで囲むことで挿入箇所へ文字列を移動させるスクリプトを考えていたのだが、こうゆう場合、文字列をcontentsで拾うより、moveメソッドを使うのがまっとうなんだな、と(マニュアル読み直した成果)。moveで移動することで、元の文字列の属性も保たれるし。

いやぁ、勉強不足だな、ほんとに。

表の自動調整

大分前に表の自動調整のスクリプトを書いたのだが、文字数×フォントサイズでセルの幅を算出していて、欧文フォントのみの表の場合だとその算出方法では幅が合わないので修正。

考え方としては列ごとに各セルを調べて、文字列の最初から最後の幅の最大値を列幅とするもの。

//表のあるフレームを選択
var myTable = app.activeDocument.selection[0].tables[0];
var left, right, max, width;

//列ごとに各セルを調べる
for(var i=0; i<myTable.columns.length; i++) {
max = 0;//文字列の幅の最大値、列ごとに初期化
for(var j=0; j<myTable.columns[i].cells.length; j++) {
var myCell = myTable.columns[i].cells[j];
left = myCell.insertionPoints[0].horizontalOffset;//文字列の左端の位置
right = myCell.insertionPoints[-1].horizontalOffset;//文字列の右端の位置
width = right - left + myCell.leftInset + myCell.rightInset;//セルのマージンも計算に入れとく
if(max<width) max = width;
}
myTable.columns[i].width = max + margin;
}


という感じで列幅が文字列の幅にぴったり合う。
が、文字列が二行になってる場合とか、オーバーフローしてる時とかのケースも考える必要があるな。。。

2009/11/22

今さらながら

InDesign CS3 スクリプティング ガイド JS.pdf
InDesign CS3 スクリプティング チュートリアル.pdf
を熟読中。今まではやりたいことだけに絞って、「オブジェクトモデルを調べる→ネットで調査→スクリプト書く」、という流れだったのだが、前回のエントリのような基本的な部分がわかっていない、というのはまずいな、と。

てことで改めて読み直すと大分頭がすっきりしてきた。
マスターページ辺りの制御はまったくしていなかったのでメモっておこう。

//マスターページ(名前はA-マスター)の取得
var myMaster = app.activeDocument.masterSpreads.item("A-マスター");

//マスターページをアクティブなページに適用
var myPage = app.activeDocument.activePage;
myPage.appliedMaster = myMaster;

//マスターページのアイテム(ラベル設定済み)のオーバーライド
myMaster.textFrames.item("スクリプトラベルの名前").override(myPage);

2009/11/15

スピードと量

辞書系書籍の制作。
項目数が3000近くあって、頁数は500弱ぐらい。
処理的には単純で反復作業が多いため、個々の処理についてスクリプトで対応しようと考えており、実際スクリプトは問題なく作れるのだが、いざ走らせてみると時間がかかる。

まぁスクリプト一晩走らせといて次の日続きを、というのも手なんだが、なんせ時間がない・・・。

試みに、1ページず追加してテキストフレームを置いて連結させて、というスクリプトで、コンソールでログ吐き出しながら、500ページ分処理すると、ページが進むにつれてどんどん遅くなっていく。
コードの書き方に問題があるとは思いたくはないw。スピードを上げるやり方ってのがあるんだろうか。
もしくは、分散処理を考えるべきなのか(500×1ではなく100×5とか)。

そもそもindesignでは大規模文書には向いていないのか(FrameMakerという手もある)。
結局今回は人力w。

後、躓いたのがテキスト変数へのアクセス。
あ・か・さ・た・な・・・というツメを作るのにランニングヘッド(段落スタイル)でテキスト変数を使うのだが、スクリプトでそのテキスト変数にアクセスする仕方がわからない。SpecialCharacterにはあるんだが、個々の変数にどうアクセスするのか、っつー。
結局、ライブラリにテキスト変数入りのテキストフレーム作って保存しといて、それをコピーという手で解決。んー、アクセスできるのかな?

2009/10/21

XML

間が空いた。
論文等を組む場合。ほぼWORD入稿。てことでWORDの書式を生かしてIndesignで流し込む、ていう方法でやっているのだが、WORD上での太字とか斜体、上付き、下付きが流し込む際にはがれるケースがあるのが鬱陶しい。

正確には上付き、下付きはOKで、日本語の斜体、太字がはがれることが多いようだ。原稿とモニタのつきあわせはなるたけ避けたい。てことでその書式を保持できる方法を調べなきゃなぁ。

論文の場合、書誌情報が必要なことがあるから、WORD原稿に簡易タグ→XML化→(自動?)組版→書誌情報抜き出し、というのが楽かな、と思ったが、結局ネックなのが簡易タグ。簡易タグ打ち込むより、Indesign上でCMD+1とかでスタイル適用した方が早いんじゃないかと。で書誌情報抜き出しは段落スタイルあたりでJavascriptで。XMLは魅力ではあるのだが、タグを手動でつけるのならしんどそう。

WORDの書式が完成度が高くてそっからXML化するのならよさそうだが。

いずれにせよ、作業効率化、短縮化を図らないと、残業が増えるだけで良くないな。

2009/07/12

グループでの作業

自分はある程度スクリプトを理解しているのだが、部下もしくは同僚がそうでない場合どうするか、という問題。

どう考えたって、「手作業」VS「タグ付け+半自動化」での後者が圧倒的に処理速度が速い。では、スクリプトを理解してもらえるように勉強してもらうのがよいのか、というとこれも問題。
個人の学習意識の問題だからな・・・。
自分にしても、楽しいから独学で勉強したのであって、強要されていたら勉強したかどうか。

てことを考えると、スクリプトを誰にでも使えるようにUIを設定したり、エラー処理できるようにしておくとか改良しておく方が早いかな。
敷居の低いスクリプト作っとけば、ネットで公開とかも可能だろうし。現状のスクリプトでは公開できるレベルではないw

スクリプトで出来る作業は集約して、一括スクリプト処理しよう。頭を使う仕事に時間を使いたいわね。

2009/07/08

easily

最近1冊組んで、2冊修正。やはり細々したところで時間がかかる。

新たに組んだ分で言えば、余計な半角スペースの除去とか、マイナスとかハイフンを音引きに変換、文献リストの形式の統一、演算記号の前後をベタとか・・・。こういうのを修正していくのがしんどい。
ここらへんは、対話型のスクリプトを作って対応するしかないか。一括処理だと怖すぎなもので。どの本についてもこういう処理は必要になってくるわけだし。

修正分だと、二分ダーシとかの統一とか。ここもスクリプト処理かな。新規作成についてのスクリプトはある程度汎用性を持つように作り直したから、次は修正用スクリプトの見直しですね。

これから組む分について。文字データの修正をどのタイミングですべきか。前の会社では、初期は分担作業をしていて、図作成+原稿データの修正(原稿整理でのアカの修正)+データの構造化を別の人にやってもらっていたのだが、データの構造化が終わったワードのファイルに文字修正のマクロ(全角→半角とか、カンマ、ピリオド、括弧の統一ぐらい)を当てていた。ただ、後期はIndesignにデータを流し込んでからスクリプトで文字修正を行っていた。

将来的なことを考えると、流し込む前の構造化されたデータをある程度完全なものにしておきたい気もする。構造化されたデータには、表のデータ、図表のキャプション、図のファイル名、図の挿入箇所も全て記述されていて、組版以外にも流用できる形式になっていて、本文データも文字修正がなされていた方がいいような気がするこの頃。

ま、ほんとはワードじゃなくてプレーンなテキストファイルがいいんだけどな。作業フロー考えなきゃなー。

文字ベースの書籍でないケースはどうするか、という問題もあるし。グラフィックフレームの処理についても少し調べておかないと。ラスタ画像はIndesign上である程度縮小してもいいような気がするし。

2009/06/30

未来

将来性で考えると、Indesignで書籍を作ったままでいいのか、というお話。
近い将来では、とりあえずPDFにしとけば問題なさそう。が、今の会社の特殊性を考えると、PDFだけではビジネスにならない。結局e-learningの教材的なものを作れるか、てことと、どれだけ使いやすさをUPさせれるか、ということ。

Indesignからフラッシュへ、とかIndesignからWEBパブリッシングへ、という流れをふまえてCS4に色々機能が付加されたわけだが、どこらへんまでできるようになっているのかを調べておかなきゃなぁ。

2009/06/29

バグ?

よく使うスクリプトはショートカットを割り当てるのだが、そのショートカットの設定が消えることがある。
全ての設定が消えるのではなく、スクリプトだけ。

選択オブジェクトを次の頁、または前の頁へ、頁の同じ位置に移動させるスクリプトを多用していて(戻ってきた校正のアカ修正で図表がずれることが多い)、ショートカットを割り当てていたのだが、たまーにショートカットが効かないうという。。。

いちいち設定しなおすのは鬱だ。
設定ファイルを一時的に退避させとくしかなさそうだなぁ。
スクリプトフォルダにスクリプトを追加したときに設定が消えているような気がするが。

2009/06/26

そろそろ

関数をライブラリ化するとか、スクリプトをまとめておかなければ。
変数名も結構適当に使ってるしな・・・。

それとUIもしくはダイアログ使っても少し汎用性の高いスクリプトにしておこう。いちいちコード書くのも面倒になってきた。

今日やっていたのは、突き出しインデントのためのスクリプト。たぶんだけど、Indesignはフレームグリッドをはみ出すようなインデントを設定できない。今組んでる書籍は、横組みで、版面は45W×40Lで小口を5Wほど開けるというレイアウト。ただ、節と項の見出しについては、45Wのサイズで作る。つまり、小口側に見出しが飛び出してるということ。

一番楽に作るには・・・と考えると、フレームグリッドは40W×40Lにしておいて、節と項だけアンカーオブジェクトにしておく、というのが結論。ま、こうゆう場合に節でスクリプト一つ、項で一つ、と分けるのではなく、スクリプトは一つで、ダイアログで両方に対応できるようにしておくといいかな、と。

UI設定するのが面倒なだけなのだが。

2009/06/23

再現可能性

というか将来性のお話。前回の続きでもあるのだが、初校作成のための自動化ってのはほぼ達成できて、これからは再校作成(=初校の修正)のことも考えなければ。

例えば、見出しのスタイルをIndesign上で図形を作ってアンカー化したとする。初校修正時に、その図形の一括修正のアカが入ったとする。そうしたときに、チマチマ一つずつ修正するのはやってられないから、おそらく、スクリプトで条件に合う図形を抽出(例えば、Rectangleで線幅2ミリとか、塗りがK20とか)して修正するはず。まぁそれでも別に問題ないのだが、それだったら初校作成時のスクリプトでその図形にラベルを指定しておけば後から一括修正するときに楽だ、ていうお話。

と考えていくと、ラベルよりもオブジェクトスタイルをもっと活用すべきと気付いた。そうすれば色の一括変更もスクリプト経由でなく行えるし。
その手の図形とか図のキャプションだとか、本文のフレームグリッド上のオブジェクトについてはいったんオブジェクトスタイルを適用する、という方向で行くのがいいのかもなー、と思ったり。

ボリュームの問題。
今まではせいぜい多くて300ページぐらいの書籍。Indesignを使い始めた頃は、各章ごとにドキュメント作って、ブックでまとめる、とやっていたのだが、逆に面倒になってきたので(スタイルを同期させたりブック全体にわたっての検索置換が面倒だったり)、せいぜい前付、本文、後付ぐらいでドキュメントを分けるようにしていた。ノンブル的に考えると前付は別、てのがほぼ100%だったので、3部構成がちょうどよかったわけだ。

で転職後。1000ページぐらいの本も組むことになると、さすがに本文を一つのドキュメントって訳には行かないかなぁ、と。マシンのパワー次第なのだろうか。
ケース次第で、各章ごとにドキュメントを作る方法を採らざるを得ないだろうから、予め準備しておかないと。

2009/06/21

再利用

将来的に改訂版の可能性がある場合、それを見越して組版しておいた方がよい。
例えば、節の見出しをデザイン的見地から、イラレで作ってアンカーオブジェクト化したり、もしくはIndesign上で図形と組み合わせてアンカーオブジェクト化しておくと、改訂版作成の時、本文からテキストデータを取り出したいときに問題が起きる。
つまり節の見出しはIndesign上では図形オブジェクトとされているので文字データとして取り出せない。
同様に、Indesignの目次機能を使う時に、データが取り出せない。

そういうことを考えると、段落スタイルの段落境界線を駆使して節などの見出しのスタイルを作るか、もしくは背後にスタイル用の図形をアンカーオブジェクトとして配置しておいた方がいいのかも。

ただ、問題があって、アンカーオブジェクトとして配置してアンカーオブジェクトの設定をカスタムにしておくと、本文よりも前面に配置されてしまうんだわな。インラインで配置すればいいのかもしれないが、細かく設定できないし。むむむ。

2009/06/01

画像読み込みスクリプト

原稿データの該当箇所にファイル名を入力。ファイルは特定のフォルダにまとめておく。
フォルダを指定してファイルを読み込むスクリプトを作っておいて、ファイルオブジェクトを配列に入れて、ファイル名と一致したら、アンカーオブジェクトとしてファイルを配置しておく。

配置が終了したら、アンカーオブジェクトを解除して、レイアウトを調整する。

その部分がちょっと面倒だが、いちいちBridgeとかから放り込むよりかは、はるかに楽だ。アンカー化してあるおかげで、図の挿入箇所を原稿みて確認する必要もあまりないし。

準備用スクリプト+段落スタイルの適用スクリプト+画像読み込みスクリプトの三段階で作業しているのだが、一つにまとめてもいいかもな。

効率化

転職して2本目の組版。

図版の点数が大幅に増えたことに対応しなくてはいけない。
前の会社では、だいたい1冊辺り、200ページ弱で図版はせいぜい50点ほど。しかもスキャンして文字を打ち込み直すぐらいのものだったのだが、今の会社では、ページ数が400以上、そして図版点数も200点以上がざらにありそうとのこと。

今回は、今のところ8割入稿で、約300ページ、図版約250点というボリューム。250点の図版をいちいち手作業でドラッグ&ドロップするのもしんどいので、スクリプトで対応することにした。

それ以前に、図版をトレースするのがしんどかったが・・・。最初はマウスでちまちまやっていたが、これではかなわんということで、急遽ペンタブレットを導入。それで大分楽にはなったが何せ時間がかかる・・・。
こればっかしは、慣れの問題で、スクリプトというか自動化できないので地道に続けるしかないな、と諦める。

図版作成後は、原稿データを構造化(スクリプト適用のためにタグ付け)して、本文にデータを流し込み、スクリプト処理。その後、図版流し込み用のスクリプト適用して、手動で調整。

図版作成で2週間弱、データの構造化で2日、組版で2日。自動化万歳!である。

会社の作業モニタが自宅より小さいのが若干ストレスになる。ここらへんは交渉しないと。。

2009/04/26

フレームグリッド

テキストフレームの種類が区別できないと書いたのだが、間違いのようだ。
テキストフレームのプロパティのgridDataからフレームグリッドの設定値が取得できる。後で調べとこ。

2009/03/22

illustratorのプラクティス

てことで、今更ながら初歩から勉強し直してるんだが、いやぁ、どんだけ時間を無駄にしていたのか、てくらい基本テクニックがなっていない。script使うまでもなく、人力でもっと効率化というか短縮化できるじゃないか!

てことはindesignでもまだまだ人力部分で効率化がはかれる部分があるはずってことだ。まぁ確かにそれほどキーボードショートカットを駆使はしてないからな。

おそらく、仕事では超初歩的なメディカル・イラストを描かなきゃいけないはずだから、ほんとトレス術を修得しておかないとな。

new

月曜から新たな挑戦。ていうほどのものでもないが。

今までは文字数多めの人文系の学術書籍であったが、これからは画像多めの医学書籍。チャレンジである。どちらかというと、indesignのscriptよりも、illustratorのscriptのほうが重要になってきそうな感じ。実際のところは、原始的な方法―ペンツールでのトレース―が肝っぽいけど。ライブトレースをかまして、パスを修正するよりもペンツールでのトレースの方が速いようだ(熟練者の場合)。つまり、それぐらいになるまでスキルを高めなきゃいけない、ということで、毎日夜練だな。

indesignのscriptで言えば、画像の配置も自動化するようにしたい。画像を特定のフォルダに集めておいて、そこをscriptで監視する、と。その場合、画像のファイル名も規則的につけるようにしないといけない。

何にせよ、始まってみないとわからない訳で。頑張ろう。

2009/03/10

グリッドの変更

判型、文字数がだいたいおきまりになってる今の会社。まぁ学術書籍ってそんなもんだ。そのおかげで仕事はすごく楽なのだが、もちろん賃金も低い、と。

でもたまに初校出してから、文字数変更、てのがある。
マスターページをうまく作ってたら、マスター上のフレームグリッドのサイズの変更で済みそうなのだが、どうもややこしいマスターページの設定にしていたせいで、ちまちま1ページずつサイズ変更していかなきゃいけない。今日の場合だと、35字×30行を28字×30行に変更、小口アキとかそんなの。

でフレームグリッドの文字数変更スクリプトを作ればいいか、と思っていたら、スクリプト上ではテキストフレームとフレームグリッドが同じ扱い。なのでテキストフレーム自体のサイズを変更するスクリプトで対応。その際、奇数頁、偶数頁で分岐させといて小口アキを実現させる、と。

そもそも、マスターページも少し工夫して作っておかないとな。

2009/03/07

CS3

やっとCS3に移行。
印刷会社からの要請によって。どうもCS2はバグが多かったみたいだ。PDF化した際に、区切り文字が半角1文字と認識されてしまったりとか云々。

問題は、CS2で使っていたスクリプト。結構な量になってきてたし、もはやスクリプトなしでは、効率よく作業できないレベルに来てしまっていたので不安だったのだが、そのまま使えるようである。一安心。

CS3からは検索置換が強化(正規表現、字形検索)されてたり、テキスト変数という機能であったり、なかなか使い勝手がよくなっているとおもう。ただ、索引パネルの挙動だけは頂けない。項目を編集したら、毎回パネルの項目が折り畳まれるので、かなり作業しにくい状況。フォーラムのぞいてみよう。

CS3ではスクリプトのリファレンスがなくなったかわりに、Extended Script Editor(であってたか)がオブジェクトモデルを読み込んで、インテリセンスぽい動きをしてくれるし、それをヘルプで読める。Editor開いて、help開いて、indesignも開いて、となるとやっぱモニタ2台ないときついかなぁ。次の会社のモニタって24インチだったかな? 今より小さくなるのはストレスがたまりそう。

CS3の索引スクリプトでのメモ。バグではないかとおもってるんだが……。
topics.add(name, sortorder)で索引項目を追加できるのだが、nameが同じでsortorderが違う項目の設定がうまくいかない。sortorderが書き換えられてしまうようなのだ。も少し深く検証しよう。まぁCS2のスクリプトをそのまま使えばいい、つー話ではあるが。