xsl-fo and professional publishing

XSL Listに興味深い議論が載っていました.


>I wonder whether xml + xsl + xsl-fo is a current practise in 
>professional publishing for technical books at least in Europe.

で始まる投稿に関してEliot Kimberさんが


>Most publishers do not use an XSL-FO process for books that have unique
>page designs--publishers today almost without exception use InDesign as
>their page composition tool.

と答え、それに対してLiam Quainが


>To give a counterpoint to Eliot's response, XSL-FO is very, very widely
>used in professional publishing; the largest publishers use XSL-FO (and
>in some cases XHTML + CSS) for most of their fiction and mainstream
>texts.

と反論しています.

そして次の例を出しています.


>>I'm happy to be proven wrong on my no-FO-in-publishing assertion
>>I don't know if it's wrong so much as a different perspective on the
>>same data.

>Some sources...
>XSL-FO renderer vendors having increased sales in the publishing area;
>consultants to publishers, and publishers themselves, attending XSL-FO
>related events (markupforum, XML Prague, W3C Workhops on publishing)
>public presentations at said events
>E.g. Hachette has moved from XSL-FO to XHTML + CSS so they can share CSS
>between epub and print more easily; Penguin said at the XSL-Fo meetup in
>Prague a couple of years ago that they used XSL-Fo for all of their
>mostly-text/prose books such as fiction; that's two of the Big Six (or
>Big N) right there.
>Similarly at JATS-Con (a conference for STM journal publishers) there
>were quite a few Antenna House users, enough that Antenna House staff
>were there.
>W3C has been relatively active in publishing (both print and epub) in
>the past year or so.

いろいろな話が載っていて興味深いですが、私は

>E.g. Hachette has moved from XSL-FO to XHTML + CSS so they can share CSS
>between epub and print more easily;

というのが、この先のpublishingを切り開くテクノロジーとして本当に採用すべき道であるかというとどうにも疑問です.簡単なものなら良いと思いますが.

例えばprofessional publishingと言われる世界で、本の索引のようなものはXHTML + CSSで可能なのでしょうか?XSL-FOならある意味電車道で作成可能ですよね?

また最近HTMLをやる機会がありましたが、いくつものCSSスタイルシートがあたっている場合、最終的にdivでもspanでも良いのですが、ある要素にどのようなスタイルが当たるのかを判定するのは人手ではとても無理と思いました.(組版時にはCSS Formatterがそれをやっている訳です.それと同じことを頭で考えろと言われてもとてもついてゆけないでしょう.)

XSL-FOではすべてのスタイルは基本的Formatting Objectのプロパティで「直接」指定します.ですからCSSよりずっとわかりやすいです.デバッグのときに考えればよいのは、上位要素からのプロパティの継承です.CSSは要素の出現条件や、クラス属性から「何がスタイルとして当たるか」を「間接」的にCSSスタイルシート見なければなりません.またCSSセレクタはずいぶん進化したように思えますが、それでもXSLTのパターン(xsl:template match="...")に比べれば足元にも及びません.結局うまくスタイルがあたるように、上位のスタイルシートでコントロールしてやらねばなりません.これはXSL-FOも同じですが、結果を直接見れるのと間接的に見なければならないのは大きく違います.

お客さんにはCSS Formatterをつかっているという事例もありますが、XSL-FOを使うまでもない簡単なものが対象と聞いています.確かにfo:lanyout-master-setをいちいちつくっているより、CSSのほうが簡単でしょう.でも実現する対象が複雑なものになるに従い、CSSで実現するのはXSL-FOで実現するよりどんどん実装もデバッグも難しくなってゆくのではないでしょうか?

私がいやなのは保守やデバッグの大変さを開発者に強制するテクノロジーの姿です.はたしてこれは杞憂なのでしょうか?

またそもそもLiam QuainがBig Six (or Big N)として出している状況と言うのはやはりPublishingの分野ではInDesignが強い、Kimberさんの論だと、

InDesign operators are essentially a commodity,
XSLT and XSL-FO programmers are rare, so even if it made technical or
economic sense it can be hard to staff and FO-based workflow

というのは当たっている気がします.これだけXMLが普及してきたといっても、まだまだそうワークフローを変革してゆくところまでは行っていないのですね.