EPUB3電子出版におけるインターオペラビリティを考える

投稿日時: 2018年6月15日投稿者: cas-support

先日、CAS-UBのあるユーザーである出版社（版元）から、「これまで長いこと、CAS-UBで制作したEPUB3をBookLive!に配信してきたのですが、今度、これができなくなったのでCAS-UBで対応して欲しい。」という連絡をいただきました。

事情を確認しましたところ、「BookLive!に出すには、横書きではpackage.opfのspineにpage-progression-direction=”ltr”の設定が必要であり、設定しないとBookLive!側では入稿エラーになってしまう。今までは、取次がその版元のEPUB3データを修正してからBookLive!に配信していたが、大変なので版元の方で設定して欲しい」ということになったとのことです。

この根拠は、電書協ガイドver1.1.3のP.8に以下のような記載がある^[1]こと、

パッケージ文書（Package Document / OPF ファイル）
ページ進行方向の遵守：コンテンツ文書やスタイルシートに記された「-epub-writing-mode」の指定にかかわらず、書籍データの「ページ進行方向」は、パッケージ文書の spine 要素に記された「page-progression-direction」の方向に従う。

さらに、取次から次のような連絡があったとのことです。

「電書協ガイドver1.1.3のP.29にある[sample code]にも「page-progression-direction」の記述があり、同梱されているサンプルファイル内のopfファイルにも「page-progression-direction」の記述がございますので、電書協ガイドver1.1.3に「page-progression-directionは必須」とは明記されておりませんが、電書協ガイドVer1.1.3では「page-progression-direction」の記述を入れることを推奨していると思われます。

「page-progression-direction」を記述していないと、ビューア側で独自に綴じ方向を判断することになりますので、「右綴じ」になるか「左綴じ」になるかはビューア側に任せる、ということになってしまいます。

そうなると、ビューアによっては御社の意図とは反対の綴じ方向になってしまうこともありますので、「綴じ方向が逆になっている」というユーザークレームに発展する恐れもございます。

ちなみにEPUB3.0.1の仕様では、この部分は次のようになっています^[2]。

page-progression-direction [optional]
The global direction in which the content flows.

Allowed values are ltr (left-to-right), rtl (right-to-left) and default.

When the default value is specified, the Author is expressing no preference and the Reading System may chose the rendering direction. This value must be assumed when the attribute is not specified.

これを見ますと、EPUB3仕様ではpage-progression-directionはオプション（省略可）となっており、しかも、省略されたらデフォルトと解釈しなければならないということです。従って、BookLive!がこうしたEPUB3を入稿エラーにするのは、EPUB3仕様違反となります。

また、電書協ガイドでも、page-progression-directionの該当箇所は、リーディングシステムに期待する動作の項ですから、EPUB3制作者への要求とはされていません。こうしたことから、BookLive!や取次の理解が間違っていると考えます。『「綴じ方向が逆になっている」というユーザークレームに発展する恐れ』って一体誰の発想なんでしょう？　ブラックなジョークとしか思えませんが、もしかすると、BookLive!ってアラビア語とかヘブライ語のEPUB3も大量に配信されている世界？　それともBookLive!はデフォルトを右開きにするかもしれない異次元空間？

さて、CAS-UBとしてはどうしたら良いでしょうか？　

考えてみますと、この件は「インターオペラビリティ」問題そのものです。

その典型的な例は、WebページとWebブラウザの関係、あるいは、PDF制作者とPDFリーダーの関係に見られます。Webの場合はWebページの文法が少々間違っていてもWebブラウザがなんとか表示できるようにする、という方法で普及してきた、といえます。PDFの場合も同じように少々間違ったPDFであってもAdobeリーダーができるだけ正しく表示しています。それはそれで困ることもありますが。

こうした例を見ますと、少々間違っていても読み手が対応するというのが、概ね利便性が高くなりますし、一般に広く成功を収める秘けつかもしれません。しかし、これは言うのは易しいのですが、リーダーを作る側に相当な体力が要求されます。ビジネスの成功は技術ではなく体力と気力によってもたらされるのが真実かもしれません。BookLive!のような正しいものを拒絶するというのは商売がへたなのでしょう。

（今回の場合、CAS-UBが作るEPUB3は仕様上は正しいですので、上の論点とは若干ズレがあります。念のため。）あまり仕様論・原則論にこだわらない解決策を考えようかと思案しております。

2018/6/22追記
2018年6月21日の定期保守更新にて、下記の仕様変更を行いました。
EPUB生成で、横書の出版物の.opf ファイルのに page-progression-direction=”ltr” を常に入れるように仕様を変更します。EPUBの仕様では、横書のとき page-progression-direction=”ltr” は省略可能ですが、省略を許していない販社があることへの対応です。

この問題は、CAS-UBで当面アラビア語やヘブライ語のような右から左に書く言語のEPUBを作れなくなるという制限が生まれることです。しかし、実際に問題になることはないでしょう。
定期保守更新の全体

[1] 『電書協 EPUB 3 制作ガイド ver.1.1.3』（2014/11/01（2015/01/01 更新、日本電子書籍出版社協会）「リーディングシステムに期待する動作」の一部の記述内容
[2] “EPUB Publications 3.0.1 Recommended Specification 26 June 2014”（International Digital Publishing Forum）3.4.12 The spine Element

Microsoft EdgeのEPUB表示機能はなかなか良い。これからはEdgeだと言いたいところですが、しかし、残念な点もあります。

投稿日時: 2017年4月23日投稿者: cas-support

4月11日にリリースされたWindows 10のアップデート（バージョン1703）でEdgeのEPUBリーダーが一般に使えるようになったとのことですので、早速、Windows 10をアップデートしてEdgeを使ってみました。

EPUB3のサンプルとしては、先日発売しました『XSL-FOの基礎第2版』を使いました。こちらで公開していますので、ぜひ、ご一読ください。

「XSL-FO の基礎 XML を組版するためのレイアウト仕様」第2版【新発売】

Webに公開してEPUBをWebページと同じようにリンクで開けます。

図1　EdgeでEPUBをWebと同じように開く

まず、Edgeでは、Windowの幅により2段組と1段組で表示されます。表示Windowの幅が広いと2段組で、表示Windowの幅を狭くすると1段組となります。

図2　2段組みの表示

図3　1段組みの表示

ページの下部に柱が出ています。左が本のタイトル、右が章または節の見出しです。これはなかなか良いです。

Windowの上部をタップするとメニューが表示されます。

図4　メニューを表示

メニューは左側に「ナビゲーション目次」「ブックマーク（一覧）」「検索」、右側に「文字など表示設定」「音声読み上げ」「ブックマーク追加」です。次の画面はナビゲーション目次を表示したところです。

図5　ナビゲーション目次を表示

音声読み上げはなかなか秀逸です。EPUBには音声同期を設定していないのに、読み上げている文節をハイライト表示します。もうメディアオーバレイによる設定は要らなくなります。

図6　音声読み上げ（ハイライト表示）

このEPUBは、章毎にファイルを分けていますので、新しい章の開始位置で改ページまたは改段します。それは普通です。

図7　章の開始で改段

さらに、節の見出しと次の本文や見出しが同じ段に入らないとき、泣き別れしないように節の前で改段できます^[2]。

図8　節の前で改段

表のテキストだけをポップアップして表示できます。

図9　表のテキストをポップアップで表示

画像は幅または高さに合わせて縮小します。ラスターイメージ（このサンプルではPNG）を縮小すると少し汚くなりますが、図だけ拡大表示もできますので問題はないでしょう。なお、図をSVG形式としたEPUB3版も試して見ました（PDF作成用の図をそのまま使ったもの）。SVGも問題なく表示できるようです。いままで、EPUBを作るときはラスターイメージにしていたのですが、これからは公開するEPUBはSVG画像でも良いかもしれません^[1]。

気になりましたのは整形済み（pre）のレイアウトです。Edgeではpre要素の前で改ページまたは改段します。これは必要ありません。そしてpreの中では改ページ／改段しません。このためpreの部分が見切れてしまいます。技術系の文書では多くの場合、preの内容はサンプルのコードなのでpreの内容を1段に収める必要はないのです。特に、見切れてしまうのは致命的です。評価用ではなく正式なEPUB3ではpreは使えないということになってしまいます。困りましたね。

図10　preの前で改段してしまう。preの内容が見切れてしまう

[1] 『XSL-FOの基礎』画像制作のこと。Word経由でインポートした画像は印刷品質の劣化が激しいため、第2版ではできるだけSVG形式に変更した件。
[2] ちなみにiBooksでは次のように見出しと本文が泣き別れしてしまいます（iBooks 4.1.1）。

Submission Request to W3C from Vivliostyleについての若干の感想

投稿日時: 2017年3月21日投稿者: cas-support

Current Status of Japanese Typography Using Web Technologies（Submission Request to W3C from Vivliostyle）（日本語訳）

という文書が1月27日付けで発表されているので、ざっと見てみた。以下に若干の感想を記す。

まず、この文書の中で一番重要なポイントは「Implementations that support pagination, such as EPUB readers or PDF formatters, do need to support such features.」（日本語訳「EPUBリーダーやPDFフォーマッタなどのページネーションをサポートする実装は、そのような機能をサポートする必要があります。」）という点だろう。

もともとJLReqは、紙に印刷する書籍の組版に関して整理したものである。従って、JLReqを議論の前提にする以上、縦横の大きさをもつページの概念が必須である。ページの概念を無視すれはかなりの部分が意味を失ってしまう。

一方において、ブラウザは画面に高速に表示することを目的としている。そしてページサイズの概念はブラウザには必要ない。このため、CSSの勧告仕様または勧告候補だけでは、まだページの大きさを指定できない。CSS Paged Media Module Level 3という仕様にページの大きさを規定する方法があるが、これはまだWorking Draftの段階であり^[1]、正式な仕様として参照できる状態ではない。

CSS Paged Media Moduleの歴史は古い。一番最初は1999年にHPのRobert Stevahn氏がWorking Draftを出している。その後、2004年に勧告候補まで行ったが、次の2006年版ではまたWorking Draftに戻ってしまった。CSSを紙への印刷に使おうとするとページの大きさの指定は必須であるのに、正式な仕様ではそれができない状態がもう長いこと続いているわけだ。

現在、リフローのEPUB3を表示するリーダーは、ページ捲りを実装しているものが多い。しかし、これらは各リーダーの独自実装である。ページ捲りの一つとして、例えば、章の見出しを画面の上下・左右中央に配置したいときは縦と横のサイズを指定して、その中央に置くのが素直なはずだ。しかし、CSSではそういう指定はできない。このため、日本語のEPUB3ではトリッキーな指定をせざるを得なくなってしまっている。

このように、紙に限らず、画面表示を前提とするEPUBリーダーやブラウザでページめくりをきちんと実装しようとすればCSS Paged Media Module Level3を実装することが必要になる。

そこまでの理屈は良いとして、CSS Paged Media Moduleがブラウザの世界で受け入れられるかどうかが問題である。なぜならば、CSSの仕様開発作業はブラウザベンダーの主導で進んでいて、ブラウザベンダー以外はほとんど影響力を持っていないからである。さらに言うならば、CSS2.0で勧告になった項目でさえも、ブラウザが実装していないことを理由にCSS 2.1で削除されてしまったものもある。その一例がここで問題にしているページの大きさである。CSS2には@pageというルールがあり、CSS2.0ではそこに’size’プロパティでページの大きさを指定できた。しかし、CSS 2.1では’size’プロパティは削除されてしまった。’size’はCSS Paged Media Moduleに移行した。こうした経緯を知っていれば、CSS Paged Media ModuleをCSS3の勧告にもっていくのが困難なことは予想に難くない。

CSSがサポートしないためにできないことがいろいろあるのは確かである。そしてこれに正面から取り組もうとすると、現状のCSSワーキンググループと長く熾烈な論争になるのは確実である。このサブミッションがどう受け止められるか、興味深いところである。

[1] CSS Paged Media Module Level 3　W3C Working Draft 14 March 2013

紙のページと電子デバイスの画面の相違がもたらす、現在のEPUB制作とリーダー開発の難点。

投稿日時: 2016年8月31日投稿者: cas-support

返信

EPUB3には紙のページと同じようなページに関することを指定する仕様は少ない。

紙のページでは次のことができる。

・ページの大きさ（絶対寸法）がある。
・版面の大きさと、版面の位置を指定できる。
・版面の中で左右中央、上下中央、右上、左上という絶対方向を指定しての配置ができる。
・柱やノンブルを配置できる。
・文字の大きさ（絶対寸法）、1ページの行数、1ページの文字数を指定できる。
・左右ページがある。
・横組では左開き（左から右へ）進行、縦組では右開き（右から左へ進行）。
・横組・縦組の混在。
・改ページと改丁を指定できる。
・見開きがある。
・ページシーケンスの偶数開始の指定ができる。

もっと細かいこともあるけれどもそれらはとりあえず省略するとして。

紙のページならできることの中で、EPUB3の仕様で規定されているのは、改ページと進行方向（右開きか左開きかということ）ぐらいである。

上に挙げた紙のページ指定の中には、紙の物的特性と製本という処理に由来するものが多い。そうした特性の多くは、紙を媒体として使うことからくる制約である。そうした制約は、電子デバイスの画面では必要ないか、またはあまり意味のないことが多い。

だから、EPUB3の仕様にページに関する規定がすくないのは自然であるとも言える。

紙には裏表があり、本は背中で製本されているので、本を読む行為はページ捲りの動作と密接に結びついている。しかし、電子デバイスではページ捲りよりもスクロールの方が使い易い。

現在、多くのEPUBリーダーは画面をページのように見立てて、ページめくりっぽいインターフェイスを用意している。これは紙で作った本のイメージを継承するためのギミックである。こうして、EPUB3の仕様に規定されていないページの概念を持ち込んでしまったところに、EPUB制作上の問題、EPUBリーダー開発の難しさが生まれてしまったように思う。

多言語EPUBの作成において考慮すべき技術要件

投稿日時: 2014年11月16日投稿者: cas-support

返信

先日に引き続き、EPUB3で多言語混在の文書を作るために、考慮にいれるべきことを整理してみます^[1]。

第一：言語の指定

EPUBファイルでは、日本語、英語、中国語というような言語の中でパッケージのデフォルトとなる言語を指定します。これはパッケージのメタデータに言語を指定するdc:languageという要素があり、そこに指定します^[2]。このほか、メタデータの要素によっては言語を指定できるようになっています。

本文中で複数の言語を混在させるときには、コンテンツの各ファイル、またはその一部の要素やテキストの範囲に対して言語を指定します。

EPUB3のコンテンツの表現（XHTML5）では、任意の要素にlangまたはxml:langで言語を指定できます。xml:langはHTML形式とXHTML形式に移行しやすくするためのものなので、必ずlangが同時に指定されていなければなりません^[3]。XHTMLをサポートしていないXML処理系で使うことを想定するのでなければ、XHTMLとして使うときでもlang属性のみを指定すれば良いことになります。

さらに、言語だけではなくてスクリプトを指定しなければならない場合があります。例えば、日本語文章で良く使われる外来語は、カタカナで表すこともラテン文字で表すこともできます。もっと、極端な例を挙げますと、ウイグル語のように、政治的な理由で、アラビア文字、キリル文字、ラテン文字、アラビア文字による表記強制を変遷している言語もあります。このように言語が同じでもスクリプトが変わることがあるわけです。但し、Unicodeでは文字コードからスクリプトを推定できることが多く、明示的に指定しなくてもあまり問題にはなりません。

第二：ページを読み進める順序

多言語文書では、ページを読み進める方向、ページの中で文字を書き進める方向を指定したいことがあります。日本語では同じ文書を、横書きでも縦書きでも表記できます。

EPUBでは、ページを読み進める順序は、spineの中のpage-progression-direction属性で全体のデフォルト値を指定します^[4]。横書き、縦書きといった、文字を読み進める方向は、ファイルごとにwitiring-modeで指定できます。ページ単位で読む進める方向を変更できます。つまり縦組みの書籍（右開き）を指定しておき、一部のページを横組に指定できます。

日本語の縦書き書籍では、本文は縦組み、参考文献や索引は横書きというような例が頻繁に発生します。一冊の書籍に異なる読み進め方向を指定することはファイル単位ではできますが、現在のEPUBの仕様では、縦組みの書籍の中で後付け（たとえば、参考文献と索引）を複数のファイルで表現し、その後付け全体を左開きにするような指定はできません。

同じような理由で、英語（左開き）とアラビア語（右開き）を一つのパッケージにすることは現在のEPUB3仕様ではできません。

第三：文章中の多言語テキストの表示（表記）

第三は、文章の中で多言語の記述が存在していたときに、それをうまく表示できるかどうか、ということが問題になります。EPUBではコンテンツをUnicodeの文字列で表します。その文字列をEPUBリーダーが正しく表示できるかどうかということです。日本語や中国語のように、原則として正方形の文字を並べるだけの表記をするときは、Unicodeのコードポイントから文字の形を表示すれば良いので処理は簡単です。但し、縦書きでは句読点など一部の文字の形を入れ替える必要があります。

しかし、アラビア文字、インドの文字、東南アジアの文字は、Unicodeのコードポイントから文字の形にするだけでは足りません。アラビア文字、インドの文字は複雑なリガチャ処理が必要です。また、東南アジアの文字は文字コードの並びから音節を組み立てる処理が必要です。このような言語はEPUBリーダーがスクリプトを処理する機能を備えていないと正しく表示できません。

Unicodeの漢字は、日本語、中国語（簡体字）、中国語（繁体字）、韓国語で同じ字体の漢字を一つのUnicodeのコードポイントに割り当てているため、Unicodeのコードポイントだけでは言語を決めることができません。漢字の中には、日本語、中国語（簡体字）、中国語（繁体字）で同じ字体であっても、字形が微妙に異なるものがあります^[5]。

現在のEPUBリーダーの多くは、多言語を表示できるフォントを内蔵しています。しかし、日本語のフォントで中国語の漢字を表示したりすると、現地のユーザーが違和感を感じる結果になります。そこで、特にCJKが混在するときは言語またはそれに代わるタグ・属性の指定が必須となります。

実用的な多言語のEPUBを作成するには、このようなことを考慮してEPUB3を作るにはどうすると良いか、また、そうして作ったEPUBファイルをEPUBリーダーがうまく表示できるかを調べてみなければなりません。

[1] この記事は、10/25：CAS-UB：多言語機能に魂を入れるため、ドキュメントの多言語化と、EPUBの多言語化を考える、10/29：Noto Sans CJK, Source Han SansフォントとAH FormatterによるPDF生成の続きです。
[2] The DCMES language Element
[3] 3.2.5.3 The lang and xml:lang attributes
xml:lang属性はXMLの仕様で定義された汎用属性。lang属性はHTML/XHTML仕様で導入されている属性です。
[4] 3.4.12 The spine Element
[5] 字体とは字の形の抽象的な概念。字形は具体的な字の形。字形はグリフとも言う。

縦書き書籍（EPUB）で画像を左右中央配置するためのCAS-UBの指定方法

投稿日時: 2014年9月24日投稿者: cas-support

返信

縦書きの書籍（EPUB）に画像だけのページを入れて、そのページで画像を左右中央配置するには次のように指定します。

１．「構成編集」で画像だけの記事を作る
２．画像のブロック（[[[:fig　画像]]]を設定する（図１）

図１　画像のブロックに :fig を指定

説明
行頭の[[[はブロックの開始、その直後の:figはそのブロックを画像ブロックとして扱うことを示します（クラス属性と言います）。
=に続く文字列はキャプションです。
{{画像ファイル名}}　（代替テキストを入れるときは、|で区切ってテキストを置きます。{{画像ファイル名|代替テキスト}}
]]]でブロックの終了を示します。
マークアップ支援ボタン「画像」を使って画像をマークアップするとマークアップが自動的に設定されます。

３．その記事について次の設定をします（図２）
(1) 文字進行方向　「横書き」　　この頁だけ横書きになります
(2) タイトルを本文に出す　チェックをオフに
(3) タイトルを目次に出す　チェックをオフに

図２　記事の横書き設定

説明
(1)文字進行方向は記事単位に指定できます。これにより電書協ガイド方式のタグを出力します^[1]。
(2)、(3)は画像の中央配置とは関係ありません。画像だけのページのタイトルを本文と目次に出さないための設定です。

４．EPUB生成のCSSテーマで「縦書き」を選択し、お好きなCSSテーマを選択します。EPUB全体が縦書きになります（図３）

図３　EPUB生成「一般」で縦書きを指定

５．EPUB3では、画像だけのページができて、画像が左右中央配置になります（図４）

図４　画像とキャプションが左右中央に配置

説明
CAS-UBのCSSテーマではデフォルトで画像のブロック（.figが設定されているブロック）を中央揃えする設定がなされています。但し、この中央揃えは、横書きの左右中央、縦書きの上下中央として働きます。そこで、画像の入ったページだけを横書きに設定することにより左右中央揃えにできます。
ちなみに、中央配置とは「テキストの中央配置(text-align:center)」、すなわち、文字を書き進める方向で見た時の中央配置です。行を進める方向での中央配置は、EPUB3.0では簡単には指定できません。

（注意）ほとんどのEPUBリーダーはキャプションをテキストで設定すると画像が大きくなって上下に一杯になったときキャプションと画像を別ページに配置してしまいます（泣き別れ）（図５）。現在、このようなEPUBリーダーで泣き別れを避けるには画像とキャプションをまとめて一つの画像にするしかありません。

図５　画像とキャプションの泣き別れ

[1] CAS-UB 5月23日のアップデート、ファイル単位の組み方向設定で電書協方式CSSに対応
[2] EPUBとPDFのサンプルを「CAS-UBで作成したPDFとEPUBのサンプルファイル」の3.2 「船中八策」（坂本竜馬）(2)に掲載しました。

ビジネス文書EPUB化普及促進に。ブラウザベースのEPUBリーダーを企業・団体向けに提供開始のご案内

投稿日時: 2014年8月17日投稿者: cas-support

アンテナハウスではWindowsとMac OS X用で使えるEPUBリーダー「AH Reader Preview2」を開発いたしました。本EPUBリーダーは、グーグルのChromeまたはChromiumベースのChrome互換ブラウザに拡張機能として組み込んで使う「Chromeアプリ」です。

「AH Reader Preview2」は、DRMフリーのEPUB3.0ファイルを①ローカルPC（またはインターネット上）から開いて表示、②ライブラリーに登録、③注釈を記入・保存する、といった基本機能をサポートしています。

本EPUBリーダーは、Chromeストアから限定配布するほか、関心をお持ちの方に直接提供致します。Chromeアプリの性格上次の制約があります。

Chromeに組み込んで、その拡張機能として使うには、Chrome Storeから配布するバージョンを組み込む必要があります。Chrome Storeから配布するバージョンでは、EPUBをインターネットから開くことができません。
IronなどのChrome互換ブラウザを使えば、企業内のURLなどから独自にAH Reader Preview2を配布して、ブラウザの拡張機能としてつかうことができます。

Windowsでは、次のような「Windowsのネイティブアプリっぽい」動作を実現できます。
・ショートカットの作成
・デスクトップ
・スタートメニュー
・タスクバーに固定

(1)「AH Reader Preview2」を企業内で利用されることをご希望の場合、無保証・無サポートならば無料で提供いたします。
(2) 動作保証やサポート支援が必要な場合は、サポート契約（有償）を締結していただくことでサポート・サービスを提供します。
(3) 機能の追加や独自バージョンをご要望される場合は、「AH Reader Preview2」に、有償で機能追加したり、カスタマイズ版EPUBリーダーを制作・提供できます。

関心をお持ちの方は、cas-info＠antenna.co.jpまでお問い合わせください。（メールをお送りいただく場合、＠を半角形にした上で送信してください）。

2011年に策定されたEPUB3.0から日本語の縦書きをサポートしたことで、EPUB3は電子書店から販売する電子書籍のデファクトスタンダードになりました。

一方、業務マニュアル、製品マニュアル、技術・事務文書などのビジネス関連文書の多くはPDFで配布・交換されています。PDFは画面の小さなタブレットやスマホでは読みにくいため、今後は、ビジネス関連文書をタブレットやスマホでも読みやすいようにEPUB形式で配布するようになると予想されます。例えば、IBMは既にオフィス文書の標準形式としてEPUBを採用しています^[1]。また、米国ではカンファレンスなどの発表資料をEPUBで配布するケースが見られます^[2]。

現在、EPUBで作成したビジネス文書を表示しようとしてもWindows, Macなどではなかなか良いリーダーがありません。これは、多くのEPUBリーダーが電子書籍ストアから提供されているためです。電子書籍ストアから提供されているEPUBリーダーにはKobo、Book☆Walkerのようにストアとは関係なく制作・配布されている電子書籍を読めるものがあります^[3]が、そのリーダーの多くは多かれすくなかれストアの販売促進の役割を担っています。

こうしたことから、今後はビジネス文書を表示するための優れた汎用EPUBリーダーが必要になるでしょう。AH Reader Preview2は、オフィス文書EPUBの表示用途の汎用EPUBリーダーとして位置付けています。

[1] IBM EPUBを社内文書の標準として使う
[2] Balisage: The Markup Conference 2014 Preliminary Proceedings
[3] EPUBリーダーを集めてみる

電子書籍、電子出版のCAS-UBブログ

みんなで作れる電子書籍、電子出版のCAS-UBのブログです

カテゴリーアーカイブ: EPUBリーダー