Kindleをはじめて使用したのは2年以上前のことだ。

その頃、第一次電子書籍ブームが舞い起こり日本も電子書籍元年と呼ばれた。
しかし、実際には日本国内のマーケットや既存の書籍流通が対応できず不発に終った。
米国は確実に離陸を果たしAmazonを始めとする幾つかの先行企業の力もあって、そのマーケットは順調に拡大している。

日本国内はと言えば、本当の意味での電子書籍元年は2012年の昨年である。
楽天がKoboをの力を借りて大々的に電子書籍サービスを始めた。
タイトル数に嘘があるとか、話はさて置いといて、新たなビジネスマーケットがようやく離陸を果たしたことも事実である。
楽天には遅れを取ったが、電子書籍販売で最も長いノウハウを持つAmazonが国内サービスを始めたのも2012年である。

そこで電子書籍リーダー(Kindle)を継続的に使っていて気が付いた事をニ三。

  • その昔Macintoshに感じたワクワク感を感じる数少ないデバイスだ。(今のApple製品には感じない)
  • タブレットよりも不便なのに、メールチェックもやってしまう
  • タブレットよりも不便なのに、ニュースチェックもやってしまう
  • タブレットの使用頻度が極端に減った
  • タブレットの理想の形が見えた(ような気がする)
  • 若干重い
  • 電子ペーパーはやはり近未来デバイスだ
  • 紙の本を読まなくなる → 読みたくなくなる
  • Kindleストアには本が少なく、それに高い
  • 本は少ないが、少ない中から本を選んで購入する傾向にある
  • 読書時間が増えた
  • 一度読んだ本を読み返し易い
  • デバイスが安いので無造作に扱える
  • 紙の本よりも相対的に利便性が高い
  • しおり機能とインターフェイスのカスタマイズ性は高めて欲しい
  • 就寝時に暗闇で読書ができる(これはもしかすれば革命的かもしれない)
  • 壁紙を変えたい(カレンダーとか時計とか電卓とか・・)
  • 色バリが欲しい(わが家には3台あってややこしい)
  • 本の実態は情報なので紙の必要性が無いことを再確認

などなどです。
継続使用してみます。^^

電子書籍(絵本) 『みんな死ぬの?』 英文タイトル:'Does Everybody Die?'

この絵本の原案は随分と以前に思いつきで執筆を始めたものです。
当初は髪媒体での出版を目指していたのですが、タイトルから想像しても理解できるように、一般ユーザー受けは無理だろうと思い、電子書籍化を目指すことにしました。
計画では初期版iPadにあわせての出版を予定していたのですが、幾つかの問題点に突き当たり発行が遅れてしまいました。
先ず最も大きな壁として絵本というコンテンツは以前もそして今現在(2012年)の電子書籍コンテンツには向かないということです。

絵本は紙の大きさをイメージして作られています。
電子書籍書籍に特徴的なリフロー(版面サイズによって文章や図版が移動しすること)な機能は絵本には向かないでしょう。
また、計画的に描かれた絵本の絵は方向が存在します。
例えば日本語の縦書きは右開き(右に開いて左に読み進む)ですが、コミックにも共通します。

Kindleでの発行を目指して英文翻訳に出す

電子書籍の最も特徴的なことに、世界中で自分の本を出版できることがあります。紙の本では不可能なことですが、国に合わせた言語的なローカライズさえ行えば世界同時発行なども可能なのです。
実際に私は『みんな死ぬの?』 を先ず、日本語で執筆し、イラストを自分のイメージにあわせて描きました。
次に書籍をデータ化してDreamweaverでXHTNLコーディングを行いました。
以前よりEPUBの作成はWEBオーサリングツールで行うことが必須だと思っていたのですが、画像付きの絵本となるとなおさらです。

 

ePUBのチェックは http://validator.idpf.org/application/validate で可能だ。最初は山のようなエラーが出るかも知れないけど諦めずにバグをつぶしてゆく。
ePUBは圧縮されたzipファイルであるが、mimetypeを最初に無圧縮しないといけない。
Info-ZIPをダウンロードしてコマンドラインで・・・などの方法が良く見られるが、個人的にはコマンドラインの嫌いなGUI野郎なので、WinRARを使っている。
先ず最初にWinRARでmimetypeを無圧縮でzip化し、次に圧縮したmimetype.zipをクリックするとWinRARのアプリが起動するので、OEBPSとMETA-INFフォルダを放り込んで圧縮する。最後にzip拡張子をepubに変更すれば完成だ。

Length of first filename in archive must be 8, but was 9 ... のエラーに対応方法

このエラーの原因は幾つかあるかも知れないが、筆者が最も多く経験したものは(実際にはこれだけだが)mimetypeを未圧縮で最初に圧縮していないということだ。
できればコマンドのパスを通して・・・などという面倒な方法はとらずに一般の圧縮ソフトを利用してスッキリと解決したかった。
そのスッキリ解決の方法がWinRARにあったのだ。

 

 

ユニークなIDの生成はGUIDGen.EXEを使用している

スタンダードな電子書籍フォーマットePUBの作成サービスを始めました。
現在はβテスト中で無料作成しています。
無料作成期間は未定で、作成ePUBファイルの修正などにも未対応ですが、宜しければご利用ください。

image 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である。
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最高! × 
    もちろんそんな訳は無い。
    単なる通過点だ。

最近、電子書籍関連のニュースも多く個人的にも作成したりしていますが、どうも「電子書籍」という名称がややこしい。
フォーマットが違えばそのフォーマットに対応していないソフトやデバイスでは表示されないことは当たり前ですが、そのうち(既に?)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が優れているという理由では無く、現状は最も適したファイルフォーマットであると言った理由です。
私自身、「ePUB最高!」なんていうスタンスではありません。
「今のところePUBかな、、HTML5でも良いけど、、」程度と思って頂ければ幸いです。

(※1)
厳密に言えば、作成と配布ファイルがあります。
紙書籍は作成と配布の情報形態は同じですが、電子書籍の場合は違ってきます。
例えば、構造化していないデザインをInDesignで作成し、ePUB化すると作成ファイルは将来的に使えないデータです。
このあたりの話は長くなりそうなので、割愛。

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


※Twitterで初期にリリースしたファイルがAdobe Digital EditionsとReader Libraryで表示されないとのご指摘を受けました。
調べてみると、Reader Libraryはチェックが厳しく拡張子のxhtmlやタグの記述がxhtml準拠で無い部分などがありました。(Dreamweaverをちょっと信じ過ぎたかも、、)
Reader Libraryに関しては、ファイルが表示されるようになっても文字化けが解消しませんでしたが、日本語フォントを埋め込むと文字化けは解消しました。
この場合、両リーダーとも日本語言語指定は不要な様子です。(指定しておいた方が良いと思いますが。)
※EpubFormatGuide20100527.epubはフォントを埋め込んでいませんので、Reader Libraryで文字化けします。


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ファイルであることを示します。

内容

application/epub+zip

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はユニークでなければなりません。

内容例

<?xml version="1.0" encoding="UTF-8"?>
<package version="2.0" xmlns="http://www.idpf.org/2007/opf"
unique-identifier="BookId">
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:opf="http://www.idpf.org/2007/opf">
<dc:title>Epub Format Guide</dc:title>
<dc:creator opf:role="aut">伊丹シゲユキ</dc:creator>
<dc:language>ja</dc:language>
<dc:rights>Public Domain</dc:rights>
<dc:publisher>VANrai,Inc.</dc:publisher>
<dc:identifier id="BookId">itami.info123456789</dc:identifier>
</metadata>
<manifest>
<item id="ncx" href="/toc.ncx" media-type="text/xml" />
<item id="style" href="/style.css" media-type="text/css" />
<item id="page001" href="/page001.xhtml" media-type="application/xhtml+xml" />
<item id="imgl" href="/images.jpg" media-type="image/gif" />
</manifest>
<spine toc="ncx">
<itemref idref="page001" />
</spine>
</package>

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

内容例

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE ncx PUBLIC "-//NISO//DTD ncx 2005-1//EN"
"http://www.daisy.org/z3986/2005/ncx-2005-1.dtd">
<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1">
<head>
<meta name="dtb:uid" content="itami.info123456789" />
<meta name="dtb:depth" content="1" />
<meta name="dtb:totalPageCount" content="0" />
<meta name="dtb:maxPageNumber" content="0" />
</head>
<docTitle>
<text>Epub Format Guide</text>
</docTitle>
<navMap>
<navPoint id="navPoint001" playOrder="1">
<navLabel><text>ページトップ</text></navLabel>
<content src="/page001.xhtml" />
</navPoint>
<navPoint id="navPoint002" playOrder="2">
<navLabel><text>はじめに</text></navLabel>
<content src="/page001.xhtml#anchor001" />
</navPoint>
<navPoint id="navPoint003" playOrder="3">
<navLabel><text>基本</text></navLabel>
<content src="/page001.xhtml#anchor002" />
</navPoint>
<navPoint id="navPoint004" playOrder="4">
<navLabel><text>ファイル構成</text></navLabel>
<content src="/page001.xhtml#anchor003" />
</navPoint>
<navPoint id="navPoint005" playOrder="5">
<navLabel><text>mimetype</text></navLabel>
<content src="/page001.xhtml#anchor004" />
</navPoint>
<navPoint id="navPoint006" playOrder="6">
<navLabel><text>META-INF</text></navLabel>
<content src="/page001.xhtml#anchor005" />
</navPoint>
<navPoint id="navPoint007" playOrder="7">
<navLabel><text>container.xml</text></navLabel>
<content src="/page001.xhtml#anchor006" />
</navPoint>
<navPoint id="navPoint008" playOrder="8">
<navLabel><text>content.opf</text></navLabel>
<content src="/page001.xhtml#anchor007" />
</navPoint>
<navPoint id="navPoint009" playOrder="9">
<navLabel><text>toc.ncx</text></navLabel>
<content src="/page001.xhtml#anchor008" />
</navPoint>
<navPoint id="navPoint010" playOrder="10">
<navLabel><text>圧縮</text></navLabel>
<content src="/page001.xhtml#anchor009" />
</navPoint>
<navPoint id="navPoint011" playOrder="11">
<navLabel><text>バリデート</text></navLabel>
<content src="/page001.xhtml#anchor010" />
</navPoint>
</navMap>
</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

※伊丹シゲユキはこのファイルの正確性を保証するものではありません。
※このファイルに起因する損害等発生等に関して一切責任を負いません。
※内容に間違い等ありましたらご報告頂ければ幸いです。
※グラフィックデザイン、WEB、電子書籍に関してはお気軽にお問い合わせください。
※以下のページを参考にしました。この場をかりてお礼申し上げます。
http://naoki.sato.name/lab/archives/45
http://www.kobu.com/docs/epub/index.htm
http://www.hxa.name/articles/content/epub-guide_hxa7241_2007.html

hp:http://itami.info/ mail:This email address is being protected from spambots. You need JavaScript enabled to view it. twitter:@buzzlyhan

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

epubbn 現在、電子書籍には様々なフォーマットが存在しますが、最も有望視されているファイルフォーマットは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に対応することを強く望んで(信じて)います。     Thumbs-up

デバイス 解像度 画面比
Aサイズ 210mm x 297mm 0.7:1
iPad 768px x 1024px 0.75:1
Kindle2 600px × 800px 0.75:1
Kindle DX 824px × 1200px 0.68:1

※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に対応してくれないと困るのです。。   Confused

 

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

紙の本のマーケット

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は現在の書籍を非常に意識した(影響を受けた)サービスとなっていますが、これらの体質から脱却してた新しいサービスも生まれて来るでしょう。

    勿論どのサービスが成功するか? 解りませんが。 Thinking

色々電子書籍に関しての情報があり、先駆者達もがんばっています。
そろそろ、自分のためにも情報をまとめておこうと思い、カテゴリを作成しました。
カテゴリ名は「電子書籍」と硬いです。。対象は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が縦書きに対応していないためです。
縦書きの問題も含めて、日本語固有の問題の解決には大きな課題があり、早急なる解決は難しいでしょう。

それでは、、縦書きができないから、電子書籍を諦めるのかという問題になりますが、この際、縦書きを諦めようというのが個人的な意見です。 Crying
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変換サイト。だけどページが目に痛い   Hot
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

Indesign、QuarkXpressからの変換サービス

電子書籍のマーケット

issuu.comは以前から知っていたので、それじゃぁ、ということでオープンソースのScribusでDTP作業を行い、issuu.comでインターネットパブリッシュしてみました。

以前からあったソースを使って、ありものの画像で簡単に作ってみました。 少々デザイン、レイアウトが荒いですが、Scribusの簡単な使用感のレポートです。

pdfベースのhttp://www.lulu.com/は販売なども手軽に行えてよいのですが、、使い心地としてはFLASHベースのissuu.comtがgoodです。
販売のための機能は無い様子ですが、有料のサービスを使えばアクセス制御が行えるので、paypalで回収してアカウントを発行して・・・とオーソドックスな手法を使えばもちろん可能。

今回少しだけ真剣に使ったScribusですが、、日本語のDTPソフトとしては50%程の仕上がりといえるでしよう。
日本語の縦書きやインライン編集が行えないのは我慢し、シェイプの描画中にフリーズするのも我慢し、日本語文字詰めや禁則処理が無いのも我慢すれば、、中々面白いソフトです。
日本語、横書きの電子出版には使えるかも知れませんね。