「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からの変換サービス

電子書籍のマーケット

An April fools joke?
http://appshopper.com/entertainment/sketchbook-pro
This is the incredible news! Autodesk SketchBook Pro for iPad will release on april 3rd.
price: ONLY $7.99 but possibly finger s tap?

youtubeと言えばもちろんフリーの動画投稿サイト。
日本国内でも様々な利用がされて、知り合いの制作会社でもyoutubeプロモーション(CM)が盛んで、地上波の時代は終わったと言っている。
日本ではニコニコ動画        なんでものもあるが、国外の動画サービスは格段の広がりと発展を見せている。

個人的にはvimeo.com などがセンスも良く、クオリティと画質の高い動画を提供しているので好きだ。
hulu.com は米国で最も伸びている動画サイトだが、残念ながら日本からの視聴はできない。
このサイト、日本で言えば、radiko.jpのようなサイトなので、それも仕方ないだろう。

上記動画サイト以外にも、注目しているのが、5min.com
How to 専門のサイトだ。
このあたりを見ると、米国のすそ野の広がりと層の厚みを感じる。

しかし、やはり今一番の注目株は、ustream.tv だろう。
ソフトバンクによる日本向けサービスが決まっているので、日本国内でも利用シーンが広がるだろうが、このサイトは何しろストリーミングが手軽にできるのだ!
しかも、、無料で!!

さあ、僕もustream.tvのアカウントを持っているから、、何かLIVE番組でもはじめようかな。。

ページ制作をしていると、よくアイコンの必要性に迫られる。
WEB上には様々なアイコン配布サイトがあるが、今日はその一つで規模も大きいfindicons.comのご紹介。
 image
キーワード検索や一覧表示から目的のアイコンを見つける!


image 
キーワード検索結果画面

検索した結果から更にバックグラウンド色、サイズ、色イメージなどで絞り込むことも可能だ。


image
変換画面

アップロードしたアイコンを変換して、そのままダウンロードできる。

APIも公開予定とのことなので(アイコン検索と作成のAPIって、、)、色々な利用サービスの出現が楽しみ?!

ページ制作をしていると、よくアイコンの必要性に迫られる。
WEB上には様々なアイコン配布サイトがあるが、今日はその一つで規模も大きいfindicons.comのご紹介。
 image
キーワード検索や一覧表示から目的のアイコンを見つける!


image 
キーワード検索結果画面

検索した結果から更にバックグラウンド色、サイズ、色イメージなどで絞り込むことも可能だ。


image
変換画面

アップロードしたアイコンを変換して、そのままダウンロードできる。

APIも公開予定とのことなので(アイコン検索と作成のAPIって、、)、色々な利用サービスの出現が楽しみ?!

twitterは“つぶやき”を発信できるサービスだ。
こう書いてしまうと、やったことの無い人にとっては意味不明になる。
別の言い方をすれば、『twitterは短い文章を発信するサービス』と言える。
twitterではこの短い文章を“つぶやき”と呼んでいる。
twitterを利用している者は各自の発信した文章がリスト表示されるページを持っている。
僕自身も1年程前にアカウントを作成し、実験的に利用している。
ある人のつぶやきを見るためには、その人をフォロー(書き込まれたら知らせてくれる設定)するか、検索するしか無い。

このtwitter、巷で言われているように中々面白いシステムだ。
ブログの代わりだとか言っている人もいるが、リアルタイム性から言うと、“公開チャット”に等しい。
チャットとの違いで言えば特定の相手やテーマ(話題)を持っていないところだろう。 (だから、つぶやきとなる。)

チャットシステムで最もグローバルなサービスを提供しているのはSKYPEやメッセンジャーだ。
これらは動的メッセージを発信するサービスだが、ブログやホームページは静的メッセージを発信している。
twitterをこの点から分類すると、動的メッセージの発信サービスで、SKYPEの次に位置する物ではないだろうか。

twitterはAPIを公開しているので、最近は中々面白い2次構築サービスも次第に見られるようになってきた。

http://qa-now.com/
http://qanow.nikkansports.com/

このサービスはtwitterのリアルタイム性に着目して、Q&Aサービスを構築している。
上手くいけば、“はてな”などは壊滅するかも知れない可能性を持っている。
現状の問題点としては、意味の無い“つぶやき”があまり多くなりすぎると、このような明確な目的を持ったサービスのブランドを低下させるだろうが、twitterはもともと暇つぶしツールなので、そんなダラダラとしたスレッドも面白いかも。。

http://www.bb-job.com/

このサービスは良い。
僕自身もtwitterを利用したjobマッチングサイトの構築ができないかと考えていたところだった。(先をこされた     
多くのjobマッチングサイトがある。個人的にもそのようなサービス構築に係わった事があるが、既存の古いビジネスモデルには限界を感じている。
近い将来(3?5年以内)、多くの仲介システムの時代は終わるだろうとも思っている。
次に来るのは、よりP2Pに近付き、仲介手数料の低い、リアルタイム性の高いサービスだと思っている。
http://www.bb-job.com/などはその一つの方向性を示している。
もちろん、サービスの信頼性など“運用”に係わる幾つかの問題点をクリアしなければならないだろう。

twitterの問題点

twitterはリアルタイム性の高いサービスだ。
もちろん匿名で使用可能だし、共有設定も可能だが、そのリアルタイム性とチャット的メッセージのやりとりのために個人を特定しやすい。
このあたり、理解していないユーザーも多くてプライベートな情報がだだ漏れ状態だ。
プライベートな情報は自分が漏らさなくても、自分の情報を持つ第三者が漏らせばそれで終わり。
例えば僕の教え子が、『昨日、伊丹先生におごってもらいました! 何でも●●会社のページ制作を相場の倍で制作して儲けたって言ってましたョ!』なんてつぶやかれたら、たまったものじゃない。

前述したように、WEBは、よりP2Pに近付き、リアルタイム性の高い方向に向かうだろう。
twitter(API)の流行は、その大きなきっかけになるだろう。

 

imageArtRage 3ではPhotoshopのプラグインが利用可能です。
ここではArtRage 3にPhotoshopのプラグインを使用するための設定方法を説明します。
尚、プラグインの種類によってパラメータ設定が出来なかったり、「ArtRage」そのものがフリーズすることがあります。
使用の際はご自身の責任で判断し、アートワークの保存、動作の事前確認等をお勧めします。

メニュー > Edit > ArtRage Preference > Filters を選び+(プラス)をクリックしてファイルダイアログボックスからPhotoshopのプラグインフォルダを選択します。
「プラグイン」フォルダに入ったところでOKを押してください。

複数のプラグインフォルダが設定できます。
FireWorksやIndesignなど試してみましたが読み込みませんでした。
他のアプリケーションも読み込み可能かも知れませんが、試す場合は、最悪アプリ本体に障害が発生することを覚悟してください。

ブログエディタとは

Joomla!ではTinyMCEが記事エディタとして初期設定されています。

TinyMCEは非常に高機能なエディタですが、フロントやバックから管理ログインして記事を編集する必要があります。

ブラウザ上で稼動するエディタですので、操作レスポンスなどにも限界があります。

最近では多くのブログで「ブログエディタ」と呼ばれるソフトをローカル(自分の)コンピュータで起動して、記事を編集し、サーバーに投稿するといった方法が良く見られます。

 

ブログエディタ利用によるメリット

  • ローカルコンピュータで記事を作成・編集できる。
  • “ワープロ的”な簡単編集
  • 編集画面が“広い”。
  • 思いついた時に記事を書け、“書き掛け”のまま保存できる。
  • 複数のCMSやブログ記事を一つのソフトで管理できる。

 

「Windows Live Writer」

「ブログエディタ」には様々なソフトがありますが、中でもMicrosoftが無償で配布している「Windows Live Writer」は機能的にもトップクラスであり、ワープロ感覚で記事編集可能な満足できる「ブログエディタ」と言えるでしょう。

ワードからの文章を直接コピー&ペーストしたり、手元の写真を貼り付けたりすることもでき、

インターネット上で配布されているプラグインをインストールすれば、本体に無い様々な機能を付加することも可能です。(2010年2月現在、プラグイン数168件)

もちろん直接HTMLを入力することもできますので、HTMLタグの知識が豊富であればより精細なレイアウトも可能です。

ダウンロードは、Microsoftのダウンロードサイトhttp://download.live.com/writerを利用してください。

 

「MOVABLETYPE XML-RPC 2.3.3」の入手

「Windows Live Writer」は標準で多くのブログサービスやシステムに対応しています。ブログシステムで利用するには問題はありませんが、Joomla!で利用するためにはJoomla!側へ「MOVABLETYPE XML-RPC」プラグインのインストールが必要です。

「MOVABLETYPE XML-RPC」はhttp://www.joomler.net/さんが制作・配布されている、MovableTypeのRPCプロトコルをJoomla!で利用可能にするプラグインです。

この「MOVABLETYPE XML-RPC」のインストールによって、「Windows Live Writer」はMovableTypeにアクセスする設定と同じ設定でJoomla!にアクセス可能となります。

※執筆現在の最新バージョンは MOVABLETYPE XML-RPC 2.3.3 です。

 

Joomla!の設定

ol li{margin-left:15px;}

  1. http://www.joomler.net/から「MOVABLETYPE XML-RPC」をダウンロードして、

    Joomla!の管理画面からインストールします。

    「拡張機能」>「プラグイン管理」>「XML-RPC - MovableType API」を“有効”にします。

    livewriter4 

  2. 必要な場合はプラグイン名をクリックして詳細設定を行ってください。

    「グローバル設定」>「システム」>「WEBサービスを有効にする」を“はい”にします。

     


    livewriter3

 

「Windows Live Writer」の設定

次に「Windows Live Writer」のアカウント設定を行います。 

  1. 一度も利用していな「Windows Live Writer」を起動するとアカウント設定画面が表示されますので、「他のブログサービスを利用する」を選択します。 
    livewriter5 
  2. 「ブログのwebアドレス(A):」にJoomla!のURLを入力します。例:http://www.myblog.com
    「ユーザー名(U):」管理画面へのログインユーザー名を入力します。
    「パスワード(P):」管理画面へのログインパスワードを入力します。
    livewriter6
  3. 「ブログアカウントの設定中」画面の次に「ブログ種類の選択」が表示されますので、「使用するブログの種類(T):」で「MovableType API」を選びます。
    「ブログのリモート投稿URL(U):」にhttp://Joomla!のURL/xmlrpc/ と入力します。
    ※最後の/(スラッシュ)を忘れずに。 
    livewriter9
  4. 「ブログアカウントの設定中」画面が表示された後、「仮の記事を作成」画面が出ますが、テンプレートの検出はできませんので、ここでは“いいえ”を選んでください。
    livewriter10

    「ブログが構成されました」画面で「ブログのニックネーム(N):」を確認して“完了”ボタンを押してください。
    livewriter11

     

Windows Live Writer編集画面

livewriter12  ここでは簡単に「Windows Live Writer」の画面を紹介します。

  1. 記事を直ちにブログ (Joomla!)に投稿します。
  2. 現在、投稿対象としているブログです。
  3. 下書き保存されている記事の一覧が表示されます。
  4. クリックすることによって編集画面に呼び出します。
  5. 最近投稿された記事の一覧が表示されます。
  6. クリックすることによってサーバーから記事をダウンロードし、編集画面に呼び出します。
  7. 設定されているブログシステムに接続して記事を編集画面に呼び出すことができます。
  8. ブログの投稿カテゴリを設定します。
  9. リンクを設定します。
  10. 画像を配置します。サムネール表示の大きさや影付き。枠付きなどを設定することができます。
  11. 表(テーブル)を挿入します。
  12. 追加したプラグインです。
  13. プラグイン追加のためのMicrosoftのサイトを表示します。
  14. 複数のブログが管理可能で、投稿対象のブログをメニューから選択できます。

※詳しい使用方法は、ソフトのメニュー > ヘルプ > 「Windows Live Writerのヘルプ」で閲覧可能です。
   ヘルプサイトURL:http://help.live.com/help.aspx?project=wl_writerv3&market=ja-JP

そうか、2chが攻撃の対象になっていたのか。
http://www.itmedia.co.jp/news/articles/1003/02/news070.html
http://ula.cc/phoenix/

通りで昨日から繋がりにくい状態だと思っていた。
丁度、プロキシの設定をしていたので、何かの設定で弾かれているのかと2日間悩んでいたところだ。
マーフィーの法則的に言うと、『奇跡的なことが複数同時に起こる確率はその奇跡的な確率に反比例して増大する。』のかも知れない。