「全角ダーシ」の問題

　主にDTPデータからの電子化での問題です。私の把握している限りで、DTP等のデータで「ダーシ」として使われている文字は以下のものがあります。

　U+2014（EM DASH）
　U+2015（HORIZONTAL BAR）
　U+FE31（PRESENTATION FORM FOR VERTICAL EM DASH）
　U+2500（罫線素片）

　このうち、U+2014は、フォントによって縦書きで中央に来ないケースが多くあるため、DTPではこれを嫌ってU+2015を使用しているケースが多く見られるようです。
　U+FE31は中央に来るようですが、電子化に際して書き出すと自動で横棒にならず、縦棒のまま残ってしまうため別の文字に置換する必要があります。

　また、ダーシは1文字幅で使うだけではなく、2文字幅の「二倍ダーシ」として使用するケースが多く見られます。二倍ダーシとして連続入力した場合、U+2014/U+2015ともに文字間に隙間ができるデザインのフォントが多く、これを避けるために本来はダーシとして使うべきでないU+2500の罫線素片を使っているケースがあるようです。これは実質的に現状フォントの指定ができない電子書籍では通常の対応となっているのではないかと思います。
　DTPではU+2015を使い、縦200％の変倍をかけているケースが多く見られるようですが、これは電子化のためにそのままテキスト化すれば変倍の情報が飛んで1倍ダーシになります。このため置換処理が必要となります。さらにU+2015はJIS X 0213外の文字であり、厳密にJIS X 0213内での電子化対応を求める場合^※1には何らかの文字に置換しなければならないという問題もあります。

（参考：https://www.youtube.com/watch?v=p9YUx_AeypA）

波ダッシュと全角チルダの問題

　Webを含めさまざまな場面で起きている問題です。過去のさまざまな経緯により以下の文字が混用されています。
　U+301C（WAVE DASH）
　U+FF5E（FULLWIDTH TILDE）

　現在多くの商用フォントではグリフで見分けがつきません。このためDTP的には問題は顕在化していませんが、U+FF5EはJIS X 0213外の文字のため、電子化では置換処理が必要になることがあります。なおこれ以外の文字混用問題も別項目で取り上げていますが、このケースはUnicodeの規格のミスなども絡んでいてだいぶ根が深いので単独で挙げておきます。参考リンク先の記述がかなり詳細ですので、この問題の概要はそちらをご覧ください。

（参考：https://qiita.com/kasei-san/items/3ce2249f0a1c1af1cbd2）

和文引用符の問題

　DTPデータからの電子化での問題です。U+201C/U+201Dのダブルクォートは、InDesignの機能によってダブルミニュート^※2として表示させることができます。ただし、バックグラウンドで持っている文字情報はU+201C/U+201Dのままなので、電子化に際してテキスト化するとグリフが変わってしまいます。このため置換処理が必要となります。U+301D/U+301Fのダブルミニュートをそのまま使えばこの問題はクリアできますが、これはInDesignの禁則文字に入っていない文字のため、InDesignで禁則文字のカスタマイズが必要となります。

（参考：https://www.youtube.com/watch?v=p9YUx_AeypA）

和文中の欧文引用符の問題

　DTPデータからの電子化での問題です。和文組版では通常、和文中の欧文であっても引用符にU+0022を使わず、U+201C/U+201Dをダブルクォートとして使うケースが多く見られます。同様に、アポストロフィとしてU+2019を使い、U+0027を使わないことも慣例となっているようです。
　これはU+0022/U+0027の字形が「間抜け引用符」などと呼ばれてデザイン的に嫌われたために起きたものですが、U+201C/U+201D/U+2019はUnicode上では全角幅／半角幅で異なるコードポイントを与えられてはいないため、テキストとして書き出した際に不自然なアキが引用符の前後に入るケースがあります。このため、電子化に際してはU+0022/U+0027に適宜置換して対応したりします。これはまた、Kindleが縦組み時にU+201C/U+201Dを強制的にU+301D/U+301Fのグリフで表示してしまうことへの対応策でもあります^※3。

グリフで見分けが付かないが使うべきでない文字の混用問題

　Webを含めさまざまな場面で起きている問題です。よく見られるのが「康熙部首」としてUnicodeに収録されている文字（U+2F00〜U+2FD5）を、通常の漢字と混用しているケースや、キリル文字の「А」「В」「С」「Е」「О」「Р」などを通常のアルファベットの文字と混用しているケースです。また、漢字の「二」とカタカナの「ニ」の混用も時々見られます。
　これらはおそらくOCRの誤認識などが混入の原因と思われますが、グリフを目視で見分けて修正することが極めて困難であるため、何らかの機械的な処理で混用を防ぐことが期待されます。康熙部首などは特殊なケース以外では使用されない文字であるため、機械的な1対1の置換でかなりの場合カバーできるかと思います。

絵文字の異体字表示文字の混入問題

　現在、Web等で絵文字が日常的に使われるようになってきており、それに伴って絵文字の異体字表示文字がDTPの元データや電子書籍のテキストに混入し、意図しない表示結果を引き起こすケースがあるようです。符号位置としてはU+FE00〜U+FE0Fがそれに当たります。

時計数字や丸数字などかつての機種依存文字対応の残滓

　現在、時計数字や丸数字などはその多くがUnicodeに独自のコードポイントが与えられており、テキストとして扱えるようになっていますが、かつて機種依存文字として扱われた経緯があるため、現在でも例えば時計数字の「Ⅳ」をアルファベットの組み合わせの「IV」で入力する等の対応をしているケースがあります。少なくともDTPデータや電子書籍では、アクセシビリティへの正しい対応のために本来のUnicodeの文字を使うべきと思います^※4。また、丸数字の外字での対応等も極力控えた方がよいと考えています。

その他問題がありそうな文字

　一部の文字が電子化の際に縦組みで左右中央に来ないため、別の文字に置換したり、場合によっては外字化しているケースがあるようです。確認できている文字は以下の通りです。こういったものはフォントのグリフに依存するため、まだ同種のものがあるかもしれません。
　「•」（U+2022/BULLET）
　「…」（U+2026/三点リーダー）

最上流としてWebを想定する

　最上流にはWebを想定します。これは最近だいぶ出版関係でもWeb運営を事業として安定的に存続している会社が増えてきたことや、noteのようなプロを含む人気の書き手が集まる投稿サービスの定着、「小説家になろう」のようなエンタメ系テキスト投稿サイトの伸張などを念頭に置いたものです。雑誌がどんどん売れなくなっている局面が続いていますので、事前告知のツールとしてのWebは今後ますます重要度を高めてきています。そういう意味でもう最上流にはWebでの告知を考えるのが正しいかなと思っています。いわば雑誌での連載の代わりです。

　ただし、本の種類によっては最初にWebに出すことを想定できないことも当然ありますので、ここはいわば「オプション」です。Webで出すことを想定しない場合はこの後からやればよいです。

Webページのデータを元に「先に」EPUBをつくる

　さて、このWebページのデータを元に「先に」EPUBを作ります。もちろんソースをコピーして手作業で書き換えもできるわけですが、可能ならある程度自動化したいところです。WebはHTMLやXHTMLの構造化文書なので、ネットからデータを抽出（スクレイピング）してそこから同じ構造化文書であるEPUBへの変換するのはそれなりに効率化できるはずです。特定のCMSで生成された記事だけを対象とする、などターゲットを絞れるならば、半自動変換まで可能でしょう。現状EPUBでは実質一般のWebよりも使えるCSSが制限されているというような事情はあるため、完全自動変換はかなり難しそうですが。

　気軽に変換ができれば出版企画の検討にも使えると思います。「本として出すか出さないかを検討するためにとりあえず電子書籍の形にしてみる」というイメージです。

EPUBの内容をブラッシュアップして完成させる

　で、一旦形を作ったあと、書籍化に際しての用語統一や約物類などの統一、必要ならコラム類や図表、注の追加など書籍として販売するための追加編集作業を行います。

　ここで問題となるのがEPUBへ修正指示を入れる方法で、EPUBを気軽にプリントする方法がなかったことが長年EPUB制作上の課題ではあったのですが、VivliostyleでEPUBを気軽にPDF化できるようになりましたのでそこはもうクリアです（参考）。

　Webを起点としない場合は、テキスト等を元としてEPUBを作ることになりますが、その場合でも作業としては少なくともInDesignを元にするよりは楽なはずです。組版調整のために入れられた電子版では不要な要素を目視確認して取り除く、というような作業はいりませんので。

　ただし、ここには一点できれば解決したい技術的な課題があります。それは、現状、電書協ガイド準拠などの商用EPUBの再編集、特に画像や新規挿入やテキストの新規ファイル追加を行う際に気軽に利用できるツールがなく、手動でOPFファイルを編集する必要があることです（manifest追記などを行わないとエラーになる）。その状態だと修正作業を行える人間が限られるため、気軽に再編集ができるツールはあるとよいなと思います。

EPUBからDTP組版用の構造化テキストを変換出力する

　さて、EPUBデータが完成したらそのテキストを元にDTPデータを作成するわけですが、正直この部分での「完全自動組版」などは想定していません。もちろんフローの最適化、効率化は必要ですが、一般的に商業出版のレベルで求められる成果物はテキストから自動変換で作れるようなものではないと思っています。
　従って、ここでは「EPUBから綺麗な形でInDesin等に流し込める構造化テキストを変換出力する」ことを考えます。ルビと見出しぐらいまでを移行できればよい、後は従来のDTP制作と同じ流れに持って行く、という感じです。

　この目的のためにはAdobe InCopyの保存形式である「ICML」型式が使えそうかなと思っています（ある程度はテスト済みです）。InCopyはInDesignと組み合わせてレイアウトデザインワークとテキスト修正を同時に別の人間がやるために作られたアプリですが、そのための保存形式である「ICML」型式は内部的にXMLなのでEPUB内のXHTMLからの変換が正規表現の力業に頼らずにできます。
　制作イメージとしてはあらかじめInDesignのドキュメント内に流し込むためのボックスを作っておき、そこに変換済みのICMLファイルを配置する感じになり、InDesignタグテキストと変わりません。配置直後はInDesign側に編集権限がないため、「埋め込み」の操作をする必要があるのですが、まあそれだけです。

　これだとDTP制作に際して大してメリットがないかのように見えるかもしれませんが、「既に電子版で完成まで行っている」というあたりがポイントになります。つまり、テキストがほぼ完成原稿であり、再校時以降でテキストレベルでの大きな修正が入らないことになります。現状DTP制作では「そうなっていない」ケースが多々あるため、これは実はずいぶん大きな話です。言い換えれば、「テキスト原稿のブラッシュアップのためにEPUBを使う」という話でもあります。

どういうメリットがあるか

　このフローに切り替えた場合、各セクションにどういうメリットがあるかをあらためて挙げてみます。

　まず、出版社にとってですが、

1. 最上流にウェブを置くことで従来の雑誌連載の代わりとして事前告知の効果を期待できる（必ずしも自社で全てやる必要はない）
2. EPUBから変換生成されたPDFに赤字を入れて返送という形になるため、従来の本の制作フローの延長として対応できる（その後のDTPでの流れも従来と同じ）
3. 制作の流れの中でリフロー型EPUBができるため、DTPデータから改めて短期間でEPUBを作成する必要がなく、出版全体のスケジュールに無理がない（確実にサイマル配信ができる）
4. リフロー電子版を紙版と同じように作り込む感覚に引っ張られずに済む（本来それは求められていないはず）

　というあたりが思いつきます。特に、従来の本の制作フローから大きく変える必要がないあたりはポイントになりそうです。

　電子版の制作会社にとっては、

1. ウェブからEPUBへの変換なら構造化文書同士のコンバートになるため、かなりの部分を自動化で対応でき、手作業の手間を減らせる
2. 電子版を紙版と同じように作り込むという本来技術的に無理のある作業からの解放
3. DTPデータが完成してからごく短時間で電子化、というスケジュールがマストではなくなる

　というあたりがメリットになりそうです。

　DTP制作会社／印刷会社にとっては

1. 「大幅な赤字の入らないほぼ完成した原稿」からDTPデータ作成作業を始められる
2. ルビや見出しのレベルまでは無理なくEPUBから持って行ける（それ以上の対応はEPUB側の最適化が必要）
3. DTPが制作フローの末端になるため、データの再利用を考えずに作り込むことができる

　というあたりでしょうか。

どういう課題がありそうか

　一方で、実際にやるにあたっての課題も結構ありそうです。

　まず、既に挙げましたが、EPUBの修正作業は現状技術的な敷居が高いため、広くやるためには何らかのツールの開発はいるでしょう。とは言えWYSIWYGで修正できるようにするなどという話でもなければそこまでの手間ではなさそうかなと思います。
　また、出版社側を含めて全体の流れの理解はやはり必要と思います。電子版でテキストを完成状態に持って行くという流れが理解されておらず、DTPの段階で大幅な修正が入った場合、手間が大きく増えてフローが破綻しますので。
　さらに、ここには図表制作の話は入っていません。電子版でも図表は当然必要になるので、事前に図表制作は進めておく必要があるでしょう。DTPデータでは使える色の制限も当然出てくるため、電子版とDTP用で色を変える対応も必要になってくるかもしれません。