CSS組版に流れ着くまでのあらすじ

この記事は、技術系同人誌 Advent Calendar 2017の第2日目の記事として書かれました。

まえがき

拙作「見えざる埋蔵金」の公開以降、某社に拾われたりバイト掛け持ちとか色々が重なってしんどくてバックレたり全くの別業種に就職したりそこを4ヶ月で辞めたりして今は職業訓練とハロワ通いをする身でして、お出しできるようなCSS組版の成果物はなんも無いのですが、その間いくつかCSS組版で本を書く個人プロジェクトを頓挫させたりしていくらか知見が溜まってきたのでアドベントカレンダーに便乗して時系列順でまとめていこうと思います。思い出話とかものすごニッチな適用例とかが主成分でポがエムってしまっているのでqiitaではなく個人ブログでやっていきます。

これ技術系同人誌ではなく同人誌系技術の話になってしまうけどこのカレンダーで良かったのか。怒られたらそのとき取り下げるか。

出会いはアットウィキ

私がHTML/CSSを使って印刷データを作る、という流れに興味を持ったのは大学・大学院時代にレポート作業で少しでも手を抜くことを考えていたことに起因してます。当時の要件としては、

  • 作業環境がブラウザベースorすぐ作れる(デスクトップ機メインだったので環境を持ち運べなかった)
  • pdfが吐ける
  • レイアウトがいじれる(スカスカのレイアウトを組んで少しでもレポート枚数を稼ぐため)

といったあたりが高優先度でした。

当時は最終的にCloud LaTeXを選んだのだけど、ツールを探す中で光るものを感じたのが、アットウィキのpdf化機能でした。

LaTeXと違って補完機能が充実してなくてもwiki記法でザクっと本文を書ける。まあ読めなくはないレベルのpdfを出してくれる。画像アップロードも組み込みの表もある。ネット環境さえあればどこでも編集可能。ネット環境があるからコンビニのコピー機にデータ送って印刷可能。

レイアウトをいじれない点がマイナスで上記の通り最終的に選ぶことはなかったのですが、軽量マークアップ言語から印刷用pdfを作るというコンセプトの存在はここで知ることとなったのです。

アットウィキのpdf化機能、今はなくなっちゃったみたい。残念！

TRPG病

私にとって「文書の印刷データを可能な限り手抜きで作りたい！」という欲求がレポート作成から来たものであるならば、「ややこしくって細かくてリッチなレイアウトを生成したい！」という欲求はTRPGから来たものでした。TRPGerのうち一定数は「自分の書いたリプレイやらデータ集やらシナリオやらの文書を公開・頒布したい」という病気に罹患しており治療方法は存在しません。そしてTRPG文書は諸般の事情によりややこしくって細かくてリッチなレイアウトを要求するものなのです。

ややこしい

Pathfinder Reference DocumentとかグランクレストRPGコアルールとかを見ていただければ明白なのですが、TRPG文書は独自のデータブロック(カタログ組版で言うところのスペック表とかに近い)を多用します。比較的オーソドックスな小説風のレイアウトが通じるはずのリプレイ文書もト書きが必須でこれが意外とままならない。

細かい

商業のTRPG書籍に特徴的なのですが、コンテンツの製作に人件費がめっちゃかかるジャンルであるためかページを切り詰め切り詰め単価を下げることに血道をあげている場合がよくあります。極端な例だと索引を取っ払ってしまったり、縦書きの本の本文がゴリゴリのツメ組みだったり。趣味でやるならそこまでシビアに切り詰める必要はないのですがデータブロックなど公式のフォーマットを踏襲した方が良い部分もあるため細かく詰めたレイアウトがしたくなります。

リッチ

TRPGはゲームなのでビジュアルも大事です。ごりっごりに背景画像を利用してフォントも凝ったのを色々ぶち込んでいきたい所です。電子媒体で頒布するならルール用語などのキーワードには自動でリンクを張って欲しいし、データ部分にはバーチャルテーブルトップなどの外部ツールと何らかの連携機能が用意できたりすると未来な感じでいいですね。欲望が際限なく広がります。

そして敗北

上記のような無茶な欲求に対して私はさまざまなアプローチを試み、そして敗北を重ねました。一応LaTeXでPathfinderRPGのモンスターデータを成型してセッションに持っていったりはしたけどもちょっとしんどかった。

モンスターデータ.texについては別のアドベントカレンダーで詳しい話をします。

何がつらいってLaTeXはなんでもできる代わりに表現がえらく冗長なのですよ。細かいデータブロックを成型したり背景画像を設定したりハシラ・ランニングヘッダを凝った見た目にしたりがいちいちややこしい。プラグインの仕組みが上手く整理されてるわけでもないしそれらを網羅的に調べる方法も乏しい。ちょうどリアルタイムプレビュー付きのTeXエディタが流行り始めてたんだけどそれでもCSS書くのに比べたら開発ツール群が弱い。出てくる単語がお前はJavaのプロジェクト内のクラスかってくらい長い。打ちづらい。補完しても合ってるのか一目でわからない。

こうして私は「ややこしくって細かくてリッチなレイアウトを生成したいけどLaTeX書くのはクソめんどくさいから絶対ヤダ！」というワガママ極まりない欲求を持つことになったのです。

Scriptogr.amよ永遠なれ

ここでちょっとレイヤーを文書作成の方に戻して軽量マークアップ言語の話をします。時系列順で言うと私がMarkdownに出会ったのはLaTeXに辟易したよりも後だからです。

私とMarkdownの最初の出会いは多分twitterにおいてだったと思います。「なんか最近この単語よく見るな」という程度ですが。当初は卒論のメモ書き用に「平文textに適用できる文書の成型ルール」として使っていたのですが、便利なツールとして認識したのはScriptogr.amを使いだしたのがきっかけです。

Scriptogr.amはDropbox内に上げた.mdファイルをいい感じに変換してブログとして表示してくれるサービスで、ちょうど静的サイトジェネレータでブログをやる時のめんどくさい所を全部やってくれるというのに似た働きをします。現に私のScriptogr.amのサービス終了後の引っ越し先はHexo + Github Pagesでした。WP立てるのに比べればずいぶんマシとは言えこれも結構めんどくさかった。

結局長くは持たなかったのですがScriptogr.amは私の性に合ったサービスでした。なんかしらMarkdownで書いてDropboxの中に放り込むだけでブログができる。スタブはDropboxの別なとこに置いとけばいいし、誤字修正なんかもDropbox内の.mdファイルを触れればどこからでもできるのでお手軽です。

「Markdownはhtmlに変換するのが簡単」、「どうしても必要になったらhtmlタグを使えばいい」というのもMarkdownを理解する助けになりました。私は中坊のころからhtmlに触れていたので文書構造をそっちに対応させて考えられるのは大変都合がよかったのです。

ちなみに

Markdown→LaTeXをやらなかったのは当時LaTeX環境をCloud LaTeXに完全に頼っておりPandoc等と連携さすのがめんどくさかったからです。あと学術用途でどうせ数式にはTeX書式を使うことを考えるとMarkdownで書くことに大してうま味がなかった。

なんとなくゴールができた

時系列は前後するものの、ここまでで私は「Markdownはhtmlに変換するのが簡単」、「軽量マークアップ言語からのpdf生成は便利だ」、「リッチなレイアウトをLaTeXを使わずに実現したい」というパーツを得ました。そして折しもこれらをつなぐアイデアがちょうどWebで見かけられるようになってきていました。このエントリの本題、CSS組版です。

つまり「Markdownで原稿を作成し何らかのイージーな手段でhtmlに変換、その見た目はcssで作ってやり、出来上がったHTML/CSS文書を何らかの方法でpdfにして吐き出す」というワークフローが自家で実現可能になりつつあり、それはおそらく自分にとって便利なツールになるであろうと予想ができるものだったのです。

求めよ、さらば与えられん

目的がはっきりしたので私は今手元に足りないパーツを探すことにしました。

まずMarkdownパーサですが当時はオプションの豊富さから言ってPandoc一択でした。他のMarkdownパーサには「ヘッダで区切ってコンテナdivなりsectionなりで囲う」といった機能がなかったからです。

今ならmarkdown-it-header-sectionsとかPandocに追随するような形で揃ってきてるよ

次にpdf化についてですが、このコンセプトにたどり着いた当初私は「CSS組版」という言葉は知らなかったため「htmlのpdf化」といったキーワードで情報収集をし、wkhtmltopdfやAdaptive Layoutといったツールを見つけ手応えを感じました。そして最終的にVivliostyleのアルファ版に辿り着いたのです。

ついでにビルドツールとして大流行してたのでgulpも触り始めました。

でけた

  • Adobe Brackets: エディタ。いい加減JmEditorを卒業した方がいい気がしたので。
  • Markdown: 軽量マークアップ言語。本文作成。
  • Pandoc: 汎用ドキュメント変換ツール。Markdown -> html。
  • gulp: ビルドツール。とりあえず.mdをwatchしてPandoc走らすとこまで。
  • Chrome DevTools: F12。主にvivilostyleの当たってない状態で使う。
  • vivliostyle.js: CSS組版ツール。当時はChrome Extension版を利用。
  • Chrome: pdf出力。背景画像も対応していてフォントも埋め込んでくれるのでえらい。

これらのツールを組み合わせることで私はMarkdownからhtmlを経由してpdfを吐かせるワークフローを構築し「見えざる埋蔵金」を公開することができたのです。

長くなったので「見えざる埋蔵金」の時にできたこの環境については別にエントリ立てて書いていきます。