Kenshi Muto
Kenshi Muto
ref https://twitter.com/vvakame/status/1340636091909595139 IDの中にEPUBまたはTeXにおける危険文字があったらWARNを出すようにした #1574 が、むしろ暗黙にエスケープしてくれたほうが嬉しい。 まじめに考えるとけっこう大工事になりそう…。 - 章ファイル名の場合はどうするか - 画像類はそのままIDを流用しているのでエスケープしすぎてはいけない - `@`による参照も注意
review-compileのオプションが歴史的にひきずっているものの、「デフォルト変えたので機能しない」「config.ymなどlに持っていった」というものがちらほらあるので整理を考えています。 今すぐ作業必要というほどではなく、6.0のときになりますが(obsolete出力はしていってもよいかも)。 - `--yaml`: config YAMLファイルの設定オプション、名前がわかりづらい。`--config` にする? - `--chapref`: config.ymlから上書きするケースはなさそう。locale.ymlでもある程度制御できる - `--chapterlink`: デフォルトをtrueにしたので無意味 - `--mathml`: 実際使われるケースはなさそうだし、config.ymlでの設定のほうがよい - `--htmlversion`: config.ymlから上書きするケースはなさそう - `--epubversion`: config.ymlから上書きするケースはなさそう (単体のreview-compileでやっても意味が薄い) - `--footnotetext`: config.ymlから上書きするケースはなさそう (単体のreview-compileでやっても意味が薄い)
参考文献DBとの連携
https://twitter.com/windowmoon/status/1321853175494668288 からのスレッド > BibtexかBibLatexに対応するか、ZoteroかMendeleyかEndnoteと連携できるようになってくれればいいのだが > Zotero・Mendeley・Endnote・ReadCubeから出力できる形式を読めるようにするか、現在の形式を出力するZotero・Mendeley・Endnote・ReadCubeプラグインを用意すればいいだろうと思います。あと、本文中での体裁を調整するCitation Style Languageに対応すればLaTeXからの移行が可能になると思います。 > Zoteroからは、CSL JSONやEndnote XMLで出力できるので、これらに対応すればいいのではないでしょうか。 プラグインについては本筋から外れそうなので誰かに任せるとして、JSON・XMLの書き出しをインポートするのはできるかもしれない。 ただ、各ビルダにおいて実際どういう結果になればベストなのか、どのくらいカスタマイズは要求されるのかが私はアカデミックに疎めなのでよくわからないところあり。 なお、bibtexを読み込むのは茨すぎるので避けたい。
https://github.com/vivliostyle/vfm markdownビルダのまま拡張フラグ分岐にしたほうがよいだろうか。
ref #1578 - LaTeXカーネルがたまにドラスティックな修正をするので、新しいLaTeXでは古いjsclasses(というかRe:VIEWにとってはjsbook)が動かない/挙動に問題が出ることがある。 - jsclassesはTeXLive 合わせで修正がされている。 ## 消すメリット - jsclassesを実行環境のTeXLiveから拾うようにしておけば、実行環境のTeXLiveのLaTeXカーネルとの相性は保証されているので問題がない。 - Re:VIEWのvendorで最新を追い掛ける必要がなくなる。 ## 懸念・デメリットなど - jsclassesは後方互換性にはかなり注意しているので、Re:VIEWが新しいものを内包し続ければ当面は問題ない。review-updateを使えばプロジェクトフォルダのバージョンを内包バージョンに更新可能。 - jsclassesの関知しない更新でreview-jsbookに問題が発生する、かもしれない。 - 消すことにした場合、review-updateでプロジェクトフォルダからjsbook.clsを消す処理を追加する必要がある。
今はbuilderのembedメソッドそのまま適用でブロック内容の末尾に改行が入るのですが、IDGXMLで取り扱う場合、改行が重要な意味を持つのでいろいろ後の処理で困ったことになります。 - IDGXML固有で末尾改行を入れないようにする。→「ほかと挙動が違う」というのがややこしい？ - 末尾改行有無をフラグ化する。→idgxmlbuilderセクションとかで調整はできる。フラグが増えるのがちょっと嫌め？
sample-bookやsyntax-bookをコピーするとか(これらの中身はもうちょっと向上したいとして)。 とはいえ、てくぶスタイルなんかだと展開リポジトリができてる状態から始まるので、用意しても使われないかな…。
#1251 の対応 compiler, builder双方にだいぶ気持ちが悪いことをしないといけない。 - リスト類をembedと同じ扱いにして、inline_compileは各リストメソッド側で実行するという回避方法。泥縄っぽくて後々痛い目にあうか？ - x01文字は当然ハイライタではエラーになるので、後の戻し処理でエラー表記spanごと削る方法で対処している - LaTeX側はlistingsがコンパイル時にスタイルマクロ内での解析実行となっており、ここにエスケープを割り込んで戻す、というロジックを入れるのは無理そう。EPUBだけの固有機能ということになり、気持ち悪い。 - ~~inline_compileを実行したときになんか改行が増える？？~~ - ~~idgxmlでテストエラー。改行まわりなのでHTML以外のほかのビルダも同じのはず~~ - ~~emlistnum, listnumはハイライト処理の一本化のマージが先に必要~~ いちおうできたんだけど、かなり怖い。リストをいじっているreview-ext系が全滅するのもアレです。
templates/web/固定で、プロジェクトフォルダのlayoutsではいじれなさそう？ レイアウトファイルの名前もhtml（EPUB）のと競合する。
SATySFi https://github.com/gfngfn/SATySFi/blob/master/README-ja.md のビルダを作ってみます。 - デフォルトのスタイルクラスはだいぶ貧弱なので、現状Re:VIEWのタグに1対1対応させるのは厳しい。 - SATySFiはnoindent（や子となるようなブロック）を+p範囲にあるかどうかで判定するロジックになっていて、ストリームで見ていくRe:VIEWでは表現できない。 - 画像挿入には必ずサイズ指定が必要になっていて、reファイル上でmetricを指定することが必須になる。あと画像形式には制約があるっぽい。 - 実際にビルドするとなるとdocument情報で囲まないといけないので、makerも実装する必要あり。 - インデントは無意味ではあるが可読性のために一応再現する。