2010/10/09

再確認。

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

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

2010/08/10

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に提供している模様。いずれブログパーツ的に一般ユーザーも使えるようになるのかもしれない(もちろん出版社の許可があってだとは思うが)。

2010/07/19

app-book

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

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

2010/06/19

iPad来た。

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

2010/05/30

iPad購入とな

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

2010/05/28

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に詳しく書いてありますね。

2010/05/21

まだまだeBook

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

2010/04/28

ebookその後

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

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

2010/03/23

e-book

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

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

2010/03/07

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()、と出来るようなので。

2010/02/22

acrobatのハイライトテキスト

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

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

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

2010/02/21

acrobat + javascript = ?

作業の効率化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以上に効果的なような。

2010/02/03

Grepのバグ?

久々にIndesignネタを。

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

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

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

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

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

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

2010/01/29

大きい。。。

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

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

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

2010/01/22

横断性

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

70%

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

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

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

2010/01/18

DTP

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

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

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

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

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

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

2010/01/04

2010

年が明けてしまった。

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

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

電子書籍ということをずっと考えているのだが、しっくりこない。書籍の電子版という意味では、PDFがある。Kindleだと文字サイズや行間、フォントとか版面も変更できるらしい。よくよく考えれば、HTMLがやっぱり柔軟な気もする。CSS+JavaScript+Flashで文字サイズ以上に何でもできるからなぁ。php使えば、データベース的に書籍データを再構築して並べ替えや抽出もできるし。

Indesignで書籍を制作した結果の副産物としての電子書籍を考えると、組み方も注意しないといけないのかも。XML吐き出しで何とかなるっていう部分もあるっちゃあるけども。

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

学術書というか、いわゆる教科書の未来、てのを考えると、B6サイズぐらいのタブレットPCが出現して、学生たちがそれを持ち歩いて教科書は電子データ化されて・・・となるのはもうそこまで来ていると思うのだが(アメリカでは学生たちはKindleにテキストを入れているようだ)、果たして日本では何時?ということだなぁ。

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

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