日別アーカイブ: 2015年8月19日

出版のワークフローは、ブラウザベースのCSS組版エンジンで変わるか？　その２　HTMLを主なコンテンツ形式にすること

投稿日時: 投稿者:
返信

先日紹介した「出版のワークフローは、ブラウザベースのCSS組版エンジンで変わるか？　その１　発表の概要紹介」の論点について順番に検討してみる。今日は、HTMLを主なコンテンツ形式にすることを取り上げる。

以下の原-番号は、先日のブログで段落に付加した番号である。

1．論旨の混乱

原-2．(1)、(2)で、Webベースのコンテンツ・ソリューションについて、HTMLを主なコンテンツの形式（main content file format）とするとメリットが大きいと主張する。
原-3．でHTML/CSSセントリックな組版ソフト、原-4.でブラウザ上で動くHTMLベースのJavaScript印刷レイアウトシステムについて解説する。

原-2の主張は、ソリューションの中核であるコンテンツ形式としてHTMLを使うということであるので、HTMLをどのように入力するか、そのどのように加工・蓄積するか、どのように出力するかが検討項目となるはずだ。

原-3、4ではHTMLを印刷することを議論しているのである。主なコンテンツ形式がHTMLである必要はなく、主なコンテンツ形式からHTMLに変換した上で印刷すれば良い。

このように原-2の主張と原-3、4の主張とは一見関係ありそうだが別の話題である。分離して考えないと混乱してしまう。本発表はかなりミスリーディングな部分が多いが、そのひとつはここだ。[1]。

2. HTMLを主なコンテンツの形式にすること

さて、原-2のHTMLを主なコンテンツの形式にするという主張について考える。つまりこういうことだ。

まず、ある出版社が（原-1(1)）と同じようにテキスト中心の内容を、印刷した本、電子書籍、Webなどのメディアで出版をめざすソリューションの開発を企画したとする。そして、あなたが出版社の社長から新しい出版ソリューションの設計を依頼されたとしよう。そのときコンテンツの中核形式を何にするかは重要なポイントになる。

まずは、現在のワークフローを分析する必要がある。原-1(1)の(a)～(d)）に４つのワークフローの記述があるが、ここで、現在もっとも普及していると思われる、最初にInDesignで印刷本のための版を作るというフローの検討が抜けている。現状分析において、現在の主要ワークフローを無視してしまうというのは、ソリューションの提案を作るためにスタートから落第点だろう。

次に、この原-2の冒頭の(1)項であるが、「出版の既存ソリューションは一つとして完全に動いていないし、自動化もされていない。」（ 原文はit was clear to us that none of them function perfectly, nor automatically. ）という主張は誤りである。この反例としては、CAS-UBを挙げるだけで足りる。

DITA-Usersでも、この部分についての指摘があった[2]。ここでの議論を見ると、どうも著者達は自分が何を主張しているかを理解できていないように見える。

原-2(2)では「HTMLを主なコンテンツ形式にすれば変換プロセスは少なくなるか、完全になくなるだろう。」と言っている。

この発表では、XML[3]、XHTML、HTMLが出てくる。XMLを否定してこれからはHTMLだと主張したいようだが、そもそも用語の定義が曖昧である。とりあえず、原-1(2)には「XHTMLはXML準拠でないHTML5に置き換えられつつある。」（XHTML is being replaced by the non-XML-conforming HTML5）という表現があるので、XHTMLを否定しているように見える。従って、主なコンテンツ形式は、HTML5であってXHTML5を含まないと推論できる。

そうすると、原-2(2)(a)の主張は誤りである。EPUB3.0のコンテンツ文書はXHTML5であってHTML5ではない。このため「HTMLを主なコンテンツ形式にすると変換プロセスは多くなる。」のである。

こうしてみるとわかるとおり、本発表は技術的にずさんすぎる。技術論というよりプロパガンダであると言うのが適切だろう。

原-2の「2. Webベースのコンテンツソリューションの必要性」での主な論点であるHTML5を中核フォーマットとするワークフローが本当に最適なのかどうか、ここのところには大きな疑問がある。

著者達を含め、HTML5＋JavaScriptでXMLを置き換えることができるということを主張する論者が多い。確かに一部はそうかもしれない。しかし、すべてを置き換えるのはおそらく不可能だろう。

XMLは「成熟しており、多数の実証された実装をもつ柔軟な技術、無数のツールがあり、XMLベースのシステムを実装できる技術者が大勢いる」（it is a mature, flexible technology with many proven implementations, and a huge set of tools for working with it, and there are many people knowledgeable about it who are available to implement XML-based systems）[4]のである。

原-1、原-2では出版ワークフローの自動化を議論している。ワークフローの自動化を進める際に、HTML5＋JavaScriptを採用するか、XML技術を採用するかは極めて大きな選択肢なのである。twitterやDITA-Usersでの議論を含めて判断すると、どうも、著者達は基本的な論点であるはずのところを全く理解できていないようだ。

[1] 論より証拠でXHTML is simple, but also other XML-formats such as DocBook/DITA can be styled with CSS via XSLT transform to HTML or directly. あたりで混乱が起きている。DITAを直接CSSでスタイル付けても無意味である。もし、DITAのtopicをCSSで、直接、組版レイアウトするというのであれば、その発言者はDITAの組版について無知であるという推論が成り立つ。(参考のため：DITA組版についての簡単な解説文)
[2] https://groups.yahoo.com/neo/groups/dita-users/conversations/messages/38075
[3] XMLとはなにかについて簡単な解説はXMLを参照。このようにXMLとは膨大な技術体系を意味するのであって、XHTMLやHTMLと比較できるものではない。
[4] https://groups.yahoo.com/neo/groups/dita-users/conversations/messages/38077