Posted in コラム, eBook | 7月 17th, 2010 No Comments »
AmazonのKindleは、専用端末だけでなくiPhone/iPad、PC、Macでも購入したコンテンツが読めるようになっているので、仮にKindleをやめてiPadに変わったとしても、購入した書籍を買い直す必要はありません。
ですが、これがAppleのiBooksで買ったものは、Kindleで読むことができません。こういうのを解決してくれるサービスが出てきて欲しいんですが、ムリでしょうか?
例えばコンテンツのフォーマットはePubがスタンダードになったとして、AppleやAmazonだけでなく、出版社のサイトから買ったものでも、購入後クラウド上にある自分の本棚にアップロードするとか、そもそも購入するときに、納品先をクラウド上の本棚を指定できるようにして、自分の買った電子書籍は、どこで買っても1カ所にまとめられるようにでき、そこからダウンロードすれば、どういう端末でも読めるようにできないでしょうか?
ebookJapanには、トランクルームという機能があります。購入時にトランクルームに購入した書籍を預けることができます。端末を2台まで登録でき(PCとiPhoneとか)、どちらかの端末でダウンロードするとトランクルームからコンテンツは出され、他の端末では読めなくなります。ですがダウンロードした端末からトランクルームにもどすと、今度は別の端末でダウンロードできるようになります。
これと同じようなことを、特定のストアだけでなく、複数のストア間で実現できたらいいなぁと思うんですが…。
Googleさんあたりがやってくれないかなぁ?どっかのベンチャーでもいいです。国内で大手印刷会社と出版社が集まってプラットフォームづくりを検討しているようですが、AppleやAmazonを排除するんじゃなくて、逆に飲み込むくらいの気概で、こういうプラットフォームにしてもらえんでしょうか?
Posted in コラム, eBook | 7月 9th, 2010 No Comments »
電子書籍っていう言葉は、そこに含まれる様々なコンテンツやファイルフォーマットを、すべて含んで呼んでいるので、人によってイメージが違ったりします。そこで自分なりに分類を試みてみました。
「それは違うよ」とか「この方がいいよ」というのがあれば、どんどん突っ込んでください。
more »
Posted in コラム, eBook | 7月 8th, 2010 1 Comment »
7月8日に東京ビックサイトで開催されているデジタルパブリッシングフェア2010に行ってきました。
話題の電子書籍関連の展示が目白押しということで、たくさんの人が押し寄せていました。
ただ展示の方向性は、当社のような具体的な制作を行う業者向けというよりは、版元である出版社向けの展示となっており「お持ちのコンテンテンツをうちのソフトやシステムを使って電子出版しませんか」というトーンでした。制作向けの出展は、今後PAGEなどに出てくると思います。
InDesignのプラグインとしてまもなくリリース予定の、プロフィールド社の製品には関心があったので、どこかに展示されてないかと思いましたが、されていませんでした。
もう一点。黒船到来と言われながら、黒船となるAppleやAmazonは日本市場への参入は表明しつつも具体的な動きは見えておらず出展はありませんでした。iPadやKindleは、そこかしこに置いてありましたが…。
しかし黒船軍団の一角を担うGoogleは比較的大きな展示ブースを構え、GoogleブックスとGoogleエディションについてアピールしていました。これについては関心が極めて高く、プレゼン時には通路にも人があふれ通行できない状態でした(向いのブースはいい迷惑だと思いますが)。Googleは小さな手提げ袋を配っていたこともあり、会場中にGoogleの文字があふれていました。
すでにGoogleブックスは、ベータ版としてリリースされていますが、この夏には米国でGoogleエディションの機能を加えて本格リリースになるそうで、日本でも来年初頭にはリリースしたいということでした。
このことについては、デジタルパブリッシングフェアにあわせて発表されたということで、本日が初お披露目の内容だったようです。
more »
Posted in コラム, eBook | 7月 6th, 2010 No Comments »
実は、有松絞りの手ぬぐい+カエルの箸置きと、iPhone4を買ったので使わなくなったというiPhone3Gとを交換してくれる人がいました。もちろんSIMは入ってません。おかげで私は晴れてiPhoneユーザに!わらしべiPhoneと呼んでます。
さて早速、iPhoneで電子書籍を読んでみました。といってもePub形式の日本語のものは見あたらないので(自分で作ったePubをStanzaで表示してはみましたが)、T-Time形式で販売されていた佐々木俊尚氏の「電子書籍の衝撃」を買って読んでみました。ちなみに電車の中で読みました。もう50手前の私は、当然老眼も入っており、かけてるメガネは遠近両用です。
結論からいうと、ビックリするほど読みやすかったです。片手でiPhoneを持ち、片手はつり革を持っていても読めます。なんでこんなに読みやすいのかな?と思ったのですが、最初は「きっとフォントの大きさが紙の本より大きいからでは?」と思って、級数表で計ってみました(アナログ!)。私が読みやすいと感じていた文字サイズは11級(7.5pt)で、以外と小さかったです。では紙の本は?と思って光文社新書で調べたら、13級(9pt)でした。なんと、iPhoneの方が文字サイズが小さかったのです。これは意外でした。ちなみにiPadで私が読みやすいなぁと思ったサイズは20級(14pt)で、iPhoneの倍近くありました。
では何が理由でしょう?
そこでハタと気付いたのは、行長です。iPhoneは1行の行数が15文字程度です。新聞の一行より少し多い程度でしょうか?これが一画面で15行程度でしたから、一画面の文字数は225文字程度ということになります。画面と顔は40〜50cm離れていましたから、画面全体を見渡すことが当然でき、そこには225文字しかありません。1行が15文字なので(しかも横書き)、目線の移動が最小限に抑えられたのではないかと思います。確か速読についての本を読んだとき、視線の移動を最小限におさえるのがキモだと書いてあったような記憶がありますが、たぶんそういうことも関係しているのでしょう。
光文社文庫は1行40文字程度あります。単純計算すれば視線の移動距離は、文字単位で2.7倍ほどあることになります。iPadでは、先の文字サイズの場合の行長は25文字でした。光文社新書に比べれば、かなり行長は短いです。
紙の本の場合、文字サイズは読みやすさ最優先にするとは言っても、あまり大きくしてページ数が多くなると、コストが跳ね上がりますし、持ち運びにも不便なので、現実的な文字サイズでトレードオフするしかありません。ですが、文字サイズが変えられて、それにあわせて画面が調整されるタイプの電子書籍の場合は、読みやすいサイズ、行長にあわせて画面が再構成されます。
そういう意味では「読みやすさ」を保証する要素が、紙と電子書籍では違ってくるということになるのかもしれません。
Posted in コラム, eBook | 7月 4th, 2010 1 Comment »
InDesignCS5でePubへのフォントのサブセットによる埋め込みが可能になったと聞いてやってみました。
まだInDesignCS5は体験版ですが…
フォントファイルの実体は約10MBあるOpenTypeフォントを使用しました。明朝系です。
青空文庫から宮沢賢治の「銀河鉄道の夜」のテキストを落としてきて、ちょうど4,2000字になるように文字を足しました。
それをInDesignCS5に流し込んでePub書き出ししました。
できあがったePubの容量は約1.3MB。拡張子をzipにして解凍してみるとFontsファイル内にサブセットフォントができていました。
42,000字で約2.25MBありました。単純計算でいうと42,000×(10÷2.25)=約186,666….。ということは20万字くらいあるとフォントファイル丸ごとより、サブセットフォントの総容量のが多くなるという計算になります。
20万字ということは、単純計算で400字詰め原稿用紙で500枚ってことになりますから、長編小説とかでは十分ありってことになりますね。
上記のサブセットフォントの容量が文字数に比例して増えるという記述については、私のInDesignの先生から「フォントの埋め込みは、文字量が多くなければそれに比例して埋め込みフォントの容量が増えていくわけではありません。それは、同じ字形が何度出てこようと、埋め込まれるのは1回のみだからです。」というご指摘を受けました。
で実際に、42000字のePubと、全く同じ文字をもう一度入力し84000字にしたものとをInDesignCS5から書き出して比較してみました。上記のときとフォントが違うので文字数は同じでもファイル容量は少し違っていますが…
42000字のePub 全体容量:1405KB サブセットフォント容量:2239KB
84000字のePub 全体容量:1442KB サブセットフォント容量:2239KB
これをみると、やはり出現する字形が同じであれば、サブセットフォントの容量は全く増えないということがわかりました。先生のご指摘通りの結果となりました。(2010.07.14追記)
もちろんサブセットですので、使われている文字によって容量も違ってきますし、圧縮もかかりますからePub本体の容量も小さくなります。
ちなみに今回のePubは画像も何もないので、サブセットフォント以外は容量的にはごくわずかですから、60%弱くらいの圧縮率だったということでしょうか。
ライセンス的にはサブセットが望ましいけれど、容量的には文字量が多くなるとePubの総容量を増やすことになります。
また現状、サブセットフォントで埋め込めるツールはInDesignCS5しかない。
うーん、仮にInDesignCS5以外のツールでサブセット埋め込みができるようになったとしても、現実的な選択肢になるんでしょうか?
フォント埋め込んだPDFなんかはネットで、やりとりされてるけど、さすがに20万字とかいうのは少ないですよね。
あ、PDFに書き出したら、容量どれくらいになるか試してみればよかった…。今度やってみます。
文字数に単純に正比例してサブセットフォントの容量が増えるということはないのですが、文字数が多くなれば出現する字形も増えるのでサブセットフォントの容量が増えるということにかわりはありません。フォントファイル丸ごとを埋め込んだ場合よりもサブセットの方がフォント容量は少ないということになると思います。ただそれでもフォントを埋め込むことが、仮にサブセット埋め込みであったにしても容量的に現実的かどうかというのは、検討する必要があると思います。(2010.07.14追記)
Posted in コラム, eBook | 7月 4th, 2010 No Comments »
昨今の「電子書籍ブーム」。私は正確には「電子書籍の時代がやってくるぞブーム」だと思うのですが…。
この「電子書籍」っていう言葉はとてもやっかいで、人によってイメージする事が、かなり違うと思うんです。「電子書籍」がテレビなんかで扱われるときは、たいていビジネス寄りの人が語ってるんで、どういうフォーマットでそのコンテンツが作られているのかなんて関係無しに「ビジネスになるのか、ならないのか」みたいな話になります。また文化論的に画面で本を読むことの善し悪しみたいな話になったりします。
「電子書籍」と言った場合、WIREDのeBook版や「Alice for the iPad」を思い浮かべる人もいれば、i文庫で提供されている、小説などのコンテンツを思い浮かべる人もいます。
ですが、そういうコンテンツを作る側にとっては、それがどんなフォーマットや技術で作られているのか、どういうツールで作られるかというのは重要な問題です。
more »
Posted in コラム, eBook | 7月 3rd, 2010 1 Comment »
私がDTPにかかわり始めたのが1994年くらいからで、Webに関わり始めたのは2001年くらいからです。94年当時が32才でしたので、若い時期にいずれも日本におけるDTPの黎明期、Web制作の黎明期に関わることができました。最初は当然ながらDTP関係の知人・友人が増えていくわけですが、だんだんWebの方にも進む人と、Webには意識的に関わらずDTPの分野で頑張る人とにわかれていきました。
最近の「電子書籍の時代がくるぞブーム」で、DTPの分野を中心に頑張っていた人たちが、ePubとかに関心を持ち始めてきています。InDesignCS3からePub形式にInDesignドキュメントを書き出せるようになり、最新のCS5で、よりその機能を強化してきたことが、それに重なりさらに関心が高まってきているようです。
そうした中で「Web頭がない」と言われる方がおられました。今までWeb制作に携わってこられなかったのか、ePubの実体であるXHTMLやCSSの扱いに苦労されているようです。それは慣れてもらうしかないということではありますが、そもそもDTP系の感覚と、Web系の感覚に違いがあるなぁと思ったので、自分の経験をふまえながら書いてみたいと思います。
more »
Posted in eBook | 7月 2nd, 2010 No Comments »
さて、ここまでのところでePubの実体は、基本的にはXHTMLドキュメントと、CSSファイルで構成され、必要な画像とフォントファイルを含んで、アーカイブ化(ひとまとめ)にしたものだということが、なんとなくわかってきました。
CSSで指定されたフォントをプラットフォーム側のフォントを使って表示するかどうか、一緒に保存したフォントファイルを使って表示するかどうかというのは、ビューワーに依存しePub側で制御する問題ではないようです。
で、このアーカイブ化(ひとまとめ)する方法ですが、簡単に言えば必要なファイルをZip圧縮したものの、拡張子を.epubにすればePubドキュメントになるということのようですが、単純にZip圧縮すればよいというものではなく、仕様書で定められた必須ファイルがあることや、圧縮したときに先頭に配置されることが指定されているファイルがあり、そのファイルだけは無圧縮で含んでいないといけないというようなルールがあるようです。
要するにSigilで保存をするときには、ePubとして必須のファイルを書き加え、条件にあったZipファイルができるように圧縮し、拡張子を.epubにして保存をかけているわけです。
本当はもっと厳密なルールがあるわけですが、それを具体的に知りたい方は、ぜひEPUBの仕様書を読んでみてください。日本語訳されたものが下記にあります。正式にはEPUBの仕様書ではなく「Open Packaging Format」というフォーマットについての仕様書となります。
●OPF 2.0 v1.0 日本語訳 [Open Packaging Format (OPF) 2.0 v1.0]
http://lost_and_found.lv9.org/opf/opf_2.0_final_spec_ja.html
逆にいったんePub化したものは、実はZip圧縮されたファイルなので、拡張子を.zipに変更してしまえば、普通にZipアーカイバソフトで解凍ができてしまいます。
では実際にSigilで作ったePubファイルの拡張子を.zipに変えて解凍をしてみます。私が作ったあるePubファイルを解凍すると下記のようなフォルダとファイル構成になっていました。
more »
Posted in eBook | 7月 1st, 2010 1 Comment »
さて、今回はフォント編です。
基本はCSSでフォントの指定をすれば、それが反映してくれればそれがベストです。しかしどうもそう簡単ではなさそうです。
これはePubの問題というよりも、ePubを表示するリーダー側の機能や仕様に依存する部分が大きいと思います。
そもそもリーダーの日本語への対応は、これからっていうところだと思うので、今は「だめじゃん」っていうことが多いんですが、これから改善されていくと思います…というか思いたいです。
まずは普通にCSSでフォント指定をしてみましょう。
Sigilで本体のXHTML文書にリンクしているCSSファイルを開いて編集し、全体を保存しAdobe Digital Editionsと、iBooksで開いて試しました。あ、環境はWindowsXPです。
more »
Posted in eBook | 6月 30th, 2010 2 Comments »
「SigilでePub体験」シリースは、あと2〜3回は書こうと思ってはいるんですが、閑話休題的に。
ePubは調べれば調べるほど、ごくフツーのXHTML文書で、なんでわざわざこれをePubなんて、ご大層な名前をつけているのか、少々疑問に感じ始めていました。
同僚のプログラマからも「別にePubになんかしなくても、そのままウェブで公開したらそれまでじゃないですか?」と言われました。
私は「いやいやePubならダウンロードしてオフラインでも読めるよ」「本のメタファーには意味があると思うよ」と答えました。しかしどうもよく考えると別にXHTMLドキュメントをリンクされたファイルごとまとめてダウンロードでき、本のように見せるブラウザがあればいいだけの話です。なんでePubはePubでないといけないのか?疑問は深まっていきました。
more »