TAMADA Akihiro

良さそうですね！ 複数テーマを参照できるようにすることについては特に異論はないです。 ### 考慮点 - entry単位でthemeを上書きできる挙動に対する対応 - 配列で与えられた場合に親テーマを保持する？ ```js { theme: 'a.css', entry: [ { path: '1.md', theme: 'b.css', // => ['b.css'] }, { path: '2.md', theme: ['c.css'], // =>...

> CSSで@pageの指定があるものをテーマ、@pageが無く断片的なスタイルを含むものをプラグインと分類します うーん、その分類の必然性はよくわからないですね… CSSなどstylesheetとして読み込ませるものを `theme`、VFMへの独自機能追加などトランスパイラやVivliostyle Coreに関与する機能を `plugin` として分けるのであればまだ理解できます。

なるほど、themeはpluginの集合体で、pluginでthemeに対して機能を付与するイメージですね。 ESLintの設定方法はこれと近い概念です。 https://eslint.org/docs/user-guide/configuring/plugins ~`extends` < `plugins` < `rules` という順序で詳細度が上がり~ (すいません、認識が違っていました。`plugins` は `extends` を上書きするわけではありません) 、`rules` では `plugins` での設定内容を上書きできる、という仕組みになっています。 おそらく `theme` と `plugin` がどちらとも単一のCSSを指定できる点が混乱を招くため、`theme` では今後CSSを指定せず新しく `plugin` を列挙したパッケージ名を指定するようにするか、逆に `plugin` という概念をやめて `theme` を列挙した新しいパッケージを用意して、`extends` などの名前で指定可能にするかが良いかと思いました。

例えばこういうイメージはどうでしょうか？ #### themeA/package.json ```json { "vivliostyle": { "theme": { "name": "themeA", "category": "novel" }, "plugins": [ "puiginA" ] } } ``` #### pluginA/package.json ```json { "vivliostyle": { "plugin": { "name":...

As the version 4.0.0, the minimum Node.js version supported by Vivliostyle CLI became v12. We'll support native ESM in the next major update.

@sky-y Hi, thanks for the kind reporting! Unfortunately, I couldn't reproduce your issue in both cases 1 and 2. Could you tell us also your Node.js version (`node -v`)?

Viewer側で頻繁にoptionが更新されるのでなければ `--viewer` の必要性はあまり無さそうですが、`--spread` は良さそうです。

ご確認ありがとうございます。Webは原則的にRGBで色情報を取り扱うので、自動的にK100で出力するChromeがある意味特殊で、C93 M88 Y89 K80で出力する他のブラウザの動作が正しいといえると思います。もしこの問題に対処するのであれば、PDFの後処理としてVivliostyle CLI or press-readyがK100に変換する処理を入れる必要がありそうです。

元テーマのCSSを編集して再利用したいというニーズについて理解しました。どういった形で実現するか考えていましたが、以下のような `theme` サブコマンドを導入することを提案します。 ### `vivliostyle theme install` themeをインストールコマンドですが、内部的には `npm install @vivliostyle/theme-` と同様の動作になります。これまではthemeのインストールに `npm` や `yarn` を利用していましたが、`vivliostyle` コマンドに共通化することで `npm` や `yarn` の知識を要することなくインストールできる方が良いと考えました。また、専用のコマンドを通すことで、将来の[バージョン固定化](https://github.com/vivliostyle/vivliostyle-cli/pull/154#issuecomment-802603256)対応やDocker対応時のbreaking changeを無くせます。 ### `vivliostyle theme eject` node_modulesにあるテーマファイルをプロジェクト直下のどこか (保存先は要検討) にコピーし、以降はそのファイルを参照するようにします。ejectという名称は、Vivliosyle管理下にあるthemeを切り離し、独自の管理下に置くというイメージです。

@MurakamiShinyu 「themeをコピーして編集しやすくすること」と「オリジナルのthemeの変更内容を反映させること」「forkしたテーマを新しいテーマとして公開すること」は個別に話したいので、このissueでは1つ目の内容について決めたいと思います。2, 3つ目の内容は別issueとして登録してもらえますか？