トップ «前の日記(2014年12月07日) 最新 次の日記(2014年12月09日)» 編集

KeN's GNU/Linux Diary
... 料理とDebianと雑多な記録


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などを利用しているが、ページ繰りが変わったときに以降の結果差分が「全部変わった」になってしまって結局目視頼りになるのが課題と考えている。

総括

版管理+自動組版というテーマでそれぞれがいろいろなアイデアや課題を持ち寄って語った感があり、参加者それぞれに何か感じるものがあった有意義な会となったと思う。時間の都合でパネルディスカッションはなくなったが、もともとバッファとして設けていた面があり、各発表の質疑応答で、パネルがやろうとしていた役割はおおむね達成できていたのではないだろうか。

会場提供のオーム社、裏方をされていた方々、発表者、そして師走に参加いただいた大勢の皆さんに感謝を。

_ [cooking] ペンネアラビアータ、ポテトサラダ


冷蔵庫整理がわりに適当に。ペンネちょっと入れすぎ&固めだったか。