Takai ayumu

現在の単体で完結するテーマだけではなく、ページ余白やノンブルの設定と文字組みを別テーマにする構成もできそうです。 例えばですが、 theme:[“A4book.css”, ”2column.css”] と指定するとA4書籍の2段組みになるようなテーマがあると便利なのでは。

変に複雑なしくみにするよりも、単にエントリ単位でも親と同じテーマを指定することにすれば良いのではと考えなおしました。 記述は冗長になりますが、こちらの方がわかりやすい気がします。 ``` theme: 'a.css', entry: [{ path: '1.md', theme: ['a.css','b.css'] }] ``` create-bookは完結したテーマを提供するのが第一義だと思います。 分割したテーマはその完結したテーマを作成する雛形や、カスタマイズするために利用する方向で考えています。

テーマ指定の方法でもう一案思い付きました。 ざっくりとですが、CSSで@pageの指定があるものをテーマ、@pageが無く断片的なスタイルを含むものをプラグインと分類します。 * 適用されるテーマは排他でひとつに限られる * プラグインは複数指定可 * 同じレベルでテーマが指定されなければ祖先のテーマを適用する * テーマが指定されるとプラグインの結合がリセットされる ルールは複雑になりますが、将来的にリプレイス機能だけを含んだテーマ(プラグイン)を作る可能性もあったので、ここでテーマとプラグインに分けてしまうのもありかなと思っています。 ``` { theme: "a.css", plugin: "p.css", entry: [ "1.md", // a.css + p.css { path: "2.md", theme: "b.css", //...

テーマの@pageを上書きするプラグインを制限するのは無意味なので分類は便宜的なものですが、分類自体なくしたほうが良いですかね。 同じファイルでも、themeとpluginどちらの項目に記述するかで継承関係が違うという説明のほうが良いでしょうか。 cssを含む機能追加がありうるので、テーマとプラグインをどこで区切るか難しいです。

頂いた案を元に既存のテーマやvivliostyle.config.jsがそのまま活かせる形で機能追加できないかもう少し考えてみます。

そうですね。 いろいろなケースやパターンを考えてしまい先に進めていませんでしたが、自分もシンプルにthemeに配列を指定する形でまずは実装してみるのが良いと思うようになりました。 書式が拡張されても内部の実装で各エントリ毎にテーマの配列を持つ形は変わらないと思いますので、まずはシンプルな形で使ってもらって使われ方を確認する方向で進めたいです。エントリ毎に同じテーマを記述するのが面倒という声があればあらためて継承ルールなどを検討します。 また、パッケージに複数のCSSファイルを格納する件ですが、将来的に"SCSSの変数をvivliostyle.config.jsで指定"できるようにしたいという考えもあり、実現するとSCSSトランスパイル時に条件分岐できるため必須ではなくなる可能性があります。 ただし、この形式ではSCSSの記述がプログラミング同様に大変になるため、パッケージ内にCSSファイルを複数用意して選択する形式と両方可能だと良いと思います。 以下は個人的に検討中のvarsフィールドでSCSSの変数を上書きすることでページごとのスタイルを指定する案です。 テーマをオブジェクトリテラルで指定するなら、その中で変数を指定するほうが良いかもしれません。この変数に関してもいろいろスクリプトと絡めてやりたいことがあり検討中です。 ``` { theme: “./theme_package”, vars: { // SCSSの変数を上書きする rows: 36, // 36行/1ページ cols: 40 // 40文字/1行 }, entry: [ { path: “cover.md”, //...

英語に疎いのでイメージ違いかもしれませんが、themeのコピー用コマンドの候補としてholdやkeepはいかがでしょうか。 ejectはどうにもCD-ROMドライブがう゛ぃーっと開くイメージが強くて。

個人の感覚ですが、node_modulesからejectするというよりvivliostyle-cliの管理下からejectするように捉えられそうだと感じたので候補を挙げさせていただきました。 反対意見というわけではありませんので、前例があるなら問題ないと思います。

cosmiconfigは*.jsファイルの読み込みをimport-freshというパッケージに依存しており、import-freshは単にキャッシュをクリアしてからファイルをrequireしているだけなのでサーバ上でJSONファイルの読み込みにも使用するなら危険なようです。 module.exports = のあとに記述するオブジェクトは、JSONの拡張形式（たとえば JSON5）としてパースする という方法は対応が簡単ですし、これまでのプロジェクトや公式ドキュメントの変更が最小限で済むと思います。 試しにPubのフロントエンド側とCLIのconfig.tsでjson5パッケージを使った以下のような実装を行なってみたところ、おおよそ上手く処理できています。 ```javascript const config = json5.parse( configString.replace(/(module\s*\.\s*exports\s*=)|(;$)/mg, '') ) as VivliostyleConfigSchema; ``` しかし、CLIのテストケースに含まれていたtests/fixtures/builder/vfm.config.js のような記述は当然処理できませんでした。 ```javascript const baseConfig = require('./workspace.config'); module.exports = { ...baseConfig, entry:...

{内容|ないよう}と{内容:ないよう}の両方をルビに使えるようにするとかどうでしょう。 これならruby.tsの正規表現を修正するだけのような気がします。 自分も以前、テーブル内に|を含めようとして結局実体参照に行きついたのですが、 "\\|"などでエスケープしてくれるのが一番ユーザとしてはありがたいです。