ワンソースマルチユースの課題:HTMLソースのオーサリング問題を改めて考えてみようと。

2017年になってから久しぶりにWebページを自分で編集・更新をし始めています。XHTML形式のWebページをoXygenというXMLエディタ[1]で編集しているのですが、このところ毎日Webページ制作の生産性の低さに辟易しています。

少し遡っての個人的な経験ですが、私は2000年頃からドキュメントの多くをXML(XHTML)で作成するようになり、Webページなども簡単なHTMLタグの組み合わせで作成していました。それらのWebページはXHTMLタグでマークアップして簡単なCSSでレイアウトを施したものです。今から見ますと原始的なものですが、この頃のマークアップ編集はAntenna House XMLエディタという自社開発のXMLエディタを使っていました。この間、Antenna House XMLエディタは、開発があまり進まず、時代の流れに遅れてしまい、結局、販売も断念してしまいました。

その間、HTMLのタグを直接編集するのはどうも生産性が低いのでなんとかうまい解決策がないものかと考えていました。そうした経験からWiki記法のような簡易マークアップを使ってHTMLを書くことで、HTML制作の生産性を高めることができるだろう、と考えました。それが、2010年にCAS-UBの開発を開始した一つの理由です。CAS-UBはWiki記法を拡張したCAS記法をつかってHTML文書を記述します[2]。これは檜山正幸さんという天才的なアーキテクトに設計していただいたものです。自分で言うのもなんですが、いつも良く出来ていると感じます。CAS記法をなかなか普及させられないのは、偏に私のマーケティング力が足りないからだと反省します。

もう一つの理由は、出版の世界は一品生産のため、DITAマニュアルの制作システムのように大きな投資が必要なシステムを作るのは難しいので、PDFとEPUBを作る仕組をWebサービスとして提供するのが向いているのではないかと考えたことです。CAS-UBは出版物を作る仕組としてうまく機能するようになっています。まだまだ改善が必要ですが。

そうしたことで、2011年頃から、業務上の文書はOffice、簡単なWebページはブログ、出版物にするときはCAS-UB、といった使い分をしていました。そんなことで、個人的には問題も感じなくなり、もうワンソースマルチユースには課題はないだろうなどと考え始めていたのです。そして、ワンソースマルチユースの大きな課題であるソースドキュメント編集の問題について、やや忘れかけていました。

で、久しぶりにWebページ(HTML)をXMLエディタ(oXygen)で編集し始めて、HTML直接編集の生産性がさらに低下しているのに辟易しています。ずっと、HTMLの生産性が低い理由は、コンテンツ(原稿)とタグ(マークアップ)の二つを同時に考えるためと思っていました。しかし、今回、久しぶりにWebページを編集してみて、レイアウトのための余計なクラス属性や余計な階層構造が、さらに生産性を下げる原因になっている、と痛感しています。

ちなみに、今『CSS設計の教科書』(谷 拓樹著、インプレス発行、2016年2月第1版第4刷)を読んでいます。この本を見ますとCSSのセレクタには要素ではなく、クラス属性を指定する方を推奨しています。要素のセマンティクスにはあまり依存しないで、div要素に多数のクラスを設定し、CSSではクラスのセレクタを使って部品化し組み合わせる方法などがあります(pp.45-52 OOCSS)。こうなってきますと、今度はコンテンツの編集の際に、レイアウトのためのクラスの設定を適切に行わなければならなくなります。結局、HTMLの編集において、テキストや画像コンテンツ、セマンティクスとしてのHTMLタグ、さらにCSSレイアウトのためのクラス属性の設定、という三つを同時に考慮しなければなりません。これはちょっと? です。

見栄えの良いWebページを作るために、CSSが複雑になりメンテナンスしにくいのでクラス属性を組み合わせ、今度は内容を書くのが大変になる! って本末転倒しているように感じます。どうしたら良いんでしょうかね。

また、最近、2回ほど学術情報XML推進協議会のセミナーに参加して、皆さんの意見も伺い、久しぶりにコンテンツ制作の問題がまだ課題なんだな、と痛感している次第です。ということで、HTMLのオーサリングについて、改めて整理し直そうと考えているところです。

[1] oXygen
[2] CAS記法リファレンス
[3] 次回 HTMLを手軽に作る方法を再検討します。手軽といえば、まずWordでHTMLを作ることが思いつきます。

■シリーズ
(1) ワンソースマルチユースの課題:HTMLソースのオーサリング問題を改めて考えてみようと。
(2) HTMLを手軽に作る方法を再検討します。手軽といえば、まずWordでHTMLを作ることが思いつきます。
(3) Word2013のWord文書をHTML形式で保存を試してみる。その問題点は?
(4) HTMLを簡単に作る方法:h1要素の話(1)

『XSL-FOの基礎 第2版』は全文をWebでも公開。CAS-UBでプリントオンデマンド用PDFを作り、Web生成機能でWebページもワンタッチで完成。

『XSL-FOの基礎 第2版』では、プリントオンデマンド(POD)版、電子書籍(Kindle、EPUB)版で販売すると同時に、新たにWebページで全文をお読みいただけるようにしました。

本書の目的は、XSL-FOについてもっと多くの人に知ってもらうことです。そこで、PODで売るだけではなくWebページを通じてお読みいただけるようにするのが良いと考えました。こう考えたもう一つの理由は、CAS-UBのマニュアルのWeb版です。CAS-UB V4からマニュアルをPDF版とWeb版で公開しています。

CAS-UBサポート&ガイド一覧

公開してから約半年経過しまして自らの使い方を振り替えってみました。マークアップ(CAS記法)であそこはどうだったかな? というところを見ようとしますと、このオンラインWebページは大変便利です。結局、この半年間PDF版はほとんど利用しなくて、大抵Web版で済ませていることに気が付いてしまいました。これは少々ショックなのですが、やはりマニュアルのようなものはWeb版がPDF版より遙かに便利なことは認めざるを得ません。

Web版はCAS-UBでPDF版の原稿からワンソースで作成できます。

CAS-UBではWeb版の形式として(1)目次と本文を別のWindowに分割した形式と(2)目次を通常のWindowに表示する形式の2種類があります。


図1 目次と本文を別のWindowに分割した形式


図2 目次を通常のWindowに表示する形式

目次と本文を別のWindowに分割した形式は、AH Formatterのページで公開しています。☞『XSL-FOの基礎 第2版』の内容を読む

ちなみに、同じワンソースから作ったPOD版用PDFを表示しますと次の通りです。PDFのナビゲーションもしおりを使えばそんなに悪くないと思うのですが。やはり、Webではワンタッチで表示できるのに、PDFは全文をダウンロードして、別アプリを起動して表示しなければならないという点が煩わしいように思います。

WebにPDFを統合する方法をもう少し考えると良いんでしょうか?

何にしましても、ワンソース・マルチユースで出版物を制作できるCAS-UB、これからはWeb生成機能についても強力アピールして行きたいと考えております。よろしくお願い致します。

【追記】
目次を通常のWindowに表示する形式は、当初公開していましたが、Googleにインデックスされないため削除しました。もしかすると重複コンテンツと見做されているのかもしれません。

ワンソース・マルチユース実現の難しさ

ワンソース・マルチユースという言葉はかなり長く使われています。テクニカルドキュメントなどでは大きなシステムを構築して実現しているケースもいろいろ報告されています[1]。しかし、書籍の出版や学術誌の出版ではワンソース・マルチユースはまだ大きな流れにはなっていません。ここではワンソース・マルチユースがなかなか普及しないのはなぜかを考えてみます。

※本ブログをもう少し加筆して次に掲載しています。この続きは下記でどうぞ:
「ワンソース・マルチユース実践の難しさを考える」

ワンソース・マルチユースの仕組み

ワンソース・マルチユースを実現するには、まずソースの形式を決める必要があります。ソースの形式としては、DocBook、DITA、JATS、HTML5などXML/HTMLによるドキュメント形式を採用するのが便利です。XMLはもともとドキュメントをデバイスやアプリケーションから独立の形式で記述するために設計されたものです。

ソースの形式をどのようにするにせよ、ワンソース・マルチユースの出版工程は二つのステップに分けられます。第一はソースとなるドキュメントを用意する工程です。第二は、それをいろいろな目的に出版する工程です。ソースの形式をどう選択するかで、ソースドキュメントの制作の方法が影響を受けます。もちろん、出版工程も影響を受けます。

第一のステップ

ソースとなるドキュメントを執筆、校正して完成する工程です。XML/HTMLではテキストにマークアップ[2]する工程が必須です。マークアップが正しくないと第二ステップの処理ができません。執筆、校正を初めとして、第一のステップは、人手で行うのが主体です。

ドキュメントを制作する工程は、まだコンピュータで処理できるようになっていません。もっとも、現在、いま問題になっているDeNAのキュレーションサイトのコンテンツの収集についての記事を読むと、文章をリライトするコンピュータ処理は、驚くほど進歩しているようです[3]ので、将来は自動的にできるようになるかもしれません。恐ろしいことです。

第二のステップ

第二ステップはソースを加工処理してWebページ、PDF、各種のHELPなどを作成する工程です。XMLはもともとドキュメントをコンピュータで処理するための技術です。ソースドキュメントをXMLで用意することができれば、プログラムで様々な成果物を用意するのは容易です。

例えば、DITAではあまりレイアウトなどに拘らなければDITA-OTを使うだけで、HTML、PDFを初めとする多種類の出力が得られます。このように、ソース文書さえXMLあるいはHTMLで作ることができれば、いまの技術を使えば多種類の出力を作成するのは比較的容易です。

問題はなにか?

ワンソース・マルチユースの難しさはソースをどのように用意するかというプロセスにあり、マルチ出力は大きな問題ではありません。

これはXMLやHTMLが技術的に難しいということではありません。上で説明しましたように、第一ステップは人手で行われます。これを担当する執筆者・制作者は、現在、すでに一定のツールを使って一定の手順により作業を行っています。その作業のワークフローをそれまで慣れ親しんできた方法から変更するように説得するのが難しいのです。

特定の企業が主体性をもって限られた数のドキュメントを制作しているテクニカルマニュアルなどの分野でさえもなかなかワークフローの転換は難しいのです。多品種少量制作の典型である商業書籍の出版や事務局が責任をもった意思決定をしにくい学会などはさらに難しくなります。

[1] SAPの大規模DITA導入事例の進展(2016年11月)
[2] マークアップ
[3] DeNA「サイト炎上」MERY、iemoの原罪とカラクリ

EPUBをアマゾンPOD用PDFに変換するツール、EPUB vs PDFの相違点など

アンテナハウスはEPUBをアマゾンPOD用のPDFに変換するツールを開発しました。

このツールはEPUBを入力とし、EPUBのコンテンツ(XHTML)を自動組版してPDFを出力します。

PDFのレイアウトは、EPUBに指定されているレイアウト指定(CSS)情報を生かして行います。しかし、EPUBに指定されているCSSだけでは印刷物を作るには情報が足りません。そこで足りない項目は外部からパラメータを指定して、CSSの指定に追加したり上書きしたりできます。詳しくは、後述のツールの概要を参照のこと。

EPUBをお持ちの場合、ツールをお求めいただければドウイットユアセルフ(DIT)でEPUBをPDFに変換できます。また、テスト変換もございます。最初からDITは無理かな? という向きには弊社でEPUBをPDF化するサービスも承ります。EPUBをお持ちで、アマゾンプリントオンデマンド(POD)で販売することを検討中の出版社の方は、cas-info@antenna.co.jp までお気軽にご連絡ください。

1.本ツールの概要

1.1 動作環境
ツールにはグラフィカル・ユーザーインターフェイスは付いていません。コマンドラインで操作します。Windows、Linux、MacOS/Xなどでお使いいただくことができます。

コマンドラインでは、変換元のEPUB、パラメータ、出力先PDF(名)などを指定します。

1.2 扱えるEPUB
リフロー型、固定レイアウト型EPUBを両方とも扱えます。

但し、変換元のEPUBを本ツールで解凍して中のコンテンツを自動的にPDFに変換しますので、DRMが付いているEPUBは扱えません

その他詳細はお問い合わせください。

1.3パラメータの説明
PDFを作るのに必要で、EPUBには無いレイアウト指定情報などをパラメータで追加します。
(1)PDFのバージョン(PDF/Xなども可)
(2)判型(必要に応じて塗足しの有無と塗足しの寸法)
(3)マージン(小口、のど、天、地)
(4)デフォルト・フォントサイズ 
(5)デフォルト・フォントファミリー
(6)デフォルト行の高さ
(7)柱のテキスト、柱の位置
(8)ノンブルを付けるかどうか、ノンブルの位置
(9)その他項目を、多数、設定ができます

1.4 目次の扱い
EPUBにはEPUBリーダー用の目次(論理目次)と、本文と同じ扱いの目次(本文目次)があるのが一般です。本ツールは本文目次をPDFの目次にします。

1.4.1 目次頁(XHTML)の識別
EPUBの中の本文目次頁を(できるだけ)識別します。次のように指定もできます。
(1)目次ファイル名を指定
(2)目次頁の先頭テキストを指定(デフォルト:目次)
※指定がないときはデフォルトを使います。

1.4.2 目次項目の識別とページ番号の付加
EPUBの目次項目には、本文の該当章などへのリンクが設定されているのみです。本ツールでは目次頁の目次項目を識別して、その項目にページ番号を付加します。

目次項目にクラス名が付いているとき、そのクラス名を指定して該当項目を目次項目にします。

1.5 表紙
表紙画像をもとにアマゾンPOD入稿仕様に準拠した表紙のPDFを作ります。
背表紙の画像または文字列を指定したとき、(本文の100頁超のとき)背表紙に入るように自動調整します。

2. EPUBとPDFの相違点
EPUBとPDFでは本質的な相違があります。次に主な相違点を述べます。

2.1 寸法
EPUBでは相対寸法が基本ですが、PDFでは絶対寸法になります。例えば、EPUB(リフロー)では本文のデフォルト・フォントサイズは一般には指定しないで、読者がEPUBリーダーで変更できます。それに対してPDFではデフォルト・フォントサイズを、xxpt(単位はいろいろ)のような寸法で指定します。

2.2 フォント・ファミリー
EPUBでは、普通、本文全体のフォントファミリー名はserif、sans-serifなどのジェネリック名を指定します。しかし、PDFでは本文全体に適用するデフォルト・フォントとして具体的なファミリー名を指定します。

2.3 画像
画像の大きさは、アマゾンPODでは300dpi以上でなければなりません(それ以下だとエラーにされます)。本ツールでは、画像を300dpiに強制する機能がありますので、これを使えばとアマゾンの必要条件はクリアできます。

3.注意点
現在のEPUBは、EPUBリーダー(Kindleを含む)を想定して作られており、そのまま印刷物にするにはレイアウト情報が不足しています。本ツールでは不足しているレイアウト情報をパラメータで補います。ただし、必ずしも十分なコントロールはできません。例えば改頁、改丁処理などは自由に指定できません。また、書籍では章の見出しを柱の内容にすることが多いのですが、章を自動的に識別して柱にするにはどの見出しが章であるかを識別しなければなりません。それは、現在、未対応です。

関連記事1:EPUBをプリントオンデマンド用のPDFに変換するツール「EPUBtoPDF」のご紹介(スライド)
関連記事2:EPUBtoPDF変換ツール+CAS-UB V2.3のちらしができました
関連記事3:EPUB校正用、プリントオンデマンド用PDF出力 EPUB to PDF 変換ツール
関連記事4:流通によるプリントオンデマンドでの出版が現実のものとなった今、その活用の課題を考える。(2017年1月時点)
関連記事5:アンテナハウス 電子出版サービス

自社ショップで、1日から先行販売開始した『瞬簡PDF書けまっせ6』。HTMLヘルプとPDFのマニュアルは、CAS-UBでワンソース・マルチユースで制作しています。

アンテナハウスは、4月1日から自社オンラインショップで、4月1日から『瞬簡PDF書けまっせ6』を先行販売開始しました。店頭発売は4月11日からです。

『瞬簡PDF書けまっせ6』のWebページ
アンテナハウスオンラインショップ

『瞬簡PDF書けまっせ6』のマニュアルはHTMLヘルプとPDF版の2種類があります。これはCAS-UBでコンテンツを制作し、ワンソースからHTMLヘルプとPDFを制作しております。

PDF生成機能については、いろいろなところで紹介しております。
また、HTMLヘルプの作り方は簡単です。CAS-UBでコンテンツを制作して、HTMLヘルプを生成でコンテンツを保存します。保存されたファイルをマイクロソフトが提供するHTMLヘルプのコンパイラーにかけるだけです。

CAS-UBでは、電子書籍をPDFとEPUBで作るだけではなく、マニュアルのヘルプなどでもワンソースで制作するのにお使いいただくことができます。

次にいくつかの画面を紹介します。

○HTMLヘルプの呼び出し
helpentry
図1 『瞬簡PDF書けまっせ6』のHTMLヘルプ呼び出しメニュー

○HTMLヘルプ
helpmain
図2 HTMLヘルプのトップ画面

○HTMLヘルプのページの例
helpSample
図3 HTMLヘルプで「図形を貼り付ける」を表示

○PDFの利用ガイド・表紙
PDFtop
図4 PDFのユーザーズマニュアルの表紙

○PDFの利用ガイド・ページの例
PDFsample
図5 PDFの利用ガイドで「図形を貼り付ける」を表示

デジタル出版物の制作方法 特にコンテンツの入力・編集の方法について

デジタル出版物(EPUB、PDF)をワンソースマルチユースで制作するワークフローについて考えて見ます。

先日Facebookで(https://www.facebook.com/kotaro.soryu/posts/580833075321422)で大変参考になる議論がありました。次に、Facebookの意見を参考にしながらもう少し考えてみました。

「ワンソースマルチユースの進化が遅い」(高木さん)というコメントがありました。確かに、そのとおりと思います。ワークフローを実際に動かすには関係者の学習が必要であり、また、システム化するとシステム構築のコストがかかるため、なかなか簡単には切り替えることができません。WYSIWYGがかなり急速に普及したのと比べると、ワンソースマルチユースの進化が遅いのは、システムコストの側面と、利用者の慣れ・学習の側面があるように思います。

「学習コストは別としてTeXはやっぱりシステム自体は完成されている」(山本さん)というコメントがありましたが、確かにTeXは、スタイルセットがいろいろ用意されているなど完成度の高い仕組みができています。

ワンソースマルチユースのワークフローでは、コンテンツとレイアウトの関係を再定義する必要があります。そこで上流から下流を、①ソースコンテンツの制作、②中間コンテンツの編集、③配布コンテンツの生成に分けてみると良いのではないかと考えています。

①ソースコンテンツとは、伝えたい言語内容を表現する文字(テキスト)、画像、数式、場合によっては動画などの表現したい内容の素材です。
②中間コンテンツとは、ソースコンテンツを配布形式にする過程で、ソースコンテンツを統合して作業する対象です。InDesignを使う場合は、InDesignのファイル形式であり、HTMLでオーサリングするのであればHTML形式が中間コンテンツとなります。XML形式のこともあります。中間コンテンツは、オーサリングの対象となりますので、オーサリングの仕組みと対で考える必要があります。
③配布コンテンツとは、デジタルコンテンツの配布形式です。現在では、PDF, EPUB, Web, などが主流です。配布コンテンツはPDFのようにレイアウト処理済みの形式と、WebやEPUBのようにレイアウト処理を、可視化時に行なうものがあります。いづれにしてもレイアウト指定が重要なポイントとなります。

ワークフローを考える第一のポイントは、ソースコンテンツから中間コンテンツを作る方法です。第二のポイントは、中間コンテンツから配布コンテンツへの変換の方法です。

TeXは大変に優れたシステムですが欠点もあります。第一に、ソースコンテンツにTeXの命令を埋め込みます。そこで、制作者がTeXの命令の使い方を学習する必要があります。つまり学習コストが大きいのです。第二に、TeXは紙への印刷やPDFの生成ではシステムとして完成しています。しかし、Webコンテンツに変換しようとすると、留意しないといけない側面もあります。つまり、TeXの命令は、ドキュメント処理用の命令、文字の表現、数式の記述の命令、システムやユーザーのマクロ命令など、役割の異なる命令が不可分に混在しています。また、TeXが開発されたのは、8ビットCPUの時代です。このためTeXは、現在ならUnicodeで表すことのできる文字をコマンドを使って表すなど少々時代遅れです。また、数式の中にテキストの記述が混在しています。MathMLでは、数式の中にテキストの配置を記述することができないため、数式をMathMLのようなマークアップに変換するのは極めて困難です。TeXドキュメントの中にユーザーの作ったマクロ命令が入っていたら汎用のコンバータではWeb形式に変換できないでしょう。

最近、人気をあつめているマークダウンは、ソースコンテンツに簡単なテキスト記法でマークをつけて、それをマークダウン処理ソフトで、中間コンテンツであるHTMLに変換する方法です。マークダウンの長所は、テキストのソースを簡単に記述できることですが、欠点はコンテンツの形式が極シンプルなものなら良いのですが、少し複雑なものは非常に難しくなります。マークダウンを採用して、今年、人気をあつめたサービスに「でんでんコンバータ」[1]があります。この記法の説明を読むと、HTMLで頻繁に使うクラス属性やID属性をつけるのが難しいことがわかります。「でんでんコンバータ」は簡単なEPUBを作るには良いですが、PDFは作れません。

CAS-UBは、Wiki記法を拡張したCAS記法を使ってソースコンテンツにマークアップします。CAS記法では、クラス属性やID属性などを簡単に付けることができるようにしています。CAS記法の方がマークダウンよりは考え方としては進化しています。CAS-UBでは、生成処理でEPUBとPDFを両方とも作れます。

CAS記法にしても、マークダウンにしても、独自の記法を覚えなければなりません。この記法によるマークアップは、プログラム作成と比較するととても簡単ですし、HTMLを直接記述するのと比べてもかなり楽です。従って、IT系では受け入れられやすいようです。しかし、どうも、一般の著者・編集者・制作者には敷居が高いようです。

結論として、一般の著者・編集・制作者にとってもっとも敷居の低い方法は、WordなどのWYSIWYGのワープロで原稿を用意して、そこから自動的に中間コンテンツに変換する方法のようです。しかし、Wordはもともと紙に印刷する想定でレイアウトを指定します。そして、一般のユーザーはレイアウトを優先して編集することに慣れています。ところが、レイアウト優先の文書は中間コンテンツにうまく変換できません[2]。うまく変換するには、Wordのスタイルを使って構造を統制した文書を作らねばなりません。CAS-UBによるワンソースマルチユースを普及させるために、今後は、Wordによるスタイル編集の普及・啓蒙活動に取り組みたいと考えています。

現在、配布コンテンツの形式が紙のみからEPUBやWebまで多様化していることから、ワンソースマルチユースの重要度が高まっています。ワンソースマルチユースでは中間コンテンツからマルチ配布形式を生成するため、中間コンテンツはレイアウトを分離しておき、生成時にレイアウト指定処理を行なうのが良いと考えます。このメリットを生かすにはレイアウト指定をパターン化・テーマ化し、そのテーマを増やすことが課題です。

[1] 電書ちゃんのでんでんコンバーター – でんでんコンバーター
[2] 『マニュアルEPUB化ハンドブック2014年版  EPUBマニュアル研究会報告書』(第3章参照)