Skip to content

Re:VIEW 開発者会議 2018 Autumn

Kenshi Muto edited this page Sep 24, 2018 · 13 revisions

Re:VIEW 開発者会議 2018 Autumn

  • https://connpass.com/event/100084/
  • 日時: 9/20 19:00-21:20
  • 場所: インプレス会議室
  • 参加者: kmuto, suzukin, vvakame, munepi, kdmsnr, kuboaki, takahashim, yyamane, mhidaka, k0miya

重点アジェンダ

  • Re:VIEW 3.0リリースに向けて
    • スケジュール
    • 実装・修正すべき機能
  • Re:VIEW 3.0に関係するTeXスタイルまわり
  • post 3.0

リリースについて

スケジュール

  • 3.0リリースを10月末〜11月頭にターゲット
  • 次のpreviewリリース #1107
    • @takahashim (RM)は技術書典が終わるまでは厳しい。
    • preview3を技術書典後にリリースしたい。
  • 可能なら3.0リリースの1週間前くらいにRelease Candidate版をリリースしたい。

実装すべき機能(リリースクリティカル)

  • TeX: 版面設計をgeometryに戻すかcalculatePageLayoutをもう少し進めるか #1090 #912 #1076

    • geometryが悪いのではなく、jsbookのmagnificationに関連する機能を使うことがそもそもよくないのでは。
    • ただgeometryは一度呼んだらその作法に合わせる必要がある。
    • jlreq+geometryも可能。ただ単位系の影響で本文サイズがおかしくなる可能性。geometry→サイズ変更をするのは×。サイズ変更→geometryなら○。
    • jsbook向けのcalculatePageLayoutの実装自体は悪くはないが、センター合わせでノドor小口の指定がない。
    • ◎「jlreq化する前の当座の対処」として、jsbookの派生クラスファイル(仮称review-jsbook.cls)を作ることを決定。munepiさんが近日で実装してみる。
      • 左右天地・ベースQ数(ptのほうがわかりやすい?)などの版面計算をここで行う。
      • 指定はドキュメントオプション。
      • QWLHとフォント名指定も? (オプショナル)
      • geometryは排除。 トンボまでやる?
      • 技術書典でよく聞かれるのは「紙面の大きさ(A5, B5, A4 など)」「文字の大きさ(8pt〜1?pt)」(8ptは見づらいけど)、「行間を詰め気味にする」(これも見づらいけど)、「上下左右の余白」
      • とりあえずupLaTeX+dvipdfmx用とする。
      • これが最大のリリースターゲットになりそう。
  • review-init: ネットワークからの初期テンプレート取り込み機能 #1102 #812 #1105

    • @takahashim がコードレビュー。問題なさそうならマージ。
    • Rubocopに怒られてやめたopen-uriならリダイレクトに対応できる。Rubocopの無視に入れてもいいのでは? とりあえずリダイレクトが必要になるという状況にならなければ現状で。
    • これができるとサードパーティからの配布は容易になるはず。
    • 展開後のスクリプト実行は、セキュリティと環境問題(具体的にはWindows)があるのでやらない。展開後のREADMEにでも指示を書いておくということで。
  • ファイルのライセンス #1093

    • review-init展開後のRakefileやdocはMITとする。
    • Sphinxだとcopyrightがファイル名に書いてある……と思ったけれどもそうでもなかった。
    • CCやPDはDebianの人としては馴染まないので採用しがたい。
  • TeX: 全面表紙の実装 #1064

    • 塗り足し付きのマクロも必要そう?
    • munepiさんのincludefullgraphics?
    • review-jsbook.cls にマクロを入れておく? (jlreqのほうがちゃんとできるが…)
    • PDFのオブジェクトをえいっと置いてしまう手もある。TikZでもできるがトリッキー。
    • 置くものは塗り足し前提でいいのでは(塗り足しがあるかどうかはデータから判断できないので)。拡縮やアスペクト変更をせず、用紙中央に原寸で貼るという挙動にする(graphicxとマクロで実装するのがよさそう)。
    • 誤った解像度のPNGを貼ったときは小さかったり大きかったりすることになりそうだが、逆にそうなっていればユーザーは気付くのでよさそう。
  • TeX: デフォルトを印刷向きに #1032

    • ユーザーは印刷と電子の違いに注意を払わない傾向(で後で問題になりがち)。
    • デフォルトでトンボを付けると気付いてくれそう。何もしないと入稿用になる。
    • PDFMaker側に印刷/電子の切り替えオプションを持たせるのは難しい。
    • クラスファイルのドキュメントオプションで与えられるほうがよさそう。(review-jsbook.cls前提)

修正可能か?(非リリースクリティカル)

  • TeX: 印刷所名による奥付デザイン崩れ #963
    • 生のLaTeXのサンプルでもうちょっと検証するが、セルの改行字送りと外の字送りが違うのが原因と思われる。
  • imgmathのドキュメント記載 #875
    • まだ万人に使ってもらうには危ないので隠し機能扱いで。
  • imgmath生成ロジックの改良 #868
    • Sphinxからの流用実装。
    • コンパイルログが大量に出る。日本語が通らない。スケール指定ができない。同じものを何度もコンパイルする可能性。コマンド固定。
    • 大幅にリライトすべき(post3.0)。
    • @munepi の改良ロジックが @tk0miya に渡される見込み。
  • bibpaperの見た目がビルダでバラバラ #838
    • 参考文献用に使ってる人がけっこう多い?
    • HTMLのをTeXの見た目に寄せるのがよさそう。
    • 箇条書きに任せたほうがいいのでは?
    • 3.0を機会に見た目を変えてしまってもよいかも?
  • label/hrefのビルダでの挙動違い #835
    • LaTeXをHTMLのほうに寄せる。
  • TeX: 縦書き時の著者欄 #695
    • TeXの制約で、できなくはないがわりと大変。
    • 縦の奥付をがんばる必要あるか? 全面貼り付けを実装すればそれで画像化した奥付PDFなどを貼るのがよさそう。
  • href内の単一%の処理 #304
    • レアケース(かつどっちにしてもエラーとなるもの)なので保留。
  • column内のtableが出ない #222
    • そもそも3.0で「H」をデフォルトにしたので問題なさそう。
    • よりがんばるには「コラム内にある場合に別のマクロを割り当てる」という方法があるが複雑化するだけになりそう。
  • texstyleにオプションを付けられるようにする? #1109
    • 実装自体は容易。
    • そこから子スタイルにオプションを渡そうとすると厄介。reviewmacro.styにオプション解析するロジックはあまり入れたくない。
    • ドキュメントオプションの指定に期待して、styleではオプション指定はしないことにする。

対処済み?

  • TeX: ユーザーカスタマイズ用のスタイルファイル #917
    • 3.0で分割した結果でよさそうなのと、review-initのダウンロード機能で対処できそう。
  • TeX: titlepageとcoverfileを独立に #848 #839
    • 3.0で分けたのでclose可能。

TeXスタイル

review-jsbook(sty/ベースマクロ、装飾、など)

  • LuaLaTeX向けにzw,zh置き換え #451
    • エラーが出ないまでを目標。
    • zw・zhがない場合に\zw,\zhを定義すればよいのでは(\relaxを忘れずに)。
    • jlreq, plistings, ltjsbookあたりの実装を参考にするとよい。

review-jlreq

  • 作業時間がない…。派生元jlreq.clsへのオプション渡しがうまく実装できていない。
  • review-jsbook.clsが届いたらそれを参考に書き直せそう。

review-techboosterの3.0化と、それに関連してのRe:VIEW側の対応

  • @mhidaka への技術支援が必要。
  • @takahashim がPR済み。
  • 自前の定義(仮称review-techbooster.sty)の呼び出しをどこに書くべきか?
    • review-custom.styに書く→意図と違いそう。
    • reviewmacroに書く→バージョンアップ時に困りそう。
    • texstyleに書く→妥当。
  • texstyleに書く場合、ユーザーにはconfig.ymlを書き換えてもらう必要がある。
    • review-initのダウンロード展開でconfig.ymlも上書きしてしまってよいのでは。
    • Techboosterプリセットみたいなこともできるのでconfig.yml上書きでよさそう。
  • Re:VIEW公式のreview-base(Re:VIEWから出した命令とLaTeXマクロとの対応関係・必須),review-style(見た目・なくてもよい)の2ファイルは、今後バージョンアップ時に更新の対象としていく。
    • 更新用のコマンドが必要になりそう。3.1時に。(issue立てておく)
  • samples/syntax-bookにRe:VIEW書式を網羅していくので、TechBoosterなどのスタイルを作成するサードパーティにはこれで互換性検証をしていってほしい。

post 3.0 (3.0リリース後の実装課題)

  • 可能そうなものがあれば3.0に入れるが、拘泥しない。

  • 節単位での管理方法 #1108

    • 節単位じゃないとatomで重くなるとか? 節単位で執筆するというケースもある。
    • Chapterからの変更は大工事。ID管理の問題。YAMLの複雑化。
    • Sphinxはroot本文からの取り込みで構築している。asciidocはindex情報。Re:VIEWは複雑化は避けたい。
    • mapfileとpreprocでとりあえず対応してほしい。
    • 劇的な解決のPRがあれば……というくらい。
  • PEG #235

    • ASTほしい!
    • js実装では参照や表の中がいろいろ辛い。
    • ブロックタグのparaとpreの分岐がBuilderの中で処理しているのが辛い。どの命令はどちらに分岐する、ということを明確化する必要。
    • インラインもオプション取りがstring解析になっているので辛い。しかしインラインのオプション記法はないので解決策が難しい。記法は増やしたくない。
  • ブロックタグのputs/printを文字列返し #741

    • PEG/ASTと絡んで本当はやりたい。
    • が、開発をいったん止めて向き合わないと厳しそう。
  • HTML: CSSフォルダはいる? #631

    • 入れる?
    • 開発陣的には必要性をあまり感じていないが。
  • HTML: id一意性 #46 #551

    • いちおうreview-epub2htmlでは内部で置換して実装済み。
    • @at_grandpa さんが試してみている模様。何か問題があるようだが報告待ち(Vivliostyle.jsのDOM処理の側にも見えるが)。
    • @vvakame も試す。
  • 表の表現手法 #110 #341 #195

    • 皆、表を好きすぎる問題。
    • Markdownの表がたのしい! 実装ごとバラバラでたのしい!
    • SphinxにはExcelの読み込みプラグインがある。
  • 以下はわかっているけど今は難しいということで保留。

    • TeX: 表セル改行ってもうちょっとなんとかならないか
    • 番号箇条書き #347
    • dt/dd途中の#@#による断絶 #151
    • 箇条書き付随段落・リストの表現 #109
    • ブロックの入れ子 #108

その他

質問: 教材への応用

  • 大量のppt。asciidoc化してasciidoctorからHTMLとPDFを生成している
  • HTMLがプレゼン資料(ベース)、PDFを配布教材(ドキュメントとして読めるように)
  • コンテンツを1つにまとめ、同じ教材リソースから作成したい
  • ブロック要素を用意してbeamerで吐く?
  • KeynoteのXMLから吐き出せばいける?
  • ppt2review?

投げ銭

  • IssueHunt
    • Issueに投げ銭制度を設け、修正PRを送った人とプロジェクトにキャッシュバックされる
    • OSSの持続性を目的
    • PayPalで支払い/引き出し。一度IssueHuntにプールされる。引き出しで所得税がかかる。 * PR送り手8割、プロジェクト2割
    • ほかには BountySource がある
  • 今のところはお金が絡むとややこしくなるだけなので見送り