電子書籍:validなePUBを作成してみた。

suc - 電子書籍

2010年 6月 10日(木曜日) 01:23

http://threepress.org/ ではepubcheck 1.0.5 とepubpreflight 0.1.0を利用したePUBのバリデートチェックサービスを行っています。

iPadではvalidなePUBでないとダメだとか、色々な話があるので、本ブログePUB関連記事を何点か抜き出してvalidなePUB電子書籍制作を試してみました。

コンバータやソフトによるePUB制作では問題も多く見られ、今回はDreamweaverで作成しましたが、色々と面倒で、いちいちこのファイルを作成しないとダメとなるとちょっと面倒ですね。

一応、IPAフォントを埋め込んだので、iPad、EPUBReader、Reader Library、Adobe Digital Editionsでは問題無く表示されます。 

こちらでダウンロード可能ですので、試してみてください。（IPAフォント埋め込みなので4MBと大きいです。。）

追記:20100618

その後色々と試してみて、iPadで画像が表示されないというバグ?がありました。
ePUB的にはvalidでもiPadでは支障ありなんてこともあります。
ファイルを解析すると、幾つか制限があるようでした。現在のファイルはiPad、EPUBReader、Reader Library、Adobe Digital Editions、http://bookworm.oreilly.com/対応です。

追記:20100625

iPad(iBooks)をはじめ各リーダーソフトには色々クセがあります。
そのため変換サービスやソフトへ完全に頼ることも無理です。iBooksのカバーグラフィック対応の変換サービスはsmashwords.comくらいですが、そのソフトは手直しが必要です。

電子書籍:問われるePUBデザイン

suc - 電子書籍

2010年 6月 06日(日曜日) 00:00

今、電子書籍はホットなニュースだ。
その中心的なファイル形式がePUBである。
ePUBはxhtml、CSS、画像などをまとめてzip圧縮したものだ。
単ファイルでの配信やDRMへの対応を考えて一塊にしたのだろう。
しかし、ePUBのレイアウト能力は非常に低いものである。
実際にはCSS2に基本対応なのだから、理屈上はかなり自在なレイアウトが可能な筈だが、リーダーソフトが対応していない。

電子書籍時代の入り口に立った日本でも、ネット上には様々な意見や考えがアップされている。
その中の幾つかは正しく、幾つかは間違っている。（、と私は思っている）

以下に巷でささやかれている意見に対して私なりの考えを簡潔にまとめてみた。

1. ePUBで自由なレイアウトはできない。 ○
   現在のePUBの仕様とリーダー環境では、自由なレイアウトは不可能だ。（自由とは何か、、という哲学的命題は別として）
2. ePUBは現在の日本語文章レイアウトに対応していない。 ○
   現在のePUBの仕様とリーダー環境では、紙書籍によく見られる日本語文章レイアウトには対応していない。
   見た目だけ良いのであれば、縦書きやルビなどもトリッキーなCSSやテーブル組みで可能かも知れないが、あまり勧められない。
3. ePUBでは日本語の書籍（雑誌等）は作成できない。 ×
   ePUBでは日本語の書籍（雑誌等）は問題無く作成できる。ただ、今までの紙書籍のレイアウト、表現とは違ったものになるだけだ。私は日常、縦書きの文章は書かないし、ルビもふらない。私の話す言葉は縦書きでもないし、ルビもふられていない。
4. InDesignでePUBは作れる。 ×
   もちろんInDesignでePUB出力は可能だが、満足のいくレイアウトが再現されるわけではない。
   InDesignで満足できるePUB出力が可能であれば10年前にWEBページはページレイアウトソフトで作成可能になっていただろう。
   InDesignに期待している人の多くは、HTMLやCSSと文章の構造化を理解していないのではないだろうか。
   ※今後InDesignの基本コンセプトが変化してソースが書き直されれば別の話。しかし、それはもはや別のソフト。
5. PDFが良い。 ×
   もちろん間違っている。
   WEBと現在の情報電子化は人間の情報記録の歴史上、大きな変化点だ。
   そのことを理解すれば、W3Cが持つ基本コンセプトや多くの理想主義者の試みからPDFが如何に外れているのかが解る。
6. ePUBではデザイナーの力が発揮できない。 ×
   もちろん間違いだ。デザインは制約された環境の上で情報を効率良く伝えることを目的としている。紙の書籍にも様々な制約があるように、電子書籍にも制約があるだけだ。これこそデザイナーの腕の見せ所だ。
7. ePUBが流行らなくて、アプリやPDFが主流になる可能性がある。 △
   もちろん未来のことなんて解らないが、もしそうなれば、関係制作者（デザイナー）と多くの理想主義者の敗北だ。
8. ePUB最高! ×
   もちろんそんな訳は無い。単なる通過点だ。

電子書籍の統一フォーマットePUB?

suc - 電子書籍

2010年 5月 28日(金曜日) 00:00

最近、電子書籍関連のニュースも多く個人的にも作成したりしていますが、どうも「電子書籍」という名称がややこしい。
フォーマットが違えばそのフォーマットに対応していないソフトやデバイスでは表示されないことは当たり前ですが、そのうち（既に?）FLASHで作成されたものまでもが電子書籍と呼ばれるでしょう。

その昔、「シンカ」やピーターガブリエルの「XPLORA 1」など伝説的な「マルチメディアソフト」というのもありまりました。
どちらもMACのソフトですが、今の言葉で言い換えれば、正に「新時代の電子書籍」でした。
しかしこれらは真の「電子書籍」とは言えません。

現在、世界中の出版界を巻き込み、グーテンベルグ以来の書籍革命と呼ばれる「電子書籍」の出現は過去のものとは全く異質なものです。

現在の電子書籍に必要な特徴として、以下の5項目を挙げてみました。

1. 独立したデバイス
   少なくとも8時間以上はバッテリーが持って欲しい。
   これじゃないと、自由に本を読むなんて普通のことができない。
2. テキストを引用（コピー）し再配布可能な構造。
   テキストじゃないと! 個人的にはDRMは×です。著作権や費用回収云々の問題じゃなく、自由じゃないからです。
3. 出版の自由を確立するために、誰でも（多くの人に）作成可能で単純な構造。
   電子書籍の時代はself publishingの時代です。
4. 1000年後も再生可能な記録、又は配布方式（ファイルフォーマット）
   紙書籍って以外と長持ちです。電子情報の脆弱性と未来互換の低さは危険ですね。
   これはデータをできるだけプレーンなテキストにしておく必要あり。
5. 自由なマーケット拡大を阻害しないために、物理的な制限を設けない。
   もちろんWEBも物理的だけど、、ネットさえ繋がっていればどこへでもコンテンツが送れないと!

上記特徴の項目には、実際にはデバイスとコンテンツ（ファイル）、配布の3つが含まれていますが、 ここで問題なのが、上述した2と3（+4も）の「電子書籍フォーマット」(※1)に係わる項目です。

現在電子書籍と呼ばれるものには様々なフォーマットや方式が存在しますが、個人的にはePUB形式が適当で主流にもなると思っています。

そこでこちらも個人的に「電子書籍」を定義しました。
このあたり、簡単にでも決めておかないと、仕事の時に困りそうなので。

• 電子書籍
  ePUB（広義ではSGMLやXMLのサブセット。）
  構造化された文章構造を持つもの。
• アプリ書籍
  それ以外のもの（pdf,FLASH,iPhoneアプリなど）
  FLASHやアプリからxmlを読み込んで、、と言うのは今のところグレーゾーン書籍っていうことで。

電子書籍 ePub 電子書籍の作り方2 シンプル ePUB フォーマット ガイド :How to create an ePub ebook? Simple ePUB Format Guide

suc - 電子書籍

2010年 5月 22日(土曜日) 11:16

「ePub電子書籍の作り方2」では実際のePubファイルの構成を簡潔に紹介します。
尚、以下の記事をePubファイル化したEpubFormatGuide20100527.epubを用意していますので、参考にしてください。（実際にはePUBファイルを作成した後に、そのソースコードをサイトに掲載しました。そのため写真もセンタリングのままです。）
作成にはDreamweaverを使用しています。※確認はEPUBReader、Win版Stanzaのみです。iPad実機テストは行っていません。（誰かお願い!）

ePUB Format Guide

はじめに

この書籍はePUBフォーマットファイルの構造を簡潔に記したものです。
ePUBフォーマットファイルの作成を用意に理解するために極力シンプルな記述を紹介しています。
詳細、又はより正確な情報は以下をご覧下さい。
http://lost_and_found.lv9.org/opf/opf_2.0_final_spec_ja.html　日本語
http://www.idpf.org/2007/ops/OPS_2.0_final_spec.html　英語
http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html　英語
http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm　英語

基本

ePUBファイルはXML、HTML、CSS、画像等から構成されています。
また全てのファイルはzip形式で圧縮され拡張子がepubでなくてはなりません。
zip形式での圧縮方法は「圧縮」をご覧下さい。

ファイル構成

このドキュメントでは最も単純なePUBファイル例を基本に説明いたします。
必須ファイル以外は必要のないものもありますが、ファイルの構成が理解し易く応用可能なように設置しています。
mimetype、META-INF、container.xmlは名称、所在とも変更できませんが他のファイルは自由にアレンジ可能です。
必要な場合は適宜フォルダを作成し分類します。

• EpubFormatGuide
  • mimetype
  • META-INF
    • container.xml
  • content.opf
  • toc.ncx
  • page001.xhtml
  • style.css
  • cover.jpg

mimetype

必須ファイルです。
名前と所在は変更できません。
このファイルがzip圧縮されたepubファイルであることを示します。

内容

META-INF

必須フォルダです。
名前と所在は変更できません。
container.xmlを含みます。

container.xml

必須ファイルです。
名前と所在は変更できません。
content.opf を指定します。
content.opfのファイル名、所在を変更している場合はファイル名と所在をフルパスで記述します。

内容例

<?xml version="1.0"?>
　<container version="1.0" xmlns="urn:oasis:names:

tc:opendocument:xmlns:container">
　　<rootfiles>
　　　<rootfile full-path="content.opf"

 media-type="application/oebps-package+xml"/>
　　</rootfiles>
　</container>

content.opf

必須ファイルです。
名前と所在は任意です。
epubファイルを構成するファイルへのパスとファイル名を記述します。

• metadata
  • title タイトル　（必須）
  • language　ランゲージコード　（必須）
  • identifier URIやISBNなどを使用したユニークなID　（必須）
  • その他の項目はオプション
• manifest
  mimetype, container.xml, content.opf以外のドキュメントのファイルリスト。（記述順は自由です。）
• spine
  実際のファイルの読み順を指定します。idrefはユニークでなければなりません。

内容例

toc.ncx

任意のファイルです。
名前と所在は任意です。
epubファイルの目次です。
以下にアトリビュートを記します。

• head
  • uid
    content.opfで付けられたユニークなIDです。
  • depth
    1以上の整数。navMap内のコンテンツ階層の深さ。
  • totalPageCount
    0を指定します。
    
  • maxPageNumber
    0を指定します。
• navMap
  コンテンツテーブルです。
• navPoint
  • id
    ユニークなIDを付与します。
  • playOrder
    1からの整数を付与します。
    navMap での並び順を指定します。
• その他詳細（英文）: http://www.niso.org/workrooms/daisy/Z39-86-2005.html#NCX

内容例

page001.xhtml

任意のファイルです。
名前と所在は任意です。
コンテンツページです。
多くのリーダーソフトで表示可能にするために、拡張子xhtmlのvalidな記述が推奨されます。
また、日本語表示のために<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">の記述とフォトの埋め込みが良いでしょう。

style.css

任意のファイルです。
名前と所在は任意です。
スタイルシートファイルです。
多くのリーダーソフトで問題無く日本語表示するためにフォトの埋め込み指定を行うのが良いでしょう。

cover.jpg

任意のファイルです。
名前と所在は任意です。
画像ファイルです。

圧縮

関係する全てのファイルをzip圧縮し、拡張子をepubとしなければなりません。
このときmimetypeは非圧縮で最初に読み込まれるように圧縮する必要があります。
※本ePUBファイルは簡易にVISTAので圧縮（マウス右クリック>送る>圧縮（zip形式）フォルダ）しています。 EPUBReaderやWin版Stanza では問題は見られませんが、障害等見られましたら是非ご一報ください。
zipコマンド:http://lowfatlinux.com/linux-zip-manual.html
コマンド例:

zip -Xr9D EpubFormatGuide.epub mimetype *

バリデート

http://threepress.org/document/epub-validate

電子書籍 ePub電子書籍の作り方1:How to create an ePub ebook?

suc - 電子書籍

2010年 5月 19日(水曜日) 04:49

ePUB電子書籍制作に関するレイアウトの問題点

現在、電子書籍には様々なフォーマットが存在しますが、最も有望視されているファイルフォーマットはePUBです。
ePUBが今後主流になる理由としては、第一にオープンであるということ、第二に既存のXMLやCSSをベースにしているテキストファイルであるということ（ZIP圧縮された拡張子ePUBファイルですが、）第三に多くの電子書籍関連ベンダーがサポートし、ファイル制作者の間でも標準形式として認知されていることなどが上げられます。
（現在KindleはePUBを採用していません。）

しかし、このePUBフォーマットは旧来の紙媒体による書籍の延長線上で電子書籍を捕らえた場合、様々な問題点を感じます。
単純なところでは、日本語固有の縦書、ルビ、縦書き横書きの混在、縦中横、傍点などへの非対応が考えられます。
私自身はこれらは大した問題では無いと考えていますが、今回、電子書籍を作成して、感じた最も大きな問題点はページの存在そのものでした。
紙媒体による書籍はページの概念があり、電子書籍もその延長線上での発想なので、ページの概念があります。
（厳密にはePUBを表示するリーダーソフトの多くが紙書籍のメタファを採用しているためです。）

最近発売された、appleのiPadなどではアニメーションによるページめくりが擬似的に再現されています。
何らかの情報セクションを移動していることを明確にするためのインターフェイスは意味のあることだと思いますが、本来このページめくりは電子書籍には必要ありません。

もちろん、紙書籍では単ページで表現しきれない情報を“見開き”で表現したり、ページの表と裏を利用して情報を伝えるといった物理的な手法であり、ページの存在とそれを利用した様々な表現方法の発生は自然なことです。
しかし、これらの紙書籍固有のレイアウトを電子書籍（ePUB）で再現するには今後様々な問題が発生し、その多くは解消しないでしょう。
ページめくり自体が古いノスタルジックなインターフェイスと言えるでしょう。

電子書籍の作成ニーズについて

電子書籍の作成には大きく分けて二つの市場ニーズが発生します。
一つは旧来の書籍を電子化する流れです。
現在多くの紙書籍が存在しますので、それらの資源を電子書籍化するニーズは非常に高いものがあります。
ただ、殆どの情報は20年程度のライフサイクルしか持っていませんので、今から20～30年後に紙書籍情報の電子化に取り掛かると無駄な作業が随分と省けるでしょう。
もう一つは、今後作成されるピュアな電子書籍（ePUB）です。
Amazon、iPadなどのマーケットの拡大を考慮に入れ電子書籍普及のスピードを考えると、ピュアな電子書籍を出版することは最も優先すべき課題の一つです。

旧来の書籍を電子化する

小説など文字を中心とした書籍

前述したように、実際にはあらゆる情報には寿命があるので、実際には現存する殆どの書籍は電子化する必要は無いでしょう。
電子化を考慮しなければならない物としてはベストセラー作家や再版を繰り返しているもの、歴史的価値のある書籍などでしょう。
レイアウト上、縦書きやルビの実現といった小さな問題は見られますが、不況下にある出版界にとって、今後の電子書籍マーケットのチャンスと市場ニーズを無視する材料にはならないでしょう。
たとえ表現上の問題は解決されてもされなくても、電子書籍の普及を阻害する要因にはならないというのが個人的な予測です。
（追記:辞書類はファイルの特性からePUB化には向いていないでしょう。）

コミック類

多くの作品が、単ページでレイアウトされていますので、こちらも大きな問題は発生しないと思われます。ただ、これらのコミックはePUBといっても紙面をスキャニングしただけの画像中心の電子書籍となります。
基本は画像データですが、主要な章の目次は作成しておきます。

HOW TO本やマニュアル

簡単なイメージに対するfloat処理程度でしたら可能でしょうが、レイアウトが複雑なものはePUBに向いていません。
紙書籍で見られるコンピュータ関係のHOW TO本のレイアウトなどは再現不可能でしょう。
現在のリーダーはCSSが普及し出した頃のWEBブラウザに似ています。
ePUBの分野でもテーブルタグによるレイアウトが一時的に再度注目を浴びるのではないかとも思っている程ですが、セマンティックな流れから考えると止めた方が良さそうですね。

雑誌類

上記のHOW TO本やマニュアルと同じ理由で、現在の雑誌レイアウトをePUBで再現することは不可能でしょう。
iPadなどではアプリ化された電子書籍も数多くリリースされるでしょう。既存の高級雑誌などはこの方法での再現が現実的です。

絵本や写真集（見開きなど変則的なレイアウトが発生する書籍）

絵本や写真集などもページの概念を利用したレイアウトが多く見られますので、ePUB向きとはいえませんが、レイアウトそのものは単純なので今後より単純化された電子書籍がリリースされると思います。

HOW TO本やマニュアルの寿命は短いので、慌ててePUB化する必要は無いかも知れません。
とにかくiPadで読める書籍にをリリースしたいのであれば、画像によるePUBが最も手っ取り早い方法ですね。
絵本なども現在のePUB向きでないことは確かですが、今後もレイアウトが不可能な訳でははありません。
これらのレイアウトに関するノウハウと言語の改善により可能になると思っています。
特にレイアウト上のノウハウはiPadのような実機が市場に広がることによって急速に確立してゆくでしょう。
次に純粋な電子書籍（ePUB）の作成を考えてみます。

ピュアな電子書籍（ePUB）の作成

小説など文字を中心とした書籍

文章が中心の書籍はePUB向きです。
携帯小説などが受け入れられている現状から考えても、あまり複雑なレイアウトは必要ないでしょう。
レイアウトとしては横書き、挿絵等は極力排除した方が良いでしょう。
挿絵を挿入する場合は文字を回り込ませず、センタリングにより段落内に配置するのが良いでしょう。
縦書きに比べて横書きの日本語は一行あたりの文字数が多くなると極端に読み辛くなるので、文章に区切りに考慮しなければなりません。

コミック類

コミック類は今後海外市場を考えた場合、左開きの文字横組みで作成するのが良いでしょう。
これはePUBフォーマットとは直接関係ありませんが、他の種類の書籍にも共通し、書籍が電子化することによって海外市場での流通問題は解消します。
クリエーターは自己の作品を如何にグローバル仕様で作成しておくかを考えなければなりません。
国内向けの右開きの縦書きコミックを作成する場合も、漫画家は右、左、どちらのページ配置でも可能なように構成する必要があります。（鏡面反転にも耐えれる絵とレイアウト構成が必要かもしれませんね。）
文字をテキストデータのままレイアウトするのが理想ですが、それはちょっと難しいので、画像が主流となるでしょう。
画像による文字表示がどの程度まで可能かという問題はWEBページの世界でも同じですが、デバイスにより画面解像度が違ってきますので、実機テストが必要です。

HOW TO本やマニュアル、絵本や写真集

既存の紙書籍レイアウトとは違ったアプローチのレイアウトが必要です。
既に米国あたりでは簡潔（単純）なpdfによるマニュアルなどが見られますので、このあたりが見本になるでしょう。
現在よく見られる図版や複雑な表を使ったレイアウトは避けるべきでしょう。
図版の挿入の場合は文字を回り込ませず、センタリングにより段落内に配置するのが良いでしょう。
レイアウトそのものは単純なものが推奨されますが、ePUBはSVGの埋め込みも可能ですので、図版の表現力は相対的に増すと思われます。

雑誌類

ePUBによる自由なレイアウトは模索されるべきですが、雑誌のような「構造化していない」ドキュメントは最もePUBには不向きなので、新たなレイアウト思考が必要となります。
それは､前述のSVGを多用したものかも知れませんし、紙雑誌を作成したデータからそのまま画像出力したものでePUBファイルを作成したものかも知れません。 （デザイナーの腕の見せ所ですね。）
多くの出版者が望む分野ですが、確率した手法は見られません。
後述するiPadの表現力から考えると、iPadアプリの可能性が最も高いのかも知れません。

今後の書籍販売は、電子書籍販売を行い必要であればオンデマンド印刷によるプリント本の販売にも対応するのが直近のニーズに合致した方法だと思えます。
雑誌などレイアウトの複雑な書籍がePUBに向いていないことは確かですが、だから、「pdf」で、という結論ではありません。
InDesignなどで構造化していない書籍を「自由」にレイアウトし、pdfやアプリ書籍としてリリースするのは商売的に言えば正しいかもしれませんが、そ れは将来再利用できないデータ的クズ書籍を市場に広める行為だと思います。
「近々紙の本が無くなるのか?」と言った議論が良く聞かれますが、「無くなる」がどの程度のことを指しているかによってその答えは変わってきます。
しかしながら、書籍にとって本当に意味があり必要なものが、テキストであり情報であることを考えると紙書籍の体裁そのものは本来邪魔なものであると思えてなりません。
私自身も「本」が好きですが、私が好きなのは「本」というフォルムではなくその「中身」です。
ようやく書籍は「紙」という重い殻を脱ぎ捨てることができる時代になったのだと思います。
著作商品を売るマーケットは存在し続けますが、本を売るマーケットは無くなるでしょう。

ePUBリーダーを考える

結局のところePUBファイルを表示するのはリーダーソフトや電子書籍端末です。
そのためePUBファイルにおけるエディトリアルデザインを考えた場合、最も注意しなければならないことはどのターゲット（デバイス）に対してファイルを作成（レイアウト）するのかといったことです。
WEBの世界ではモダンブラウザが主流になり、IEの呪縛かも開放されつつあります。
しかし残念ながら、ePUBファイルを表示する端末やソフトには様々なものがあり、これらのソフトウェア上での表示互換は暫くの間、期待できないでしょう。
そのため、明確なターゲット（リーダーデバイス）を決めた後に書籍のレイアウトを行う必要があります。

画面比

ePUBファイルの表示は基本的に伸縮自在です。
文字サイズも自由に変更可能ですので、通常はレイアウト幅100%に設定し、文章はWEBページと同様に句点で改行するのが基本です。
そのためレイアウトには画面の縦横比が関係します。
以下の資料から考えても、概ね1:0.7程度でレイアウトするのが良いでしょう。
注意)現在KindleはePUBに対応していません。
今後ePUBに対応することを強く望んで（信じて）います。    

※iPadでは画面を横に倒すと表示されている書籍が見開き状態で表示されます。
これは見た目非常に面白いのですが、ePUBを基本とした電子書籍には全く意味の無い機能であるばかりか、この機能があるために誤ったレイアウトのePUB書籍が多くリリースされるかも知れません。

モノクロ/カラー（アニメーション）

現在、KindleはE Inkを使ったグレースケールディスプレーです。
1～2年以内程度でカラー化した電子ペーパーが採用されるでしょうが、今現在はiPadのみがカラー対応電子書籍デバイスといえるでしょう。
本来、iPadとKindleはまったく開発コンセプトが違い、よりピュアな電子書籍端末はKindleだと言えます。
将来、Kindleがカラー化されても電子ペーパーの表示可能なフレームレートは低いので、快適なアニメーション表示は暫く先のことになりそうです。
この点から推測して、カラー表現の電子書籍はあと1年～2年程度はiPad（もしくはコピー商品）の独占市場であり、よりリッチ（マルチメディア的）な電子書籍は4年～5年程度、こちらもiPad（もしくはコピー商品）の独占市場となります。
ただ、これらのリッチ電子書籍のマーケット（非ePUB書籍）規模がどの程度かは現時点で判断できませんが、個人的にはePUBマーケットがその何十倍にも拡大すると考えています。

追記)ここで私が現在ePUBに対応していないKindleに言及するのは、Kindleが最も電子書籍端末として完成しているからです。
また、Kindleを発売しているAmazonは電子書籍マーケットを左右する大きな存在として無視できず、今後電子書籍をリリースする全ての関係者にとっては悩みの種になるからです。
そう、KindleがePUBに対応してくれないと困るのです。。  

実際の作成方法はこちら。

電子書籍のマーケット

suc - 電子書籍

2010年 4月 29日(木曜日) 04:26

紙の本のマーケット

iPadやkindole、nookが販売され、国内にいても電子書籍への期待度が非常に高まってきました。
個人的な予測では3年以内に多くの書籍が電子化され電子書籍マーケットは急拡大するでしょう。
勿論、紙の本が3年後に全く無くなるなどとはいえませんが、気が付けば無くなっている。。と言った状況が起こっているでしょう。
そこまで到達するには、多分10年程の時間が必要と思いますが、確実にやってくることに間違いありません。

CDの販売推移はインターネットでの音楽配信の影響を直接的に受けていることを表していますが、電子書籍のマーケット成長も同様の推移をたどると思われます。
（音楽CDは紙の本と違って最後には全く姿を消すでしょうが。）

電子書籍のマーケット

それでは電子書籍マーケットは今後どうなるのでしょう。
ここで「電子書籍マーケット」といっても電子書籍の“何”のマーケットを考えるかが重要です。
つまり正確には「電子書籍●●マーケット」について考えなければならないのです。

現在の書籍マーケット

1. 電子書籍コンテンツマーケット
   これはコンテンツ制作のこと。
   執筆者（小説家、漫画家、画家、エッセイイスト、詩人、評論家、ブロガーなど、、）
2. 電子書籍プロダクツマーケット
   つまり、本を作るところ。出版社です。
3. 電子書籍流通マーケット
   現在の出版取次ぎのことで、トーハンや日販のことです。
4. 電子書籍販売マーケット
   現在の本屋さんです。
   

未来の電子書籍マーケット

現在のマーケットが今後どのように変化するか。
キーワードは個人レベルで行える作業がどの程度の割合かにより、現在のマーケットが今後どのように変化するかといったことが考えられます。

1. 電子書籍コンテンツマーケット
   変化ありません。
2. 電子書籍プロダクツマーケット
   現在の書籍制作は様々な技術や設備が必要ですが、電子書籍の制作は個人でも可能になります。
   ただ、書籍としての文章校正やレイアウトやなどのクオリティ維持にはプロフェッショナルな技術が必要です。
   電子書籍のファイルフォーマットがpdfであれば簡単な出力で済みますが、主流はePUBに向かっている様子です。
   ePUBのレイアウトは現在CSS2で将来的にはCSS3に移行するでしょうが、日本語固有の縦書きやルビなどへの対応はかなり遅れるでしょう。（もしかすれば対応されないかも知れない。）
   電子書籍とはいってもePUBフォーマットは現在のWEBページ作成と同じです。
   現状のWEBページに縦書きページが無く、WEB独自のレイアウト方向に向かっていることを考えると、ePUB電子書籍も同じ道を辿ると考えられます。
   尚、出版社は流通とのパイプを持っているので、その後の電子書籍販売を考えた場合、個人製作には課題が残ります。
   つまり、電子書籍は個人でも制作できるが、、やっぱり、ちょっと難しい。。けど、頑張ればできる。ですね。
3. 電子書籍流通マーケット
   必要無くなります。
   流通とは基本的に物流を扱う技術です。
   電子書籍に限らず、物流を必要としないデジタルコンテンツは今までのような複雑な物流システムは必要ではありません。
   現在の書籍販売では最終的に全国の本屋さんに本を並べる必要があるので、このような流通マーケットが存在します。
   ISBNコードのような管理コードの付与も独占的な流通システムの上に成り立っています。
   紙書籍の場合は著者を特定し、コピーや偽著者の書籍出版をブロックしているとの考えもありますが、この問題に関しては他のデジタルコンテンツ（音楽、ブログ、Twitter等）全てに関する課題ですので、問題として取り上げるには無理があるでしょう。
   また、DRM（Digital rights management）は技術的には可能でも本来のWEB志向ではありません。著作物の権利と利益を守るには技術で無く、新たなビジネスモデルが必要だと考えています。
4. 電子書籍販売マーケット
   リアルな本屋さんは姿を消し、amazonやiBookstoreなどネットワーク上でのダウンロード販売が一般的となります。
   現在のところISBNの付与が必須なので、前述の流通も含めた古い（現在）の体質が問題となるでしょうが、海外では格安のISBN付与や個人でも可能な電子書籍の販売サイトが次第に姿を見せ初めています。
   kindoleとiPadは開発コンセプトが違いますが、kindole向けの書籍であればより自由な販売が可能でしょう。
   また、kindoleやiPadは現在の書籍を非常に意識した（影響を受けた）サービスとなっていますが、これらの体質から脱却してた新しいサービスも生まれて来るでしょう。
   
   勿論どのサービスが成功するか? 解りませんが。

電子出版のまとめはじめ

suc - 電子書籍

2010年 4月 11日(日曜日) 07:45

色々電子書籍に関しての情報があり、先駆者達もがんばっています。
そろそろ、自分のためにも情報をまとめておこうと思い、カテゴリを作成しました。
カテゴリ名は「電子書籍」と硬いです。。対象はiPad、Kindle、Nookなどです。
フォーマットはpdf、ePUBなどです。

ePUBの概要

ePUBの実態はXMLファイルとXHTMLファイル、CSSファイル等をZIP形式で圧縮し拡張子をepubとしたものです。
なので、一般的な圧縮ソフトで解凍し、各ファイルを確認することが可能です。

http://naoki.sato.name/lab/archives/45 

http://blog.elearning.co.jp/?p=4193

http://admn.air-nifty.com/web_design/2010/04/file-514epub---.html

ePUB作成

作成方法は、Adobe Indesign等ページレイアウトソフトで編集したファイルをePUB形式で書き出したり、pdfファイルをePUB変換するなどの方法が考えられますが、現在（2010年4月現在）満足できる方法は確立していません。
多くのソフトや変換サービスで、日本語の縦書きが再現されなかったり、文字化けが発生します。
このあたりは、現在採用されているCSS2が縦書きに対応していないためです。
縦書きの問題も含めて、日本語固有の問題の解決には大きな課題があり、早急なる解決は難しいでしょう。

それでは、、縦書きができないから、電子書籍を諦めるのかという問題になりますが、この際、縦書きを諦めようというのが個人的な意見です。
http://plusd.itmedia.co.jp/pcuser/articles/1004/08/news020.html

ePUBのオーサリング環境は今後、次第に充実してくると思われますが現在のWEBページオーサリング環境から考えても、質の高いレイアウトには専門のクリエーターが必要となるでしょう。
このことから考えて、ePUBファイルの作成はIndesignのようなページレイアウトソフトの役目では無く、DreamweaverのようなWEBオーサリングソフトの役目だと考えられます。（IndesignやDreamweaver よりもオープンな制作ツールの充実を強く望みます）
電子書籍市場は多くの出版関係者が注目していますが、制作に最も近いのはWEBデベロッパーでしょう。


販売はappleやamazonが直販を行いますので、出版社の必要性は高くありません。
ただ個人でePUBファイルを作成することには無理がありますので、これらの作業をコーディネート、ISBNコードを付与するマネージメント仲介業者の必要性は強く感じます。


結論として現状の出版社が自らのノウハウを基にして、全く新しいビジネスモデルを試行すればそこには大きなチャンスがあるでしょが、書籍の電子化が自分達の側に近付いて来たと考えると、大きな間違いを犯し業界の破壊を早めることになります。

現在最も簡単、確実にドキュメントをePUB化するには画像を変換する方法が考えられます。
先ず、ページレイアウトソフトで各ページを連番画像として書き出します。
次に、「ChainLP V0.37-2 」 等ソフトでePUBファイルに変換します。
この方法は確実ですが、もちろん文字検索などには対応していません。コミック等、画像を中心としたePUBファイルの作成には適しているでしょう。

Adobe Indesignでの書き出し

Adobe Indesign  で Digital Edition用に書き出しを選びます。（CS4で確認）
表一、表四が書き出されず、縦書きが再現されません。

サンプルファイルを作成しました。iPhone、iPad、Nook、Sony Reader 等で閲覧可能です。
実機テストはしていませんので、コメント等頂けるとありがたいです。
DOWNLOAD 

pdfからePUB変換

フリーのpdf –> ePUB変換サイト。だけどページが目に痛い  
http://www.epub2go.com/Web/default.aspx

有料の変換ソフト

http://www.pdftoepub.com/

http://www.pdftokindle.com/

html –> ePUB「Book Glutton」

https://www.bookglutton.com/api/convert.html

「Feedbooks」

http://www.feedbooks.com/

「ブログ出版局」電子書籍ツール(公開実験中 ～5月31日まで)
http://print.cssj.jp/2/ebook/#publisher

連番画像のePUB化

「ChainLP V0.37-2 」
http://no722.cocolog-nifty.com/blog/chainlp/index.html
http://naoki.sato.name/lab/

電子書籍の管理ソフトでファイル変換も可能
http://calibre-ebook.com/

ePUBオーサリングソフト

「sigil 」
http://code.google.com/p/sigil/
「eCub」
http://www.juliansmart.com/ecub/

「eBook Publisher」

http://www.ebooktechnologies.com/support_publisher_faq.htm

ePUBリーダー

「Stanza 」
http://www.lexcycle.com/
Firefox addon「EPUBReader」
http://www.epubread.com/en/
「AZARDI」
http://www.infogridpacific.com/igp/AZARDI/

リンク

http://www.lexcycle.com/faq/how_to_create_epub

電子書籍のマーケット