2014年12月07日
_ [computer] イベント「版管理+自動組版」に行ってきた (1)
オーム社さんのセミナールームを使って開催されたイベント「版管理+自動組版」に参加。
40名の枠で、参加者34名(+α)、都合が合わずにキャンセル30名と、ニッチなテーマかと思いきや関心が高くて驚く。そもそもRe:VIEWを知っている人がかなり多い時点でおかしいとも言えるが……。 7つの発表はどれも密度が濃く、13:30〜18:00という時間があっという間に過ぎていった。あと1、2回くらいはこういうテーマで集まれるかもしれないなと感じた(その後はたぶんダレるだろう)。
golden_luckyさんの「ドキュメントにおける抽象化の梯子」
原稿・原書のフォーマットをできるだけ利用しながら、編集者(兼プログラマー)がPDFを作るシステムを提供する。最後の最後までバージョン管理と自動生成のシステムを使って、原稿と結果との齟齬が出ないようにするのと、ブランチを切ることで改訂版と増刷修正の両方を管理する。
抽象化の梯子については公開されている資料に詳しい。入力(原稿)、何かの汎用フォーマット、スタイルに合わせるカスタマイズ変換器、書籍(PDF、EPUBなど)という自動組版順路の中で、後工程に進むほど融通が効かなくなる。
自動制作する上での課題としては、図表の管理のしづらさや、エンジニアマインドな編集者が少ない(技術書出版社においても)、初校・再校といった区切りがなくなったことでスケジュール管理が大変といったことが挙げられた。
- 改訂と増刷修正を「ブランチ」と考えるのは、なるほどとうなずかされる。自分の職務の範囲だと、改訂と増刷はプロジェクト管理を含めてまったく別の作業(直し方もいろいろ異なる)なので、基本的には改訂のときには新たなリポジトリができるのが普通だった。
- 「できるだけ利用」については、原稿がMicrosoft Wordでもがんばるのだろうか、また翻訳者の負担が大きくないだろうか、という点が気になった。Re:VIEWにおいても、「翻訳者のマークアップ付けが無理なのでWordで(後は編集で)」というケースが過去にいくつかあった。
- スケジュール管理については確かにちょっと辛いところで、進捗報告において「今何をやっていますか」という問いに答えにくい。大まかな進行予定は版元の担当者から指示があるにせよ、ピークに振り幅があったり、(まだあまりないが)競合時の対応をどうするかといった課題がある。
dmiyakawaさんの「『継続的出版』への『自動組版』的に見たシステムの考察とコメント求む」
Re:VIEWを使った書籍ビルドシステム。WebとGitで構成され、コミットされた原稿が即時にPDFやEPUB(およびmobi)として生成される。
Re:VIEWやその他の処理系におけるユーザーのカスタム操作の許容は、悪意を持っているかもしれない不特定多数への提供においては脆弱性ともなり得るため、軽量コンテナであるDockerを使ってサンドボックス化している。Dockerのコンテナ内は親環境と独立して新しいTeXなどを入れておいたり、バージョンを固定化できたりすることが可能。DockerHubにRe:VIEW環境一式入れたものを登録するか考えている。
機構としてはできているので、Sphinx、あるいはその他のオレオレマークアップでも対応はできそう。
PDFについては本当は「綺麗なフォント」を埋め込みたい。今はIPAフォントを埋め込むやり方を提供しているが、たとえばフォントベンダーのフォントを埋め込む場合にそのライセンス契約をどうするか、要するに契約と実行の主体を誰とするか。「dmiyakawaさんが」リクエストに応じてポチっと「手動で」ビルドするなら1マシン向けのモリサワパスポートだけでもいけるかもしれない。ただ、無人で実行させるとなるとサーバーライセンスになる可能性。Dockerコンテナが起動されるごとに1ライセンスとなると辛い。ライセンス費用を応分する手段も含めて検討中(イワタ等も検討してはどうかという会場意見あり)。
- Re:VIEW開発者会議でも指摘されていて、Re:VIEWがいろいろ好きにできてしまって第三者提供だといろいろ危ない(maker系のフック、review-ext.rbによる上書き、YAMLでも何かあるかも)というのは当方も理解してる。いちおう外部系禁止のREVIEW_SAFE_MODEという環境変数は対策の1つとして導入したけれども、review-ext.rbの一部は使いたいといった要求には耐えない。特権ユーザーだけが触われるシステムの拡張ライブラリの置き場を別途用意するほうがよいのかもしれない。
- フォントについてはとりあえずモリサワパスポートで、キュー化してdmiyakawaさんが時間のあるときにポチっとなをするシステムから始めてはどうだろうか。dviファイルに攻撃コードを含めるのは難しいだろうから、ビルドされたdviファイルを途中でポチっとな環境に送るようにして、モリサワフォントマップ付きでdvipdfmx。
shimizukawaさんの「某PyPro本執筆時にSphinxを使った話」
『エキスパートPythonプログラミング』『Pythonプロフェッショナルプログラミング』『Sphinxをはじめよう』『Pythonプロフェッショナルプログラミング第2版』などの制作を通してやってきたこと。
『エキスパートPythonプログラミング』はアスキーからの刊行で、組版はEWBを利用。EWBって何ですか? という会場の質問に、アスキーメディアワークスの嘉平さんがEWBの歴史を説明。TeXバックエンドの組版システムだと皆思っていたのだが、実は写研の写植コマンドを生成するのが始まりという説明に会場から驚きの声が上がる。
『Pythonプロフェッショナルプログラミング』では執筆時はCIによる自動化。Googleスプレッドシートでチケットを管理。版元の編集に出すときにはmake shuwaで秀和フォーマットテキスト(見出し記号や指示が記述された簡易マークアップのプレインテキスト)を書き出し、Dropboxで引き渡し。秀和テキストで修正されたもののreST原稿へのフィードバックは手動。管理から乖離するといろいろ辛い。
『Sphinxをはじめよう』は、reSTで執筆、XMLを吐き出して、オライリーの編集者がRe:VIEW形式に変換(XSLT)。
『Pythonプロフェッショナルプログラミング第2版』は、初版のシステムを改良しているが、校正戻し以降のreST原稿へのマージの問題はまだ残る。執筆にreST、執筆者レビューにRedmine、社内レビューおよび社外レビューにHTMLかLaTeX経由PDF、版元向けに秀和フォーマットテキスト。
- 秀和システムさんが秀和タグからどのように組版をしているのか気になった。画面をぱっと見した限りでは人間向け指示記号が多く、正規表現で段落/文字のスタイルを軽く付けて人力、あるいは全部目視人力というように思えた。こういうフローをせっかく導入しておきながら手戻りがいろいろ発生しそうであれば、版元さんに積極的にもっと前の工程、つまりreST原稿の時点で文字校正を一緒にしてもらったほうが初校・再校がもう少しスムーズになるかもしれない(「実際の紙じゃないとヤダ」と言われるとそれまでだけど)。
- InDesign XMLのキモは結局、物理改行位置、テーブル表現、浅い構造、タグを使い回さない(か、フィルタで必死に構造を見て指定)なので、SphinxのXML吐き出し部分をいじってInDesignで組めるようにすることは多分可能。ただSphinxは、ファンシーHTMLの提供といったように、ある程度整形済みのものが望ましいというスタイルに見えるので、何か事前にInDesignでテンプレートを設計しておき、そのIDMLテンプレートにSphinxのコンテンツを埋め込んだIDMLファイルを作る、というほうが筋に合っているかもしれない(そういえばPandocにはidmlあったっけ)。
後半 (2)に続く。
