EPUBの外字画像の使用事例について

2016/11/10

 JEPAの村田真さんよりEPUB Accessibility 1.0絡みで現状のEPUBでの「外字画像」の使用事例を知りたいとのお話をいただきましたので、私の知る限りで書いてみます。何人かの方にもお話をお聞きし、参考とさせていただきました。

 どういった種類の外字かをわかりやすくするために、各種文字集合規格のマップを作成し、各外字がどこに位置するかを以下に図示しました。解説の番号に対応しています。併せてご参照ください。

外字の分布

画像内で使用している文字関連の専門用語をまとめて記述しておきます。

  • Unicode:1991年にバージョン1.0が出版された国際的な符号化文字集合の規格。世界中の文字を単一の文字集合で表記することを目的としている。2016年6月にUnicode9.0が出版されている。詳しくはこちら
  • JIS X 0208:1978年に最初に制定された日本の符号化文字集合の規格。改訂年度によって「JIS78」「JIS83」「JIS90」などと呼称される。JIS第2水準までの漢字をサポートしている。詳しくはこちら。これとセットで運用された符号化方式がShift_JIS
  • JIS X 0213:2000年に最初に制定された日本の符号化文字集合の規格。改訂年度によって「JIS2000」「JIS2004」などと呼称される。最新版は「JIS2013」。JIS第4水準までの漢字をサポートしている。詳しくはこちら
  • Adobe-Japan1-6:アドビシステムズ社によって制定された符号化文字集合の規格。商用日本語OpenTypeフォントの採用している文字集合規格のデファクトスタンダードである。実際に販売されているフォントのうち、「Pr6」「Pr6N」という名前が付いているものがこの規格のもの。「N」はデフォルトの字形をJIS2004の例示字形に対応させたものを指す。内包する文字数の異なる下位規格としてAdobe-Japan1-5(Pr5/Pr5N)、Adobe-Japan1-4(Pro/ProN)、Adobe-Japan1-3(Std/StdN)などがある。詳しくはこちら
  • Unicode IVS:異体字セレクタ。親文字(漢字)と、Unicodeの第14面(追加特殊用途面)に収録された異体字表示文字を組み合わせることで、漢字の微細な字形差を表現できるようにするためのもの。これにより例えばAdobe-Japan1-6の包含している字形の再現が電子書籍やWebで期待できるようになる。詳しくはこちら
  • 基本多言語面:Unicodeの0面。もともとはここに全ての文字を収録する計画だったが、足りなくなったために桁(面)を増やした経緯がある。詳しくはこちら
  • 追加漢字面:Unicodeの2面。CJK統合漢字拡張や補助漢字などの文字が収録されている。詳しくはこちら

特定の文字集合規格で表現できない文字を「外字画像」にしているもの

❶ Adobe-Japan1-6にしかない文字の外字化

Adobe-Japan1-6にしかない文字の例

Adobe-Japan1-6にしかない文字の例

 Adobe-Japan1-6の文字は、そのほとんどがCMapによってUnicodeと紐付けられていますが、ごく一部Adobe-Japan1-6にしか収録されておらず、Unicodeと紐付いていないために実質的にInDesign等のDTPアプリ内でしか使えない文字(参照:CID/GID番号のみしか割り当てられていない記号類)があります。これは外字画像にする以外の方策はありません。

(追記)事例画像には一部既にUnicode符号化済の文字を含んでいます。

❷ 中国語の人名など日本語フォントで現状表示できない字形を表示するための外字化

日本語と中国語のフォントで字形が違う例

日本語と中国語のフォントで字形が違う例

 簡体/繁体中国語の人名など、現状日本語フォントで表現できない字形を表現するために外字画像を使用しているケースです。これはUnicodeの符号位置としてはAdobe-Japan1-6内のものが多数含まれると思われますが、その場合でも日本語と中国語では符合位置が同じでも割り当てられている字形(グリフ)が微妙に違うことがあるため、外字画像にせざるを得ない場合があります。学術書などでは厳密な字形の再現が要求されるケースも当然出てくるため、そういったケースでは現状では外字画像にすることになります。

 将来的にEPUB内での部分言語指定を各RSがサポートし、デバイスが対応する各国語のフォントを搭載すればテキスト化できるかと思われます。

❸ Adobe-Japan1-6内の異体字の字形を保つための外字化

 InDesignなどのDTPアプリ内では使用できるものの、テキスト化するとGSUBの情報が消えてしまうために字形を維持できなくなる文字の字形を保持するために外字画像としているケースです。

 典型的なのはJIS90字形を保持するために外字画像としているケースです(参照:JIS90字形とJIS2004字形で変化する文字の一覧)。この問題は古くはJIS78→JIS83の字形変化の問題、いわゆる「新JIS旧JIS問題」にまで遡る話ですので、割に根は深いと思います。

段落スタイルで印刷標準字体を指定

段落スタイルで印刷標準字体を指定

 また、EPUBのビューアに搭載されているフォントは現状ほとんどがJIS2004字形の「Pr6N」などのフォントであるにも関わらず、JIS2004字形を外字化してしまっているケースもあるようです。おそらく元の印刷データでJIS90字形基準のフォント(Pro/Pr5/Pr6)が使用されており、InDesignなどDTPアプリの機能でJIS2004字形のグリフを割り当てていた(「印刷標準字体」を段落スタイルで割り当てるなど)ケースで電子化の際に字形の維持を図ったものと思われますが、これは明白に意味がないためやめた方がよいと思われます。

 将来的にUnicode IVSが標準的に使用できるようになれば微細な字形の再現はテキストで可能になるはずですが、まだIVSを付加した文字が縦組み時に横転してしまう実装のビューアがあったりするなどRS側の状況が不安定なこと、InDesignデータから字形情報を保持したままUnicode IVSのテキスト化することが技術的に難しいことなどから、厳密に字形を保持するには当分は外字画像化が必要になるでしょう。

 ただ、このあたりの文字はもともとがJISの「包摂」範囲で、本来は規格内に双方の字形を含んでおり、JIS2000からJIS2004では「例示字形」が変わっただけです。微細な字形差に留まるケースが大半ですので、人名などどうしてもやむを得ない場合以外はテキスト化を許容した方がよいと考えています。

 なお、このあたりの話は以前に私のブログで書いておりますので、併せてご参照ください。Unicode IVSに関してはこちら。WindowsやMacも既にOSレベルでのUnicode IVS対応は済んでいますので、あとはInDesignなどDTPアプリの対応待ちという印象です。

❹ JIS X 0213内だがUnicodeの基本多言語面外の文字の外字化

 JIS X 0213内の文字で、少数ですがUnicodeで基本多言語面(BMP)外のCJK統合漢字拡張Bのエリアに割り振られた漢字が存在します。特に注意が必要なのは「𠮟」(U+20B9F)および「𠮷」(U+20BB7)です。
 「𠮟」はJIS第3水準漢字ですが、類似の文字にJIS第1水準の「叱」(U+53F1)があるため、通常はこちらで代用可能でしょう。ただ、「𠮟」の方が常用漢字とされたため(参照)、厳密に常用漢字の使用を求めた結果、外字画像となっているケースはあるかも知れません。

 また「𠮷」は人名に用いられる漢字ですので、厳密な字形の再現が求められるケースはそれなりにありそうに思います。例えば元首相の「𠮷田茂」氏の「𠮷」がこの字形です。通称「ツチヨシ」と呼ばれる、割に一般的な人名の異体字です。

 基本多言語面(BMP)外の文字は、展開するために内部的に2つの符号位置を必要とする処理となる(サロゲートペア)ため、長く表示に問題のある状態が続いていました。具体的にはついこの間までWebkit系のエンジンを用いるRSで縦書き時に正常に文字が表示されないなどの問題がありましたので、現状市場に出ているEPUBにはこれを回避するための外字画像を含むものが多数あるものと思われます。

 2016年11月現在では、EPUBのサイドロードに対応しているメジャーどころのRSで正常に表示ができておりますのでほぼ問題は無くなったと考えていますが、サイドロード非対応のRSも数多く存在しますので、完全な確認は私も取れておりません。

❺ JIS X 0213外だがAdobe-Japan1-6内の文字の外字化

 そう数は多くありませんが、Adobe-Japan1-6には含まれるものの、JIS X 0213には含まれない文字が存在します。漢字では例えば「髙」(U+9AD9)がそれに当たります。通称「ハシゴダカ」と呼ばれるかなり一般的な人名の異体字です。この文字はJIS X 0213としては通常の「高」に包摂されると見なされたため、独自の符号位置を与えられませんでしたが、Unicodeでは日本以外からの要望によって収録され、結果的に使えるようになったために広く使われているという経緯があるようです。

 また、記号類が多く含まれ、例えば「㈠」「㈳」「㈪」「⑴」「⒜」などがあります。これらはかなり一般的に印刷物で使用されている文字です。特に縦書きの文章でよく見かけます。

 「髙」や「㈠」「㈳」「㈪」「⑴」「⒜」といったような文字に関しては、現状メジャーどころのほぼ全てのビューアで文字の表示が可能になっているようですので、現状そこまで神経質に外字画像にする必要はないと考えています。

 (追記)一部、日本語フォントとしてIPAフォントを採用しているRSがあり、IPAフォントにはJIS X 0213までのグリフしか収録されていないため、外字化せざるを得なくなるという話もあるようです。

❻ XMDF/.bookのデータを変換した影響での外字化

 過去に作られたXMDFや.bookをEPUBに変換したケースで、XMDFや.bookが符号化方式としてShift_JIS(文字集合はJIS X 0208)を用いていたために、使用できなかったJIS第3水準、第4水準の漢字が外字画像になっているケースがあります(正確にはXMDFはバージョン3でUnicodeに対応したが、ほとんど普及していない)。XMDF/.book由来以外にも、処理プログラムの一部にShift_JISベースのものを用いているケースで同様の事例はありそうです。

 文字としては既にテキスト化可能であっても、過去に制作して既に市場流通しているものに再度手を加えるには当然ながら相応のコストが見込まれますので、まだしばらくはこういったものも市場に残りそうです。

縦書き絡みの「外字画像」

❼ 縦書き時に3桁以上の英文字/4桁以上の数字を縦中横で挿入するための外字化

InDesignでは等幅4分字形が使える

InDesignでは等幅4分字形が使える

 現状、EPUBで縦中横指定で表示対応可能な英文字/数字の桁数はRSによって大きな差がありますが(参考:項目3-1)、各RSの最小公倍数としては英文字2桁、数字3桁が最大値で、それ以上は外字としないと横転表示されてしまうRSが出てしまいます。このため、3桁以上の英文字/4桁以上の数字の縦中横組版の再現のために外字としているケースがあります。

 通常例えば数字なら3桁あればほとんど組版の問題はなく、4桁の縦中横は相当なレアケースではありますが、Adobe-Japan1-6には等幅4分字形のグリフが収録されていたりもしますので、まったくのゼロではありません。そういったケースでは外字画像を利用することになります。

 将来的にRSが3桁以上の英文字/4桁以上の数字の縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❽ 化学式のようなものを縦中横で挿入するための外字化

 化学式のように上付き/下付き文字を含むものを縦中横で挿入するために外字画像としているケースがあります。「H2O」のように3桁以上になるケースも多くあるため、複合的な要因で外字化せざるを得ません。

 将来的にRSがこういったものの縦中横表示をサポートすれば、テキストで表現することができるようになるでしょう。

❾ 一部記号類の正立/横転指定にRSが対応していないための回避措置としての外字化

Kindleでは時計数字は必ず正立する

Kindleでは時計数字は必ず正立する

 一部記号類の正立/横転指定にRSが対応していないために縦書き時に外字にせざるを得ないケースがあります。一例としてはKindleでの時計数字(Ⅰ、Ⅱ、Ⅲ・・・)の挙動があります。Kindleでは時計数字は必ず縦書きで正立する文字として扱われ、明示的に横転の指定(text-orientation: sideways)を行っても正立してしまいます。このため、例えば欧文との混植を行って欧文内に時計数字を含めるようなケースでは、横転させて表示するために外字とせざるを得ません。こういった文字は時計数字以外にも複数あります。(参考:KADOKAWA-EPUB PORTALでダウンロードできる資料内の「20150123-文字の向き確認用【全頁版】.pdf」)

 EPUB/Webにおける縦書き時の文字の向きの挙動のデフォルト値については、UTR #50で一応の標準化がされ決着がついているのですが、まだRSレベルでの差異はあり、また(過去のドキュメントとの互換性を考えれば簡単に変えられないのは当然ですが)InDesignやWordのデフォルト値とUTR #50の間にも差があります(参考)。このため、当分ある程度RSの挙動に差異が残るのは仕方ない部分はあると考えています。

 ただ、デフォルト値はともかく明示的に横転を指定しても正立してしまう挙動はちょっと困ります。Kindleは他の記号類を見る限りtext-orientationの指定自体には対応しているので、一部の文字のみ指定が効かない挙動を早く修正して欲しいところです。

❿ Kindleが縦書き時に一部文字の字形を誤って置換表示してしまうため回避措置としての外字化

右:Kindle/左:iBooksの表示結果

右:Kindle/左:iBooksの表示結果

 Kindleで縦書き時にダブルクォート(「“」U+201C 「”」U+201D)をダブルミニュート(ノノカギ/「〝」U+301D 「〟」U+301F)に強制置換して表示する挙動があるため、回避措置として外字としているケースがあります。行頭字下げなどの挙動を見る限りでは、どうやら字形のみを置き換えて表示しているようです。

 縦書きでダブルクォートの代わりにダブルミニュートを用いるというのは組版のルールとしては間違っていませんが、あくまで制作者が判断して行うべき措置で、RSが勝手に強制置換をしてしまうのは困ります。例えば縦書きの文中に欧文をダブルクォートで包んで表示したいようなケースでは、ダブルクォートは欧文の一部なので横転したダブルクォートとして表示させたいのですが、Kindleはこれも強制的にダブルミニュートにしてしまいます。このため、外字画像にせざるを得なくなります。

 なお、二重引用符には他にU+0022の「"」があり、こちらは問題なく表示できます。外字とせずこちらを使用しているケースもあるでしょう。

文字を分離禁止にするための「外字画像」

⓫ 一部記号を分離禁止で表示させるための外字化

繰り返し記号の使用例

繰り返し記号の使用例

 二倍ダーシ(U+2014「—」/U+2015「―」/U+2500「─」)や連続する三点リーダー(U+2026「…」)などを改行による分離を禁止して表示させるために、あえて外字画像としているケースがあります。個人的にはこれはやや神経質すぎだと思っていますが、二倍ダーシなどについてはもともと活版印刷の時代には通常のダーシとは違う約物として存在していたなどという話もあるようですので、そういった影響がずっと尾を引いているのかも知れません。

 このほか、古い文献で多く見られる繰り返し記号にも2つの文字を組み合わせて用いる前提のものがあり(U+3033「〳」+ U+3035「〵」/U+3034「〴」+ U+3035「〵」)、これを確実に分離させずに表示させるために画像とするケースがあるようです。
 現状多くの出版社は一般的にはそこまで厳密な記号類の分離禁止を求めていないと思われますが、学術書などで厳密な組版の再現を求められるケースでは外字にせざるを得ないという判断はあり得るでしょう。

 これらはいずれCSSでの特定の文字の分離禁止指定がほぼ全てのRSで効くようになればテキストで表現できるものと思います。

RS側の組版再現が現状不完全なための「外字画像」

⓬ 合字の組版再現のための外字化

InDesignで使える合字の例

InDesignで使える合字の例

 現状、多くのRSではまだ、DTPアプリ内では合字(リガチャ)として表示できるものが分離して表示されてしまう挙動が見られます。このため、組版再現のために外字とせざるを得ないケースがあります。

 具体的には通常濁点や半濁点を付けないカナ文字にU+309Bの合成用濁点やU+309Cの合成用半濁点を付けて特殊な表現を行うケース(例:「あ゛あ゛あ゛あ゛あ゛」)や、英語以外の欧文でアクセント組み合わせ済みのグリフを持たない文字へアクセント類を付加したいケースが考えられます。

 これらのケースはいずれほぼ全てのRSで合字の組版再現が可能になってくればテキストで表現できるものと思います。

⓭ 数式組版の再現のための外字化

 現状、多くのRSではまだ、MathMLによる数式の表示再現はできていません。また、MathJaxなどもJavaScriptを使用できないRSが多数ありますので使用できません。このため、数式の組版を再現するために外字もしくは画像として挿入しているケースがあります。

 いずれほぼ全てのRSがMathML等に対応すればテキストで表現できるようになっていくものと思われます。

⓮ 日本語での斜体を再現するための外字化

InDesignの斜体機能

InDesignの斜体機能

 EPUBでは文字に対して「font-style:italic」を指定することでイタリック体として表示されますが、日本語の部分に対する指定は斜体になるRSとならないRSがあります。

 日本語にはイタリック体はないからこれが正しいという意見もあるようなのですが、斜体自体は写植の時代からあった機能であり、DTPでもこれを引き継いで実際の印刷物の中で使われている以上、場合によってはどうしても再現しなければならないケースは出てきます。このため、外字もしくはブロックごと画像としています。

 いずれほぼ全てのRSが日本語の斜体指定に対応すればテキストで表現できるようになっていくものと思われます。

⓯ 特定のフォントデザインを保持するための外字化

 特定のフォントのデザインをEPUB内で保持するために、外字もしくはブロックごと画像とするケースがあります。これはどちらかと言えば見出しなどをブロックごと画像とするケースの方が多いでしょう。

 現状、日本語のEPUBではゴシック体と明朝体のそれぞれ平体と太字、合計4種類の書体バリエーションしか使えません。モリサワパスポートのようなサブスクリプション契約をもとに多種多様なフォントを自由に使って表現できるDTPの世界とは雲泥の差があります。フォント埋め込みで対処できればよいのですが、現状まだフォント埋め込みに対応していないRSが存在し、また商用フォントのEPUBでの使用ライセンスに目処が立っていません。このため、外字とせざるを得ないケースが出てきます。

 いずれほぼ全てのRSがフォント埋め込みに対応し、商用フォントのライセンスに目処が立ってDTPに近い形で自由にフォントを使えるようになればテキストで表現できるようになっていくものと思われます。

その他

⓰ アイコンなどもともと文字でないものをインライン表示させるための外字化

 その他、もともと文字ではないアイコン類をインラインで表示させるために技術的手段として外字としているケースがあります。これは実用書などでは多々あります。これらはDTPのデータ内でも画像として挿入されていたケースが大半ですので、将来的にも外字として残るものと思います。こういった類のものは「もともと文字ではない」ので仕方がないものと思われます。

 以上、さまざまな外字画像のパターンを挙げてみました。誤解や過剰なこだわりによって外字にしないでもよい文字を外字としてしまっているケースもありますが、多くは現状のEPUBの技術的制約や、印刷物の表現にまだまだ遠く及ばないEPUBの表現力の中でどうにか印刷物に近い表現を実現するためにやむなく外字としていることがおわかりいただけると思います。

 将来を考えればバッドティップスとなりかねない外字はできるだけ使用を控えるべきという意見には私も賛成なのですが、とはいえ「今」電子書籍を購入してくれた読者に不満を持たせるわけにはいきませんので、そこはどうしてもせめぎ合いにはなるかと思います。

 また、書籍の場合、権利そのものは当然著者のものであり、本来的には出版社や制作会社がたとえテキストの細部であれ勝手に改変するわけにはいきません。何らかの形で承諾が必要になります。これは著作権(同一性保持権)が絡む話です。このため、もとが紙の書籍を電子化するケースではどうしても外字とせざると得ないケースは出てきます。

 EPUBの表現の拡充や、RS側の実装の充実によって少しでもテキストで表現できるケースが増えることを願っております。

(2016.11.14)

 コメントをいただき、IPAフォントに関する部分などを追記いたしました。

(2016.11.14)



OMUSUBI EPUBMAKER 2.0リリースです

2016/10/17

OMUSUBI EPUBMAKER

 以前に発表しました、フィックス型EPUB作成アプリ「OMUSUBI EPUBMAKER」の改訂作業がやっと終わりました。「OMUSUBI EPUBMAKER 2.0」です。今回の改訂の一番の目玉は、UI部分をAppleScript StudioベースからXojoベースで作り直した点ですので、機能的にはそこまで大きな変更はありませんが、いくつか以前からご要望をいただいていた点、実装が不十分だった点を修正しました。今回の改訂の機能的な追加ポイントは以下になります。

  • 論理目次項目の外部読み込みに対応
  • Finderのソート順通りに画像が並ばないケースがあった点の修正(自然順ソート対応)
  • 「ImageMagickでの画像変換を行わない」オプションの追加
  • ImageMagickインストール先フォルダ指定をウィンドウ内でパスの書き換えが可能な仕様に変更
  • デフォルトの画像サイズを長辺2000pxに変更
  • その他EPUBのメタデータを若干変更

 コミックなどで使われる、画像をまとめてEPUBのパッケージの形にした「フィックス型」EPUB作成用のアプリはコマンドラインツールとしては例えばWakuFactoryさん(お世話になってます!)の「mkepub 1.4」などがありましたし、GUIを備えたものとしてはVOYAGERさんの「Romancer」に固定型EPUBの作成機能もあったりしますので、既にそれなりに環境が整ってきてはいるのですが、オフライン環境で使えるGUIアプリの需要もまだないわけではないだろうと思いましたので、こちらをリリースすることとしました。

 ごく単純なEPUBパッケージアプリで、高度なことはなにも出来ませんが、気軽にフィックス型のEPUBを作りたいという要望には応えられると思っています。また、インタラクティブなEPUB作りのためのベース生成用としても使えると思います。ソフト名は、ごはんを握っておむすびを作るように、画像の束から手軽にEPUBを作れるアプリというようなところから付けました。もっとカジュアルに、それこそPDFの代わりくらいの感覚でEPUBを使ってほしいなという願いを込めております。

 こちらのアプリはフリーで提供させていただきますので、ご自由にお使いください。書誌情報内にメタ情報でクレジットが入りますが、それ以外の制限はありません。
 ただし、個人向けということでISBNやJP-eコードなどの出版社向けID情報の入力機能は外しています(出版社ごとに要件が異なるためカスタムにせざるを得ません)。

 ビジネス利用のために必要な場合などのカスタマイズは別途こちらの窓口からご依頼下さい。私の所属する組織で承らせていただきます。

使い方

column58_2このアプリは画像サイズの取得およびサイズ変換にフリーの画像操作・変換ソフト「ImageMagick」を使用します。こちらなどからMac用パッケージを取得し、あらかじめインストールをしておいて下さい。その後「OMUSUBI EPUBMAKER」を立ち上げ、「設定」タブを開いてインストールフォルダを指定します。デフォルトでは“/opt/ImageMagick/”にインストールされるはずで、この状態であれば設定の必要はありません。

1 変換元画像の準備

 任意のフォルダに素材として使う画像を準備しておきます。形式はjpgもしくはpng、カラーモデルはRGBにしてください(jpg/png形式以外の画像はパッケージ化されません)。Finder上で画像をリネームし、ページ順に並ぶようにしておきます。連番がラクだと思います。なお、1番目の画像を自動的にカバー画像として設定します。全画像の縦横のピクセル数を統一しておくのが望ましいです。

2 書誌情報の入力

column58_3 アプリを起動し、各種書誌情報を入力します。制作者名は3名まで対応しています。出版者名は任意入力です。「カナ(整列用)」には読みのカタカナを入力してください。

3 目次情報の入力

column58_4 目次が必要な場合は情報を入力します。なお、ここで言う目次はコンテンツ内にページとして表示される目次ではなく、ビューアのメニューから呼び出せる「論理目次」です。
 目次として項目設定したいページの変換元画像のファイル名を表の「設定する画像名(拡張子込み)」に拡張子込みで記入し、目次に表示したいテキストを「目次表示テキスト」に記入していけばOKです。項目を入力するには、「+」ボタンを押して行を増やし、順次項目を入力してください。「−」ボタンを押すと最後の1行が消去されます。

 今回のバージョンから、外部テキストからのデータ読み込みにも対応いたしました。設定画像名と目次表示テキストの間をタブで区切ったタブ区切りテキストを「読込」ボタンで指定することで情報を読み込むことができます。なお、読み込めるテキストの文字コードはBOMなしのUTF-8のみとなります。同梱する倫理目次指定用テキストのサンプルをご参照ください。
 目次を全く指定しなかった場合、「表紙」の項目だけが目次に入ります。

4 綴じ方向の選択

column58_5 「右綴じ」「左綴じ」のいずれかを選択してください。通常縦書き文書は右綴じ、横書き文書は左綴じです。EPUB3では綴じ方向の混在はできませんので、必ずいずれかを選んでください。デフォルトでは「右綴じ」が選択されています。

5 見開き/単ページの選択

column58_6 「見開き」「単ページ」のいずれかを選択してください。EPUB3にはページ配置の指定項目(page-spread)があり、これを各ページに指定することで見開きレイアウトが実現できます。単ページを指定した場合は画面中央に各ページが配置されます(rendition:page-spread-center)。ただし、iBooksなどまだ指定を反映しないビューアも数多くあります。Readium等ではページ指定が反映されて表示可能です。デフォルトでは「見開き」が選択されています。

6 元画像のフォルダを選択

column58_9 変換元画像のフォルダを選択し、指定します。

7 リサイズ画像サイズ/画質を指定

column58_7 このアプリは画像のサイズを自動的にリサイズし、パッケージ化しますが、リサイズの際の画像サイズ(長辺)を指定することもできます。変更が必要なら「設定」タブをクリックしてドロワーを展開し、数値入力を行ってください。数値の上限などはありませんが、iBookStoreなどEPUB内使用画像のサイズに制限を設けているストアもありますので、ケースに応じて適切な値を入力するようにしてください。2016年10月現在では、上限2000程度に止めておくのが無難です。
 同じく、JPEG圧縮時の画質も1〜100の間で指定できます。数字が大きいほど高画質ですが、その分ファイルサイズも大きくなります。デフォルトの画質は70です。
 PNG圧縮の画質は、減色をするかどうかを選択出来る他、減色時の色数を2〜256色で選択できます。デフォルトの色数は256色です。
 画像サイズ/画質はツールが前回の設定値を記憶します。また、「デフォルトに戻す」ボタンで既定値に戻すことができます。

column58_8 なお、「ImageMagickでの画像変換を行わない」オプションがチェックされていた場合には、画像のリサイズ処理を行わず、指定した画像をそのままパッケージ化します。Photoshopなど外部アプリでリサイズ処理した画像をそのままEPUB化したい場合にご利用ください。

8 EPUBパッケージの作成

column58_10 「作成」ボタンを押すと、EPUBパッケージが元画像のフォルダと同じ階層の「タイトル名」フォルダ内に作成されます。ファイル名は作成年月日/時刻+「.epub」です。

ダウンロードはこちら
>>OMUSUBI EPUBMAKER
Mac OS X 10.9/10.11にて動作確認済みです

※10.7以降で搭載されたセキュリティ機能「GateKeeper」により、アプリを実行出来ない場合があります。その場合はこちらのページの「未確認の開発元からのAppを開き、そのAppをGatekeeperの監視の対象外にする方法」を参考に設定を変更することで起動できます。

ImageMagickはこちらより入手できます。

 

 「homebrewでImageMagickをインストールしている場合にインストーラパスの設定ができない」というお話をいただきましたので、設定用簡易マニュアルを作りました。なお、2.0からGUIの画面内でもパスの打ち換えが可能になっています。マニュアル改訂が追いつかないのでそのうち改訂します。すいません。

「OMUSUBI EPUBMAKER」homebrewでのImageMagickパスの通し方 (872)

 とりあえず、以前に私が作成した資料をEPUB化してみました。以下の画像をクリックするとブラウザ内でご覧いただけます。

InDesignデータ→電子書籍で字形の変化する文字

 フルサイズでご覧になりたい場合は「open in New window」をクリックしてください。

 これはKitaitiMakotoさんの作られた「BiB/i’d」を利用したものです。「BiB/i’d」はウェブデザイナー松島智さんが作成したブラウザ内で動作するEPUBリーダ「BiB/i」を手軽にブログ内などで利用するためのサービスです。古いブラウザ環境などで見られない場合は、最新版のChrome/Safari/Operaでご覧いただければ幸いです。
 もともとA4サイズの資料でしたので少し文字が細かくて読みにくいですが、そこはご容赦ください。

 なお、こちらのアプリを利用したことによる損害等につきまして私として責任は負いかねますので、あくまで自己責任にてご利用ください。

(2016.10.18)



「自然順ソート」あれこれ

2016/09/20

 最近ちょっとしたツールを作っていて、スクリプト内で「Finderの表示順にファイルをソート(整列)させたい」という要件がありまして、なかなかに手こずったので今後のために備忘録としてまとめておきます。

Finderでのソート順って?

 まず、Finderでのソート順って何かっていいますと、

ファイル1,ファイル2,ファイル3…ファイル10,ファイル11,ファイル12

 となるようなソート方法のことです。文字列の後に数字が来るような場合でも数値順にソートさせたい。
 perlなどで普通に文字列順にソートさせても数値でソートさせても

ファイル1,ファイル10,ファイル11,ファイル12,ファイル2,ファイル3…

 となってしまい、思ったような処理ができません。

 Finderでのソート順については、降りてきた天の声によると

 とのことらしく。ありがとうございます@ogwataさん。

 なお、どうやらJIS X 4061 照合順番で定義されてるようなソート方法を「自然順ソート」と言うらしいのですが、PerlだとSort::Naturallyあたりのモジュールを利用すればできる模様(参考)。ただ今回は配布ツールでの使用を考えているので、CPANからモジュールを入れる的な話はできれば避けたく、いろいろと違う方向性を模索していたわけです。

Xojo内でCocoaのライブラリを呼び出してソート

 フロントエンドのツールはXojoなので、Xojo内でできればなと思って、過去にQiitaにされていたアップされていたこちらの神エントリをもとにどうにかソートできるようにしたのが以下。さすがです@monokanoさん。

 Xojo内でモジュール化しておいて元の配列を投げ、ソート後の配列を得る、みたいな使い方です。今回の目的としてはFinderのソート順の再現なので、Finderと同じエンジンを使うこちらが一番目的に叶いそうです。ただもちろんCocoaのライブラリを呼び出している以上Mac専用にはなります。

Applescriptでの自然順ソート

 AppleScriptでもできそうかなということでこちらの投稿をもとに作ってみたのが以下。

 他の処理系に投げるので一回文字列に結合して引数として投げ、ソートした後に再結合した文字列を得ます。でそれをまた分解して配列に。
 AppleScriptはテキストアイテムデリミタでの文字列の分解結合処理がいつもながらややこしいのですが、そのあたりはまあご愛敬ということで。こちらもAppleScriptを使う以上Mac専用です。まあそのうちAppleScriptで自然順ソートさせなきゃならないケースも出てくるかも知れないし。

PHPのnatsort関数でソート

 PHPには自然順ソートができるnatsortという関数がデフォルトで入っているとのことなのでやってみたのが以下。

 一番簡単かも。Mac環境に依存しないのでそういう意味での使い出もありそうです。

 3種類の自然順ソートを収録したXojoのファイルをこちら (165)に置いておきます。

 で、ブログにまとめてたら最後になんかPerlでモジュールを使わずにできそうなサンプルを発見してしまった。最初に出てきて欲しかった(汗)。

(2016.9.20)

追加情報メモ。
・ApplescriptならFinderにtellしてsort by nameで並べ替えちゃうのが手っ取り早いと。ただし処理は遅いから大量のファイル処理には向かないとのこと。
・OS Xでもバージョンによって微妙にソート結果が変わったりするらしい。なので確実にFinderのソート順通りのソート結果が欲しければApplescript上からFinderを呼び出して値を取得するか、Cocoaのライブラリを呼び出してソートさせるかするしかない。
・対象がファイル名ならPerl内からosascriptでApplescript呼んでFinderに聞くのが手っ取り早いんじゃないのと言われたのでちょい試しました。以下コードをメモ。

行けますね。楽でいいかも。



プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。