フォント埋め込み(草稿)

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

電子ドキュメント内の文字情報は文字コードを使って表されるが、文字コードだけでは文字の形は分からない。文字コードをもとに文字の形を描画するにはフォントを使う。電子ドキュメント作成時にフォントのデータを内部に含めることを「フォント埋め込み」という。フォントを埋め込んだ電子ドキュメントを配布すれば、受け手は埋め込まれたフォントを使って文字を可視化できるので、例えば太字、丸文字など、ドキュメント作成者の意図した形で文字を表現できる。

フォントの所在
モバイル機器、PCなどの機器(デバイス)で、電子ドキュメントを可視化するにはデバイス・OS・リーダアプリなどに装備されているフォントのデータを使うのが普通である。Webフォントという、インターネット上のフォントサーバーからフォントのデータを入手して表示する技術も普及し始めた。

アウトラインフォント
デジタルフォントでは文字の形をグリフという。フォントは、一定のデザインのもとに作成した多数のグリフの集合である。一つの文字コードに対して複数のグリフが用意されている文字も沢山ある。もっとも成功したデジタルフォントであるアウトラインフォントはグリフを曲線で描画する。この描画パラメータをグリフデータという。OpenTypeのようなインテリジェントなフォントは、グリフデータに加えて、文字コードからグリフデータへの対応表、縦書・横書などでのグリフの切替表、ある文字を表示したとき、次の文字をどこに表示するか決めるためのグリフの各種寸法、配置すべき位置に関するデータ(フォントメトリックス)などの付随データをひとつにまとめて提供している。

電子ドキュメント作成時のグリフの扱い
電子ドキュメントを作成するとき、グリフの扱いを大きく分けると次の3通りになる。
① 電子ドキュメントに文字コードのみを含め、グリフデータは含めない(フォント埋め込みなし)
② 電子ドキュメントに、グリフデータを含める(フォント埋め込み)。
③ フォントからグリフデータを取り出し、グリフを描画する線画データに変換してから電子ドキュメントに埋め込む(アウトライン化)。
アウトライン化は特殊な用途なので除外し、以下では、①フォント埋め込みなしと②フォント埋め込みについて、a. 表示の違い、b. PDFとEPUBの埋め込み方法を比較しながら説明する。

フォント埋め込みの有無による表示の違い
受け手が電子ドキュメントを表示するとき、フォント埋め込みがないときとあるときでの相違を簡単に説明する。

(1) フォント埋め込みなし電子ドキュメントの表示
電子ドキュメントの表示アプリケーションは、デバイスやアプリなどがもつフォントを使う。電子ドキュメントの中で指定されているのと同じフォントが使えないときは、類似のフォントを使う。表示に使うフォントが文字コードに対応するグリフをもっていないとき、持っていてもグリフの形がオリジナルを作成したフォントと違うときは文字を正しく表示できない。また、多くの場合、フォントが違うとフォントメトリックスが異なるので作成時と文字の配置が変わり、レイアウトが崩れてしまう。

(2) フォント埋め込みあり電子ドキュメントの表示
フォントを埋め込んだ電子ドキュメントは、埋め込まれたフォントを使って表示すれば、文字の形や配置が変わることなく、作成時のレイアウトを再現できる。但し、表示アプリケーションによっては正しく再現できない。これはアプリケーションの責任である。

PDFとEPUBのフォント埋め込み方法の比較
PDFとEPUBでは、フォント埋め込みの技術的な仕組みは相当に異なる。次にそれぞれの仕組みを簡単に説明する。

(1) PDF
PDFは文字の位置を正確に指定する機能を備えている。そこでPDF作成ソフトがPDFにフォントを埋め込むとき、PDF作成ソフトはテキスト中の文字コードからレイアウトされたグリフIDにする。必要なグリフデータはPDF中の共有リソースとして保存される。そしてグリフIDから文字コードへの対応表(ToUnicodeCMAP)も作成する。中には、ToUnicodeCMAPを作成しないPDF作成ソフトもあるが、このようなPDFでは文字を検索したり、テキストの読み上げ、テキスト取り出しができない。このようにPDFのフォント埋め込みではフォントの中のグリフデータだけを使うので、それをPDF以外に転用するのは困難である。

(2) EPUB
EPUBのコンテンツ文書はXHTMLであり、テキストは文字コードで表される。EPUBのリーダーはフォントを使ってコンテンツを可視化する。このためEPUBのフォント埋め込みはフォントファイルの形式で埋め込む必要がある。具体的にはWebフォントと同じ方式で、CSS3の@font-face規則でフォントの属性とフォントのパスを記述する。Webフォントとの相違は、EPUBのフォント埋め込みではフォントファイルを自分のパッケージ内に含めるのに対して、Webフォントはフォントの存在をURLで示す点である。

サブセット化・難読化
フォント埋め込みのオプションについて説明する。

(1) サブセット埋め込み
電子ドキュメント作成時にフォントを埋め込むとき、フォントの中の全ての文字ではなく、その電子ドキュメントで使われている文字のみに絞ってグリフデータを埋め込むことをサブセット埋め込みという。日本語は文字数が多いのでフォントのサイズが大きい。サブセット化するとサイズを大幅に圧縮できるので、日本語のフォント埋め込みではサブセット化が重要である。PDFのサブセット埋め込みでは使われているグリフデータだけ集めれば良いが、EPUBのサブセット埋め込みはEPUB作成の度にサブセットフォントを作成する必要がある。Webフォントでも指定されたフォントファイルを丸ごとダウンロードするのではなく、フォントサーバーでダイナミックにサブセット化するのが普通なので、技術的には同じである。

(2) 難読化
EPUBのフォント埋め込みではフォントファイルの形式で埋め込むため、フォントを取り出してEPUB表示以外の目的につかうことも難しくない。目的外利用を抑制するため、フォントファイルの内部を解読し難くすることを難読化という。EPUB作成時にフォントが難読化されると、EPUBリーダーではそれを解読して読む必要がある。このため難読化に関しては作り手と消費側で合意が必要であり、EPUB3.0の仕様書には難読化のアルゴリズムやキーの使い方を規定している。

埋め込みとフォントの権利
フォントはプログラムとして著作者の権利が認められている。フォントを埋め込んだ電子ドキュメントの作成・頒布は、フォントの一部または全部の複製と再配布に該当するので、原則として著作権者の許諾が必要である。

PDFが登場したのは1990年代の後半であるが、当初はフォントを埋め込まないPDFは読み手の環境によっては正しく表示できないという問題による誤解や混乱が見られた。フォント・ベンダーによってはライセンス契約に埋め込み許諾・制限・不許可を記載している。しかし、PDFを作成するにあたって、ユーザーがいちいちフォント・ベンダーの許可を確認するのは面倒である。そこでOpenTypeにはフォントファイルに「埋め込み許可フラグ」が設定されており、PDF作成ソフトがそのフラグをみて埋め込みできるかどうか判断するという枠組ができている。また、1998年には日本タイポグラフィ協会は「電子ドキュメントデータへのフォント埋込み機能に対する タイプフェイス/フォントの権利保護に関する声明書」[1]で秩序ある埋め込みを許容する方向を示すなど、フォント埋め込みが幅広く使えるようになっている。この結果、どこでも、だれでもPDFを正しく表示できるようになった。このようにPDFの普及にあたってフォント埋め込みが果たした役割は大きい。

EPUBへのフォント埋め込みを許諾するかどうかはフォント・ベンダーによって方針が異なるようだ。またフォントファイルの「埋め込み許可フラグ」がEPUBを想定しているかどうかも不明である。こうしたことでEPUBのフォント埋め込みはまだ普及していない。フォント埋め込みが普及すれば、特殊な文字や外字などをイメージファイルとして表す必要がなくなるし、さらに文字による表現力が豊かになる。フォント埋め込みの普及を期待したい。

[1] 電子ドキュメントデータへのフォント埋込み機能に対する タイプフェイス/フォントの権利保護に関する声明書

Facebookで頂いたコメント

〔宣伝〕CAS-UBは、EPUB、PDFへのフォント埋め込みに対応しています。PDFはサブセット埋め込みのみです。EPUBはフルセット埋め込みとサブセット埋め込みの選択に対応しています。難読化は未対応です。

インライン(草稿)

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 ¶)で区切って、行内に連続してレイアウトしても構わないとされている。

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

先日紹介した「出版のワークフローは、ブラウザベースのCSS組版エンジンで変わるか? その1 発表の概要紹介」の論点について順番に検討してみる。今日は、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))に4つのワークフローの記述があるが、ここで、現在もっとも普及していると思われる、最初に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

出版のワークフローは、ブラウザベースのCSS組版エンジンで変わるか? その1 発表の概要紹介

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.マルチメディア出版のワークフローを促進する

(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

本のかたちを考える:四六判・基本版面の推奨値を検討する(案)

縦組書籍の判型の代表例は新書判と四六判です。今日はこの中の四六判の基本版面の推奨値を考えてみます。なお、今回は2段組を除外し、また脚注・頭注がある本も除きます。

前回[1]にも書きましたが、日本語組版における基本版面のパラメータは①文字のサイズ、②1行の文字数、③1頁の行数、④行間の4つです。

最近の四六判の基本版面の分布は以前に本ブログで紹介しました[2]。その後、追加調査した本を含めて四六判64冊の実態を整理してみます。

1.文字のサイズ
最小:8.8ポイント、最大:10.9ポイント、平均:9.4ポイント
文字サイズが9ポイント未満の本は珍しい存在ですが、今の時代では文字が小さすぎるとみられるのではないでしょうか。
10ポイント超も珍しい存在です。一般読者向けとしては、文字が大きすぎるでしょう。
推奨値としては9.0ポイント~10.0ポイントとします。

2.1行の文字数(字詰め)
最小:35文字、最大:46.0文字、平均:43.1文字
1行文字数は文字の大きさと余白の関係で決まりますが、9.0ポイント~10.0ポイントでは、40字~45文字が推奨となります。

3.1頁の行数
最小:15行、最大:21行、平均:17.8行
1頁15行の本はやや文字の並びが疎な印象があります。また、9.0ポイント以上では21行の本は無理があります。
16行~20行が推奨範囲となります。

4.行間(文字サイズに対する割合)
最小:50%、最大:92%、平均:67%
行間50%ですとルビがあるとき、ルビと左右の行がくっついてしまいます。
行間比率80%超の本はややスカスカな印象となります。
行間は55%~80%を推奨します。

5.1頁の文字数
1頁の文字数は、1行の文字数(字詰め)と1頁の行数の掛算となります。
実態としては最小:525文字、最大:900文字、平均:770.4文字です。
上の1~4の推奨値を組み合わせますと、
最小:40文字/行×16行=640文字
最大:45文字/行×20行=900文字
を推奨します。

基本版面としては次の5つを推奨パターンとします。

(1) 最小
640文字 40文字/行×16行 文字サイズ 9.8ポイント 行間比率70% 行間6.9ポイント(行送り16.7ポイント)
(2) 少なめ
714文字 42文字/行×17行 文字サイズ 9.6ポイント 行間比率68% 行間6.5ポイント(行送り16.1ポイント)
(3) 平均
774文字 43文字/行×18行 文字サイズ 9.4ポイント 行間比率66% 行間6.2ポイント(行送り15.6ポイント)
(4) 多め
836文字 44文字/行×19行 文字サイズ 9.2ポイント 行間比率64% 行間5.9ポイント(行送り15.1ポイント)
(5) 最大
900文字 45文字/行×20行 文字サイズ 9.0ポイント 行間比率62% 行間5.6ポイント(行送り14.6ポイント)

次に5つの推奨パターンによる組版例を示します。上から順に、最少、少なめ、平均、多め、最大です。
minimum
smalleraveragelargermax

実際にこの基本版面の設定で本を試作してみたいと思います。試作結果により最終的に決定します。

[1] 本のかたちを考える:基本版面のパラメータ設定の考え方を整理してみました
[2] 本のかたちを考える:(縦組・四六判)基本版面の分布実態、読み易い版面は?

マークアップとは(草稿)

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

マークアップ
マークアップとはコンテンツに対して指示マークをつけることである。マークアップの目的はさまざまである。ここでは編集者によるエディトリアル・マークアップ、コンテンツをブラウザで表示するためのHTML(Hyper Text Markup Language)タグによるマークアップ、テキストに簡単な記号でマークアップしてHTMLタグに変換する軽量マークアップ言語を取り上げる。

エディトリアル・マークアップ
編集者が、著者の原稿に、テキストを再入力するための指示、組版作業者に対する指示を記入することをエディトリアル・マークアップという。テキストの挿入、削除、置き換え、入れ替え、終了、分離、句読点の変更、ダッシュとハイフン、大文字化、小文字化、イタリックとボールド、段落のインデント、フラッシュ・ライト/レフト、縦方向の空きなどの指示をプリントされた原稿に記入する。また、見出しを階層化して構造をはっきりさせ、テキストの表示方法を区別する要素―引用、箇条書き、テキストボックス―をマークアップする。指示の仕方には、丸で囲む方法、アンダーラインやキャレットなどの記号を使う方法、例えば章のタイトルを<ct>のようなコードを用いて表現する方法がある。レイアウトに関わるコードに対しては、デザイナーが、別途、レイアウト指示を追加することもある。こうしたマークアップやコード化は分業で仕事をするための便宜的なものであり、一緒に仕事をする編集者、デザイナー、組版制作者の間で合意があれば、その具体的な方法は自由である。

ブラウザでコンテンツを表示するマークアップ
1990年代半ばに登場したWebブラウザは、インターネット上のサーバーに蓄積されたコンテンツを、端末のブラウザで可視化する。インターネットのコンテンツは、HTMLタグでマークアップされている。初期にはHTMLタグでコンテンツのレイアウトも指示したが、だんだんHTMLタグとレイアウトを分離するようになった。現在では、HTMLタグは主に文脈を指定し、レイアウトはCSSで指定する。ブラウザはコンテンツに付与されたHTMLタグとCSSによるレイアウト指定を解釈してコンテンツを可視化する。

HTMLのマークアップ作業
最新のHTML5では、100個以上のタグが規定されている。例えば、文章の大きな区切りをsectionタグで、見出しはh1~h6のランクタグで指定する。タグが複雑なことから、Webページを適切にマークアップするには、HTML専用のオーサリングツールを用いることが多い。しかし、HTMLタグの知識が十分あれば、テキスト編集ソフトを使って手作業でマークアップもできる。

マークアップと可視化の分離
マークアップはコンテンツの文脈やレイアウトを、コンテンツとは別のタグなどにより指定する考え方である。コンテンツに指示をするマークアップ工程と、マークアップされたタグに基づいてコンテンツを組版・可視化する工程が分離している。エディトリアル・マークアップにしても、HTMLタグのマークアップにしてもマークアップ作業と可視化処理は分離している。

コンテンツとレイアウトが渾然一体のWYSIWYG方式
コンテンツの制作では1980年代半ばからWYSIWYG方式(What You See Is What You Get)がマークアップ方式よりも優勢である。WYWIWYGとは画面上で表示されているレイアウトと出力レイアウトが同一という意味である。WYWIWYG方式のワープロやDTPでは、画面上にレイアウトされた状態のテキストを対話的に編集する。コンテンツとレイアウトが渾然一体の状態で編集作業が行われ、レイアウトを整えるためにコンテンツの文脈が無視されがちである。WYSIWYGによる制作作業と、マークアップ作業とはコンテンツ制作に関して、考え方が対立している。

軽量マークアップ言語
プログラムのマニュアルなどをHTMLで作成する開発者は、HTMLオーサリング・ルーツを使わずテキスト・エディタで記述することを好む。しかし、テキスト・エディタでHTMLタグを直接マークアップするのは作業負荷が大きい。そこで、原稿テキストに簡単な記号でマークアップし、プログラムを使ってHTMLタグに変換する方法に人気がある。またWikiでは、ブラウザのフォームで、テキスト入力時に簡単な記号でマークアップし、内蔵のプログラムでHTMLに変換して表示する仕組みが採用されている。こうした方式を軽量マークアップ言語(または、簡易マークアップ言語)という。その代表例としてはMarkdownとMediaWikiを代表とするWiki記法がある。軽量マークアップ言語によるマークアップの利用者は開発者が中心で、WYSIWYGになれた一般ユーザーにはあまり普及していない。

Facebook

プリントオンデマンドの用語解説(草稿) 

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

プリントオンデマンドとは

プリントオンデマンド(POD、 Print on Demand)の語義は「要求がありしだいすぐに印刷する」である。印刷ビジネスとしてはデジタル印刷機をつかって、小ロットの印刷物を短納期で製作する形態を意味する。出版が対象とする書籍(本)や雑誌では、印刷だけではなく製本や流通までを含む意味で使われることが多い。本の場合は、ブックオンデマンドという用語をあてる方が適切だろうが、今はプリントオンデマンドという言葉を使うのが主流である。ここではブックオンデマンドの同義語としてのプリントオンデマンドを中心に考える。

歴史
プリントオンデマンドは、1990年代後半から登場したデジタル印刷技術と、糊などの材料を含む製本技術の進歩によって支えられている。

印刷技術の進歩
現在主流になっているオフセット印刷は、印刷機にセットする版を制作し、印刷機によって版に転写したインクを紙に転写するアナログ方式である。版の製作、印刷機を動かして刷り出しを見ながらインクの量を調整するなどの準備工程が必要であるため、小ロット・短納期の印刷物には向いていない。これに対し、デジタル印刷機は複写機やプリンタのように印刷物を作るので、ロットの大きさでコストが変わることがない。印刷開始までの時間も短いので、小ロット・短納期が要求される印刷物に向いている。

印刷コストは、部数が少ないとデジタル印刷機の方が安いが、部数が多くなるとオフセット印刷の方が安くなる。オフセット印刷では版代や印刷の立ち上げコストなど初期費用がかかるが、刷り始めるとページあたりのコストが安い。デジタル印刷機では、ページあたりのコストは部数にあまり関係なく一定であるためである。両者のコストがクロスするのはモノクロで数百部といわれている。

製本技術の進歩
ちらしなどと違い、本をつくるには製本が必要である。製本は丁合・折り・綴じ・糊付け・表紙の取り付け・断裁など複雑な工程からなる。綴じにもさまざまな方式があり、即乾性の糊の登場など進歩が速く、製本専門の会社が工夫を重ねて製本技術が進歩してきた。単行本の製本は印刷会社とは別の製本専門会社が担当することが多い。雑誌は発行日が決まっているので、部数が多い雑誌の製本では、発行日に間に合わせるため、専用のラインを使って高速に製本することが求められる。現在の単行本や雑誌の製本工程は一度に大量の部数を、専門化したラインでバッチ処理することで、高い生産性を実現し、結果として製本コストが安くなっている。

最先端のプリントオンデマンド・システムではデジタル印刷機と自動製本装置を連動する一貫システムで、ほとんど人手を掛けずに製本ができる。このようなシステムは日本では数システムが導入されているといわれる。自動製本システムは、専門会社の製本ラインほどの高い生産性を挙げることができない。こうして、現在のところ、最先端の製本システムを使ってもバッチ処理のシステムより一部あたり製本コストが高くなるようだ。

流通
プリントオンデマンドのコストの仕組みは電子書籍に似ているが、決定的に異なるのは形があるモノを作ることだ。このため、一般の読者に本を届けるには新しい物流の仕組みを構築する必要がある。

その一つはデジタル印刷機と製本を一体化したエスプレッソマシンである。アメリカでは大学などのテキストを組み合わせてその場で製作して学生に渡すのにつかわれているといわれる。日本でも、一時、神田の三省堂本店に導入され、お客の要望で本を作る試みがなされた。このように出版物を読者の手元で作るのにつかえる。

アマゾン(日本)は2011年4月よりプリントオンデマンドを導入した。当初は洋書から開始したが、現在は、国内出版社の本も対象にしている。電子書籍のKDP (Kindle Direct Publishing)は個人の出版者が参加できるが、PODサービスでは取次を通す必要がある。このほか、楽天ブックス、hontoのようなオンライン書店が次々とプリントオンデマンドの本を扱い始めている。こうしたオンライン書店のプリントオンデマンドサービスは、読者からみると従来のアナログの本作りと同じである。

出版活動の経済面とプリントオンデマンド
印刷・製本の両面からみてプリントオンデマンドでコスト・メリットがあるのは小部数の出版物である。プリントオンデマンドでは部数が多くなっても単価が下がらないので、千部以上ともなればアナログの印刷とバッチ製本の組み合わせで製作する方が安い。商業出版社の本では企画・編集・制作のコストが最初にかかるが、千部以下でそのコストを回収するのは難しい。プリントオンデマンドが有利になるような部数の本はそもそも出版できないのであり、商業出版社にとっては初版にプリントオンデマンドを採用する意味はない。むしろ増刷の際やシリーズものの欠品を回避するために採用されている。

出版活動には、自己の思想や考え方を広める出版、学術研究成果を社会に還元する専門出版、企業のPR本などの利益を目指さない分野がある。こうした商業出版以外の領域では初版部数を気にする必要がない。むしろ少ない部数から出版できて、コストの総額を小さくできるプリントオンデマンドを採用することで、出版できる本の種類が増える。

経済面からみるとプリントオンデマンドは電子書籍に似ている。電子書籍とともに、出版活動の敷居を下げ、その活発化を担う両輪となることが期待される。

[1] https://www.facebook.com/tokushige.kobayashi/posts/1057419407676505