アカベコマイリ

HEAR NOTHING SEE NOTHING SAY NOTHING

CSS 組版 Vivliostyle 開発者とユーザーの集い 2019 夏

September 02, 2019イベントVivliostyle

2019/8/31 に開催された「CSS 組版 Vivliostyle 開発者とユーザーの集い 2019夏」へ参加したので感想などを。

《第 1 部》Vivliostyle開発者ミーティング

この部は元々、Vivliostyle 開発者である村上さん、緑豆はるさめさんと開発に強く興味のあるユーザー数人で実施される想定だった。しかし実際には多くのユーザーが参加することになったので

  • 前列中央へ開発陣 + α のコアな円卓席
  • その他のユーザー席

と設営した。最終的にコア席は村上さんとはるさめさん、私の計 3 名が着席。会場へコア席の参加を促したものの「開発に強く興味のある」という条件が尻込みさせたのだろうか、メイン開発者ではないユーザーは私だけとなった。

Vivliostyle のこれまで

Vivliostyle と村上さんの略歴から始まり、開発環境を ES5 + Closure Compiler 型注釈 から TypeScript 移行した際の苦労話が語られた。

ES5 からモダーンな環境へ移行するにあたり ES2018 などを検討していたが、現状の型注釈を活かすなら TypeScript の方がいいでしょ？そして自動変換ツールもあります！という感じの Johannes Wilm 氏による提案から試行錯誤がはじまる。着手時の 2018/8 に自動で 97% も変換されたよ！やったぜ！となり楽勝ムードだったが、実際には大量の警告やエラーと戦うことになり、完了まで 1 年かかったとのこと。

Vivliostyle の TypeScript 化は独立したブランチでおこないつつ、並行して新機能の実装も進んだ。TypeScript 化が完了した後、これら実装も改めて言語移行して現在に至る。

プロジェクトの開発環境を大きく変更する際に、今ある要望対応やバグ修正と並行するかは悩ましい問題である。結果として Vivliostyle は並行を選んで TypeScript 移行に 1 年かかったのだから、エンド ユーザー視点としては正解だったと思う。以下の記事は開発者の視点だが、ユーザーを意識した開発体制の考察として Vivliostyle の事例に通じる部分がある。

Vivliostyle のこれからの開発課題

先月、村上さんに Vivliostyle の GitHub issues を整理する方法として Project boards を提案した。これはいわゆるカンバンを実現するもので、さっそく取り入れられたようだ。フットワーク軽いですね。さすが。本項では Projects の課題分類を列挙し、ユーザーからみた優先度を計るため会場に挙手を求めた。

私は PDF printing、Input formats、Paged media など出版物を作るのに重要そうなものを支持。Input formats についてはエレキ ギターを趣味にしていることもあり、楽譜を表現できるとありがたい。例えば TAB 譜サイトの ULTIMATE GUITAR TABS は ASCII Art、Songsterr Tabs with Rhythm は画像で譜面を表現しているのだが、これらがセマンティックな記法で表現されれば、Web Audio API と組み合わせてソフトウェア的に面白いこと (練習用にテンポ変更しながら演奏とか) もできそうだ。

終了時間が差し迫ってきた。第 1 部の締めとして村上さんが Terminal や vscode を表示しつつ、実際どのように Vivliostyle 開発をおこなっているかデモ。

個人的にはせっかくコア席を設けたので、そのメンバー間で議論する時間もほしかった。特等席で話を聞ける良さはあったものの私は置物状態だったので。今回のコア席ぐらいの小規模な開発定例的なものを今後、検討するとのことなので、この点についてはそちらへ期待する。

《第 2 部》Vivliostyle・CSS組版ユーザーミーティング

Vivliostyle ユーザー会の合同誌の制作

締切のある冊子を作る際の心がけと事前対策について。凝った組版やレイアウト崩れなどのトラブル対応に試行錯誤する時間を捻出するため、効率的な制作環境を整える。remarkjs/remark による Markdown 処理と独自拡張、ページをまたぐレイアウト崩れの緊急回避として強制的な改ページなど。

remark が JavaScript と Node.js 学習テーマとしてもよい、というのは確かに。身近な Markdown 文書を処理して好みの HTML 出力を得るのは楽しく、特にこのイベントへ参加するような出版に興味あるユーザー層へはピッタリだろう。

Vivliostyle と関連ツールの便利な使い方

Vivliostyle Viewer と vivliostyle/vivliostyle-savepdf の紹介。

Vivliostyle Viewer は外部の HTML/CSS や EPUB など外部データをホストして Vivliostyle に表示できる。そのためサーバーなどに Vivliostyle をインストールせずとも試せて便利。http://localhost:8080 もホスト可能なのは面白い。

vivliostyle-savepdf は以前、violapub/viola-savepdf だったもの。viola 版は現在 DEPRECATED になっている。これは HTML/CSS を CLI で組版して PDF 化してくれるもので、技術書典6にVivliostyleユーザー会が出展します！ | Vivliostyle Foundation に紹介された同人誌の作成にも使われた (この時点では前身の viola-savepdf)。

remark と vivliostyle-savepdf を組み合わせれば Node.js のみで Markdown による HTML/CSS 組版 + PDF 出力環境が揃う。remark や HTML 変換についてはプログラミングの知識を要求されるが、これも前述の同人誌で用いられた spring-raining/tbf06-draft などをベースにカスタマイズする手もある。私もこれを参考として自分用に akabekobeko/env-create-book というリポジトリーを作った (作りかけ)。

問題があるとすれば Vivliostyle 本体にも言えることだが Chrome に依存する点。Chrome はバージョンを明確に固定するのが難しいため、リポジトリーを共有しても PDF 出力結果が環境によって異なる可能性がある。

これを防ぐ方法として Headless Chrome のようにユーザー環境の Chrome を操作するのではなく、基盤となる Chromium を採用する Electron も選べるとよさそう。Electron は npm 配布されているためバージョン明示が可能だから、結果としてその時点の Chromium を固定したことになる。

「マンガでわかるRuby」のCSS組版・制作秘話

本書はマンガを主体とするため画像中心となる。Vivliostyle 的にそのような本は珍しいので、事例としての紹介を要請されたとのこと。マンガの合間にキャラクターの顔と吹き出しによる対話形式の解説などが挟まれる。

マンガ主体ではあるが、文書は Markdown で書かれている。パーサーは vmg/redcarpet。どこかで聞いたことがあると思ったら、Redmine 本体の Markdown 処理もこれを採用しているのだった。redcarpet による解析結果と YAML のメタデータ (目次など) を自前の Ruby スクリプトで処理。言語は異なれど設計思想は前述の Vivliostyle 本に近い。

対話形式は一般的な Markdown (GFM 程度) で表現するのは難しいため独自タグを用意した。記法は以下のような感じ。

## 見出し

[begin dialog]

キャラクター名「セリフ」

[end dialog]

タグで範囲指定されたテキストを取得、内容の解析は正規表現で処理しているとのこと。対話形式は需要ありそうだし書式も直感的なので参考にさせていただく。

本書を作成するのに使用した Ruby スクリプトは Gist に公開されている。前述の Vivliostyle 本もだが、こうした制作環境を惜しみなく公開してくれることに感謝したい。

キンコーズ印刷の話。

制作した文書を Vivliostyle により PDF 出力してキンコーズで印刷しようとしたのだが、エラーになる。どうやらサポートされていない形式らしい。PDF は A5 サイズとしたのに少し大きい。キンコーズは A5 ピッタリを要求される。ちなみに日光企画とプリペラなら OK、キンコーズはダメだった。

この問題について村上さんにアドバイスを求めたら、PDF を Acrobat で確認すると A5 より縦横 6mm 大きくなっているとのこと。これは CSS の bleed: 3mm; が原因。印刷用に marks: crop cross; を消したが bleed は残っていた。なので

@page {
  size: A5;
  /* bleed: 3mm; */
  /* `marks: crop cross; */
  margin: 8mm;
}

のように両方とも消す必要あり。キンコーズ以外が OK なのは印刷所で対応してくれていたのではないか？と予想している。こうした印刷所の対応については CSS組版・パブリッシング交流会(東京都) の入稿ヨシ、ご安全に！ CSS組版による商業書籍制作の理想と現実でも指摘されていた。善処はするが、可能なら事前に InDesign や pdfToolbox などで検証・修正してもらえたら助かりますとのこと。

その他、Vivliostyle は Web ブラウザーの技術を利用しているため px の mm 変換で誤差 (例えば 1px 以下のサイズ指定) が出るので用心したほうがいい、など。

将来展望として Kindle 配信を検討している。しかし EPUB は厳格な XML なのでエラー解決が難しい。Vivliostyle で Kindle 用 EPUB 出力している人がいたら話を聞きたいとのこと。

Vivliostyleで縦組シナリオを組版する

縦組みシナリオ形式を CSS 組版する話。編集者・ライター (非デザイナー) の立場から CSS に取り組んだ。対象は以下の作品で使用されたもの。

元原稿は MS Word 形式。これを縦組みシナリオ形式にしたい。手始めにシナリオ形式の組版を分析、InDesign で再現してみる。役名とセリフをタブ区切りにして段落スタイルにより突き出しインデントする方法を試した。

これを CSS に移植しようとしたが、そもそもタブ文字の幅は環境依存なので上手くゆかない。改善するとしても対処療法が関の山。なので正攻法である CSS の機能を模索することにした。村上さんのアドバイスにより、こんな感じで CSS を定義。

p.line {
  margin-inline-start: 5em;
  margin-block-start: 0;
  margin-block-end: 0;
}

p.line > strong:first-child {
  display: inline-block;
  margin-inline-start: -5em;
  min-inline-size: 5em;
}

縦書き対応も踏まえ、位置の指定は top や left ではなく start と end のように論理的なものとした。これは L2R 言語 (英語など) 以外へ対応する際にも役立つ知見だ。

CSS組版やってみた！

Vivliostyle 本 vol.1 に寄稿された方。技術書典 5 で kosen14s 闇鍋同人本 TOGETHER を書いた際の CSS 組版に関する経験を踏まえた話。学校のレポートなども CSS 組版で書いているのだという。

技術同人誌を書くため当初 TeX を検討したが面倒だった。執筆環境は重く、エラーも分かりにくい。表のセル単位で外観を変えたいだけも難しく、労多くして功少なしといった感じ。そんな折、CSSではじめる同人誌制作 に出会い、これだ！と。

評価点としては開発のしやすさと学習コスト、フロンティア感 (先駆者感？)。やましーさんとしてはコードをバリバリ書くとか CSS 組版に詳しいわけでもない (懇親会でお話した感じ、謙遜だと思う) そうなので、Vivliostyle への貢献として CSS 組版事例を紹介できればと登壇されたそうだ。

私も以前、技術書典の執筆者がよく利用している Re:VIEW を試そうとしたのだが Tex 力 (ちから) がなさ過ぎて不安になり断念。要するに Tex の時代の "敗北者" じゃけェ...、というわけだ。大学などで Tex/LaTeX に親しんでいれば既知の応用として検討したかもしれないが、あいにく私には手強すぎた。

そういうわけで本スライドに強く同意する。

楽したい組版（仮）

Vivliostyle を組み込んだ自作組版フレームワークの話。使い方はMarkdown組版へまとめたとのこと。組版システムに求めるものとして

  • それなりの報告書を高速に作れる
  • タイトル ページ、フッター、章番号などを表現できる

がある。過去に Google Docs や Tex なども試したものの手間がかかり過ぎる。そして 2 年前くらいに Vivliostyle へたどり着き利用中。他には Ghostscript も使っているとのこと。

最近の困りごととして物忘れがひどく、多くのプログラミング言語を同時に使うとか新しいものを習得し難くなっている。そのためよく使うものを選別し、そうした「迷わない言語」で楽して報告書を作りたい。その結果 Markdown → HTML/JS → PDF となった。

Markdown パーサーは markedjs/marked を採用。私は remark しか使ったことないのだけど marked はどうなのだろう。GitHub だと marked のほうが圧倒的なスター数だが、機能や設計面も踏まえた remark との比較評価を知りたい。

PDF 出力は make コマンドを利用。この環境は aquaxis/biblio_doc として公開されている。しかし Markdown to HTML 的なものはたくさんあるし、PDF 化も vivliostyle-savepdf がある。それでも自作フレームワーク作るのはなぜか？楽しいから。

この気持ち、よく分かる。車輪の再発明と言われても、自分の手の内にある技術で望みのシステムを構築したくなるものだ。チーム開発なら多様な観点から評価して技術選定するが、個人または好事家の集まりなら趣味に走るのも許されるのではないか。

EPUBファイルからVivliostyleでPDFを作る

ずっと EPUB を手軽に PDF 化したかった。なぜなら出版社が校正で紙を出したがるから。しかし既存の EPUB ビューアーには印刷機能がないため難しかった。印刷機能を提供しない理由は海賊版の作成を防ぐため。簡単に印刷できると作成の手助けになる。

そのため macOS のアクセシビリティ関連機能でアプリケーションを自動化、EPUB ビューアーで開いた状態の書籍スクリーンショットをページ単位で撮影、それを結合して PDF 生成するようにした。しかしテキスト中心の書籍でも全ページ画像なので巨大な PDF ファイルになるうえ、ページめくりとスクリーンショット撮影に膨大な時間がかかる。

という問題の解決方法として Vivliostyle の EPUB 展開表示を試した。やりたいことは以下。

  • EPUB を CSS の標準的な表現にそって PDF 化
  • 流通前の商業電子書籍を校正することが目的なので Web 公開せずローカルで処理したい
  • 可能なら校正指示のためページ番号を入れたい
  • 可能なら macOS 標準のツール群で動作させたい

まず Python でローカル HTTP サーバーを起動。Node.js も試したがインストールでトラブって断念したとのこと。Python は macOS バンドルのものを使用したので結果オーライ。ただし macOS は将来、Python や Perl などのスクリプト言語バンドルをやめる話もある。そのため環境構築は Homebrew あたりで管理するほうが安全だと思う。

起動した HTTP サーバー上で Vivliostyle Viewer を実行、これを Web ブラウザーで表示させてローカル EPUB ファイルのパスを指定。これは前述の村上さん登壇で紹介された EPUB ホスティング機能を利用している。結果、無事に表示。サンプルは黒死館殺人事件。三陽社メディア開発室：ダウンロードで配布しているファイルだろうか？

ページ番号は Vivliostyle の設定で Override Document Style Sheets をチェックして CSS による上書きを許可。こうすることで元コンテンツを加工せずに外観を後付でいじれる。この機能で追加した CSS は URL パラメーターに埋め込まれるとのこと。

他に諸々、設定して実用になりそうだが何度も手動でおこなうのは厳しい感じなので Perl により自動化。これは JunTajima/epubVivliostylePreview.pl として公開している。ただし職場だと Terminal で CLI も辛そうだから更に Xojo でアプリ化した。

村上さんの Vivliostyle Viewer 紹介と本登壇を聞いて、環境構築の手間は Electron で解決できそうと感じた。Renderer プロセスで Vivliostyle Viewer を表示すれば Chrome (Chromium) でローカル HTTP サーバーを表示しているようなものだし、file:// がまずければ Main プロセスに HTTP サーバーを起動してホストする手もある。

Electron にすると前述のように Chrome バージョンを固定できない問題の対策にもなるので、後で村上さんに提案してみるか。

ディスカッション

  • ユーザーがVivliostyle・CSS組版のこれからに求めるものは？

と題して登壇者によるディスカッション。これは熱い！！...はずだったけれど私は本イベントの運営を手伝っており、16:00 より懇親会の買い出しがあったので参加できなかった。残念。

《第3部》交流懇親会

懇親会では主にやましーさん、ちげさんとお話した。二人とも高専生とのことなので、それやロボコン、インターンよもやま話などで盛り上がる。

Web フロントエンド技術でやましーさんは React、ちげさんは Vue 派。それを踏まえ、それぞれの設計思想について議論。React に比べて Vue がグラフィック デザイナーに受け入れやすいのはなぜだろう？という話では単一コンポーネント .vue が慣れ親しんだ HTML/CSS/JS に近く、依存も閉じている (ような印象を与える) からではないか、という意見があった。

React はエントリー ポイントが JavaScript で、その中に JSX を入れ込む形式だから、パッと見はよくないのかもしれない。JSX なしで書いた場合は尚更だろう。それでもディレクティブで分岐やループを書くより JavaScript でそうするほうが好みだから React に肩入れするのだけど、こういう印象面の話は重要だと思った。

まとめ

全体を通し、CSS 組版は広く普及して標準化された技術であることが支持されているのだと感じた。組版も外観なので、それを定義するなら慣れ親しんだ技術を採用したくなるのは自然な考えである。

これはアプリケーション開発者としても頷ける話しで、外観 = View を定義する技術はプラットフォーム毎にバラバラなのだが、これも CSS など汎用なものへ統一されてゆくことを願っている。

技術書典 7 で頒布予定の Vivliostyle 本 vol.2 へは、この辺をテーマにした話を寄稿するつもりなので、興味のあるかたは是非！

Copyright © 2009 - 2023 akabeko.me All Rights Reserved.