XHTMLのID名のエラー

　エラー内容は「value of attribute "id" is invalid; must be an XML name without colons」とのことだったので、まずは該当箇所を見てみます。ID名が「id="toc-001*"」のような形となっており、なるほどこれはエラーになるわけだと一旦は思いました。XMLではID名に「*」の記号を使うことを許容していないからです^※2。ということでまずはEpubCheckの各バージョンでこの状態のEPUBでエラーになるかを見てみます。

　EpubCheck3.0.1だと

　なるほどエラーとなるようです。

　EpubCheck4.0.1だと

　エラーになりません。なるほど。

　では、ちょっとID名を変えて見てみます。「id="toc-あ001"」と、ひらがなの「あ」を入れてみました。この状態でEpubCheckをかけますと

　EpubCheck3.0.1で

　おや、エラーになりませんね。

　同じくEpubCheck4.0.1だと

　こちらもエラーにならないようです。

HTML5ではID名に何を使ってもよい

　困った話だなと思ったのですが、さらに調べるとどうもHTML5では途中にスペースが入らない限りID名に何を使ってもよいとの話もあるようで^※3、これに従うと挙動としては実はEpubCheck3.0.1でエラーになるのが間違いだったということになるのでしょうか。
　ただ、EPUB3を内部的にXMLなどに変換して表示しているビューアも存在しますので、XMLのID名使用可能文字の制限に従っておくのが無難なのは間違いないと思います。ということでどうやらこの件ではEpubCheckを当てにできませんので、独自にPerlでチェッカーを作ってみました。

　こんな感じでしょうか。一応これでチェックは可能となりました。ターミナルで引数にEPUBファイルを指定してやることでログファイルを出力します。環境によってはArchive::Extractモジュールのインストールは必要かもしれません。

音楽や動画では常識化してきているサブスクリプション型サービス

　近年、動画や音楽の世界では、定額で見放題、聴き放題型のサービス・・・サブスクリプション契約型のコンテンツ提供サービスが一般化してきています。
　動画配信では今は日本における事業では日本テレビの傘下となったHuluを皮切りに普及が進み、現在はアメリカ最大手のNetFlixに勢いがあります。今テレビを購入するとリモコンの目立つ場所にNetFlixのボタンが配置されているという話もあり、もうこれは完全に一般化したと見ていいでしょう^※1。ちなみにこれは従来の放送と通信のバランスを崩すかなり大きな動きです。

　一方、音楽の世界でも聴き放題サービスが続々と登場してきています。海外で大きな勢いがあり、近々日本上陸も噂されるSpotify、アジアに拠点を置き、日本を含むアジアの楽曲に強いKKBOX、LINEのサービスとして登場し、かなりの注目を集めたLINE MUSIC、3500万曲という膨大なラインナップを誇るGoogle Play Music、AppleのサービスということでiTunesを始めとした従来のシステムに統合された形で提供されるApple Musicなど、こちらも既に飽和状態と言ってよいかと思います。

まだ課題の残るビジネスモデル

　ただ、こうしたネット経由のサブスクリプション型コンテンツ提供サービスはまだまだ黎明期ということもあり、さまざまな課題も浮かび上がってきています。
　Apple Musicの3ヶ月間無料キャンペーンでキャンペーン期間中にアーティストへの楽曲利用料支払いが行われないという方針に抗議して、米国のビッグアーティスト、テイラー・スウィフトがApple Musicから楽曲を引き上げると表明し、Appleが即座に方針を変えて支払うことになったという一幕が過去にありましたが、新しいビジネスモデルだけにこういった権利者と事業者の駆け引きは当分付いて回りそうです。

　また、LINE MUSICが有料期間に移行した途端に利用者数が激減したなどという話もあり、事業者側にしてみればそれはもちろんタダでサービスを展開し続けられるワケがないのですが、利用者視点としてはラジオやYoutubeの代替と見ているとすれば話がわからなくもありません。また、次から次へと聴き放題サービスがサービスインし、一定期間無料で聞けるキャンペーンを行っていますから、サービスを次々に乗り換えればかなりの間無料で音楽を楽しめるのも確かです。

　いずれにせよこれは利用者側に「常識」的なものがまだ形成されていない新しいサービスだからこそ起きている現象だとは言えそうです。

電子雑誌にサブスクリプションを根付かせた「dマガジン」

　では、本題である出版でのサブスクリプションサービスはどうでしょうか。すぐに思い浮かぶ成功例は、電子雑誌市場でのdマガジンの成功です。これはこれまでほぼ不毛の地だった電子雑誌の世界にサブスクリプションを持ち込むことで、紙に比べて売り上げが大きいとは言えないまでも計算できる一定の売り上げが見込めるものにしたという点でとても評価できるサービスです。
　おそらくはNTTドコモのサービスとしてスマホの契約者を取り込むところからスタートし、ゼロからのスタートではないという立ち位置が良かったのだろうなと思っていますが、出版社にしてみれば各雑誌に一定の売り上げが上積みされるわけで、有り難いことに違いありません。

　また、このdマガジンで配信されている電子雑誌は、写真の権利関係の影響などで一部変更があったりはするものの、ほぼ紙雑誌のデータをそのまま流用して作れる固定版面のEPUBデータですから、制作技術面での参入障壁も非常に低いです。レイアウトで見せているようなタイプの紙の雑誌をリフロー型に作り変えるのは相当以上の手間がかかりますし、雑誌ということで時間もかけられない以上さらに大変なことになるのは明白ですから、「今は固定版面でよい」というのは現実的な判断だと思います。もちろん今後もずっとこのままでよいのかという課題はあるでしょうが、それは各雑誌側が今後考えるべきことになるでしょう。

　電子雑誌の技術面では、epubの次世代規格として検討中のものの中に「Epub Multiple-Rendition」という策定中の規格があり、これに各ビューアが対応してくれば結構大きな影響が出てくるだろうなと思っています。これはひとつのepubパッケージ内に複数のepubデータを収納するというような規格なのですが、固定版面型データとシンプルなリフロー型データを両方収納しておき、適宜切り替えて読ませるといったような使い方が期待できるわけです。

書籍の「定額読み放題サービス」

　さて、肝心の書籍の定額読み放題サービスはどうかと言えば、こちらも既に先行している例はあり、auの展開する「ブックパス」やYahoo！ブックストアの「月額読み放題プラン」などがあります。いずれも手軽な値段でコミックや軽い読み物などを楽しめるという性格のストアです。また少々変わり種としては、有斐閣が展開する法律系古典書籍の定額読み放題サービス「YDC1000」などもあります。

　Kindleがここに参入してくるとなると、当然ビッグプレーヤーということで相当以上のインパクトはあるでしょうが、やはりコンテンツの中心は軽い読み物やコミックになるようには思います。
　ただ、Kindleはもともとビジネス書に強いという特性を持つストアですので、そちら方面がかなり多く並ぶというのはあるかも知れません。
　また、Amazonはサービス開始初年度には通常の販売と同額の代金を出版社に支払うとの話もあるようですので、これが本当ならそれなりに人気作がラインナップに入ってくる可能性はあるでしょう。

堅い専門書などは一見向かないが・・・

　一方、専門書など「堅い」タイプの本はKindle Unlimitedのような一般向け読み放題サービスには一見向かないようには思えます。ただ、例えば新刊発売後の数ヶ月間だけKindle Unlimiedで読めるようにしておき、プロモーションとして利用する手はあるのではないかと思います。

　先日の紀伊国屋書店新宿南店の閉店に象徴されるように、利幅の薄い本を商品とする書店は大型書店ですら苦戦を強いられているのが現状であり、従来新刊の販売プロモーションに大きな役割を果たしてきた書店店頭の面陳、平積みの面積は減り続けています。これを補完する意味で、一定期間電子読み放題サービスに出すというのは意味があるように思います。

　「堅い」本は現在でも多くの場合は紙で購入されていますし、通常手元に置いておいて折に触れて何度も参照したいものでしょうから、数ヶ月で読めなくなるのであれば結局「試し読み」と同義になるでしょう。従来も書店店頭では全ページ目を通すことができたのですから、これによって書籍の売り上げが減るといったようなことは無いのではないでしょうか。

　ただし、普通に考えれば他の大量のコンテンツに「埋もれ」ますから、出版社の側で販促用Webページを用意し、SNS等で拡散をかけるなどの方法で独自に導線を用意してやる必要はありそうです。
　また、「堅い」本であっても、例えば大学で教科書に使われるようなものなどにはちょっと向かないようにも思いますし、実際にどの本で仕掛けるかは各出版社が慎重に判断する必要はあるでしょう。

調査対象の文字

　今回調査の対象にしたのは、InDesign内コンテキストメニューの「特殊文字の挿入」「スペースの挿入」「分割文字の挿入」から選択して入力できる文字のうち、明らかに通常の記号に過ぎないものおよび、ページ番号など通常EPUBには書き出さないものを除いたもの（「特殊文字／記号」「特殊文字／マーカー」「特殊文字／引用符」項目を除去）、および、索引マーカー、脚注マーカーなどの各制御文字です。また、今回の基本資料として、こちらの英文記事を参考にしました。

　これをもとに機能名を日本語版InDesignでの表記に置き換え、またEPUB制作時にXMLでの書き出しを行うとどういった状態で出力されるのか、同じくコピー＆ペーストで書き出した場合はどうなるかに関して調べました。結果が以下の表です（クリックでGoogleドキュメントの元データにジャンプ）。

　特に注意が必要そうな箇所は赤で塗りつぶしてあります。XML書き出し時にはかなりの制御文字が削除もしくは置き換えられていることがわかります。また、改行などを見ればわかるように、同一のコードが複数の制御文字に割り当てられています。あくまで推測ですが、InDesign内で異体字を表示する際に親字のUnicodeひとつに対して複数の異体字をaalt等のサブ属性を割り振って管理しているのと同種の処理を行っているのではないかと思います。

XML書き出しで問題が出そうな文字

　さて、InDesignはXML書き出し時におおむね問題のない置換を行ってくれているようなのですが、いくつかちょっと問題のある処理があるようです。
ちょっと問題ありそうな箇所を列挙してみます。

・U+2011の分散禁止ハイフンが消えてしまう
・U+2003のEMスペースが通常の半角スペースに変わる（幅が狭すぎる）
・U+00A0の分散禁止スペース（ノーブレークスペース）がそのまま残る
・U+2006の1/6スペースがそのまま残る
・U+2005の1/4スペースがそのまま残る
・U+2004の1/3スペースがそのまま残る
・U+000Aの強制改行が通常の半角スペースに変わる
・U+200Bの任意の改行がそのまま残る

　「分散禁止ハイフン」が消えてしまうのはとても困った挙動で、これは欧文の前後の文字を行末改行させないという挙動以外は通常のハイフンと変わらない約物ですので、消えてもらっては困ります。せめて通常のハイフンに置換して欲しいところです。

　また、特殊幅スペース類に関しては、欧文フォントにはグリフの割り当てがあるようですので将来的にEPUBのほとんどのビューアで部分言語指定がきちんと反映されるようになってくればそのままでもよいかと思うのですが、現状では部分言語指定が効くビューアの方が少数で、また日本語フォントには該当コードポイントにグリフの割り当てがないようですので、現状まだ半角スペース等に変換した方が無難と考えます。

　それから改行コード類ですが、「強制改行」は通常、組版の最終段階で文章中の改行位置の微調整に使うものですので、これが半角スペースになるのは困ります。削除が正しい対処かと思います。あとは「任意の改行」ですが、これは主に欧文などで長い単語が行末に来た際などに改行を許す位置を指し示すためのものですので、こちらもEPUB化では削除するのが正しそうです。
　他には「索引の付加位置を示すマーカー」、「脚注のマーカー」、「アンカーオブジェクトのマーカー」、「CID/GIDしかない文字のInDesign内部表示用キャラクタ（参考）」が消えてしまうのも問題で気になるところですが、これらについては目視確認して個別箇所の処理が必要になりますので、別枠とします。

XML書き出し前にInDesign内で置換処理を行う必要がある

　さて、対処なのですが、どうやらXML書き出しを行う前に、InDesign内で処置をする必要がありそうです。例えば強制改行などは半角スペースに置換されて書き出されてしまうため、XML書き出しを行った後では目視で潰すしかなくなってしまいます。ということでInDesign内でスクリプト処理を行うとすると、例えばAppleScriptを使って

　といった形で、検索置換パレットを使ったループ処理を行うことになります。多少時間がかかりますが、制御文字の性質上これは仕方ありません。

コピー＆ペーストで問題の出そうな文字

　一方でInDesign内のテキストをそのままコピーし、テキストエディタにペーストした場合には、索引マーカー、脚注マーカー、アンカーオブジェクトマーカー、XMLタグマーカーなどを例外として、ほぼ全ての制御文字がそのままペーストされるようです。miにペーストした際にはU+2001のフラッシュスペースがU+2003のEMスペースに変換されるという挙動が見られたのですが、これはどうやらmiのみの問題のようで、テキストエディット等にペーストした際にはU+2001のままペーストされました。おそらくmiの内部でこのコードポイントを使用して何らかの処理をしており、それとバッティングするのを防ぐために変換されたものと思われます。

　そのままペーストされるということは制御文字が剥き出しになるということなので、これは置換、削除する必要が出てきます。処理内容としては

・U+00ADの任意ハイフン　→　削除
・U+0008の右インデントタブ　→　削除
・U+0007の「ここまでインデント」文字　→　削除
・U+0003の先頭文字スタイルの終了文字　→　削除
・U+200Cの結合なし　→　削除
・U+2003のEMスペース　→　全角スペースに
・U+00A0の分散禁止スペース　→　半角スペースに
・U+202Fの分散禁止スペース（固定幅）　→　半角スペースに
・U+200Aの極細スペース　→　半角スペースに
・U+2006の1/6スペース　→　半角スペースに
・U+2009の細いスペース　→　半角スペースに
・U+2005の1/4スペース　→　半角スペースに
・U+2004の1/3スペース　→　半角スペースに
・U+2008の句読点等の間隔　→　半角スペースに
・U+2007の数字の間隔　→　半角スペースに
・U+2001のフラッシュスペース　→　半角スペースに
・U+200B任意の改行　→　削除

　といったところでしょうか。強制改行が普通の改行と見分けられなくなってしまうのは問題ですが、これはテキストになってしまった後では目視で発見するしかありませんので自動処理はできません。あるいはコピー＆ペーストする前に（テキストデータにする前に）InDesign内の検索置換で消しておくというような処置をすることになるでしょう。