アカベコマイリ

HEAR NOTHING SEE NOTHING SAY NOTHING

CSS 組版 Vivliostyle ユーザーと開発者の集い 2021 秋

November 21, 2021イベントVivliostyle

去る 2021/11/14 (日) に開催された「CSS 組版 Vivliostyle ユーザーと開発者の集い 2021 秋」へ参加 (登壇) したので感想を書く。

第 1 部 ユーザから見た Vivliostyle

人工言語イジェール語の辞書を Vivliostyle で作る

人工言語の辞書を Vivliostyle で組版して生成する話。

冒頭に人工言語の例としてエスペラント語や創作の演出として生み出されたものが紹介されている。私の印象はどちらかといえば後者。そのため演出に必要な分だけあればよく、現実世界の生活に利用できるほどの網羅性は持たないものだと思っていた。この目的だと英語や日本語など現実の既存言語と可換な文字いじりだったりする。こういうの異世界情緒を盛り上げる演出として面白く好きだ。また未知の言語という暗号的な性質を利用して創作者からの隠しメッセージが仕込まれることもあり、それを解読するのも双方向性があって楽しい。

ざすろんさんの作っている「イジェール語」は現実から地続きの未来を想定した架空 SF で用いられる言語で、日本語と英語をベースにしているとのこと。人工言語用に OTM-JSON (OneToMany-JSON) というデータ形式があり、イジェール語の辞書はこれで定義される。

今回の登壇ではこのイジェール語の辞書を Vivliostyle で組版してみたことで苦労した点などが語られた。

Vivliostyle を選んだ理由。

辞書のデータ形式が規則性のある JSON なので、規則的に処理するため Vivliostyle (CSS 組版) を選んだとのこと。通常の Web ページとして組んだものを Chrome で直に印刷するとページに応じた処理などが実現しにくい。Vivliostyle ならば印刷想定のページ処理などが充実しているので目的を達成しやすいのだろう。

どうやって使い始めるのかわかりにくい。

Vivliostyle 公式 Web サイトの構成だと Vivliostyle の使い方しかわからない。その先にある組版としてのデータ (コンテンツ) をどう作るか？を知りたいとのこと。プログラマー視点だと HTML/CSS のリファレンスをあたることになるのだろう。実用的な目的 (組版) に応じた逆引き CSS プロパティー的なのは確かにほしい。プログラマーである私も組版に詳しいわけではないので Vivliostyle Themes の CSS を読んで、あれってこうやって実現するものなんだ！と知ったりする。

開発者ツールが役に立たないので、サンプルを見てもどう参考にしていいのかわかりにくい。

これは Vivliostyle の仕様も関係しているだろう。Vivliostyle は未実装の組版用 CSS をシミュレーションすることを想定して HTML タグの style 属性にインライン CSS を出力する。そのため元の CSS ファイルとインライン CSS 間の対応が非常にわかりにくい。前に開発者会議でもこの問題を提起して Source Maps を出力できないか？という相談をしたことがあるのだけど、それも設計的に難しいとのことだった。

しかし Vivliostyle を利用するなら必ず遭遇する問題なので、何らかの改善策がほしい。例えば Source Maps ほどではないが開発モードで起動された場合は style 属性と一緒に data-css-source みたいな属性も出力して、そこに CSS ファイル上の行番号を入れるとか。

「Vivliostyle ユーザーと開発者の集い」では毎回、その名のとおり「ユーザー側」の登壇者を招くことにしている。開発者側だけだとなかなかユーザーの感じる困難や課題を想像し難い。そのためこの方針を採っているのだが、今回も改善の参考になる登壇であったと思う。

人工言語といえば MAGMA のコバイア語 (Kobaïan) を OTM-JSON にできないかな？などと登壇を聞きながら考えてた。歌唱を目的とした言語であり作者の Christian Vander も意味的ではなく音声的なものだと言っているのだが、MAGMA ファンとしては大意ぐらいは把握して聴きたい。そういう層はそれなりにいるようで OTM-JSON のように形式化されたものではないが有志の手による辞書は散発的に作られている。

コバイア語の OTM-JSON とボーカロイドを組み合わせて Zeuhl Music を生成とか面白そう。

Vivliostyle Pub で Web フォントを使う

Vivliostyle Pub 上で Google Web Fonts を表示するデモ。

現状の Pub はアルファ版ということもあって機能的な制限事項が色々とあるが、CSS 上で @import する方法ならば Web フォントを利用可能。厳密には @import の参照先となる Google Web Fonts などの CSS に定義されたフォントの URL またはパスが Web ブラウザーからアクセス可能であれば OK。

読み込み処理の関係で時間はかかるものの、デモでは複数の Web フォントがプレビューに反映されることを確認できた。任意のフォントを指定可能になるとテンションあがる。Twitter でも指摘されていたが『とたんに「本物らしく」なる』のだ。

今後 Vivliostyle 本体の外部 JavaScript 実行制限が解決されれば Adobe Fonts や FONT PLUS なども選択肢に入るだろう。特に日本語のように膨大な文字数を持つ言語を扱う際、これらのような JavaScript を利用したサブセット化は重要なので期待している。

第 2 部 ライブラリとしての Vivliostyle

Vivliostyle.js の進化と今後の開発予定

本イベントの直前にリリースされた v2.12.0 の機能 を紹介。

標準設定でもいい感じに処理されるようで組版にあまり詳しくない私としてはありがたい。Twitter 上では組版の従事者から熱い反応がいくつかあって、そこからも重要な機能であることが読み取れる。

技術書典で頒布した Vivliostyle ユーザー会の本だと約物の処理用に「約猫」というフォントを利用していた。

その解説に

そこでこう考えてみてはどうでしょうか。約猫は「未来を少しだけ先取りしたフォント」であると。まだWebブラウザが追いついていないだけ。そしてやがて追いつき、追い抜き、このようなフォントを作る意味そのものがなくなるといいなぁと思っています。

とあるが、今回の機能は展望の実現へ近づいたといえるかもしれない。

Inside Vivliostyle.js への入り口

Vivliostyle.js の Code Reading と設計の話。

そういえば月次開催してる Vivliostyle 開発者会議の第一回で Code Reading を実施しようとした。この時のことを思い出しながら登壇を聞く。

TypeScript 化により可読性は大幅に向上したが、非同期処理のタスク スケジューラーが Promise 標準化前だったので独自実装とか設計として EPUB Adaptive Layout への理解を求められるなどでハードルは高そう。開発者会議で実施した Code Reading の個人的な印象だとコメントが皆無に近いのとクラス ベースなのでオブジェクト分割単位の役割が明示されないと読むのが厳しいという感じだった。

村上さんは Vivliostyle Foundation を立ち上げた際、自身は代表として組織運営を主に担当して実装は別のプログラマーで、と考えていたそうだ。しかしそれは難しく、結局は自身が苦労しながら設計を理解して現在唯一の Vivliostyle.js メンテナーになっている。

開発者会議の Code Reading はメンテナーを増やす目的で実施された。しかし本登壇の小嶋さんのように Vivliostyle と EPUB Adaptive Layout に通じていそうな方でも難しそうなのでなんとかしたいものだ。

とはいえ即効性のある方法は思いつかない。登壇でも指摘されてた Promise 化とか

コード ドキュメント (コメントや設計の概念図) 拡充などを地道におこなってゆくぐらいだろうか。

VFM 1.0 リリースと今後の展望

私の登壇。

VFM 1.0 をリリースしたので前半では初見の方に向けての説明をしてみた。なお本スライドは Vivliostyle Themes の Slide をベースに作成している。そのため代表的な機能として紹介した例は実際に Vivliostyle で組版されたもの。Math は最初の実装をやめて MathJax 移行したこともあって苦労した思い出がある。

後半は運営的な話が中心。前述の Vivliostyle.js もだがメンテナーをどうやって増やすか？は重要な課題である。ただしメンテナーのハードルが高いのは VFM を引き継いだ私としても理解しているつもり。なのでサポーターと表現した。プログラミング以外でも手伝うことは可能で、その中から実装に興味を持っていただけたらと期待している。

登壇の反応として Frontmatter は喜ばれているようだ。これは村上さんからの強い要望で拡充した機能。

当初は <title> や <body> 属性と簡単な処理モードぐらいを想定していた。しかし <head> に定義するものを一通り対応しようということになり、長い議論を重ねて現状に至る。自由書式の <style> などは remark による Sanitize だろうか、不等号がエスケープされて p > q が p &gt; q のようになる問題を解決できず見送った。とはいえ外部ファイルとしての CSS 参照は link、JavaScript なら script で定義可能なので実用十分といえるはず。

第 3 部 アプリケーションとしての Vivliostyle

Vivliostyle CLI v4におけるDockerモードと今後の課題（緑豆はるさめ）

Vivliostyle CLI の実行環境を Docker で運用可能とした話。

Docker こそ必要だが、これさえ用意すれば他の環境依存を避けられる。例えば Vivliostyle CLI 用には Node.js + npm が必要で印刷所へ入稿するための PDF/X-1a 生成に vibranthq/press-ready を利用したい場合、Windows だと面倒なセットアップを経なければならない。

プログラマーではないユーザーが Vivliostyle を利用しようとした際、こうしたセットアップで挫折するのでなかろうか。実際、これらを改善してほしいという意見は聞く。Vivliostyle Pub が公開されれば Web ブラウザーだけで済むのだが現状だとセットアップのハードルは高い。

では Docker はどうか？Docker もなかなか難しいのだが、依存をこれだけにできる。また冪等性という大きなメリットがあって印刷出版系のユーザーにとってはこちらのほうが訴求力を持つのかもしれない。冪等性とはある操作を繰り返しても同じ結果を得られるということ。

印刷出版の現場だと出版した書籍の「版」について再現性を求められる。版を重ねて二桁に達しても必要に応じて第三版も印刷可能としておく、という感じで。これを実現するために Adobe InDesign の古いバージョンとフォント リソースなどの維持を求められ、これが結構な負担だったりするのだ。

Vivliostyle は InDesign と棲み分けていて直接的な代替にはならない。しかし Vivliostyle で組版可能なものであれば InDesign に環境に比べて低用量かつ可搬性の高い Docker のデータ (Image/Container) として冪等性を実現できる。なお Vivliostyle 動作環境となる Docker イメージ以外のデータ、例えば画像やフォントなどは Git みたいな SCM で管理するか ZIP にでも固めて保存するとのこと。

Vivliostyle Theme 開発ガイドラインの公開

開発者会議でテーマ名どうしよう？という話があった。きっかけは以下の PR。

公式テーマに theme-bunko がある。しかし bunko という名前でありながら CSS に定義されたサイズは日本の文庫本になっていないので修正したというもの。これは紛らわしい名前にしたことが問題で、日本語の長文を意識したものなら他によい命名があったはず。

というのを起点にテーマの名前や開発についてガイドラインが必要という結論に至った。テーマについてはプログラマーでなくとも組版や CSS の知識があれば開発可能なので、より広範にサポーターを募れる可能性がある。そのためガイドラインは大切だ。

本登壇ではそのための取り組みを紹介している。なお本スライドは Vivliostyle Viewer 形式でも公開されていて、そちらから各資料のリンクを辿れるようになってる。素晴らしい。私も Vivliostyle でスライド作成をしているのだから、次からこの方法を導入したい。

ガイドラインやギャラリーなどは以下のページにまとまっている。

そういえばガイドラインの話でサンプル原稿を含めることを推奨していたが、Create Book でもこれを想定した機能を実装してみた。

推奨のとおりサンプル原稿を定義しておくと Create Book で Vivliostyle プロジェクトを生成した際、それが初期原稿となる。従来はテーマを選択しても Create Book 組み込みの「吾輩は猫である」冒頭文だったが、今後はテーマ毎のサンプルが反映されるためとっつきやすくなるはず。

Theme 取得ライブラリの開発

最近 Vivliostyle Pub のメンテナーにも参入してくれた高井さんの登壇。

Vivliostyle Themes の取得、確かに共通化できそう。Create Book だと api.npms.io を利用して https://api.npms.io/v2/search?q=keywords:vivliostyle-theme を検索している。こういう処理だけでなく登壇で挙げられてるようなローカルのテーマ管理や Validation なんかもライブラリー化して共通にできたら嬉しい。個別に作り込む必要がなくなるし、抽象化されることで自身のプロジェクト固有処理に注力しやすくなる。

というわけで大いに期待してます！

Vivliostyle Pub の現状と今後の開発スケジュール

Vivliostyle Pub メンテナーなかひこさんの登壇。

前述の Docker イメージは Pub でも共通利用するとのこと。press-ready なども考慮すると Vivliostyle 動作環境に絡むものを Docker に集約する方針は賛成。Pub のプレビュー動作について以下のような質問をなげてみた。

回答は現時点だと全体更新になっているとのこと。パフォーマンス面で部分更新する構想はあって、もう一人のメンテナーである高井さんも乗り気なので期待したい。

プレビュー更新については私以外にも色々と議論があった。リアルタイム更新またはプレビュー自体をオフにし、まとまった更新をした後にプレビューで確認というのはありだと思う。前述のような質問をしておいてなんだが、私も VS Code で Markdown を書く際はそのように運用してる。

第 4 部 Vivliostyle 開発会議

開発者会議の出張版。やましーさんの Miro 板書を読みつつ議論。

Vivliostyle というか VFM のドッグ フーディングについて静的サイト ジェネレーターを作るのはどうか？という提案をした。そして言い出しっぺの法則により私が担当することに。ただし SPA 対応とかは将来展望とし、とりあえず年明けぐらいに複数 Markdown を階層化された HTML にするものを作る予定。名前は仮に vivliostyle-ssg とする。

本ブログは GatsbyJS + Netlify で運用しているのだが、SPA までゆければ vivliostyle-ssg で置き換えてみたい。とりあえず私の Private Repository を作成したので設計中。

最後に

登壇者、参加者のみなさまお疲れさまでした！！

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