2014年12月01日
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)に続く。
2014年12月08日
_ [computer] イベント「版管理+自動組版」に行ってきた (2)
(1)の続き。
tk0miyaさんの「マークアップ言語を拡張することのメリット・デメリット」
Sphinxコミッタとして荒ぶっている小宮さん。緑。敵だ!
主にSphinxの紹介。
Pythonリファレンスを構築するために作られ、読みやすさに重点を置いたreST記法。インラインマークアップのロール、ブロックマークアップのディレクティブを拡張できる。ディレクティブの終わりは、その範囲のインデントがブロック開始よりも少なくなった時点で判断される、というのはPythonっぽい。スペースを_で表すとして、
.._csv-table:_見出し ___:header-rows:_1 ___CSV ___CSV ___CSV 以降で先頭インデントが3より少なくなったらブロック終了
となる。
reSTを変換する実体はdocutilsだが、docutils自体は複数ファイルを扱えないため、その拡張APIを使う形で、Sphinxが目次やクロスリファレンスなど書籍構成に必要なことをすべて面倒を見る統合環境となっている。HTML化の際にはテーマを使ってファンシーな見栄えを最初から作ることができる。
テーマを除いてもSphinx拡張は200以上は存在。Excelファイルを取り込むsphinxcontrib-exceltable、メディアファイルやスライド、Google Maps、Gist、Twitter等の埋め込み、リンク、Doxygen、ソースコード解析、DBスキーマ解析等々。ただ、セットアップがバラバラなのと、「1ソースマルチユース」にどの拡張も対応しているとは言えない状況。拡張だらけだとreSTの方言化につながる。プロジェクトに設定ファイルがあって、どういう拡張が必要かという定義は可能(コンテナへのデプロイなどに使えそう)。
Sphinxを使うことで(拡張された)reSTを覚えたユーザーが多いため、GitHubで記法が使えないことを不審に思われることが。Sphinxで作った文書は基本的にSphinxで処理することを想定。
- 記法に関しては、インラインマークアップで、リテラルな単体記号を使うのはやっぱりどうかなぁという気がする。ブロックマークアップでインデントに気をつけながらというのも若干負担が大きいような。
- docutilsとSphinxの関係は、Re:VIEWだとreview-compileとreview-pdfmaker/review-epubmaker相当だね。後付けで必死なRe:VIEWよりうまくいろいろやっている印象。
- sphinxcontrib-exceltable、気になります!
taisonさんの「自動組版と版管理や進捗管理の事例紹介」
書籍制作会社のPythonエンジニアであるtaisonさんの、「カタログ」「雑誌」「書籍」の制作システム実務のお話。同業他社さんの技法を聞ける機会はなかなかないので、貴重。
基本構成としては、InDesign Serverをコアに利用し、WebのUIを通してライター・編集者・素材提供者、テンプレートデザイナーからの各コンテンツ要素をまとめ、IDML(InDesignコンテンツのXMLデータ表現。Re:VIEWが作るような単純なXMLとは違って、InDesignネイティブデータ互換のすでに紙面配置の終わった状態)と(たしか)PDFを返す。
カタログ。これまでは大量のデータを手入力、紙面をマスターで進行していると元データに還元されず、改訂のときとかに困ったことになっていた。
Web上でblogを書く程度の労力でデータを入力・修正できるようにし、データベースに格納、XML化してInDesignテンプレートに投入。テンプレートは要求に合わせて5,000くらい用意した形。生成結果を確認して、文字詰めなどが気にいらなければWeb上でInDesignスタイルと対応するスタイルを箇所指定する(ただし、Web UI上でWYSYWIGで見栄えが変わるわけではなく、生成結果に反映されるのみ)。欠点としては、XMLが独特で、他への転用はしづらい。
雑誌。どうしてもえいやっと気合いと短期集中で作成しがち、コンテンツを保っていく意識は低い。ただ、この素材はどこからのだっけと散逸したり、あとでムック化したいといったときにPDFしかないということにもなりがち。
同様にWeb上で制作管理するように。フローを統一し、コンテンツをすべてデータベースに集積していく。InDesignテンプレートでどのタグとどのコンテンツが対応するかを決めておき、工程が進むにつれてデザインが変更することになっても、対応関係を保つことでコンテンツが失われることがないようにする(ただし、最後は手作業で調整する余地も)。
書籍。文学やミステリー、ラノベも。紙進行、へたすると原稿用紙に戻ったり。進行がバラバラになりやすく、追記・修正が頻繁に発生する。hotfixとして緊急修正したものが、ほかのブランチに反映されていないという事態への対応をどうするか。工程での内容の担保が難しい。
システム化することに対する編集側のアレルギーが課題。意識を高める必要？
- まさに同業他社で、似たようなことを別のアプローチから高度に攻めているのを拝見できて非常に興味深かった。お話を聞けてよかった。
- 雑誌組みの場合、マークアップとか構造化とかは、よほど強固なリーダーシップをこちらが取れないと終盤に全部台無しになるのがオチなので、ベタにInDesignスタイルと結び付けるtaisonさんのアプローチは多分正しい。類似の手法としてはAdobeのInCopyが近いのかなと思ったけど、あれはコスト高めだよね……。
- 秘伝だと思うけど、Web UIの画面を見てみたかった。
- IDMLは今後のためにはやはり手を出さざるを得ないかなぁというところ(ちょっと勉強したけど、大変そうだったので避けていた)。登場する紙面要素が多い技術書においてどの程度モノにできるかはちょっと未知数なところがあるが、XMLマークアップ混じりだと(主にInDesignのバグのせいで!)いろいろと困った問題があるので、最初から組み済みでマークアップが入っていない素直な紙面ができると嬉しい。
MurakamiShinyuさんの「CSS組版の話」
Vivliostyleを立ち上げた村上さんによる、CSS組版最前線のお話。
TeXユーザーの集い2014の発表と内容はかぶるところはあるが、情熱的な語りで聴衆を大いに魅了。
CSS組版はHTMLに限らず、XML+CSSでも可能。DITAドキュメント(XMLで記述されるトピックベースのドキュメント)の組版にも使える。
Web用のCSSだけでは書籍組みには不足なため、書籍用の見本CSSテンプレートは揃えていかないといけないというお話があった。
- InDesignはバッチ化辛いし(そこでIDML？)、XSL-FOもまた別の意味でいろいろ辛いので、HTML/XML+CSS組版としてアンテナハウスフォーマッタや、Vivliostyleにはとてもとても期待している。
- 昔Twitterでも書いたけど、本格的な組版としての要望を満たすためには「日本語組版処理の要件」を実装したところがようやくスタートラインで、そこから版元・印刷所・DTP・デザイナーといろんな分野や組織の人たちにヒアリングしていく必要があるんだろうなと思う(Adobeは、そういうことをがんばって今のInDesignのデファクトスタンダードの地位を築き、さて今は誰の意見を聞いてどこを向いてるんだろう？)。
jj1bdxさんの「図表の版管理，どうしてますか?」
コンテンツを構成する文章と図表をどのように管理したらよいのかという観点での、聴衆への問い。論文等では「差分」や「変更時刻」がエビデンスとして重要になることがある(「"誰が"、"どのような意図で"も重要」が、質疑にて追加あり)。
文章がテキストの場合は差分管理容易。ただし文字コードや改行コードの違いに対しては一手間かかるし、「ソースコード末尾に無意味なスペースが追加」のような変更はセマンティクスとしては変更されていないが、「違うもの」にはなる(diffのオプションで無視するようにすることはできるけど)。
差分が取れない場合はコピーするしかなくなる。コピーから差分を追跡するのは目視に頼ることになるが、見落しなど破綻する可能性が高い。
Microsoft Wordの場合にどうするか。テキストに落とすと構造の情報が落ちてしまう。
[ここで、Wordの差分機能の利用や、HTMLにして差分をとってはどうかという会場の意見があった。 前者についてはWordの中で閉じてしまっていて外部からは判断できないというのが問題。 後者については詳細議論までは進まなかったけれども、ネイティブデータから情報が劣化しているという点でテキストと五十歩百歩な気がする。]
図版の場合はどうするか。そもそも「同じ図」とは何かという哲学的な話になる。exifが違ったら異なる図か。ドロー図で要素を書く順番が違ったら異なる図か。解像度が違ったら異なる図か。差分だけを見ても、変更に至った意味の表現(たとえばコミットコメント)がないとわからない。SVGがテキスト形式でもその差分からは意図はわからない。
同一という判断を目視判断に頼るか。人は間違える、見落す、厳密な判断ができない、時間と体力が費される。
OCRやFacebookの顔認識などに見られる自動認識はどうか。認識はできてもその理由に明確な「なぜ」を証明できない。誤認識の問題が大きい。指紋認証の信頼性などで、「本人であるにも関わらず本人でないと拒否する本人拒否率」と「他人なのに受け入れてしまう他人受け入れ率」があり、一方の間違いを減らそうとするともう一方の間違いが増えてしまう関係にある。間違いを許容しない限り、自動認識はできない。
- 着眼点に優れた良い発表だった。コンテンツの同一性の担保については、まさに自動組版やblockdiagのようなコマンド記述型図版が目指しているところだろう。生成された組版結果の差分についてはdiffpdfなどを利用しているが、ページ繰りが変わったときに以降の結果差分が「全部変わった」になってしまって結局目視頼りになるのが課題と考えている。
総括
版管理+自動組版というテーマでそれぞれがいろいろなアイデアや課題を持ち寄って語った感があり、参加者それぞれに何か感じるものがあった有意義な会となったと思う。時間の都合でパネルディスカッションはなくなったが、もともとバッファとして設けていた面があり、各発表の質疑応答で、パネルがやろうとしていた役割はおおむね達成できていたのではないだろうか。
会場提供のオーム社、裏方をされていた方々、発表者、そして師走に参加いただいた大勢の皆さんに感謝を。
