JEPAの「いまさら聞けない電子書籍のABC ~ebookpedia~」の下書きです。最終版は、JEPAのページをご参照ください。

ラインは線であり、インラインとは線を構成することあるいは線を構成する部品のことである。デジタルドキュメントの領域では、インラインという言葉は、様々な使われ方をする多義語であり、言葉の定義は曖昧でなんとなく使われているようだ。そこで、ここではいくつかの分類に分けて例を挙げて説明してみる。

1. 記述方式としてのインライン
次に挙げるいくつかの例のように、ある文脈で表したコンテンツの中に、別の文脈のコンテンツを記述することをインラインと表現する傾向がみられる。厳密な定義によるものではなく、なんとなく使う、自然発生的な用語のようだ。

(1) CSS（Cascading Style Sheets）のインライン・スタイル
HTML文書にレイアウトをCSSで指定するには3通りの方法がある。
① HTML文書に外部のCSSファイルをリンクする。
② HTML文書のhead要素の子供としてstyle要素を置き、そのstyle要素の内容としてCSSを記述する。そのときCSSはHTML文書全体に有効となる。
③ HTMLの要素にstyle属性を置き、その値としてCSSを記述する。例えば次のように記述する。
<h1 style=”color:blue;margin-left:2em;”>見出し</h1>

③のように要素にスタイル属性を持たせることをインライン・スタイルと言う。しかし、HTML5の仕様書には単に、「HTML5ではすべての要素にstyle属性の値を指定できる。これはCSSスタイル属性である。」と書かれているだけである。

(2) インラインSVG（Scalable Vector Graphics）とMathML（Mathematical Markup Language）
HTML4まではsvg要素やmath要素はHTML4で規定される要素ではなかった。このため、SVGやMathMLで記述したコンテンツは、画像ファイルとして作成して、ラスター画像のように参照するか、embed、object、iframe要素から参照した。これに対して、HTML5ではHTMLの要素のひとつとしてsvg要素、math要素を記述できるようになった。これを「HTML5ではインラインSVGやインラインMathが使えるようになった。」という言い方で説明されることが多い。但し、HTML5仕様書の中ではインライン（inline）という言葉は使われていない。

(3) インラインコメント
電子メールでは相手のメールに返信するとき、「インラインで失礼します」という言い方をすることがある。IT用語辞典やメールソフトの説明書などでは、相手のメールを引用して、そこに自分のコメントを挟むことをインラインコメントと表現している。メールの文章全体をひとつのラインとみて、相手の文脈の中に、別の文脈として自分のコメントを挟むことから由来しているようだ。失礼かどうかは別として、インラインという表現が当てはまるかどうかは曖昧である。

2. レイアウトにおけるインライン
テキストをレイアウトするときに、インラインという言葉を使う。この場合のラインは行であり、インラインは行としてレイアウトされることを示す。

(1) インライン数式
数式を段落の1行中に書く方法をインライン数式またはインライン・モードという。数式は、通常、上下・左右の領域に平面的に書くが、段落内に数式を書くときは、一行に広げて書くと段落内の行間が均一になり見やすい。例えば分数は、分子を上に書き、横線で区切って、分母を下に書くのが普通である。インライン・モードでは、最初に分子を書き、区切りの「／」を置いて次に分母を書く。TeXやMathLのような数式記述言語ではインライン数式を使い分けできる。

(2) CSSのインラインボックス
CSSはボックスモデルというレイアウトモデルを使ってコンテンツを配置する。領域全体を包含するボックスの中に、インラインレベルのボックスを水平に並べることをインライン・フォーマッティングという。CSS2.1の仕様書には次の例が出ている。
<P>Several <EM>emphasized words</EM> appear
<STRONG>in this</STRONG> sentence, dear.</P>
P要素は段落領域を作る。そこに次の5つのインラインボックスを作る。EM要素、STRONG要素はインラインボックスを作る。また、前後の文字も匿名のインラインボックスを作る。
Anonymous: “Several”
EM: “emphasized words”
Anonymous: “appear”
STRONG: “in this”
Anonymous: “sentence, dear.”
これらのインラインボックスを段落内に並べて行を作る。

CSSでは各ボックスに対して、文字の大きさ、ウエィト、色などのプロパティでレイアウトを指定する。また、HTMLの要素に対して、displayプロパティでどのようなブロックを作るかを指定できる。

3. HTMLのインライン要素

HTMLでは長いことインライン要素、ブロック要素という区別が使われてきた。しかし、HTML5ではこの区別がなくなった。インライン要素、ブロック要素の分類は暗黙のうちにレイアウトで分類しているのであるが、コンテキストをセマンティックスとレイアウトに分離する流れの一貫である。

(1) インライン要素とブロック要素
HTML4までは文書を構成する主な要素の種類としてブロック要素とインライン要素という区別があった。ブロック要素の代表は段落要素Pや区切り要素DIVである。ブロック要素の中には、他のブロック要素やインライン要素を含むとされており、インライン要素の代表例は、強調（EM、STRONG）やインラインの範囲指定（SPAN）などである。
このブロック要素やインライン要素という分類方法には、ブロック要素は大きめの構造を表し、インライン要素は小さ目の構造を表すという曖昧なコンセプトが与えられていた。しかし、むしろ暗黙のうちにレイアウト方法も指定していた。つまり、Pは段落という領域にレイアウトし、EM、STRONG、SPANなどは行としてレイアウトするという暗黙の了解である。

(2) HTML5
HTML5では、要素はコンテンツのセマンティックスの観点から分類されており、インライン要素とブロック要素という分類はなくなった。HTML5でもp要素は段落を表すものとして定義されている。ブラウザは、CSSのdisplay:blockレイアウトをデフォルト値としてもち、p要素は段落領域を作るようにレイアウトするが、p要素で段落を区切らないで、インラインのパラグラフマーク（U+00B6 ¶）で区切って、行内に連続してレイアウトしても構わないとされている。

2015年8月11日～14日にワシントンDCで開催されたBalisageマークアップカンファレンスで、Vivliostyleの村上真雄氏とJohannes Wilm氏の共著による“Vivliostyle – Open source, web browser based CSS typesetting engine”という発表が行われた。

Twitterやメーリングリストを見るとこの発表はかなり人気をあつめたようである^[2]。

早速、一読したが、なかなか興味深い発表である。まず大筋を紹介する。次の回でいくつかの問題について一緒に検討してみたい。

(追記)　レビュー: HTMLを主なコンテンツ形式にすること

Ⅰ 発表文の要約

オリジナル発表文はCC BY 4.0で公開されているので、最初に英語に詳しくない読者のために適当に要約する。詳しい方はぜひ原文をお読みいただきたい。なお、番号は次回以降で検討を加えるために段落毎に私が付加したものである。

１．マルチメディア出版のワークフローを促進する

(1) テキスト中心の内容を、印刷した本、電子書籍、Webなどのメディアで出版しようとすると多数の挑戦に直面する。ほとんどの出版のワークフローは、一般的な出版ワークフローの一部または全部を合体している。

(a) 小規模の商業出版では、原稿を主にMicrosoft Wordで書き、HTMLにエクスポートしている。Web版ではそれをクリーンアップし、テキストを埋め込むサイトで使うタグ、属性、クラスに変換する。EPUBにするときはHTMLファイルをさらに変換する。印刷版を作るときはテキストをInDesignのようなDTPに取り込んで設定する。WordでPDFにするかもしれない。

(b) 小規模の学術出版では、LaTeXとpdfTeXのようなツールでPDFを作る。LaTeXは参考文献の管理や数式に強い。EPUBやWebを作るときは、最初にTeXからHTMLに変換する段階がある。この変換は完全にはできないので大抵手作業が必要である。同じような問題は入力でも起きる。原稿がWordで書かれているとTeXにするのが大変だ。

(c) 大きな出版社や組織ではXMLを経由する。WordからXMLに変換し、手作業でクリーンにする。次に各種の変換ツールでPDF、HTML、EPUBにする。PDFは例えばXSLTでXSL-FOに変換し、フォーマッタで解釈してPDFにする。Webは他のXSLTでHTMLに変換して得る。HTMLからEPUBを変換して得る。理論的には、これらのプロセスは完全自動化が可能だが、実際には沢山の手作業と手による編集が必要である。それは、内容には出版物の種類に特化した要素を含んでおり、そうした要素が変換ソフトの作者が予期しなかった、ためである。

(d) XMLを中核とする他のワークフローでは、XMLを直接変換する代わりに、InDesignにインポートして印刷用に調整する。このときは、XMLが変更されたらInDesignでの変更が再度必要になるという問題がある。

(2) 上記の変換システムの問題は、手作業が多いこと、異なる出力媒体毎に異なるワークフローのステップが必要なことだ。XMLを含む専門的なソリューションでは理論的にはワンソースでできるはずだ。しかし、XMLは編集し難い。また、XHTMLはXML準拠でないHTML5に置き換えられつつあるようだ。

(3) XMLをスタイル化するもっとも一般的な方法はXSL-FOである。XSL-FOを使う出版物は依然として増えており、CSSよりも進んだ機能をまだ持っている。しかし、XSL-FOの標準化への関心は少なく、W3CはCSSがXSL-FOを置き換えると信じたため無期限に停止されたという問題がある。

2. Webベースのコンテンツソリューションの必要性

(1) 出版の既存ソリューションは一つとして完全に動いていないし、自動化もされていない。また、多くの出版のワークフローの中心部にはXMLが置かれているが、それはHTMLがXHTMLに置き換えられようとした20世紀末の歴史的な人工遺物である。XMLは最終出版形式ではなく、Webには存在しない。XMLをWYSIWYGで編集できるエディタはHTMLについてよりも少ないので、不必要な変換プロセスが多く必要である。

(2) HTMLを主なコンテンツ形式にすれば変換プロセスは少なくなるか、完全になくなるだろう。

(a) EPUBはHTMLの制限付きのバージョンであり、スタイル付けは限定的なCSSである。従って、HTMLソースファイルからEPUBへの変換は多くの場合自動的にできるだろう。もし、タグ、属性、CSSの規則を制限するならば、変換プロセスは完全に自動化できるだろう。

(b) Webに出版するときは、ソースファイルはそのままで良い。さらに追加が必要であれば単純なコンバータを追加できるだろう。

(3) WebやEPUBの出版では、変更は必要ないかもしれないが、印刷の状況はかなり異なる。標準的な印刷組版はどれもHTMLを中心としてその周りに作られていない。ソースファイルはMicrosoft Word, Adobe InDesign, XMLファイルである。

(4) 多くの出版社はワークフローをHTMLに変更することでメリットがあるだろう。また、XSL-FOで定義されるスタイリングをCSS組版に切り替える利益があるだろう。なぜならば、すべての出力形式のために類似のスタイル定義を使えるからである。

3．既存のHTML中心のプリント組版

(1) AH FormatterとPrinceXMLというHTML/CSSを使う二つの組版ソフトがある。

(2) 両社はCSSとHTMLを入力とするスタンドアロン版である。少なくとも二つの大きな出版社（O’Reilly MediaとHachette Book Group）が採用している。組版ソフトは普通に使うHTML要素を受け付けるが、両者の実装は少し異なる。Webベースのコンテンツ制作者や編集者は、Webの仕様に準拠するだけでなく、普通のWebブラウザの実装に従う必要がある。さらにWebのコンテンツがブラウザで問題なく可視化できるとしても、上記のCSS組版ソフトで組版する前に余計な注意を払う必要がある。組版ソフトは、ブラウザとは多少違うし、そのCSS仕様の実装は比較的ゆっくりしている。これが現在の印刷出版業界が直面している問題の一つである。他の問題は標準CSSが、本のスタイル付けのために必要な規則のすべてを実装しているわけではなく、本の出版のためのスタイル付け機能の開発は始まったばかりであることだ。

4. WebブラウザとJavaScriptを印刷出力作成のために使う

(1) 2012-14年に開発されたPagenation.jp, simplePagenation.jsの二つは、ブラウザで走るHTMLベースの印刷レイアウトシステムである。JavaScriptで書かれており、印刷する本に特有のスタイルを付けることができる。但し、ブラウザのprint-to-pdf機能を使っておりApple Safariでしか動かない。

(2) 二つのJavaScriptパッケージはすべてのページを通じて特別なルールに従って繰り返す一般的な本の印刷専用である。雑誌やページ毎のレイアウトをする本用ではない。

(3) 二つのJavaScriptパッケージはコンセプト実装であり、特別なレイアウトタイプの本には良いが、応用性がない。

5．必要なこと：印刷のための共通のスタイル仕様

(1) 我々の焦点の一部は、印刷や他のページ媒体だけに重要な余分の要素をWebの仕様として定義して、他のプロジェクトと相互運用可能にすることである。

(2) 重要な仕様の一つはCSS Paged Media仕様である。これはAH Formatter、PrinceXMLを含む幾つかの組版エンジンがCSS Paged Mediaを実装している。

(3) ブラウザは、PDFを作る方法を実装しているが、主要なブラウザはCSS Paged Mediaを実装していない。電子書籍リーダーの多くも同じである。

(4) 補足すると、CSS Paged Media仕様を実装する組版エンジンはベンダー間で非互換の独自拡張をサポートしており、ソースファイルをエンジン間で移すのが困難である。

(5) Vivliostyleプロジェクトでは、Web標準を進めることを優先しており、Vivliostyle.jsが他のまた未来のWebペース印刷エンジンと相互運用可能になるようにする。

(6) W3Cと一緒の作業を始めており、CSS Paged Mediaや他のCSS Page Floats, CSS Generated Content for Paged Media仕様を推進する。

6. 必要なこと：JavaScriptベースの一般的な印刷レイアウトの実装

(1) 一般的な印刷レイアウトのためのJavaScriptベースのソリューションが必要である。すべての主要なブラウザの上で動き、付随するページレイアウトを定義するCSSを読み、レイアウトを完全にCSSで定義できるようにする。印刷のためのWebコンテンツを準備したり、ブラウザを電子書籍のリーダーにするのに使える。

(2) 半年ほどVivliostyle.jsのコーディングしてきており、開発を継続している。ページに関係するCSSプロパティをパースする。脚注、ページ番号、ページヘッダを含む基本的なページスタイルが可能である。

(3) W3Cの仕様のかたちで標準化途中の新しい機能をJavaScriptで実装するのはExtensible Web Manifestにふさわしい。JavaScriptでどのように動くかを試すことで、関連する仕様を推進できる。うまく行けば、印刷に関連するCSS仕様の完成とブラウザが印刷関連の仕様を実装するのを支援できる。

7. 結論

テキスト出版の世界は分断されている。これを統合する試みはいくつかあり、XMLが長い間もっとも見込みがあった。出版業界では労働力集中型のDTPベースのワークフローの代替、インプットから最終出力までできるだけ少ないステップで、コンテンツの変換を自動化する印刷ソリューションを探している。ここに示したように、CSSとHTMLの組み合わせは、出版のワークフローの統合に置いてもっとも見込みがある。CSSとHTMLがもっと多くの出版社のための実行可能な代替手段になるためには、CSS標準の開発とJavaScriptの早期実装が必要である。

Ⅱ 感想
この発表は、異なる種類の課題を一緒くたに詰め込んで議論しており突っ込みどころが多い。また、著者は現実世界の問題の本質をあまり理解していないように感じる。次回にこうした点について検討を加えてみる。

[1] Vivliostyle – Open source, web browser based CSS typesetting engine Shinyu Murakami, Johannes Wilm (Vivliostyle Inc.)
[2] Great responses after I presented our paper on @Vivliostyle at #balisage today! Thnx! http://www.balisage.net/Proceedings/vol15/html/Wilm01/BalisageVol15-Wilm01.html
[3] XHTML is simple, but also other XML-formats such as DocBook/DITA can be styled with CSS via XSLT transform to HTML or directly. @AntennaInfo

『本はどのように消えていくのか』（津野　海太郎著、晶文社、1996年発行）
四六判、220頁、1900円＋税

書名と同名の短文を中核とする短文集である。一読して、やはり「本はどのように消えていくのか」（pp. 76-97）が最も印象に残る。

本文の趣旨を整理すると、次のようになるだろう。

冒頭で「はたして紙と活字の本はなくなるのか。」と問い、「おそらくなくなるだろう。」、ただし、数百年かかるだろう、と答える。本文で論じているのはどのような過程をたどってなくなるのか？　ということである。

まず、紙と活字の本のモノとしての側面を、①明朝体の文字をタテヨコそろえて組み、②それを白い紙の上にインキのしみとして定着し、③綴じてページづけしたもの、と定義付ける。(p.77)

津野さんは、そのような本と並行して、数十年の間に①ネットワークを通じてデータを入手し、②ディスプレイ画面にデジタル文字として表示、③複数のウィンドウを切り替ながら読むという仕組みが出現するという。(p.91)

こうしたモノとしてのデジタル電子本は50年以内には完成するかもしれない。しかし、「いまあるような紙と活字の本が、まるごと別のモノによっておきかえられるには百年、二百年、いや三百年かかる。」（p.92）

その理由は、紙と活字の本は「水のように流れる自分の想念を書くことによってせきとめ、ふかめ、それをインキのしみとして、紙やその他の素材の上にしっかり定着しつづけてきた。」（p.94）、「ディジタル・ネットワークにおける…中略…ディスプレイ画面上の文字はインキのしみではなく、かげろうのようにはかない一瞬の映像に過ぎない。印刷が印刷でないものにとってかわられるということは、…印刷によってきざまれる動と静、運動と定着のリズムが私たちの社会から完全に消滅してしまうことを意味する。」（p.95）

要するに印刷が安心感の根拠であるが、モノとしての電子本が新しい安心感の根拠になるまでの社会あるいは人間の「読書習慣」の変化には数百年かかるだろうから、その間は、紙と活字の本と新しいデジタルの本が共存する期間となる、というのが津野さんの主張の骨子である。

さて、この記事が書かれてから既に20年になろうとしている。この間、活字は既に消滅し、デジタルフォントに置き換えられた、そして印刷もデジタル印刷に変わりつつある。そして、津野さんのいうデジタル電子本も技術的にはかなり進んできた。そして電子書籍が一部で確実に普及している。

しかし、この文章の冒頭の「はたして紙と活字の本はなくなるだろうか？」という設問への答えはまだ見えておらず、相変わらず想像力を掻き立てる問いのままである。

本は津野さんのいうように一つの世界観を封じ込めた精神的なカプセルである。そのカプセルの内容を表示する装置が紙か電子デバイスであるかということが紙の本と現在のデジタル本の違いである。ところで、そのカプセルの内容を紙の上に定着させた場合と、画面に一瞬表示した場合で、読み手に与える効果・影響にどの程度の相違があるのだろうか？　これはまだはっきりとはわかっていない。津野さんの主張は、その相違および読書習慣の永続性を強調しすぎているとも思える。

いずれにせよ、日々の糧を得ようとしてアクセクしているわが身にとっては、数百年後に紙と活字の本はなくなるだろうというのは時間のスケールが違いすぎる。