ファンド

電子書籍、国が後押し　出版デジ機構に１５０億円出資
http://www.asahi.com/business/update/0329/TKY201203280905.html

うーむ、これはインパクトある。関係者各位頑張った！と褒めてあげたいような気もするが。。。
出版デジタル機構で電子書籍を作る時は、出版社側から見ると制作費が売上相殺（＝売れた時に支払う）となり初期費用がかからない、てのが機構のセールスポイントで、とはいえいつ売れるの？　無期限無利息借金状態？　資金回収できるの？　20億で足りるんだろーか、とか思ってたけどもう少し体力があるということだ。

経済産業省「コンテンツ緊急電子化事業」

経済産業省「コンテンツ緊急電子化事業」と出版デジタル機構の説明会に行ってきた。説明会の詳しい内容はここにまとまっている。

国から助成金が出るとか、出版社の初期費用はゼロで売上相殺だとか、色々とつっこむところはあるのだが、一番気になっているのは電子書籍のフォーマット。まだ検討中のようだが、固定型とリフロー型の二つ、固定型は画像で、リフロー型はxmdf/epubで、落ち着きそうな予感。

それと前後して新ipadの発表があり、ディスプレイの解像度が圧倒的にあがっていて印刷レベルに近くなっているらしい。
http://plusd.itmedia.co.jp/mobile/articles/1203/15/news027.html

自分の先見の明のなさ加減は恥じるばかりだが、端末の性能が上がるのなら、PDFでOKで、リフローする必要ってなかったんじゃないってことだ。将来的な機能・スペックの進化を見越しておかないといけないんだな。

つまり、今後、アンドロイドタブレットもアマゾンのkindleも高解像度のディスプレイになるわけで、そうするとやっぱり印刷用PDFで問題ないんじゃないかと思う。



紙書籍の電子化だったら、PDFに文書構造の入れ替えとか串刺し検索とかソーシャルとかのダイナミックな機能をつける（もしくはリーダーで何とかする）方が未来があるような。。。


もひとつ気になったのは、この手の説明会て業界向けだからかもしれないけど、読者のことを考えた発言がひとつもなかったってことだ。

お金の話で言えば、6万タイトルを20億円使って作るってことは、1冊あたり（厳密には頁単価になるとは思うが）33,333円のコスト。33,333円で制作可能なのか？ 　そしてとにもかくにも20億円のお金が動くってことだ。

編集と制作と最終形態

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

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

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

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

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

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

2012

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

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

そもそも

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

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

書誌情報とカバー画像

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

ワードプレスのデータベース名は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のレコード数が肥大化していくのが気にはなっているのだが。。。

カスタム投稿

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

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

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

再構築に当たって

まず再構築の目的。

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

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

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

1. 今のサイトの情報（html）をデータベース化
2. CMSを使ってみるので、その勉強
3. CMSに1のデータベースを突っ込む
4. 適当に調整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に大抵のことは載ってるけど、知りたいことは大概訳されていないんだな。。。

ということで

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

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

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

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

再確認。

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

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

google edition

昨日行ってきた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

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

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

iPad来た。

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

iPad購入とな

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

window

自分用メモ。
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

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

ebookその後

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

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

e-book

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

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

findGrep()で検索したとき

よく忘れるのでメモ。

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のハイライトテキスト

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

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

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