自社サイト再構築日記

編集と制作と最終形態

2012-01-03T16:32:00.000+09:00

制作から編集メインに異動した後も、自分が満足のいくクオリティを求めると結局自分で制作しているという現状。信頼できる制作会社があればよいのだが、納期と費用を考えると「今のところは」全部自分でやるのが手っ取り早い。動いている企画が少ないから。

全部自分でやるとなると、原稿のデータと制作のデータ、そして最終のデータってのがなかなか悩ましい。発注する側だったら、ワードで簡単に整理して「これでやってね」でおしまいだった。受注する立場だと、何のデータであれ結局indesignで組んでいって入稿用のPDF作って終了、と（2012年の現在では、PDFだけでは済まされない。そのデータ作ってさらに何か出来ないかっていいだす著者も増えてきているし、もちろん自分も興味がある）。

編集作業と制作作業が分断されていたのが、ひとりでやるとなると、制作しながら編集のことも考えたりすることになる。というかそれがメリットである。「ギリギリまで中途半端な形にしておく、すなわち保留状態を最大限引き伸す」という方法論をとりがち。雑誌はやったことないけど、きっとこうゆう感じで締切直前までがドタバタなのだろう。

ウェブ構築の作業の中で、「データベース」という概念がなんとなくわかったつもりになってくると、原稿ってのもこうゆう考え方で整理して作品というか何らかの情報集約物を作れないかと思ってしまったりする。いわゆるCMS（to indesign or latex）的な考え方。

アドビ的に言えば、indesignがCMS的なソフトウェアなんだろうけどね。ただ、indesign to html, epubなんて実際使えるものなの？

ここらへんは今年ちょっとよく考えてみよう。

2012

2012-01-03T16:00:00.000+09:00

仕事が忙しすぎて放置プレイだったウェブ作業にようやく戻って来れた。といっても正月中だけだろうけど。
さすがに半年も間が空くとデータベースの構造を忘れてしまってもう一度やり直しだ。集中してやりきってしまわないとこうゆう二度手間になってしまう。

ということで、ひとまずはfunctions.phpとwp_postsを見直さねば。
ワードプレスのバージョンも上がってしまったし。

そもそも

2011-05-07T03:41:00.000+09:00

カスタム投稿の機能を使った場合は、カスタム分類という仕組みを利用しないと、記事の分類ができないようだ。そして、タグも然り。分類やタグと使って書籍の情報をいろんな角度から見せようと思うと、テンプレートタグを駆使しないといけなくなってくるのだが、カスタム投稿だとそれがややこしい。

そもそも、書誌情報に関しては、素直に投稿を使い、それ以外のページをカスタム投稿にしたらいいのかもしれない、という結論に落ち着きそうな予感。。。

書誌情報とカバー画像

2011-05-04T17:03:00.000+09:00

「カスタム投稿」という機能を使うことは決定した。何点か投稿してデータベースの構造を探ってみることにした。

ワードプレスのデータベース名はwpでテーブルがいくつかある。現サイトでは書誌情報は1頁ごとのhtmlファイルである。すでにその情報はある程度構造化してデータベースに格納してある。ワードプレスでは、一点ごとに投稿という形で書誌情報を登録することになり、その除法が格納されるテーブルがwp_posts。今回、書誌情報の色々なスペック（定価、判型、ISBNなど）はカスタムフィールドという機能を使って投稿することとした。そのデータはwp_postmetaというテーブルに格納される。

wp_postsとwp_postmetaの関係はwp_postsのIDがwp_postmetaのpost_idと一致するということ。ちなみにwp_postsのIDはauto_incrementで、wp_postmetaのauto_incrementなキーはmeta_idとなる。

wp_postmetaの構造は結構シンプルで、同名のキーがあっても問題ないように考慮されているようだ。今回は、投稿タグやカテゴリには手を出していない。そっちはテーブルの関係は若干入り組んでいる。

第一段階として行ったことは、まずwp_postsに書籍名、目次、内容などのデータを挿入し、そのレコードのIDを取得して、それをwp_postmetaのpost_idの値にして書誌情報データを挿入。目次や内容の値は、アポストロフィー等の記号をちゃんとエスケープしておかないといけない。

次はカバー画像。投稿の中に挿入するよりも、「アイキャッチ画像」という機能を使った方がよさげである。そこで、同様に何点か挿入してからデータベースの動きを見る。

関係のあるテーブルは先ほどと同じで、wp_postsとwp_postmeta。
注目すべきwp_postsの項目は次の通り。

ID：auto_incrementな値。仮に画像投稿IDとしておく。
post_status：データの公開状況。親の状態を継承。
post_title：画像のタイトル。
post_name：投稿の名前。
post_parent：親子関係。この画像がアイキャッチ画像として使用される投稿のID。
post_type：投稿データのタイプ。attachmentでメディア。
post_mime_type：メディアのタイプ。
guid：投稿した画像の場所？

wp_postmetaでは3つのレコードが作られるようだ。

アイキャッチ画像と投稿の関係？

meta_id： auto_incrementな値。
post_id：上記wp_postsのpost_parentと同じ値。
meta_key："_thumbnail_id"という値。
meta_value：画像のID。上記wp_postsのID。

アイキャッチ画像の情報

meta_id：auto_incrementな値。
post_id：上記wp_postsのID。
meta_key："_wp_attachment_metadata"という値。
meta_value：画像の大きさなど配列で値が入っている。

アイキャッチ画像の場所？

meta_id：auto_incrementな値。
post_od：上記wp_postsのID。
meta_key："_wp_attached_file"という値。
meta_value：wp/content/uploads以下のディレクトリ名とファイル名。

ぐぐってみるが、関係のある情報がありそうでなかったりするものだ。全てを確かめるのも面倒になってきて、手探り状態でレコードを挿入していく。wp_postmetaの_wp_attachment_metadataのレコードは必要無さげだったので無視した。

とここまできてブラウザで確認。うまく行っているようではある。wp_postmetaのレコード数が肥大化していくのが気にはなっているのだが。。。

カスタム投稿

2011-05-01T16:58:00.000+09:00

どのように書誌情報を追加（投稿）するか？　カスタム投稿、という機能を使うと便利なようだ。とはいっても実質的には、wp_postsにデータは格納される。post_typeの値で通常の投稿か、カスタム投稿か、などなどが決まる。

カスタム投稿にあたっての情報はここ。

WordPressをカスタマイズするなら絶対覚えておきたい条件分岐やカスタム投稿タイプなどいろいろ
 カスタム分類を投稿一覧カラムに表示する

再構築に当たって

2011-05-01T13:24:00.003+09:00

まず再構築の目的。

更新作業の簡略化。
サイトの使いやすさの向上。
今までにないwサイト。

今までにないってのがどうゆうことなのかは自分でもよくわかっていない。（ｷﾘｯ
まぁ、面白くなっていればいいとしよう。

大まかな作業の流れとしては

今のサイトの情報（html）をデータベース化
CMSを使ってみるので、その勉強
CMSに1のデータベースを突っ込む
適当に調整w

ということを考えているんだけど、何か間違っているような気もするが、気にしない。今回はCMSとして無償のwordpressを使うことにする。

と実はここまでは半年ぐらい前には構想済みで、早速1の作業にとりかかったのだが、現サイトのhtmlがまったく構造化されておらず途方に暮れて放り出していたのだ。とはいえ、ここで止まっていても埒があかないから、正規表現勉強したり、rubyに手を出してみたりとか、文字コードをちょっと調べてみたりして、何とかデータベース化する手順はできた。

それが3月末。そして今2と3に取り組んでいる。数週間前は、データベースできたからそれをwpで読み込ませればいいだけだね、楽チンだぁ、とか思っていたんだけど、そう簡単な話ではないようだ。wpの機能をより生かすためには、投稿という形でデータベースに格納されていたほうがよいってのがわかったのがつい先ほど（つまりwp_postsというテーブルにレコードを挿入するだけでなく、メタ情報や、カテゴリのテーブルも更新しなければいけない）。色々と調べてくうちに、メモがわりにブログつけるかな、と思うようになって前回の投稿となった。

さて、話は変わるが、今回の再構築に当たってwp本を何冊かかったので現状でのインプレ。
まず、「PHPによるWordPressカスタマイズブック」。分類を文類を表記しているのはいただけないwと思いつつも知りたい情報が結構載っていて重宝している。特にデータベースに関する章は助かった。
「WordPress 3　サイト構築スタイルブック」。Notesという囲み記事に色々とtipsをのせているのだが、それを検索できないのがつらい。CMS的とサブタイトルがあるのなら、記事データをどのような形式にしてインポートするのかについて説明があるとよかった。
「WordPress　ポケットリファレンス」。一番最初に買った。これでWordPressの概要をつかんだ。でも同じ説明がなんども出てくるのは困った。

codexに大抵のことは載ってるけど、知りたいことは大概訳されていないんだな。。。

ということで

2011-05-01T12:53:00.001+09:00

大部が間が空いてしまった。その間に、制作部から編集部への異動があって、InDesignにどっぷりかかわることもなくなってしまい、原稿整理と校正と企画立案で忙しい状況である。

制作部にいたときから、自社サイトの更新作業も受け持つことになっていたのだが、これがなかなか面倒。まず、書籍の書誌情報の頁を作り、その書籍が属するカテゴリの頁を更新し、そしてトップ頁も更新する。さらに検索用のテキストファイルにデータを追加する。もし書籍のカテゴリが複数あれば、書誌情報の頁ももう一度作り（各頁にカテゴリ表示があるのだ）、カテゴリの頁を更新しなければいけない。
新刊が書店に出る数週間前にはサイト上に情報を出し始めるのだが、その段階では、「近日発行」というアイコンをつけ、書店に出るタイミングで、「新刊」というアイコンに変更する。同じタイミングで、カートを表示さて、サイトで購入できるようにする。もし、その書籍が改訂版であれば、古い情報は削除しなければいけない。
書誌情報の頁はhtmlファイルなのだが、そのファイル名は、カテゴリ用コード＋発行年月＋社内用書籍コードという三段構えになっている。カバーの画像は大と小があり、先ほどのファイル名を流用する。云々。。。。。

自社サイトが構築されたのは数年前で、担当者のA氏はもういない。ウェブの知識がほぼない後任者がA氏のやり方を引き継いで、何人か続き、自分にまわってきたわけだ。実際は、個人的にウェブ構築をやってみたかったので、名乗り上げたのだが。その時は、制作の仕事も落ちついてきており、DTPとウェブを絡めて何か面白いことができないか、と思っていたのだが、当てが外れて編集の仕事になってしまったとw。

編集の仕事が意外に手間取っていて、ウェブの方は引き継いだ通りのやり方で更新していたのだが、さすがに面倒くさくなってきて、この春ぐらいには何とかしようと思い立ったのである。で、再構築にあたってのメモをつけようと考えていたとき、このブログの存在を思い出したわけだ。

再確認。

2010-10-09T22:12:00.000+09:00

当たり前のことの再確認。
ユーザーはそれが欲しい瞬間に手に入ることを一番望んでいる、ということ。つか自分の経験だけど。
肝なのは、その即時生と入手するための簡略性。まぁアマゾンのワンクリックということだ。
先日、ネットラジオを聴いていて気になった曲があってすぐに検索してアマゾンJPにCDが、アマゾンUSにmp3が販売されていて今すぐ聴きたいと思ったからアマゾンUSでダウンロードしようと思ったらUS以外は無理ということでかなりがっくりした。
正直な話、これは現代人の病だということはわかっている。数年前であれば、次の日CD屋さんに買いに行こうかな、と思ったぐらい。でも悲しいかな、現代はいかに時間を無効化するか（うまい言い方が思いつかなかった）、という方向なのだ、ビジネス的に。そして一度それに慣れてしまうと戻れない自分がいる、と。

とまぁInDesignとはまったく関係のない話なんだが、電子書籍ってそういうことだ。読みたい物をすぐにそこで読めるかどうか、と。

google edition

2010-08-10T23:34:00.000+09:00

昨日行ってきたGoogleエディション説明会＠新大阪の個人的メモ。

Googleエディションの土台としてGoogleブックスがある。まずはそのGoogleブックスの説明から。

Googleブックスとは書籍の全てのページをデジタル画像化し、その画像からOCRをかけてテキストデータを拾いだす。そのテキストをもとに検索できるようにする。
ユーザー表示用にはページのデジタル画像を、検索にはテキストが使われるという仕組み。

書籍の提供（Google側からすると入手）方法には二通りある。
・パートナープログラム＝出版社から提供
・ライブラリプロジェクト＝図書館蔵書を提供（日本だと慶応大学など、アメリカ国外では著作権が切れたもののもい対象）

パートナープログラムに参加している出版社は全世界で3万社、200万タイトルが提供されている。アメリカではほぼ全ての出版社が参加している（例えばピアソン、シュプリンガーや、大学出版局など）。日本では400社強、4万冊といったところ。先日のブックフェア以降増加傾向にあるとのこと。

Googleブックスでは、表示できるページ（プレビュー）が1ヶ月20%に制限されている（のだが、参加者より80％ほど見えてしまっているとの苦情があり）。また、一部の内容はどんな場合にも表示されないようにしているとのこと。印刷、保存、コピーは不可だが、スクリーンショットでの保存はできる（OSレベルの機能は制限しようがないらしい）。出版社はいつでも書籍を追加・削除可能。

出版社からの書籍の提供方法は、PDFまたはEPUBか書籍本体1冊献本。Google側でそれをデジタル化する。書籍本体の場合は画像化→OCR。PDFの場合でも画像として扱い、OCRにかけるとのこと。また、OCR後のテキストデータの校正は一切に行われない。検索用に使用するという目的にはそれで十分な精度があるらしい。OCRエンジンは常にアップデートしており、定期的にOCRをかけ直して、テキストデータの精度を上げていくつもりらしい。

Googleブックスの使い方としてはGoogleブックスから直接検索する場合と、通常のGoogleの検索から飛んでくる場合があり、圧倒的に後者の方が多いらしい。画面設計として、左カラムが購入用や版元への外部リンク、メインカラムがページ画像となる。出版社には、詳細なデータやサマリーレポートがGoogleより書籍タイトルごとに提供される。

Googleエディションは簡単に言えば、Googleブックスはで20％しか見れないところを有料で100％すべて見せますよ、というもの。様々なデバイスでウェブブラウザを介して読む、という形態。一回購入すれば、どのデバイスでも読むことができる。ウェブブラウザ以外にiphoneアプリとしてブックリーダー的なものを提供していきたいと考えている。
ブラウザでの表示以外に、出版社側のオプションとして提供したPDFやEPUBといったファイルのダウンロードも可能。DRMをかけた形でダウンロードする。またHTML5では、ブラウザそのものにオフライン機能があるため、それを利用することもできる。
AmazonやiBookと違うのは、購入をどこでもできるようにするということ。例えば、Amazonからでも楽天ブックスからでも版元のサイトからでもGoogleブックスを購入できるようにする。

販売価格は版元の希望小売価格で、版元の取り分はその小売価格の51％以上。取り分の割合は提供タイトル数だったり提供方法（PDFか書籍本体か）だったりいろいろな条件で変わる様子。Googleエディションは電子書籍ということで、再販価格制度には縛られないものとGoogleは理解しており、販売価格は一定ではなく、市場動向により下がることもあり得るが、積極的にGoogle側でコントロールするつもりはない様子。

課金方法はGoogleチェックアウトが基本。自社サイトでの販売でもGoogleチェックアウトを利用できる。

開始時期は、まずアメリカでのこの夏。次にヨーロッパは秋。日本は年明けを予定している。

他には、
・クラウドブックスの場合、一つのアカウントで同時アクセスできるのではないか？という質問に対して、常識的に同時アクセス数が多い場合はスパムと見なし制限する、との回答。
・ファイルのダウンロードは回数制限を設定するかもしれない。
・スキャンできるのは今のところせいぜいA4サイズまで。大判は想定していない。また、紙質によっても対応できないケースがある。ただ、PDF提供ならその問題はない。
・プレビューの制限量は20％だが、もっと多くすることは出版社側でコントロールできる。統計的にはプレビュー量を多くした方がよく売れている。
・Google検索と一体化しているため、現在登録している200万タイトルのうち8〜9割は毎月誰かがプレビューを見ている。

他にも色々あったような気がするが。。。個人的には、プロモーションとしてGoogleブックスを使うのは全然ありかなぁ、と。
エディションまでいくとなると、同時アクセスあたりの問題が確実に解決されていないと提供しづらい。大学のゼミ等での少部数購入ってのが積み重なっているのが学術系テキストなわけで。
ユーザーとして考えると、iPadで専用アプリが出ればかなり使えそう。課金方法がどれくらいシンプルかつ安全かつ楽か、てのが気になる。
マーカー引いてそのデータを共有したりとかこのフレーズをツイッターで、みたいなソーシャルな機能はまったく想定していないようだ。そういう意味では、電子書籍推進者が一番批判しそうな形（テキストのコピーも出来ない、リフローも出来ない、紙の本の電子化以外の何ものでもない）の電子書籍と言える。
現在、プレビュー機能を紀伊国屋のBookwebに提供している模様。いずれブログパーツ的に一般ユーザーも使えるようになるのかもしれない（もちろん出版社の許可があってだとは思うが）。

app-book

2010-07-19T19:34:00.001+09:00

個人的なかなり大雑把なカテゴライズとして、紙の書籍の意味合いを保持したものの電子書籍をe-bookと呼び、変化したものを暫定的にapp-bookと呼ぶことにしよう。
前者の規格としては、PDFとかEPUBがあり、基本的には紙の書籍をある程度忠実に再現するものだ（EPUBだとリフローすることで見た目は変わるけど）。
後者は、アプリとして書籍の機能を拡張させたようなもの。中身の並べ替えや、抽出・検索が行えるようなもの、また電子体でなければできないような機能のあるものだ。例えば、iPhoneアプリで言えば、有名な大辞林やウィズダム英和辞典などがある。また、画像をレイヤーして説明するようなものがある（CD-ROM等でよくある）。

前者については、やはりPDFで十分であるように思える。頑張ってEPUBに手を出す気がしない。後者はいろんなやり方があると思う。iPhoneアプリを作ってしまうというパターン。またはウェブアプリを作るパターン。比較的教育コストが低くて、将来性もあるとしたらウェブアプリなのではないだろうか、ということで、php+mysqlの勉強を始めた。これが面白い。というか新たなプログラム言語を勉強するのは無条件に楽しいのだが、phpもjavascriptと同じぐらい手軽にプログラムを走らせることができるのがいい。
会社で出してる用語集のデータをデータベースにぶっこんで何か面白いものができないか模索中の今日この頃である。

iPad来た。

2010-06-19T19:45:00.000+09:00

やっとiPad届いた。アップルのオンラインストアで注文して2週間弱。
自分は16GBのWifiのみにしたのだが、やはり3Gにしておけばよかった…。1500円のプリペイドに。まぁ後の祭なので仕方があるまい。。。
さて、使用感。やはり画面は大きい。B5版の書籍のPDFと、A4変型判（学会誌に多い）のPDFをiPadで読んでみる。画面が縦ならズームしなくても1ページ問題なく読める。これは大きい（正直、モニタだといくら画面が大きくても読む気がしない）。そしてPCに詳しくない人にとっても抵抗があまりないように思える。実際、iPadの購入層というのは、ライト層が多いようだ。
コンテンツ供給側としては、iPad的なタブレット端末が爆発的に普及してもらいたいものだ。
規格の話で言えば、過去の出版物についてはPDFでOKなのは間違いない。これぐらいの画面サイズがデフォルトならば、リフローさせる必要性がないと思うし、そこで手間が発生するとPDF化が止まってしまう。
現在、巷の関心の対象は未来の規格。ePubなのか？　中間フォーマットてのも気になる。

iPad購入とな

2010-05-30T20:13:00.003+09:00

といっても、今日注文しただけで、まだ手元にはない。実機を店舗で触ってきたが、電子書籍はアリスしかなく、またPDFを読めるアプリもなかったのでなんとも言えないのだが、やはりあの大きさは魅力である。
まぁ予想するにB5版ぐらいまでのPDFだったら問題なく読めるんじゃないかと思う。だとしたらますますPDFでいいよな、て方向だ。InDesignから日本語の文字化け等を気にしながらePub書き出すよりも、PDFでいいんじゃね？と。確かにPDFも永続性が保証されているわけではないが、ePubも同じことで。というか、PDFだと楽だよね、てのもあるんだけど。
ここの記事で興味深いことが述べられている。
http://blog.drikin.com/2010/05/magastoreipad.html
アプリ化することと永続性。
とは言え、iPadを使ってみたら意見が変わるかもしれない。

window

2010-05-28T01:55:00.004+09:00

自分用メモ。
xmlでタグ付け等をした後、タグのつけ忘れがないかチェックする時、今までalertでログを表示していたのだが、最近やたらログの量が多くなり、画面に収まりきらなくて困っていた。
scriptUIを使うとスクロールバー付きのウインドウを作れる。

var log //チェック結果のログ
var myDialog = new Window("window", "タグのチェック", [0,0,200,200]);
myDialog.add("edittext", [10,10,190,150],log,{multiline:true});
var myButton = myDialog.add("button", [120,270,180,290], "ok", {name: "ok"});
myDialog.center();
myDialog.show();

myButton.onClick = function(){
myDialog.close();
}

しかし、scriptUIのリファレンスはどこにあるんだろ。estkのヘルプもなんか不十分だし。。。と思ったら、JavaScript Tools Guideに詳しく書いてありますね。

まだまだeBook

2010-05-21T21:47:00.002+09:00

来週にはiPad発売である。で状況がかなり変わるのかどうか。
で最近のAppleを見ていると、彼らの心境で右往左往するのは困るってわけで、appStore経由でのeBookてのはリスクがそれなりにありそうで、やはりとりあえずの結論としては、いかにHTMLで読みやすいものを作るかってところが目下の関心。
ページめくり機能とかは自然科学系の学術書ではどうでもいい話。教科書（参考書）であればいかに理解しやすいレイアウトか、構造かってことだなぁ。
HTMLを前提すると、XMLをベースにして、InDesignはレンダリングソフトウェア的に考えるのが至極まっとうではある。赤字校正もXMLで。

ebookその後

2010-04-28T22:59:00.002+09:00

多くのサイトが競ってeBookの未来予測を立てるこの頃。
まぁ自分もそのうちの一人（ってほどのことでもないが）なのだが、appleのFlash締め出しとかを見るとなかなか動きづらい（出版社側では）。それよりも単純にしておくべきなのは、制作データの社内管理。
印刷会社と出版社の関係では、欧米では出版社が完全に印刷データ（組版データ、製版データ等）を完全にコントロールしている模様だが、日本ではそうでもない。ほんの数年前にも、製版データをめぐる訴訟が起きているし、印刷会社としては、印刷はしても組版データは渡さない、というところも多いのである（まぁここらへんは単純に権利関係の問題で契約を見直すことで解決できるのだが）。
図版や表が多い書籍の場合のeBookの作り方ってのは試行錯誤するしかない。当たり前だが。でも結局、HTML化（WEBアプリ化）するのが一番早いのだと思う。アプリとして売るとしてもHTMLをパッケージすればいいだけのことだし。
もちろん検索性は重要であるから、本の索引をうまく変換することが肝心。

とか考えてもiPad的なB5サイズのタブレットが主流になればPDFで問題ない気もするんだな、これが。

e-book

2010-03-23T19:35:00.002+09:00

電子書籍て呼び方に違和感があるのかもしれない、結局のところ。
例えば、WIREDやVIV MagのiPadデモを見て、未来の本！と騒ぐ気にはなれないのである。WEBとどーちがうの？というわけで。個人的には、FLASHサイトは鬱陶しかったのだが、それをタブレットで見ることで変わるのかもしれない、てところに期待はしている。

送り手からのメリットとしては、WEBコンテンツの切り売りが可能となり、しかもコピーの問題も多分クリア、てところだろうか。ただ、先のVIV Magのようなリッチなコンテンツを作るのであればそれなりにコストもかかるだろうしな。。。

findGrep()で検索したとき

2010-03-07T03:14:00.002+09:00

よく忘れるのでメモ。

findGrep()で検索したときの返り値はマッチした文字列の配列。で文字列がどの場所にあるのかを知りたい時は、配列をfor文とかで回してindexプロパティで親ストーリーの何番目のキャラクターなのかがわかる。

例えば次のように取得する。
app.findGrepPreferences.findWhat = "(?s)▲▲(.+?)▼▼";
var result = myStory.findGrep(true);

for(var i=0; i<result.length; i++) {
$.writeln(result[i].index);
$.writeln(result[i].toSpecifier());
}

indexで最初の▲の位置がわかる。toSpecifier()だと最初と最後がわかる。
単純にindexとな。ここで躓いてしまった。

何がしたかったというと、タグで囲まれた部分を吹き出し的なアンカーフレームにする、というもの。テキストフレーム作成→ライブラリ経由→カーソル位置に配置、と今までやってたんだけど、insertionPointがわかってれば直接insertionPoints[x].textFrames.add()、と出来るようなので。

acrobatのハイライトテキスト

2010-02-22T22:22:00.004+09:00

数時間ネットで調べたのだが、やはり皆苦労しているようだ。
そもそもacrobatのJavascriptはリソースが少ない。少なすぎる！ってことで勉強する気にもなれず、一番手っ取り早いが不完全な方法で手を打つことにした。

単純にテキストがハイライトされたPDFをXMLで書き出すだけ。ハイライトされている部分は<Annot></Annot>で括られてるのでその部分だけを拾っていこうかと。頁番号はちょっと厄介。ノンブル部分の作り方に特徴があれば（例えば章タイトル＋全角スペース×２＋ノンブル、とか）、その規則性から拾ってくる手もあるんだが、そうでない場合は。。。。

まぁハイライト部分は出現順に拾えるはずなので、拾えているかどうかチェックもかねてノンブルを入力してもらっていくのがいいか。。。

acrobat + javascript = ?

2010-02-21T21:39:00.003+09:00

作業の効率化UPということを考えると、結局InDesignでできることは最小限に抑えたい、ということになる。InDesignを使える人ってのは限られているわけで、使えない人にもできる作業を増やすことで、効率化だけでなく、全体の作業量を増やすことができる。

で色々考えると、結局InDesignで色々やるんじゃなくて、wordで文書の構造化やレイアウト、文字属性を決めてしまうってのが手っ取り早いのだろう。
プレーンなテキストファイルってのはたしかに扱いやすいが、逆に手間がかかかる。例えば、学術書であれば、イタリックだったり上付き・下付き文字ってのは日常茶飯事でそれをテキストエディタでタグでくくっててのは手間。ワードだったらキーボードショートカット一発でそこらへんの文字属性は設定できるし。

ということでワードの文字属性やスタイルをほぼ完全にInDesignに読み込ませるようなスクリプトが必要。いや、実際InDesignの機能でほぼ読み込みできるのだが。

次に、InDesignで組み上がってきたものに対する処理。予算があればInCopyという手もあるのだが、そうではないので修正はInDesignでちまちまやる、と。

もひとつ面倒なのは索引。InDesign上で索引マーカーひいてくのが便利なのは確かなのだが、その時間を別の書籍の組版にあてたい。てことでPDF書き出して注釈可能にして、テキストをハイライトさせて索引マーカーを著者に引いてもらうのが一番いいかと。でAcrobatからハイライトテキストを書き出す。

という構想だったのだが、ハイライトテキストを書き出すにはいろいろとややこしい。そもそもテキストをハイライトさせる時にハイライトされている文字列を注釈にコピーする必要がありそれが自動的にコピーしてくれるのはAcrobatのみ。でReaderでハイライトされたテキストは文字列として書き出せないのである。ここでInDesignのようにJavaScriptで何とかなるんじゃないかと思ったんだが。。。

ぐぐってみても良い解決策は見当たらない。ここに
http://www.acrobatusers.com/forums/aucbb/viewtopic.php?id=14150
一応の答えはあるんだが。。。というかそもそもAcrobatでのJavascript環境が貧弱すぎ！でっ挫折気味なのだが、ここらへんちゃんとしたスクリプト出来たらかなり強力かもしれん。

つか調査不足だが、PDFをプログラムでコントロールするってはInDesign以上に効果的なような。

Grepのバグ？

2010-02-03T23:55:00.005+09:00

久々にIndesignネタを。

簡易タグから段落スタイルの割り当てというスクリプトを作っていて、例えば

<ex>
文字列文字列文字列文字列文字列文字列文字列文字列文字列文字列文字列
</ex>

とタグがあってスクリプトを走らせると、現ドキュメントで使用している段落スタイルを選びそのタグで囲まれた文字列に割り当てられる、というもの。

上記の例でいえば
app.findGrepPreferences.findWhat = "(?s)^<ex>\r(.+?)<\/ex>\r";
app.changeGrepPreferences.changeTo = "$1";
としておいて、findGrep()の戻り値に段落スタイルを適用して、changeGrep()でタグを取り除く、という仕組みにした。一段落ずつ見ていってタグを取り除くより正規表現で置換した方が楽に思えたので。

何回か検証して問題がなかったように見えたのだが、よく見ると、タグを除去した後に、上付き文字の位置がずれている。正確に言うと、上付きの属性がかかる位置がずれているのである。例えば、「H₂０の・・・」となっていたところが「H2O_の・・・」となっているのである。。。

どうも置換する際に属性の位置が保たれていないようである。いやいや本格運用する前に気づいて良かった。
ってこれはスクリプトだけではなく、Indesignの検索置換ダイアログでも同様の症状のようだ。。

大きい。。。

2010-01-29T20:03:00.005+09:00

iPhoneの巨大版。。。この冬実家に帰ったとき思っていたこととリンクした。
田舎にいる父母にプレゼントしたらいいと思った、iPadを。
別に電話機能はいらない。でもメールのやりとりはしたいはず。特に孫の写真が大きく見れたらいい。
3月発売か。。。兄弟と相談してみよう。

つか、電子書籍というよりそっち方面（高齢者とか、PC苦手な人とか）に受けそう。
となると日本では競合はDSあたりなのかもしれない。ゲームもできるし。
何よりDSよりわかりやすい。使いやすい。ペンをなくす心配もない。そしてゲーム機じゃない。

まじめに考えると、青学がiPhoneを生徒に配布したように、今度は小・中学校でiPadを採用するって流れが出てきそうですね。学校にそのシステムを構築するよりも、iPadを買い与えて3年なり6年使った方がコストはかからないだろうし。そういう意味ではクラウドっぽい。

横断性

2010-01-22T08:05:00.002+09:00

目次・索引、てのが書籍における重要な側面だとすれば、電子化することで、検索性とかフィルタリング、並べ換え、が可能になると有用かもしれない。
書籍単体を横断してそのようなことが可能となればさらに面白い。WEB頁のクリップのようなものだ。
OSレベルでの検索機能（たとえばMacの場合のスポットライトとか）が書籍内容にまで拡張できるかどうか。書籍自体にタグ付けだったり注釈がつけれるかどうか。

70%

2010-01-22T01:10:00.002+09:00

印税率やらなんたら、アップルのiSlateとかなんとかで、電子書籍をめぐる動きというかニュースが多い。
出版社側としては、マーケットが広くなるのはよいことなのだが、優良な著者が離れるかもしれない、というのがやはり一番怖い。
音楽業界を見てると意外にそうはならないかもしれないような気もするが。

学術系というくくりで考えると、アマゾンで出版するのは自費出版にすぎず、当面は業績にカウントされないのかどうか。というか論文誌とかはとっくに電子化してるわけで、そこらへんとの関係とか。

電子書籍というネーミングに惑わされすぎかもな。

DTP

2010-01-18T03:52:00.002+09:00

といってもDegital Text Platformのことだけど。

ますます、Javascriptとは関係のない話。
電子書籍の場合、厳密な組版ルール（例えば、Indesignでいうところの文字組み調整機能を駆使するようなもの）がどれほど求められるんだろうか。

画面サイズを自由に変更できるような端末の場合（というか文字サイズを拡大縮小しても一行が画面に収まるようになるという意味で）、版面という概念がないわけで。

PDFは当分の間、標準規格とはなるだろうが（オンラインジャーナルの場合PDF配信が標準）、商業的には別の規格が出てくる予感。結局HTML5なのか。

携帯端末、スマートフォン端末、電子ブックそれぞれで別の規格を作られてもたまったものじゃない。
PDFだと画面の拡大・縮小の問題があるわけだし。

Indesignでの組み方ってのとデータの吐き出し方ってのはよーく考えておかないといけないような。

2010

2010-01-04T02:45:00.003+09:00

年が明けてしまった。

アップルがタブレットＰＣ発売を公表するのではないかという噂が大分前から出ている。macbook airは確かに薄いものの、自分的にはインパクトには欠けていた。もしかしたら、タブレットＰＣを出すための準備的なものだったのかもしれない。

Ｋｉｎｄｌｅがヒットしているようである。アップルのタブレットＰＣはそれに近い端末、と考えることができるかもしれない。サイズはＢ6ぐらいだろうか。iPhoneに代表されるスマートフォンで青空文庫を読んだり、ネットしたりというのは定着しつつある。

電子書籍ということをずっと考えているのだが、しっくりこない。書籍の電子版という意味では、ＰＤＦがある。Ｋｉｎｄｌｅだと文字サイズや行間、フォントとか版面も変更できるらしい。よくよく考えれば、ＨＴＭＬがやっぱり柔軟な気もする。ＣＳＳ＋ＪａｖａＳｃｒｉｐｔ＋Ｆｌａｓｈで文字サイズ以上に何でもできるからなぁ。php使えば、データベース的に書籍データを再構築して並べ替えや抽出もできるし。

Ｉｎｄｅｓｉｇｎで書籍を制作した結果の副産物としての電子書籍を考えると、組み方も注意しないといけないのかも。ＸＭＬ吐き出しで何とかなるっていう部分もあるっちゃあるけども。

Ｉｎｄｅｓｉｇｎをただの組版ソフトとしてより、文字データと画像データの集約ツール的として認識して使うべきな気がしてきた。アニメーションは組み込めないけどそのうちフラッシュも組み込めるようになるだろう。実際、電子書籍て考えるとＤｉｒｅｃｔｏｒとかなのかもしれないが。

学術書というか、いわゆる教科書の未来、てのを考えると、Ｂ6サイズぐらいのタブレットＰＣが出現して、学生たちがそれを持ち歩いて教科書は電子データ化されて・・・となるのはもうそこまで来ていると思うのだが（アメリカでは学生たちはＫｉｎｄｌｅにテキストを入れているようだ）、果たして日本では何時？ということだなぁ。

タブレットＰＣだと、電子化された書籍というよりはもっとインタラクティブな要素のある書籍（というより画面？インターフェース？もしくはソフトウェアになるのか）なんだろうか、求められるのは。

ちょっと真面目に教育の現場を調べないと。

コピペじゃなくてムーブ

2009-11-29T11:22:00.002+09:00

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

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

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

表の自動調整

2009-11-29T01:07:00.004+09:00

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

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

//表のあるフレームを選択
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-22T13:24:00.002+09:00

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-15T01:28:00.002+09:00

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

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

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

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

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

XML

2009-10-21T00:03:00.002+09:00

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

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

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

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

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

グループでの作業

2009-07-12T23:26:00.003+09:00

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

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

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

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

easily

2009-07-08T00:52:00.002+09:00

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

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

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

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

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

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

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

未来

2009-06-30T22:58:00.002+09:00

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

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

バグ？

2009-06-29T01:49:00.002+09:00

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

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

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

そろそろ

2009-06-26T00:43:00.002+09:00

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

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

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

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

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

再現可能性

2009-06-23T23:50:00.002+09:00

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

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

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

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

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

再利用

2009-06-21T16:25:00.002+09:00

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

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

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

画像読み込みスクリプト

2009-06-01T01:33:00.003+09:00

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

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

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

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

効率化

2009-06-01T01:19:00.002+09:00

転職して2本目の組版。

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

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

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

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

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

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

フレームグリッド

2009-04-26T04:16:00.000+09:00

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

illustratorのプラクティス

2009-03-22T22:12:00.003+09:00

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

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

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

new

2009-03-22T15:55:00.002+09:00

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

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

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

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

グリッドの変更

2009-03-10T02:57:00.002+09:00

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

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

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

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

CS3

2009-03-07T07:39:00.003+09:00

やっとCS3に移行。

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

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

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

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

CS3の索引スクリプトでのメモ。バグではないかとおもってるんだが……。

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

索引入力支援

2008-08-30T03:33:00.002+09:00

間が空いてしまった。
その間に、だいぶスクリプトも充実してきた。初校の赤の修正時に、索引も入力するのがスタンダードになってきたので、以前のやり方をも少し洗練化。

読みを入力する手間を省くために、索引を拾う際に、既存の索引項目とマッチするものを、候補として選択できるようなダイアログを出せるようなスクリプト。
基本は、選択文字列と索引項目の比較、というもの。
これはかなり便利になった。事項索引については、これでほぼOK。

問題なのは、人名索引。人名は、執筆者がマーキングするのはではなく、機械的に拾うケースが多い。本文中では、ファーストネームは省略されているのが普通だが、索引では補完しなければならない。
そこで、文献リストとの照合作業が必要になってくる。その作業は、別のバイトにまかせて、イニシャルを逐一校正紙に記入してもらっていたのだが、それを確認しながら、入力していくのも面倒。

本文中での人名→文献リストとの照合→出版年数での判別→イニシャル補完。
という一連の作業を、効率よく且つミスらずするには、結局人の手をなるたけ省く――機械的に処理することは機械に任せる、ことが最短かと。
文献リストから人名を抽出してリスト化しておき、人名索引を拾う際に、マッチするものを候補として挙げる、というスクリプトを作ってみたんだが、これがかなり便利。

人名リストから自動的に拾ってく、てのができると一番楽なんだけど、それはちょっと怖いな。どうやって判別させるか、かなり工夫しなくてはいけない。

索引エラー

2008-08-05T22:16:00.002+09:00

前日のつづき。
スクリプトで索引を拾っていって（読みは空白）、後から索引パレットで読みを入力していくと、やはり固まる。
スクリプトで一括して読みを埋めようかと思って、以前作ったスクリプトを走らせてみると、重大なエラー云々というメッセージが出て、インデザインが落ちる。

対処方法がわからんな・・・。
しゃーないので、読みが空白の分の索引項目はすべて除去して、索引拾いなおし。
索引拾い応援スクリプトというか、文字列を選択して、（スクリプトに割り当てられている）ショートカットキーを押したら、その選択部分が索引項目になって、プロンプト画面がでて、読みを入力できる、というスクリプトで、カーソル移動とかの余計な動作を省く。
でも、結局拾いなおすのに1時間ぐらいはかかって、まぁまぁ疲労してしまった。

後から読みの入力、てのがうまくいかないのは、厳しいなぁ。どーしたものか。

索引のスクリプト

2008-08-04T21:43:00.002+09:00

索引項目を追加するとき、ダイアログウインドウを開いて、読みにカーソルを移動させて、入力するってのが、非常にわずらわしい。

そもそも、索引語はえてして頻出するので、拾う度に、読みを入力するか、もしくは参照ポイントを追加していく、てのが面倒なわけで。
そこで、選択文字列をスクリプト経由で索引に追加するスクリプトを作って、ショートカットキーを割り当て、快適に作業していたのだが、たまたま索引パレット上で、ある用語の読みを入力してみたら、固まってしまった。
むむむ。
索引追加のダイアログウインドウ上では、読みが不完全だと、警告が表示されて、読みをきちんと入力するまで、先に進めない。そこらへんが問題？

しゃーないので、読みの部分も、スクリプト経由で入力するか。まぁ、そっちのほうが楽なんだけど。
索引パレットは、読みを入力すると、すぐパレットが更新されて、並び替えされてしまって、大変なので。

レイヤーとな

2008-08-04T21:35:00.002+09:00

執筆者がインデザインを扱えるとのことで、データを渡したのだが、レイヤーは使わないのですか、というお問い合わせ。

その存在、すっかり忘れていました。
イラレを使うときは、レイヤーを駆使しまくっていて、インデザインを始めたころ、同様に、レイヤーでオブジェクトを操作しようと思っていたのだが、CS2では、レイヤーパレットにオブジェクトが表示されない、ということでかなりがっかりきて、それ以来使っていなかったような気がする。どのレイヤーにどのオブジェクトがあるのかが、（イラレのようにパレットで）視認できないと、危険だと思ったわけで。

で、今回の問い合わせで、ハッとしたのだが、たとえば、索引部分のマーカーとかを別レイヤーでマーカーオブジェクトとして描画していけば、わざわざ、本文の文字にアミかけ（実際は下線）しなくてもいい。

そういう点では、使えるかもしれない。ちょっと考えてみようっと。

当面の課題

2008-08-01T05:27:00.004+09:00

本題の前にメモ。
insertionPoint.horizontalOffset
insertionPoint.baseline
でカーソルの親フレームの左上からの相対位置が取得できる。

原稿データはだいたい、各章ごとにファイルがある。で、１ストーリー＝１章、という風に組んでいるんだが、いちいち、流し込むのも面倒になってきた。
修正されたデータが完璧だと仮定して、フォルダごと、もしくは複数ファイル選択して、各章ごと改丁で自動的に流し込みつつ、ハシラも補完、てことができるようにすれば、だいぶ楽になるはず。

文字列選択部分を囲むオブジェクトの生成スクリプト、を作ってみたのだが、テキストの背後に配置したい場合、アンカーオブジェクト化（カスタム）ができないっぽい。→要チェック。

先述のカーソル位置。baselineだと、欧文ベースラインの位置、ということで、本当は、仮想ボディの下の位置が知りたい。差分の求め方を調べておくこと。

忙しい

2008-07-28T21:40:00.003+09:00

進捗表のプロジェクト欄、埋まってしまった。案件多すぎ。
てことで、さらなる効率化を計らないと、疲労感が高まってしまう。こまごました設定の疲労感を避けるには、キーボードショートカットがきく。てことで、最近のお気に入りは、ちょっとしたスクリプト＋ショートカットのコンボ。
たとえば、括弧でくくった部分は、括弧の前後はベタ組み、とか、選択部分の全角カンマを半角カンマに変えて、前後ベタ組み、とか、そんなの。
ストーリー単位とかで一括変換するのは、怖いというか危険だから、結局字面をおっていかなきゃいけないときに、チマチマ文字設定→字詰めの設定とかしていたら、だるすぎるわけで。

長年（てどんだけだ）の懸案は、本文以外のオブジェクトの扱いだな。コラムとか、脚注とか。図表に関しては、ある程度共通したフォーマットがあるんだけど、そのフォーマットがプロジェクトごとに変わるのが面倒。

たとえば、今日組んでた本だと、本文、コラム、ワークショップ、キーワード、要約、問題、、、とか。まぁテキスト系の組版に比べれば、格段に楽だけど。
ここらへんを効率化する方法、を考えなければ。

もひとつは、初校出力以降の、差し替えとか、大幅なテキストの挿入に耐えうる、組み方。まぁ、アンカーオブジェクト化、てこと。時間見つけてやっておかないと、夏以降、死にそう。

まぁ、ここ3日ぐらいは、特急で仕上げなきゃいけない分がたまってるから、それをちゃっと片付けたいものだ。だが、明日は、大事なものが夕方届くはずだから、残業はしないこと。

メモ

2008-07-14T23:55:00.002+09:00

よく忘れるのでメモっておこう。
今のカーソルのあるページの取得の方法。

app.activeDocument.selection[0].parentTextFrames[0].parent.name

でOK。リファレンスでTextFrameのところを見てもPageオブジェクトが出てこないのでいつも戸惑うのだが、parentでPageオブジェクトにアクセスできる。

も一つ。
索引マーカーにも文字ツメの設定があって、デフォルトでは自動になっているため、たまに、索引マーカーのせいで、文字組みが変化することがある。これは凄く困る。そもそもマーカーは印刷されないのに、文字組に影響するってのはどうかと。なんで検索置換で前後のツメをベタにすれば問題ないか、と思っていたら、Windows環境では、索引マーカーの特殊文字がない。
これは困ったってことでspecial character enumにないかと探すが見つからない。しょうがないのでtopicsからinsertion pointを取得して～、とかやることで対応。
CS３では改善されてるのかしら。

アンカーオブジェクト

2008-07-13T16:08:00.002+09:00

なんとか3本組んだ。しかし、原稿の整理がなってないものを渡されて、「急ぎです」というのは無茶やな～。
で、こっちも忙しいので、別の人に整理してもらったんだけど、ファイルをまとめてなかったり、画像が汚かったり、そもそもの原稿データの挿入を忘れてたりとか、手落ち多過ぎ。毎回、マメに指摘してんだけど、それでも直らないとは、これ如何に。

で本題。
節のスタイルとか、見出しのスタイルに、ちょっとした図形を加えようと思って、アンカーオブジェクトを生成するスクリプトを作っていたんだけど、ライブラリ経由でないとうまくいかないんだろうか。『そのままあんかーオブジェクト』という便利なスクリプトが既にあるので、わざわざ作る必要もないのだが、勉強がてらシコシコやってるんだが、どうもうまくいかない。

Rectangleオブジェクトを作ってから、カーソル位置に挿入しようとすると、エラーが起きるんだわな。
も一個、アンカーオブジェクトのサイズを変えようと思って、visibleBoundsの値を取得すると、よくわからない数値になってる。
時間がなかったので、ちまちまサイズは手作業で修正していったんだが、来週、時間を見ても少し探ってみよう。
それからアンカーオブジェクトの参照ポイントで、仮想ボディの中央に設定する方法がわからん。まぁ行送りの先頭でもやれないことはないんで問題がないといえばないんだが。

そもそもは、Indesignの日本語版のスクリプトリファレンスがないってのが問題なんだよなぁ。

表関連のスクリプト

2008-07-03T23:52:00.002+09:00

まず、列幅の自動調整。セルにはcolumnsからアクセスして、各セルの文字列のバイト数を求めて、最大値×フォントサイズ＋マージンを列幅とする（セル内で改行されてる場合もあるので、paragraphオブジェクトのcontentsで文字列を取得する必要がある）。マージンはプロンプトウィンドウを表示させて、都度入力。
バイト数を求めるには、

function countByte(str)
{
return str.replace(/[^\x20-\xFF]/g, "##").length;
}

みたいな関数作って対処。結構これは、使い勝手がいい。今組んでる本が、各章につき30ぐらいの表があるんで、いちいち手作業でやってたら腱鞘炎起こします・・・。

次にセルの結合作業支援スクリプト。セルを複数選択して、列ごとに一気にまとめたい時用に。選択状態のセルのインデックスは行方向に増える様子。

そろそろ、ライブラリ化も考えて、関数とか変数の命名法を統一しておこう。

で来週末までには3冊分ぐらい組まなきゃいけないのか・・・。スクリプト開発ばっかりやってるわけにもいかなくなってきた。

やれリスト

2008-07-01T21:25:00.002+09:00

忘れがちなので、メモ。

図表オブジェクトをアンカー化。
文字組の設定もいっかい見直し→本で調べる。
テキストを流し込む時の作業を簡略化。
表の自動生成の不具合の修正（フレームからはみ出す分が表にならない）。
矢印の頭を合わす。
表の列の幅を自動的に調整。
表のケイの調整のオプション。
チラシの自動作成（XML使ってみる？　書誌データ＋テンプレートでラフ見本が作れるように）。
人名索引作業の修正。

こんなもんですか。
気になってることとして、段落スタイルの肥大化。どうにかできないものか、と思いつつも、スタイルをどんどん登録したほうがらくなんだもんで。ツリービューとか出来たらいいんだがなぁ。スクリプトウィンドウはツリービューなのに（まぁフォルダの階層構造使ってるから当たり前だけど）

正規表現

2008-07-01T21:10:00.003+09:00

文献の表記の統一ってのも面倒な仕事のうちの一つ。語の間が半角スペースだったり全角スペースだったり。全角カンマか半角カンマか・・・。外国人名のときは、半角の約物、日本人名のときは全角の約物、というわけでもない。ここらへんは正規表現＋スクリプトで対処することで、煩わしさから解放されるはず。

もひとつ問題は、書名または雑誌名はイタリックにして、巻数はボールドとか、いう規定の問題。そもそもデータはワード形式での入稿が多く、ワード上でイタリックにしたりボールドにしたりしてるんだが、基本的には、ワードのスタイルをインデザイン上で読み込みたくないので、いちいち指定し直さないといけない。ちなみに、先頭文字スタイルを駆使することで、イタリック、ボールドの処理はいくぶん楽になる。

ワードのマクロで正規表現使って処理するのが一番真っ当な気がするんだが、VBマクロのリソースがやたら少ない（エクセルは多い）。でもって、VBの文法覚えるのもめんどくさいので、この方向性はなし。

あー、perlのwinOLE（だったっけな）で制御する、という方法もあるのか。もしくはruby。どっちにしろ勉強が必要だわな。

やっつけ

2008-06-26T01:14:00.009+09:00

人名索引スクリプト。さすがに、こればっかやってるわけにもいかなくなってきたので、暫定的に仕上げる。

①本文から索引項目を追加していく。選択部分からスクリプトで抽出した人名を項目に、選択部分を読みに。
②それをテキストではきだして、エクセルで読み込み、読みの部分（選択部分＝人名＋年号）から人名を補完していく（外国人名のときは、イニシャル、日本人名のときは、ファーストネーム）。日本人名のときは、読みの部分にローマ字表記を入れておく。
③補完したらテキストで保存しておき、それをスクリプトで読み込み、indesignの索引項目を修正していく。

③の部分が問題だったわけだが、今回の対処方法。

a．項目を入力することで、並べ替えられるのを避けるために、まず、読みの部分（選択部分が入ってる）ところに数値を入れていく（10000、10001、、10002、、、、10000+n）。
ｂ．次に項目部分の修正（イニシャルの追加、ファーストネームの追加）。
c．読みの部分を修正（数値を消して、読みを入れていく。外国人名のときは空白、日本人名のときはローマ字表記）。

indesignの索引の並べ替えのルールは、まず読みを見てから、読みが空白ならば項目を読みとする。数値の方が、アルファベットより先。なので読みの部分を修正する時、for文をつかうなら注意が必要。
これでやってみた。
250ページぐらいの本で、人名索引は1000個弱。手作業でやるとおそらく1日仕事。
スクリプトで補助することで、索引を拾うのに1時間、人名補完で２～３時間。半分ぐらいの短縮率。

チェック用に、索引部分をアミカケにするスクリプトを走らせたのだが、さすがに1000個弱だと時間がかかる。20分近く。ここで時間切れ。明日PDFにしてチェックしてみるか。

今回、選択部分から人名を抽出するのに、文字コードのことを考慮していなかったので問題が。indesignでは「'」とか「‘」をスペシャルキャラクターとして扱うので、数値を返す時がある。例えば

o'reilly

と拾って欲しいのに

o143593847234reilly

みたいになっていた。ここは修正しておくこと。

実際のところ、このイニシャル補完の作業をオペレータがやるべきではないな。本文との人名表記の違い（単純な誤植）とか、引用文献の年号の違いとかを発見することは非常に多くあるわけで。
なんで結局次のやり方がベターのような気がしてきた。

①文献チェックの際に、本文にイニシャルを書き加えてもらう。人名索引としてとる部分にマーカーをひいてもらう。→校正者の仕事。
②索引を拾う時にそのイニシャルを補完。→オペレータの仕事。

え、そうなると、今回作ったスクリプトをまた使う日が来るのかいな・・・^^;。まぁ自分が校正者かつオペレータとなるケースもないわけではないから、いいとするか。

リフレクションインタフェイス

2008-06-25T00:55:00.003+09:00

さっきのmoveメソッドとか、スクリプトリファレンスだけでは詳細がわからないものは多い。で、今何気にスクリプティングガイドを眺めていたら、

ExtendScriptには、オブジェクトに関するあらゆる情報を取得できるリフレクションインタフェイスが用意されています。

とのこと。家のPCにはindesignをインスコしてないので明日調べてみよ。リファレンスに載ってないプロパティやメソッドもありそうだし。日本語版のindesignと英語版ではかなり違いがあるからしょうがないけど。

まだまだ、人名索引。

2008-06-24T19:52:00.002+09:00

格闘中である。
昨日の続きで、本文中での、以下のような対象個所

Frued, 1925
Lazarus & Folkman, 1969
田中・加藤（2004）
Eysenck et al.（1985）
Smith, Gibson, & Jacob, 1966

を選択して、余計な文字を除去して、次のような二次元配列（人名,　選択部分）

["Freud", "Freudm 1925"]
[["Lazarus", "Lazarus & Folkman, 1969"], ["Folkman", "Lazarus & Folkman, 1969"]]
[["田中", "田中・加藤（2004）"], ["加藤", "田中・加藤（2004）"]]

を生成して、その配列の一つ目の要素を、topic.nameに、二つ目をtopic.sortOrderへと格納する。
索引は、事項索引と人名索引の二種類ある。事項については、普通に、読みを入力しておいて、人名索引は、記号（たとえば$とか）の入れ子項目、というふうにしておく。

ここまでは比較的問題なくできた。原因不明のバグ？もあった。それは項目を入れ子にする際、

var t = index.topics[0];
var tt = t.topics.add("Frued", "Frued, 1934");
tt.pageReferences.add(textObj);

という順にするとエラーが発生。どうも読みを参照位置よりも先に指定すると駄目みたいで

var tt = t.topics.add("Frued");
tt.pageReferences.add(textObj);
tt.sortOrder = "Frued, 1934";

とすると問題がないみたい。なんでこうなるのかがよくわからんな・・・。

まぁともあれ、選択範囲を、人名を項目に、選択範囲を読み、にして索引に放り込むことはできた。次は、できた索引をいったん出力して、エクセルか、テキストエディタとかで、イニシャルを補完してから、そのデータを索引に反映させることが必要。

indesignの索引は、読みを入力すると自動的にソートしなおされてしまうので、for文で回しながら、うまく読みを修正するのは難しい。しかも問題なのが、人名を、項目$の入れ子にしてたこと。topicのメソッドにmoveというものがあったので、それを使えば、for文で、該当topicを取得→修正して、別の索引項目（例えば#とか）の下へ移動、とやれば、カウンタを気にすることがないはず、と思っていたのだが、そのmoveの使い方がわからない。値はlong型なので、該当項目のindexを入れとけばいいのかと思ったが、うまくいかないし。
しかも、スクリプトで見ると、項目は入れ子構造になってない。indexSection.topicsをfor文で回すと、$と入れ子のつもりだった人名は並列である（階層ではなく）。例えば、indexSecition.topics[0].nameが$でindexSecition.topics[1].nameがFreud、indexSecition.topics[2].nameがGibsonだったりする。

ここらへんで時間切れ。手間取るなぁ。しかも、出力待ちの原稿も増えてきたし・・・。明日どうするかいな。

そういえば、indexSection

2008-06-23T22:44:00.004+09:00

索引の初期化、てのが索引ウインドウではできない。何で、簡単なスクリプトで対応する必要がある。

var indexObj = app.activeDocument.indexes[0];
for(var i=indexObj.topics.length-1; i>=0; i--) {
indexObj.topics[i].remove();
}

とかそんなかんじ。
このままだと全部消えてしまうので、特定項目のみ（例えばアルファベット分だけ）消したい時はindexSectionを使えばいいか、と思って、

if(indexSections[i].name.match(/[A-Z]/) != null) {
ここでindexSections[i].topicsをの個々のtopicについてremove()していけばOK！
}

とやってたら、remove()をこのオブジェクトに適用できない云々、と。何故だかは不明・・・。アルファベット分だけだったら、まぁtopicsのindexで範囲を限定して消去、とかでいいけど、ほんとにタ行だけ、消したい、とか言うときはどうすればいいんだろ。

indexSectionから取得したtopicはremoveできないのか・・・。

人名索引

2008-06-23T22:15:00.003+09:00

試行錯誤中。

方法その1。文献リストから、出版（発表）年を参照しつつ、検索して一致したものを索引に追加していく。この方法の問題は、検索方法が複雑になること（というか、どこまで考慮すればいいのかわからん・・・）。

方法その2。ひとまず、本文中の人名と年号をまとめて索引として追加していく。後から、文献リストと照合してイニシャル補完。ページがずれる心配がないのならば、この方法が一番手っ取り早い。例えば、本文中での

Frued, 1925
Lazarus & Folkman, 1969
田中・加藤（2004）
Eysenck et al.（1985）
Smith, Gibson, & Jacob, 1966

こうゆう表記をそのまま索引項目に追加していって、いったん、CSV方式かなんかで出力してから、エクセルとかで、ソートして、人名を分解して、年号を参考にしながらイニシャルを補完する。indesignの索引機能を、一時的に使って、最終的には、エクセルかなんかの索引データを整形して、本文にはりつけることになる。indesignを使わずに、人力で人名索引を作成する時は、この方法でやっていた。エクセル上で

Frued, 1925
Lazarus & Folkman, 1969　　45
田中・加藤（2004）　　４６
Eysenck et al.（1985）　　８９
Smith, Gibson, & Jacob, 1966　　９７

と入力していって（空白部分でセルを区切る）後からソートし直して、人名部分をセルごとに分解して・・・と。
問題は、再校段階で索引を作るときは、ページがずれる可能性があるってこと。indesginで索引を作成するということの一番のメリットは、索引頁のチェックをする必要がないことにあるわけで、それが使えなくなるのは痛い。

で今思案中の方法。索引項目には連名でなく一名ずつ採っていく。ただそれだけだと、イニシャルの補完が大変なので、一時的に、項目の読みの部分に連名＋年号を入力しておく。索引を取り終わったら、読みを基準にソートされているはずなので（すなわち、アルファベティカルオーダー）、文献リストのオーダーとほぼ同じなはず＝照合しやすい。問題は、漢字表記は読みに使えないのでどうするか、と。まぁ暫定的に、アルファベットで入力しておくか、どうか。日本語文献が多い時は厄介かも。

この方法だと、索引をとるときが面倒。まず、本文での「連名＋年号」の部分を選択して、コピー。で次に名前を一名ずつ索引にとっていく。読みにコピーした「連名＋年号」を入力。タブキーで動かして、Alt+Sで読みに移動して・・・とか手間かかりすぎ。
こうゆう部分はスクリプトで手間を省くべきということで、選択部分から人名を抜き出して、一名ずつ索引項目に追加しつつ、それぞれの読みに選択部分を貼り付け、と動くものを作ってるうちに、時間切れ。

今まではアウトプットの部分で、スクリプトを考えていたのだが、こうゆうインプットの部分でのスクリプトもだいぶ作業時間を短縮してくれるはず。

索引

2008-06-20T21:58:00.003+09:00

学術書の場合、だいたい事項索引については執筆者にマーキングしてもらい、それを編集部のほうで拾っていき、人名索引は、機械的に拾っていく、というケースが多い。
indesignには索引機能があるので、重宝してる。校正の結果のページズレも、反映してくれるからだ。ただ、索引を拾った部分を、出力紙では視認できないので、索引個所にアミカケ、というスクリプトを作って対応している（アミカケというより、アンダーラインの設定をいじったアミカケ風）。

さて、厄介なのは人名索引である。本文に出てくる人名というのは、だいたい引用文献で言及されるケース。その場合は、イニシャルは省略されていて、索引ページでは、そのイニシャルは補完されていなければならない。つまり、人名を拾う際に、文献リストと照合して、イニシャルを補完していく必要がある。

章末に、文献リストが記載するケースの場合は、それほど苦ではないのだが（せいぜい、多くても2ページほどである）、が巻末に文献リスト、ということになると、下手すると10ページ以上にわたるリストとの照合作業をする必要がある。
これが面倒。非常に面倒。やりたくない作業の一つである（一番やりたくないのは、責了前の索引チェックだが）。

本文での人名記述のパターンとして

Piagetは、思考発達段階説を唱えた。
・・・・・・ということになる（Lazarus & Folkman, 1984）。

というものがあるのだが、どうやるのが効率的なものか・・・・・・。

オブジェクトを別のページへ移動させる

2008-06-17T23:25:00.004+09:00

先日のエントリでのNaNの件。

現ページから、前もしくは次のページを取得するとき、

pages.itemByRange(currentPage.name-2, currentPage.name-2）

というふうにやってたのが駄目だったみたいだ。この場合、Rangeが1ページ分でも、返される値は、配列になるわけで、そこが問題だったと。

ということで単純に前ページのときは、

pages[currentPage.name-2]

で、次ページのときは、

pages[currentPage.name]

で取得するように変更したら、問題なく動く。

てことでオブジェクトを前もしくは次のページに移動させることはできた。だが、オブジェクトが回転されてたりする場合は、どっかに飛んでいってしまうので^^;、注意が必要。要検証。

原稿整理のルール

2008-06-16T22:45:00.002+09:00

自分用メモ。

タグテキストでやるのは、タグをそもそも打ち込むのが面倒なので却下。XMLはこれから勉強。なんで暫定的に、簡易タグ～制御文字で。

まず、段落スタイルを統一しておく（A：本文、B：章、C：節、D：項、E：見出し、F：図表、G：引用、とか）。
段落スタイルに対応したタグもしくは制御文字を原稿データに入力していく（＄＄章、＄＄節、～、～など）。
一つの段落でおさまるものは、＄＄○を段落の頭に挿入。ブロック単位のものは、タグで囲む。

インデザインに整形された原稿データを流し込む。スクリプトの適用（段落を一つずつチェックして、制御文字、タグで段落スタイルを適用していく）。

先頭スタイル終了文字はかなり使えるので、別途、制御文字を用意しておく。それから、マイナスとかイコールだとかの記号や、半角カンマと和字のアキの設定とか、ややこしい作業はこの流し込みの後に、一括調整できるようにスクリプトを作っとく。

図を放り込む

2008-06-16T21:58:00.006+09:00

原稿整理の段階での簡易タグ付け（制御文字――例えば、「＃＃節」などを使う）によって、原稿流し込み→自動的に段落スタイルの適用、という作業が可能になって、だいぶ楽になった。その際に、表についても、自動的にインデザイン上で組むようにできたので（もちろん、罫線やセル幅などの微調整は必要）、残っている手間のかかる作業というと、イラストレーターで作成した図の配置。

これが結構厄介。アンカーオブジェクトにする、て手もあるだろうが（たぶん、こっちの方が楽？）、キャプションとの位置関係とか、図の配置位置は、天もしくは地の左右中央が基本だったりすることから、スクリプトで制御しようかと。

オブジェクトは、放り込んだ図＝Rectangle、キャプション＝TextFrame、となる。版面のテキストフレームの種類がフレームグリッドかどうかで取得して、そのフレームの天もしくは地に合うように、visibleBoundsを設定する。その時、図とキャプションの間隔を、図中文字の1字分に固定する。図がRectangleでない場合――例えば、インデザイン上で図を作った場合のことは次考える^^;。

このスクリプトはサッとできた。で次に考えたのが、校正で図を別のページに移動する必要が出てきた時。これも手動でやってると、手間がかかる、というかイライラしてくる。

なんで、これは図にかぎらず、ページ上のオブジェクトを別のページに移動できるスクリプトを考えたんだが。。。時間切れ。

移動先のページを取得→オブジェクトのmoveメソッドの引数にそのページを割り当て。これでオブジェクトの移動は簡単にできるんだが、その時、移動先のページの(0, 0)の位置にオブジェクトが配置される。で2番目の引数で位置を設定する。この場合、ページの左上からの位置になるので、あからじめ、移動前のオブジェクトのページ左上との相対位置を取得して、当てはめることになるんだが、レイアウトグリッドの設計が左右中央でないばあいは、偶数ページ、奇数ページで設定を調整する必要がある。

これは面倒、ということで、レイアウトグリッドとの相対位置をオフセット値みたいなかんじで保存しといて、ページ⇔レイアウトグリッド⇔オブジェクト、という関係で、位置の数値を決めようと思ったんだけど・・・。
ページ⇔レイアウトグリッドのとこで、数値がNaNになってしまう・・・・・・。ここらへんは勉強不足でなぜだかわからんので、後でしらべておくこと。

矢印問題

2008-05-29T01:33:00.005+09:00

問題というほどたいそうなものではないんだが・・・。

ここのページにヒントがある。
http://park12.wakwak.com/~shp/cgi-bin/wiki.cgi/view/JavaScript_scripts#arrow

このやり方を応用して、矢印の頭の形を増やしていけばよい、と。曲線の場合の矢印の傾きの計算方法がわかるので非常に助かった。部品的には、頭と本体を別々に作っておくということだな。

図の作成

2008-05-29T00:47:00.011+09:00

原稿に制御文字を追加することで、原稿読み込み時に段落スタイルを適用することはできるようになった。その際、表の部分については、タグで囲んでおいて、テキストをCSV形式で整形しておけば、自動的に作成できる。

だが、図に関しては、少々厄介だ。職場では、図作成者（執筆要項にはトレス工ってなってたな。なんかやな呼称・・・）が別にいたりするのだが、まかせる時間がないときもある。一応、イラストレーターのスクリプトで、作業を軽減化するものは作ってあるのだが、もっと楽にする方法はないものか。
イラレでよく使うスクリプトとして

　・貼り付けたテキストを改行コードで分割
　・テキストに二分あきのマージンで枠を作成
　・選択したオブジェクトを直線で結ぶ
　・オブジェクトの入れ替え

というものがある。いらいらすることとして、ワードなりPDFなり、図のデータはあって、それをイラレで開いた時に、余計なパスが追加されていて、それを除去するのが面倒、てことだ。おそらく、ワードやPDFのファイルを開いた時（もしくはコピペした時）、一定の変換形式があるはずなので、それがわかれば、逆算してスクリプトで必要な部分だけを取り出すことができるような気がする。
も一つは、矢印。矢印はメニューから作成できるのだが、線の先端と矢印の頭が揃うように作ってくれないので厄介なわけで。矢印の頭のサイズの決定方式もよくわからないし。ここらへん調べておくこと。

マスターページの使い方

2008-05-28T01:24:00.006+09:00

今までは、元となるページを作ってそこにレイアウトグリッドとフレームグリッドを置き、それをベースにどんどんマスターページを作っていったのだが、このやり方だと幾分、問題もある。

テキストを流し込むときに、いちいち、フレームグリッド作るのが面倒なので、マスターのフレームグリッドをオーバーライドしていたのだが、途中で、別のマスターを適用したいときに、原理上はオーバーライドしたフレームグリッドと、適用したマスターのフレームグリッド（オーバーライドしなければ選択できないので実質は見えていない、ことになるのだが）が重なることになる。たいしたことではないのだが、このときに文字数が重なって見づらくなる、ていうのが生理的に気持ちが悪い。
あとは、間違ってCtrl＋Shift押しながらクリックとかしたらフレームグリッドがオーバーライドされてしまって、ややこしいとか（そんなことはほとんどなかったけど）。

ということで、これからはテキスト流し込み用（というかオーバーライド用）にマスターを作っといて、まず原稿を読み込むときはそのマスターを使い、後から、フレームグリッドが配置されていないマスターを適用していく、ていうやり方を採ることに。

マスターとは別だが、「章ごとにドキュメントを作って、ブックで統合」というやり方でやっていたのだが、スタイルを同期ってのはちょっとリスクがある。InDesignをさわり始めた頃は、どちらかというと、メモリのことを気にして、あまり巨大なドキュメントを作らないほうがいいと思っていたのだが、学術書の場合、それほど巨大化することもない（画像は概ねグレースケール、ベクターイメージがほとんど）。

なのでせいぜい、

前付け（まえがき＋目次）
本文
文献
後付（あとがき＋索引＋奥付）

の４つぐらいでドキュメントを作ってブックで統合、というかたちに移行。

今のところ問題はないが、章の位置の入れ替え、などがあると厄介かもしれない。

ひとまず

2008-05-28T01:04:00.001+09:00

仕事で使い始めたindesgin CS2をJavaScriptで制御する上でのメモ用に。