将来性で考えると、Indesignで書籍を作ったままでいいのか、というお話。
近い将来では、とりあえずPDFにしとけば問題なさそう。が、今の会社の特殊性を考えると、PDFだけではビジネスにならない。結局e-learningの教材的なものを作れるか、てことと、どれだけ使いやすさをUPさせれるか、ということ。
Indesignからフラッシュへ、とかIndesignからWEBパブリッシングへ、という流れをふまえてCS4に色々機能が付加されたわけだが、どこらへんまでできるようになっているのかを調べておかなきゃなぁ。
2009/06/30
2009/06/29
バグ?
よく使うスクリプトはショートカットを割り当てるのだが、そのショートカットの設定が消えることがある。
全ての設定が消えるのではなく、スクリプトだけ。
選択オブジェクトを次の頁、または前の頁へ、頁の同じ位置に移動させるスクリプトを多用していて(戻ってきた校正のアカ修正で図表がずれることが多い)、ショートカットを割り当てていたのだが、たまーにショートカットが効かないうという。。。
いちいち設定しなおすのは鬱だ。
設定ファイルを一時的に退避させとくしかなさそうだなぁ。
スクリプトフォルダにスクリプトを追加したときに設定が消えているような気がするが。
全ての設定が消えるのではなく、スクリプトだけ。
選択オブジェクトを次の頁、または前の頁へ、頁の同じ位置に移動させるスクリプトを多用していて(戻ってきた校正のアカ修正で図表がずれることが多い)、ショートカットを割り当てていたのだが、たまーにショートカットが効かないうという。。。
いちいち設定しなおすのは鬱だ。
設定ファイルを一時的に退避させとくしかなさそうだなぁ。
スクリプトフォルダにスクリプトを追加したときに設定が消えているような気がするが。
2009/06/26
そろそろ
関数をライブラリ化するとか、スクリプトをまとめておかなければ。
変数名も結構適当に使ってるしな・・・。
それとUIもしくはダイアログ使っても少し汎用性の高いスクリプトにしておこう。いちいちコード書くのも面倒になってきた。
今日やっていたのは、突き出しインデントのためのスクリプト。たぶんだけど、Indesignはフレームグリッドをはみ出すようなインデントを設定できない。今組んでる書籍は、横組みで、版面は45W×40Lで小口を5Wほど開けるというレイアウト。ただ、節と項の見出しについては、45Wのサイズで作る。つまり、小口側に見出しが飛び出してるということ。
一番楽に作るには・・・と考えると、フレームグリッドは40W×40Lにしておいて、節と項だけアンカーオブジェクトにしておく、というのが結論。ま、こうゆう場合に節でスクリプト一つ、項で一つ、と分けるのではなく、スクリプトは一つで、ダイアログで両方に対応できるようにしておくといいかな、と。
UI設定するのが面倒なだけなのだが。
変数名も結構適当に使ってるしな・・・。
それとUIもしくはダイアログ使っても少し汎用性の高いスクリプトにしておこう。いちいちコード書くのも面倒になってきた。
今日やっていたのは、突き出しインデントのためのスクリプト。たぶんだけど、Indesignはフレームグリッドをはみ出すようなインデントを設定できない。今組んでる書籍は、横組みで、版面は45W×40Lで小口を5Wほど開けるというレイアウト。ただ、節と項の見出しについては、45Wのサイズで作る。つまり、小口側に見出しが飛び出してるということ。
一番楽に作るには・・・と考えると、フレームグリッドは40W×40Lにしておいて、節と項だけアンカーオブジェクトにしておく、というのが結論。ま、こうゆう場合に節でスクリプト一つ、項で一つ、と分けるのではなく、スクリプトは一つで、ダイアログで両方に対応できるようにしておくといいかな、と。
UI設定するのが面倒なだけなのだが。
2009/06/23
再現可能性
というか将来性のお話。前回の続きでもあるのだが、初校作成のための自動化ってのはほぼ達成できて、これからは再校作成(=初校の修正)のことも考えなければ。
例えば、見出しのスタイルをIndesign上で図形を作ってアンカー化したとする。初校修正時に、その図形の一括修正のアカが入ったとする。そうしたときに、チマチマ一つずつ修正するのはやってられないから、おそらく、スクリプトで条件に合う図形を抽出(例えば、Rectangleで線幅2ミリとか、塗りがK20とか)して修正するはず。まぁそれでも別に問題ないのだが、それだったら初校作成時のスクリプトでその図形にラベルを指定しておけば後から一括修正するときに楽だ、ていうお話。
と考えていくと、ラベルよりもオブジェクトスタイルをもっと活用すべきと気付いた。そうすれば色の一括変更もスクリプト経由でなく行えるし。
その手の図形とか図のキャプションだとか、本文のフレームグリッド上のオブジェクトについてはいったんオブジェクトスタイルを適用する、という方向で行くのがいいのかもなー、と思ったり。
ボリュームの問題。
今まではせいぜい多くて300ページぐらいの書籍。Indesignを使い始めた頃は、各章ごとにドキュメント作って、ブックでまとめる、とやっていたのだが、逆に面倒になってきたので(スタイルを同期させたりブック全体にわたっての検索置換が面倒だったり)、せいぜい前付、本文、後付ぐらいでドキュメントを分けるようにしていた。ノンブル的に考えると前付は別、てのがほぼ100%だったので、3部構成がちょうどよかったわけだ。
で転職後。1000ページぐらいの本も組むことになると、さすがに本文を一つのドキュメントって訳には行かないかなぁ、と。マシンのパワー次第なのだろうか。
ケース次第で、各章ごとにドキュメントを作る方法を採らざるを得ないだろうから、予め準備しておかないと。
例えば、見出しのスタイルをIndesign上で図形を作ってアンカー化したとする。初校修正時に、その図形の一括修正のアカが入ったとする。そうしたときに、チマチマ一つずつ修正するのはやってられないから、おそらく、スクリプトで条件に合う図形を抽出(例えば、Rectangleで線幅2ミリとか、塗りがK20とか)して修正するはず。まぁそれでも別に問題ないのだが、それだったら初校作成時のスクリプトでその図形にラベルを指定しておけば後から一括修正するときに楽だ、ていうお話。
と考えていくと、ラベルよりもオブジェクトスタイルをもっと活用すべきと気付いた。そうすれば色の一括変更もスクリプト経由でなく行えるし。
その手の図形とか図のキャプションだとか、本文のフレームグリッド上のオブジェクトについてはいったんオブジェクトスタイルを適用する、という方向で行くのがいいのかもなー、と思ったり。
ボリュームの問題。
今まではせいぜい多くて300ページぐらいの書籍。Indesignを使い始めた頃は、各章ごとにドキュメント作って、ブックでまとめる、とやっていたのだが、逆に面倒になってきたので(スタイルを同期させたりブック全体にわたっての検索置換が面倒だったり)、せいぜい前付、本文、後付ぐらいでドキュメントを分けるようにしていた。ノンブル的に考えると前付は別、てのがほぼ100%だったので、3部構成がちょうどよかったわけだ。
で転職後。1000ページぐらいの本も組むことになると、さすがに本文を一つのドキュメントって訳には行かないかなぁ、と。マシンのパワー次第なのだろうか。
ケース次第で、各章ごとにドキュメントを作る方法を採らざるを得ないだろうから、予め準備しておかないと。
2009/06/21
再利用
将来的に改訂版の可能性がある場合、それを見越して組版しておいた方がよい。
例えば、節の見出しをデザイン的見地から、イラレで作ってアンカーオブジェクト化したり、もしくはIndesign上で図形と組み合わせてアンカーオブジェクト化しておくと、改訂版作成の時、本文からテキストデータを取り出したいときに問題が起きる。
つまり節の見出しはIndesign上では図形オブジェクトとされているので文字データとして取り出せない。
同様に、Indesignの目次機能を使う時に、データが取り出せない。
そういうことを考えると、段落スタイルの段落境界線を駆使して節などの見出しのスタイルを作るか、もしくは背後にスタイル用の図形をアンカーオブジェクトとして配置しておいた方がいいのかも。
ただ、問題があって、アンカーオブジェクトとして配置してアンカーオブジェクトの設定をカスタムにしておくと、本文よりも前面に配置されてしまうんだわな。インラインで配置すればいいのかもしれないが、細かく設定できないし。むむむ。
例えば、節の見出しをデザイン的見地から、イラレで作ってアンカーオブジェクト化したり、もしくはIndesign上で図形と組み合わせてアンカーオブジェクト化しておくと、改訂版作成の時、本文からテキストデータを取り出したいときに問題が起きる。
つまり節の見出しはIndesign上では図形オブジェクトとされているので文字データとして取り出せない。
同様に、Indesignの目次機能を使う時に、データが取り出せない。
そういうことを考えると、段落スタイルの段落境界線を駆使して節などの見出しのスタイルを作るか、もしくは背後にスタイル用の図形をアンカーオブジェクトとして配置しておいた方がいいのかも。
ただ、問題があって、アンカーオブジェクトとして配置してアンカーオブジェクトの設定をカスタムにしておくと、本文よりも前面に配置されてしまうんだわな。インラインで配置すればいいのかもしれないが、細かく設定できないし。むむむ。
2009/06/01
画像読み込みスクリプト
原稿データの該当箇所にファイル名を入力。ファイルは特定のフォルダにまとめておく。
フォルダを指定してファイルを読み込むスクリプトを作っておいて、ファイルオブジェクトを配列に入れて、ファイル名と一致したら、アンカーオブジェクトとしてファイルを配置しておく。
配置が終了したら、アンカーオブジェクトを解除して、レイアウトを調整する。
その部分がちょっと面倒だが、いちいちBridgeとかから放り込むよりかは、はるかに楽だ。アンカー化してあるおかげで、図の挿入箇所を原稿みて確認する必要もあまりないし。
準備用スクリプト+段落スタイルの適用スクリプト+画像読み込みスクリプトの三段階で作業しているのだが、一つにまとめてもいいかもな。
フォルダを指定してファイルを読み込むスクリプトを作っておいて、ファイルオブジェクトを配列に入れて、ファイル名と一致したら、アンカーオブジェクトとしてファイルを配置しておく。
配置が終了したら、アンカーオブジェクトを解除して、レイアウトを調整する。
その部分がちょっと面倒だが、いちいちBridgeとかから放り込むよりかは、はるかに楽だ。アンカー化してあるおかげで、図の挿入箇所を原稿みて確認する必要もあまりないし。
準備用スクリプト+段落スタイルの適用スクリプト+画像読み込みスクリプトの三段階で作業しているのだが、一つにまとめてもいいかもな。
効率化
転職して2本目の組版。
図版の点数が大幅に増えたことに対応しなくてはいけない。
前の会社では、だいたい1冊辺り、200ページ弱で図版はせいぜい50点ほど。しかもスキャンして文字を打ち込み直すぐらいのものだったのだが、今の会社では、ページ数が400以上、そして図版点数も200点以上がざらにありそうとのこと。
今回は、今のところ8割入稿で、約300ページ、図版約250点というボリューム。250点の図版をいちいち手作業でドラッグ&ドロップするのもしんどいので、スクリプトで対応することにした。
それ以前に、図版をトレースするのがしんどかったが・・・。最初はマウスでちまちまやっていたが、これではかなわんということで、急遽ペンタブレットを導入。それで大分楽にはなったが何せ時間がかかる・・・。
こればっかしは、慣れの問題で、スクリプトというか自動化できないので地道に続けるしかないな、と諦める。
図版作成後は、原稿データを構造化(スクリプト適用のためにタグ付け)して、本文にデータを流し込み、スクリプト処理。その後、図版流し込み用のスクリプト適用して、手動で調整。
図版作成で2週間弱、データの構造化で2日、組版で2日。自動化万歳!である。
会社の作業モニタが自宅より小さいのが若干ストレスになる。ここらへんは交渉しないと。。
図版の点数が大幅に増えたことに対応しなくてはいけない。
前の会社では、だいたい1冊辺り、200ページ弱で図版はせいぜい50点ほど。しかもスキャンして文字を打ち込み直すぐらいのものだったのだが、今の会社では、ページ数が400以上、そして図版点数も200点以上がざらにありそうとのこと。
今回は、今のところ8割入稿で、約300ページ、図版約250点というボリューム。250点の図版をいちいち手作業でドラッグ&ドロップするのもしんどいので、スクリプトで対応することにした。
それ以前に、図版をトレースするのがしんどかったが・・・。最初はマウスでちまちまやっていたが、これではかなわんということで、急遽ペンタブレットを導入。それで大分楽にはなったが何せ時間がかかる・・・。
こればっかしは、慣れの問題で、スクリプトというか自動化できないので地道に続けるしかないな、と諦める。
図版作成後は、原稿データを構造化(スクリプト適用のためにタグ付け)して、本文にデータを流し込み、スクリプト処理。その後、図版流し込み用のスクリプト適用して、手動で調整。
図版作成で2週間弱、データの構造化で2日、組版で2日。自動化万歳!である。
会社の作業モニタが自宅より小さいのが若干ストレスになる。ここらへんは交渉しないと。。
登録:
投稿 (Atom)