flickr2016/06/08Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけこれ、FAQっぽいんで、ちょっと私見を書いておこうと思います。Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。これには、二つの面から「ちょっと認識が違うから待って」と言いたい。「認識が違う」と思うのは、プレインオールドでない方法も部分的にはすでにけっこう導入されているという事実です。自分は、全面的に「マークアップ原稿を最後の最後までGitHubで管理する」ための仕組みをもう何年も実際に運用して売り物の本を作ってきました。「出版の中の人は現代的なプラットフォームを使えない」と言われると、どうしても「ぼくはちがうもん」と言いたくなるんですが、なんで自分はできてるのか、という点についてはあとで改めて書きます。ルールが決まってる組版で自由な表現をするための仕組みはどうするの?という点に対する回答がないことです。これは、原稿の形式と版管理ではどうにもならない問題です。プラットフォームをチューニングして、「今回のプロジェクトで作りたい形の本を作れるようにする」部分です。毎回同じ体裁で似たような本を作るなら、yamlなどの設定を書き換えることによるシステム的なチューニングだけで済むかもしれません。いうか、実際に済んでいます。それでも、そのチューニングができる人が出版社の中に必要になるんですが、その程度なら、まあ、システムのお守りをする人がプロジェクトごとに担当者に要件を聞いて調整すればいいでしょう。頭が痛いのは、「この本では見出しでこんな表現をしたい」とか、「強調をいくつか使い分けたい」とか、「標準的ではない構成にしたい」とか、そういう個別の本の中身に対する要求に合わせたチューニングです。いう要求を吸収できるようにシステムを作りたいということであれば、Markdownの原稿では絶対に無理(無理)なので、素直にLaTeXでもなんでも既存のプラットフォームを使おうよ。(本音)勝手が許されない「組版」と、自由な「レイアウト」と、それを吸収するプラットフォーム出版物は、特に紙の本は、歴史がそれなりにあるので細部のルール(いわゆる組版)がわりときっちりしてます。そのルールを逸脱していると、単純に読みにくい本になります。ソースがXMLベースの原稿でも、本気のページ組版のためには、通常のブラウザエンジンではなく専用のフォーマッターが使われています。ブラウザのレンダリングエンジンでJavaScriptとCSSを使ってきちんと組版しようと思ったら、専門の会社を一つ作らないといけないレベルで大仕事です。そんなわけで、出版物というのは、組版というミクロな部分の見た目についてはあまり融通が利きません。一昔前の業種がいつまでも生き残ってるのでも、デザインセンスが必要だからだけでもなく、組版という仕事が本質的に専門知識を要求されるものだからです。はいっても自動組版したい人、軽量マークアップの原稿を機械的に組版したい人にとっての選択肢は、いまは主にバックグラウンドでLaTeXを使うプラットフォームになると思います。そのLaTeXですが、ご存じのとおり鬼門ですよね。Markdown+PandocやSphinx、Re:VIEWでとりあえずページ組版されたものを出すなら既成のスタイルを使うだけなので、とくに苦労はいりません。問題は、ちょっと違った見た目にしたり、新しいレイアウト要素を追加したかったりする場合です。これにはLaTeXのコマンドを使って自分でスタイルを書くしかありません。新しいレイアウト要素を追加するにはそれだけでは済まず、ソースにおける構造とレイアウトとのマッピングを定義する必要があります。自分は、このような拡張が簡単にできないと死ぬと思ったので、かなり早い段階でそのためのDSLを開発してました。これまで十年くらい、「マークアップしたテキスト原稿を版管理」しながら「本として最後まで作り込む」という環境を実現できてたのは、こういう仕組みを作ったからです。これは自分だけでなく、「マークアップしたテキスト原稿を版管理」しながら「成果物として最後まで作り込む」を実現している人は、だいたいこのような構造とレイアウトのマッピングをする仕組みを自分たちで作り上げてるようです、というのを昔開催した「版管理+自動組版」という勉強会で知りました。厄介なのは、そういう仕組みを「誰もが使える」ようにする点です。GitHubのようなベースとなるプラットフォームを使い始めてもらうためのハードルが高いわけではありません。自分の経験だと、毎回の書籍原稿における文書の構造とレイアウトを実現するメカニズムの両方をそれなりに理解しないといけないのが唯一の障壁です。いうことを考えたい人が中に常駐していないと、プラットフォームがあったところで、多様な個々の本に対してそれを適用し続けることができないのです。いうプラットフォームを使って勝手が許されない組版かつ自由なレイアウトを実現しながら本を作り込もうとする人が足りてないことが大きな理由だと思っています。単純なプラットフォームで実現できる形の本だけで出版というビジネスを回してやろう、という大胆な発想もありえると思います。Bookshelf社の取り組みについて調べてみるとよいと思います。さんのコメント...この話と、今回のIDPF/W3C合併にまつわる下記討論とはよく似た構図にありますね。(自分も似たようなことを考えたことがあります)細かなカスタマイズを切り捨てて体系を単純化することで、書籍作成をコモディティ化しつつ、かつ慣れ親しんだ開発フローを適用できるところに可能性と魅力を感じているのでは。ルールが決まってる組版で自由な表現をするための仕組みはどうするの?の部分については、その「自由な表現」というのを多少犠牲にしてでも、この方法でやったほうが全体として幸福度が高まるはずだ、ということなのかなと。最終的にパースされてLatexに落ちる前提であれば、そこでいくらかスタイルの選択は可能なので、お仕着せの幾つかのパターンから選べれば十分とか、どうしても弄りたい所があれば自分でスタイルファイル作りますとか、そういった温度感ですね。出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「...職務経歴書いろいろあって職務経歴書を作成してみることにしました。機能を使うのが一番お手軽です。編集をお手伝いしました。Blogger.自己紹介Unknown詳細プロフィールを。