CSS Nite LP, Disk 17「HTML5による電子書籍」
9/17にCSS Nite LP, Disk 17「HTML5による電子書籍」に参加してきました。
ここでは電子書籍関連のネタをちょこちょこ書いていますが、私は基本的にはDTP系の人でWebのトレンドとかよくわかっていないので（HTML5はEPUB3の関係で勉強はじめたところ…）、どこまでついていけるか不安でしたが、非常に内容の濃いセミナーで勉強になりました。
個々の内容はまとめられるほど理解できていませんが*1、いちばん印象的だったのは境祐司さんのセッションの中の「Webマガジンと電子雑誌の違い」について。
「HTML5による電子書籍」というタイトルを聞いたときに、サイト上にHTMLデータが置かれているのなら、それってWebサイトと違うの？ と思っていたのですが、ビジネスモデルに応じてデザインが変わるということでした。*2
広告モデルのWebサイトの場合は、広告への接触機会を増やすためにコンテンツの横にずらずらと並べたり、ページを増やすためにコンテンツを途中で切って次のページに移動させたり、ひどいものになるとコンテンツを覆い隠すように広告が表示されることがあります。
一方電子雑誌の方は、定期購読モデルで、読者がうっとうしくなるような広告表示は少なくなる（ようにデザインされる）ということのようです。電子雑誌の方が読者の方を向いた形態ということでしょうか。
もっとも定期購読モデルで成り立つかどうかは別の問題でしょうけど。広告を入れるとして電子雑誌だと記事と別のページに広告掲載しても読み飛ばされることが多くなるようですし。*3
電子雑誌とはいえWebサイトにアクセスするという形式だと、お金を払うという意識が出にくいという意見もどこかで聞いた気もします。中身は同じHTML5でも、パッケージ型でダウンロードするEPUBのほうがお金を払うことに心理的な抵抗が低くなるのではないかという話もありますが…。*4
このあたりはセミナーの趣旨とは離れるので触れられていませんでしたが、個人的には興味のあるところです。
IGAS2011
初日に見てきました。朝早めに行ったのでそれほど混んではいませんでしたが、入り口のチケット売り場に列ができていました。Webサイトで事前申し込みをしても無料にはならないとはいえ、招待券自体があまり配られていないのでしょうか。*1
前回のIGAS2007に比べて６割程度の出展数ということですが、東館だけにまとめたせいか、レイアウトを工夫したせいか、閑散としているという雰囲気ではなく、歩きやすくて見やすくなった印象でした。
とはいえ昔に比べると印刷機などの巨大機械がガンガン動いてるといった雰囲気はあまりなく*2、インクジェットやオンデマンドプリンタなどが増えているのは明らかでしょう。インクジェット機も以前のように大判サイズを売りにするより、高品質化、高スピード化、多品種化を売りにしているところが目立っていました。
ちなみに特殊印刷などのサンプルは普段はそうそう手に入らないと思いますので、マニアな人は行ってみるとよいのではないでしょうか。*3
Adobe Digital Publishing Suite正式販売開始
Adobe Digital Publishing Suiteが日本で正式販売開始だそうです。正直「まだだったの？」という印象ではありますが。これまで先行して制作、販売していたところはベータテスターということなのでしょうか…。
今後は「ADPSリセラーパートナー」という販売代理店経由での契約になるようです。Adobeのチャネルリセラーパートナーリストを見ると、日本は今のところ大塚商会、キヤノンマーケティングジャパン、Too、モリサワの４社のようです。最初は少し業者を絞って様子見という感じなのでしょうか。それなりに需要があれば扱いたいと思う代理店も増えるのかもしれません。
全印工連のプログラムでの契約はどこかがまとめて取り仕切るのでしょうか。
…って、モリサワってMCBookとかMCMagazineとかの競合製品になるんじゃないのかな？
自炊業者に質問状を出した作家の作品はどれくらい電子書籍で入手できるのか？
- 出版社7社、作家・漫画家122人が「自炊業者」に質問状（eBook User）
- 出版社からスキャン代行業者への質問状を全文公開、潮目は変わるか（eBook User）
自炊業者に質問状を送付したということ自体は特に感想もないのですが、差出人として名を連ねている作家たちが自炊業者*1に反対しているとして、その作家たちの作品が正式な電子書籍でどれくらい販売されているのか、気になったので調べてみました。
複数ストアの電子書籍の検索ができるらしいダ・ヴィンチ電子ナビで作家名で検索して、電子書籍のみのヒット数を調べました*2。同一作品でも別ストアで販売されているものは別の件数としてカウントしているようですので、件数が多い＝作品数が多いというわけではないようです。またこの検索がどれだけのストアを網羅しているのかは不明です。
追記：ダ・ヴィンチ電子ナビはたまたま9月6日にリニューアルオープンだったようです。またInternet Watchによると、電子書籍の検索対象サイトは「App Store」「eBookJapan」「電子貸本Renta!」「電子文庫パブリ」「BookLive!」の5サイトだそうです。
こうしてみると、作家によってかなりばらつきがありますね。もっとも漫画の場合は巻数が多い＆ストアが複数あるせいでしょうが。小説家の中には漫画版の原作として検索結果に表れるけど、元の小説は電子書籍化されていないものもあるようです。
ここに名前のある作家の方たちは自炊業者には反対という事なのでしょうが、電子書籍自体に対してはどういう考え方なのか知りたいところです。*3
あ
か
は
ま
ら
- 六花チヨ（34）
全印工連 Adobe CS5.5特別ライセンスプログラム
全日本印刷工業組合連合会（全印工連）が会員企業に対してAdobe Creative Suiteを安価に提供するというもので、簡単にいえば全印工連が元締めになって共同購入によって大量発注する事でAdobeに値下げさせてるということです。
ちなみにこのプログラムは昨年も行われ、6000本目標で進めていたけど結局3200本程度だったようです。*1 6000本以下ならAdobeが断る事もできたようですが、それでも（「Adobeは全印工連の取り組みに理解を示し」という言い方をしつつ）受け入れたのは、かなりの割引とはいえ3200本分の売り上げが魅力だったという事でしょうか。*2
もともとは２年契約で２年おきの募集だったようですが、昨年に続き今年も行われるというのはAdobeのバージョンアップポリシーの変更のせいでしょうか。
InDesignとCSSの行組版の違い
InDesignを使っているDTP関係者がCSSで組版をやろうとすると、細かな違いに戸惑うことがあります。今回は行送りの扱いの違いをまとめてみました。
※ここでは問題をシンプルにするために、日本語の文字組で、すべて同サイズの文字を組む場合を前提にしています。
用語説明
まずは組版の基礎知識として、行間、行送り、文字サイズの用語から。「日本語組版の要件」*1によると
- 行送り（line feed）
- 隣接する行同士の基準点から基準点までの距離．（JIS Z 8125）
- 行間（line gap）
- 隣接する行の文字の外枠間の距離．
- 文字サイズ（character size）
- 文字の大きさ．通常，文字の行送り方向の外枠の長さ．
とあります。「[図36]: 基本版面を行送りで指定する方法」の図を見れば一目で分かるかと思います。
[図36]: 基本版面を行送りで指定する方法より
行送り方向の版面サイズ
版面のサイズを計算する際に、行送り方向のサイズ（ヨコ組の場合は高さ、タテ組の場合は幅）は通常、
文字サイズ×行数＋行間×（行数-1）
で計算されます*2。行間はその名の通り、行と行の間ですので、最終行の後（もしくは最初行の前）には付きませんので、「（行数-1）」となります。
CSSの場合は？
CSSで行送りを指定するにはline-heightを使用します。しかし、line-heightは組版での行送りとは少し動作が異なります。line-heightの名のとおり行の高さを指定するもので、line-heightからfont-sizeを引いた値をリーディングレディング（leading）と呼び*3、この半分の値（half-leading）が文字の前後（ヨコ書きなら上下、タテ書きなら左右）に追加されます。
下図をごらんいただくとわかりやすいでしょうか。
ここで問題になるのは、最初行の前および最終行の後にもそれぞれhalf-leadingがついていることです。つまりCSSで行送り方向のサイズ（ヨコ組みの場合はheight、タテ組みの場合はwidth）は、
(line-height)×行数＝文字サイズ×行数＋行間×行数
になってしまい、これまでの組版と比較して行間１つ分大きくなっています。
これまでの感覚で版面設計をして、（ヨコ組みで）heightを「文字サイズ×行数＋行間×（行数-1）」で指定してしまうと、実際に必要な高さに足りず、１行少なくなってしまいます*4。
参考資料
この記事は、2011年5月30日に開催された「次世代電子出版とWeb 表現技術フォーラム2011」でのアドビのNat McCully氏による資料を参考にしています。当日は参加できず内容に関しての詳細は不明ですが、参加したかった…。
縦書きテキストを美しくジャスティファイするために（Webkit調査編）
先の概論編の最後で、「テキストの領域（段落等）の行長を『文字サイズ×１行の文字数（字詰め数）』にします」と書きました。
では実際にやってみましょう。下記のようなテキストを作ってみます。
《html部分（p要素以外は各自で補足してください）》
<p id="test">あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもや ゆ よらりるれろわゐ ゑをん</p>
《css部分》
p#test { writing-mode: vertical-rl; -webkit-writing-mode: vertical-rl; -epub-writing-mode: vertical-rl; padding: 0; background-color: #ffa; /* 範囲がわかるように背景色を指定 */ font-size: 1em; height: 10em; text-align: justify; }
これを縦書き対応webkit環境で表示させてみます。ここではLion 10.7のSafari5.1(7534.48.3)を使用しました（デフォルト設定で表示）。
「height: 10em」と指定したのに１行に9文字しかありません。最終行とそのひとつ前の行の字送りがずれているのがわかるでしょうか（空白文字のせいでわかりにくいかも）。text-align指定をコメントアウトして行頭揃えにしたものがこちら。
行末にかなりスペースがあるのがわかります。というわけで、現状webkit環境では、「テキストの領域（段落等）の行長を『文字サイズ×１行の文字数（字詰め数）』にし」ても意図通りには表示されません。
heightをどれくらい広げれば意図通りになるのか？
「height: 10em」で9文字しか入らないのなら、10.1emとかちょっと増やせばいいんじゃないの？ なんて勘のいい方は気づくと思います。ではどれくらい増やせば10文字になるのか、つい勢いで徹底的に調べてみました。デフォルト状態のSafariで2文字の場合からheightの数字を少しずつ増やしていって、正しく表示された時点の設定を調べていきました。ついでにemだけでなく、デフォルト設定で1emと同じサイズの12ptの場合、16pxの場合もそれぞれの単位の指定で調べてみました。
それをまとめた表がこれです。
height指定一覧
| 文字数 | height(em) | height(pt) | height(px) |
|---|---|---|---|
| 2文字 | 2.061875em | 24.7426pt | 32.99px |
| 3文字 | 3.061875em | 36.7426pt | 48.99px |
| 4文字 | 4.061875em | 48.7425pt | 64.99px |
| 5文字 | 5.061875em | 60.7425pt | 80.99px |
| 6文字 | 6.061875em | 72.7425pt | 96.99px |
| 7文字 | 7.061875em | 84.7425pt | 112.99px |
| 8文字 | 8.061875em | 96.7425pt | 128.99px |
| 9文字 | 9.124375em | 109.4925pt | 145.99px |
| 10文字 | 10.124375em | 121.4925pt | 161.99px |
| 15文字 | 15.124375em | 181.4925pt | 241.99px |
| 16文字 | 16.124375em | 193.4925pt | 257.99px |
| 17文字 | 17.124375em | 205.4925pt | 273.99px |
| 18文字 | 18.186875em | 218.2425pt | 290.99px |
| 19文字 | 19.186875em | 230.2425pt | 306.99px |
| 20文字 | 20.186875em | 242.2425pt | 322.99px |
| 26文字 | 26.186875em | 314.2425pt | 418.99px |
| 27文字 | 27.249375em | 326.9925pt | 435.99px |
| 35文字 | 35.249375em | 422.9925pt | 563.99px |
| 36文字 | 36.311875em | 435.7425pt | 580.99px |
emはfont-size:1emの場合、ptはfont-size:12ptの場合、pxはfont-size:16pxの場合です。
見てるだけでうんざりするくらい細かい数字です*1（つい勢いで調べてしまったけど、ふと我に返って軽く後悔…）。よく見ると1行あたりの文字数が9文字、18文字、27文字、36文字と9の倍数の時に誤差が少し大きくなっていくようです。内部処理がどうなっているのかはわかりませんが、何らかの処理が影響しているのかもしれません。
これをまとめると下記のようになります。
height計算式
| 文字数 | font-size:1em | font-size:12pt | font-size:16px |
|---|---|---|---|
| 2〜8文字 | 1em*文字数+0.061875em | 12pt*文字数+0.7425pt*2 | 16px*文字数+0.99px |
| 9〜17文字 | 1em*文字数+0.124375em | 12pt*文字数+1.4925pt | 16px*文字数+1.99px |
| 18〜26文字 | 1em*文字数+0.186875em | 12pt*文字数+2.2425pt | 16px*文字数+2.99px |
| 27〜35文字 | 1em*文字数+0.249375em | 12pt*文字数+2.9925pt | 16px*文字数+3.99px |
| 36〜44文字？ | 1em*文字数+0.311875em | 12pt*文字数+3.7425pt | 16px*文字数+4.99px |
さらに問題が…
状況が変われば現象も変わるようで、height:10emで9文字しか表示されていない場合でも、ブラウザの表示を拡大（cmd+「+」）もしくは縮小（cmd+「-」）すると時々正しく10文字表示される時があります。逆に、height:10.124375emを指定しても、ある拡大率では9文字しか表示されない場合もあります。
じゃあもう少し大きな数字を入れればいいかというと、そうなるとジャスティファイ指定した場合に文字間が空いてしまうようになります。それに、ざっとテストしてみたところ、どの拡大率でも意図通りの文字数を表示させるのはけっこう難しそうで、いずれかの倍率では文字ずれが起きていました。
じゃあどうすればいいの？
webkitが改善されていくのが理想ですが、どうなるかはわかりません。*3 逆に言えば、現状の問題を解決するために小手先のバッドノウハウを駆使して、将来webkitが改善されたために逆に表示がおかしくなるという可能性も考えられます。
まあとりあえずは、見た目の文字組みが違和感がない程度にheight指定の数値に余裕を持たせておくのが現実的な解決法だと思います。
こればかりは制作者がどの部分にどれだけこだわって手をかけるかによって対応が異なると思います。納得できる範囲で表示ずれを許容しつつ、こだわる部分にはこだわって制作するのがよいかと思います。ただ、読者の表示環境によっては、そのこだわりが読者に伝わらない可能性もあるわけですが。
「だいたいそこまで文字組みにこだわるのならPDFにすればいいじゃん」*4とここまでの長文を全否定するかのような意見で締めておきます。
