February 2024 - Githubissues

date	time	location
February 12, 2024 JST	14:00-16:00	Online

Agenda

Vivliostyle.js（@MurakamiShinyu）
- 2.26.0 (2024-01-20)
- CSSのテキストスペーシングプロパティ変更の反映（#1251）
  - デフォルトで行頭を詰めなくした（段落冒頭、折り返しともに行頭は何もしない）
  - 理由はWebとの互換性等
  - 詰めたい場合は自分で指定する
- バグの修正
- 2.27.0 (2024-02-09)
- 1年前からの予告どおり、デフォルトスタイルシートをWeb標準に従ったものへ変更（ #1128）
  - 見出しのマージンの値変更
  - ブロッククォートとリストの前後のマージン等をゼロだったものを、標準どおり1emのマージンをつけるように変更
  - なお、ネストされたセクション要素内でh1要素のサイズを変更する動作は不採用にした
  - これはHTML5の確立前の段階の考え方で、現在は推奨されていないので不採用とした
- 目次要素を目次として処理する過程のバグを修正（ #1258）
- 今後の予定
- #1256などのバグがあるので、それを今後フィクスしていく予定
  - 1つのブロックの中に長いテキストがあると処理に時間がかかってしまう
Vivliostyle CLI（@spring-raining , @MurakamiShinyu）
- 8.7.0 (2024-01-22)
- 前月指摘分の修正
  - EPUBの出力時に圧縮するようにした
  - EPUのなかに含まれていた不要なファイルを削除するようにした
- 8.8.0 (2024-02-09)
- Vivliostyle.jsのアップデート（2.27.0）にともなうもの
- TOC in webpub should be converted to in EPUB output #469
- 文書内に <nav role="doc-toc"> などのマークアップで目次を入れることで、Vivliostyle Viewer の目次メニューや出力したPDFの「しおり」には目次ができるのに、EPUB出力ではそれがEPUBの目次にならない問題
- 現状の分析
  - なぜこうなるかというと、元のHTMLにあった<nav class="toc" role="doc-toc">とは別に、body要素の終わりにnav要素が追加されており、そこには目次項目としてtitleしか入っていないから
  - landmarksにおける目次のリンク先が文書内の目次ページであるべきなのに、hidden属性で非表示になっている部分EPUB用の nav 要素になっている
- 修正の提案
  - ⓵元の文書内にEPUB用の目次 <nav epub:type="…"> がある場合はそれをそのまま活かし、別のnav要素を追加しない。
  - epub:type属性の値は "toc", "landmarks", "page-list" に限らず何でも有効とする (See: https://www.w3.org/TR/epub-33/#sec-nav-def-types-other)
  - ⓶EPUB用ではない目次（<nav role="doc-toc"> など）が元の文書内にあれば、その内容を使ってEPUB用の目次
    を作る。
  - 目次要素の検出については Vivliostyle.jsの findTocElements() の処理（最近 Improve TOC handling vivliostyle.js#1259 と fix: All
    elements in EPUB navigation doc should be shown in TOC box vivliostyle.js#1271 で修正したもの）を参考にする。
  - EPUB用の目次の仕様ではリストの要素として <ol> しか認められていないが、Webpub用の目次では <ol>, <ul> とも有効なので、EPUB用の目次に変換するには <ul> を <ol> に変える
  - ⓷<nav epub:type="landmarks"> で目次へのリンクを出力する場合、そのリンク先は文書内に元からある目次の要素（hidden 属性なし）とする。
  - ⓸<nav epub:type="landmarks"> は <nav epub:type="toc"> のあとに出力する
  - Vivliostyle ViewerでTOC Boxで出現順に表示される。
  - landmarksよりも目次が最初にあるほうが便利。
  - ⓹各
    要素内に見出しがあったほうがよい。
  - 例： <h2>Table of Contents</h2>、<h2>Landmarks</h2>。
- ディスカッション
  - はるさめ：指摘のような動作になっている理由
  - EPUBの出力はWebpubへの変換を経由しているが、その際にpublication.jsonを参照するようにしている
  - なので提案に対応するにはWebpubに変換するタイミングで対応しなければならず、処理が多くなりそう
  - 提案⓵：nav要素を追加しないは問題ない
  - 提案⓶：<nav role="doc-toc">がある場合の対応は、どの程度優先度をあげるか悩む
    - もともとVivliostyle CLIの目次作成機能が貧弱だからという問題に対応するもの、なのでこれを解決すればよいかも
    - あるいは目次作成機能を別途切り出し、それをCLIで利用するという手もある
  - 提案⓸：landmarksをTOCの後にすべきのはその通り
  - 提案⓹：見出しをつけるのもその方がよいと思う
  - 提案⓷について質問：これはhidden属性をとってほしいということか？
  - 村上：提案⓷のlandmarksでの目次へのリンクの問題は、通常どおり組版する目次と、アプリのUIで使う目次が別々にある場合に、アプリのUIで使う目次（組版に出ないようにhidden属性がある）のほうにリンクされているという問題
  - landmarksに入れるのは組版結果に出る目次へのリンクであるべきなので、現在の実装は意味がないことになる
  - それを実現するには提案2の機能を実装する必要あるので、それができない場合はリンクを無効にする対応をとった方がよい
  - ul要素でなくol要素にするのはMarkdownで使いづらい問題あり
    - 目次を書く時にハイフンを使わずに、数字を使って書かないといけなくなり面倒
  - はるさめ：まとめると、提案のうち⓵と⓸、⓹は対応、提案⓷はランドマークをなくすのはリンクを無効にする消極的対応をとる
  - 提案⓶はCLIの目次作成を強化することで対応する方法と、Vivliostyle.jsで対応する方法あり
  - 村上：Vivliostyle.jsの目次機能において、EPUB互換である目次作成機能もサポートするということ？
  - はるさめ：直接EPUB対応の目次を作る必要はないが、Vivliostyle.jsの方で階層的な情報やハイパーリンクの情報が分かるようにしてくれるとうれしい（APIなどを想定）
  - 村上：そもそもブラウザの中での話しなので、それとは別にVivliostyle.jsの中でやるのは困難
  - そんなに複雑に解析する必要はなく、Vivliostyle.jsの目次よりも簡易に、<nav role="doc-toc">があればその内容をコピーしてEPUB用の目次を生成し、そのうちul要素だけはol要素に変えるようにすればよいのでは
  - 目次の自動生成機能とWebpub用の目次機能が両方できればよいのでは
  - はるさめ：了解。目次の自動生成という位置づけでCLIで実装して、結果としてEPUB生成の機能強化にもなるという感じで対応を検討する
  - 2つめは目次機能の強化にもなる（Vivliostyle Viewerよりも深い階層の見出しを目次項目にできる）。
  - 村上：見出しのうちどのレベルまで目次で反映するかパラメータが必要になる
  - わりと時間がかかりそう
Theme (@spring-raining)
- 細かいアップデートを報告
- 先日themeのmanifestファイルのcommitをした（fix: Add a main property for package.json）
- メインフィールドを追加することで動く環境が増える
  - UNPKG（アンパッケージ）
- 今までだとthemeの名前まで指定する必要あったが、メインフィールドを参照して指定なしに参照できる
- もう一つ、実装中なのはthemeで今までの書き方は冗長だった問題を解決したい
  - PostCSSというライブラリを利用
  - アップデート後に、themeのコントリビュータ向けにドキュメントを改訂する必要あり
  - PostCSSを使う場合、コンパイルが必要になる懸念あり
  - メリットはあるがビルドのステップが追加されるデメリットは理解できる
  - プラグインを使う処理として、オプショナルにする予定
- 村上：脇に逸れる質問だが、CSSのネスティングの機能やレイヤーなども拡張されている中で、Vivliostyle.jsでもネスティングへの対応が課題だが、それらはどのくらい必要か？
- はるさめ：Vivliostyleのパースの部分まで外部のライブラリを使うのはありではないか？
- 村上：できるかもしれないが、外部ライブラリを使う場合、Vivliostyleの実装と両立できるかどうか、慎重な検討が必要。
  - 場合によっては自前で実装した方が早い
  - 基本的にネスティング対応は頑張れば可能であることは分かっている
  - ただ、それなりに面倒。とはいえ、やらないとブラウザと違いが出る
  - CSSネスティングができるとCSSの書き方が変わる。今後手をつけたい
VFM, create-book, vivliostyle-sitegen（@akabekobeko）
- 前月からの報告と今後の予定
- なし
Vivliostyle Pub（@takanakahiko, @MurakamiShinyu）
- 前月からの報告と今後の予定
- なし
gihyo.jp Web連載について（@U-1F992）
- Vivliostyleでなにができるの？｜gihyo.jp
- データはまだ、次回報告したい
- 「いいね」はそれなりについている（現在169）、周りの記事に比べても多い方
yamahigeから質問
- SlackのIssueチャンネルとGitHubのIssueとの使い分けは？
- 村上：Issueは実際の開発と結びついているのはGitHubIssue
- Slackの方はもっとくだけた用途、何を書いてよいか分からない場合の相談等
- GitHubのIssueにまとめるに至らないものはSlack
- yamahige：Slackの#Issueに投稿したが、本当にここでよいか自信がない
- 村上：見落としていたので返事する
- yamahige：Vivliostyle以外のCSS組版ツールでのCSSのサポート状況を知るには？
- 村上：各サイトのドキュメントを参照するのが一番
  - pagefloatに関しては、W3Cの仕様にもとづいた実装はVivliostyleくらいだけ
  - 他のものは独自実装、アンテナハウスは充実している
  - princeも機能はあり、それなりにできている、
  - この3つがpagefloatを使えるが、それぞれ微妙に違うのでそれぞれのドキュメントを参照する必要あり、標準化がちゃんとされていない状態
  - Vivliostyleも修正したいところがあるけど放置しているのが実情、不具合もある、一応使えるので使ってみてください。他もオプションあり得る
- yamahige：論文観点なのでVivliostyle一択でしょみたいなことが言えればよいと思ったが？
- 村上：アンテナハウスなどは業務向けの高価な製品なので、学生向けは想定外で無理がある
  - オープンソース以外は負担が大きいのは皆同じではないか
  - その意味でオープンソースであるVivliostyleは向いていると言えるのでは
  - 最新のドラフトに一番近いのはVivliostyle、
  - また、その他のWeb仕様に近いのもVivliostyle
  - 他の製品は独自に実装しているものの積み重ねなのでW3Cの仕様と離れている
  - 頑張っているのはアンテナハウス。対応を改良しているがまだ古い処理が残っていて注意が必要
- CSS組版アプリの比較サイト
  - https://print-css.rocks/lessons
  - これでどの製品がどこに強いか分かる
次回日程
- 3月3日（日曜）14時から

Members

@MurakamiShinyu
@ogwata
@spring-raining
@yamasy1549
@UskeS
@lwohtsu
@macneko-ayu
@U-1F992
@akabekobeko (Scribe)

vivliostyle / community

February 2024 #121

Agenda

Members