2016/12/30

2017年賀状

年賀状書いた。

%!PS
<< /PageSize [285 420] >> setpagedevice

/setrandcolor {% def
    /r1 {rand 5 mod 3 div} def
    /r2 {rand 4 mod 4 div} def
    /r3 {rand 3 mod 4 div} def
    r1 r2 r3 setrgbcolor
} def

/f {% def
    dup dup dup
    4 mod 0 eq {(2) 4 1 roll -1 0 rmoveto} if 
    4 mod 1 eq {(0) 3 1 roll -3 0 rmoveto} if 
    4 mod 2 eq {(1) 2 1 roll -3 0 rmoveto} if 
    4 mod 3 eq {(7 ) -5 0 rmoveto} if
} def

/i 4 def

/lineto-chars { % def
  /ex x def /ey y def
  /y exch def /x exch def
  /d x ex sub dup mul y ey sub dup mul add sqrt def
  /R y ey sub x ex sub atan def
  R rotate
  { d 0 le % ifelse
    { exit }
    { setrandcolor 
      /ra rand 5 mod 3 div 10 mul 22 add def
      /Georgia-Bold findfont
      [25 0 0 ra 0 0] makefont setfont
      i f show
      /i i 1 add def
      /d d 7 sub def }
  ifelse
  } loop
  0 R sub rotate
} def

1 1 20 { % for
  /n exch def

  newpath
  0 0 moveto
  135  45 moveto
   85 140
  110 165
  110 130 curveto
  0 0 moveto
  150 130 moveto
  155 190
  210 140
  130  40 curveto
  flattenpath
  {/y exch def /x exch def}{lineto-chars}{}{} pathforall
  gsave
  
  32 230 moveto
  0.9 0.1 0.2 setrgbcolor
  /Georgia-Bold findfont [90 0 0 100 0 0] makefont setfont
  (2017) show
  
  grestore
  showpage
} for

2017 by Keiichiro Shikano on Scribd

PSの解説でよく登場する、パスに沿った文字列描画の簡易版です。 まずflattenpathしてカレントパスをlinetoの配列に変換したあと、各linetoが描く直線がX軸になるまで回転→linetoの長さまで数字を順番に書く→回転を戻す、を繰り返しています。 どのへんが簡易版かというと、グリフを書き終わったポイントは当然ながらオリジナルのパスからはずれているのだけど、そこへ戻す処理をさぼっています。そのため、ベースになるパス(ハート型)よりも文字列の描く図形のほうが肥大していく、それもフォントや処理系によってずれ幅がけっこう違ってしまう、という緩い仕様です。 このコードはWindowsのDistillerに合わせてあります。 gsだと、なぜかずれがもう一回り大きい。

過去のやつ。

2016/12/24

JSONをTeXで組版する

昨今、ドキュメント技術の主戦場といったらウェブです(ワールドワイドなほう)。 ウェブ上ではさまざまな構造化テキストが飛び交っています。 まっさきに思いつくのは、HTMLをはじめとする、ブラウザがネイティブにレンダリングできる構造化テキストでしょう。

しかしブラウザにはJavaScriptという強力なプログラミング言語の実装が組み込まれているので、HTML以外の構造化テキストをサーバから取得して整形する場合も少なくありません。 そのようなデータ形式のひとつにJSONがあります。

最近のWebサービスでは、サーバからHTMLを送らずにJSONデータだけを送り、ブラウザがそれをJavaScriptで解析して画面表示をすべて動的に作っている場合もあるようです。 この場合にブラウザがやっていることは、ある種の自動組版だといえるでしょう。 そもそもブラウザによるHTMLのレンダリング自体が自動組版だという見方もできますが、それよりさらに抽象化した、JSONを原稿とする自動組版という考え方です。 必ずしもページ全体をJSONから表示していなくても、たとえばJSONデータから表を生成してdiv要素に差し込むといった局所的な組版もありえると思います。

ブラウザとJavaScriptでできることがTeXでできないはずがない

というわけで、TeXでJSON組版をしてみました。 題材としては、CTANの各パッケージのJSONクエリとかも考えたのですが、残念ながらCTANではパッケージの詳細説明の項目にプレーンテキストではなくHTMLが直書きされている場合があるようです。 TeXで扱うのにHTMLタグは邪魔でしかありません。 まさかCTANともあろうものが、TeXでJSONデータを利用することを考えていなかったなんて。

それに、どうせならもっとクリスマスらしい題材にしたいところです。 クリスマスといえばホワイトクリスマス、ホワイトクリスマスといえば雪だるま。雪だるまを組版するなら天気予報でしょう。 OpenWeatherMapという会社のサイトで天気予報をはじめとする気象データをJSONにより取得できるので、これを組版していきましょう。

天気予報JSONデータの取得

まずはデータの取得です。TeXからHTTPリクエストを発行する汎用の手法はないので、cURLでもwgetでも好きなものを使ってください。 OpenWeatherMapでサインアップしてAPPIDを手に入れれば、たとえば下記のようなURLによって、東京の5日後までの3時間おき予報データが取得できます。

http://api.openweathermap.org/data/2.5/forecast?q=Tokyo,jp&APPID=0000000000000
参考までに、取得できるのはこんな形のJSONデータです。
{"city":{
  "id":1850147,
  "name":"Tokyo",
  "coord":{"lon":139.691711,"lat":35.689499},
  "country":"JP",
  "population":0,
  "sys":{"population":0}},
 "cod":"200",
 "message":0.0103,
 "cnt":37,
 "list":[
    {"dt":1482483600,
     "main":
       {"temp":9.94,
        "temp_min":8.84,
        "temp_max":9.94,
        "pressure":1015.88,
        "sea_level":1017.11,
        "grnd_level":1015.88,
        "humidity":71,"temp_kf":1.1},
     "weather":[
       {"id":802,
        "main":"Clouds",
        "description":"scattered clouds",
        "icon":"03n"}],
     "clouds":{"all":36},
     "wind":{"speed":6.71,"deg":318.003},
     "rain":{},
     "sys":{"pod":"n"},
     "dt_txt":"2016-12-23 09:00:00"},
     ...

JSONデータのTeXによるパーズ

JSONデータを取得できたら、パーズします。JSONを読むパッケージが見当たらなかったので、ざっくり再帰下降パーザを書きました。TeXは関数型言語なので、素直に書けますね。

公開APIは以下の3つ。

\readJson #1 #2
第一引数に渡したコントロールシーケンスに、第二引数に渡したJSONデータが格納される
\readJsonValueById #1 #2 #3
第一引数に渡したコントロールシーケンスに、第二引数に渡したJSONデータの、第三引数の名前に対応する値が格納される
\showJsonValueById #1 #2
第一引数に渡したJSONデータの、第二引数の名前に対応する値が入力に残る

ちょっと例を見てみましょう。青字になっているのがJSONデータです。

\documentclass{article}
\usepackage{jsonlite}

\begin{document}

\readJson{\json}{{"id":[1,2,3], "class":"foo", "data":{"id":"456"}, "info":"Is this a text?"}}
\readJsonValueById{\jsonId}{\json}{"id"}     %=> expl3 sequence
\readJsonValueById{\jsonData}{\json}{"data"} %=> id:456

\readJson{\jsonJsonData}{{\jsonData}}
\showJsonValueById{\jsonJsonData}{"id"}      %=> 456

\end{document}

天気予報JSONデータを表組する

OpenWeatherMap社から提供される天気予報JSONデータから、都市名、予報の時刻、予想天気、予想気温を取ってきて、LaTeXの表として組みましょう。 各時刻の予報は、"list"という名前の配列の各要素になっているようです。 この配列に対するmapで、表の各行を整形するという戦略にします。 実はjsonliteパッケージではJSONの配列をexpl3のシーケンスとして保持するので、シーケンス用のmapが使えます。

\NewDocumentCommand{\showForecast}{ m }{%
  \begin{longtable}{ l | c | r}
    日時 & 空模様 & 気温 \\\hline
    \endfirsthead
    日時 & 空模様 & 気温 \\\hline
    \endhead
    \seq_map_function:cN #1 \format_forecast:n
  \end{longtable}
}

TeX言語のくせにシーケンスとかmapとか、お前はなにを言ってるのだ、という感じかもしれませんが、2016年にもなればそういうものなんです。 そもそもTeXは関数型言語なのだからシーケンスに対するmapくらいできないはずがありません。

あとは、\format_forecast:nを書いていくだけなんですが、 OpenWeatherMap社のデータで"weather"がさらに配列になっていたりして無駄にめんどくさいので解説は省略します。 jsonliteパッケージと同じディレクトリに完全なコードを置いてあるので参考にしてください。

天気記号のサポート数がそこそこあるDejaVuSansを使いたかったので、XeLaTeXで実行してみた結果がこれです。DejaVuSansの☃はどことなく品がいいですね。

ところで、Brzozie(ブジョジェ)という地名がどこなのか気になった人がいるかもしれません。ブジョジェはポーランドの湖水地方で、バホテク湖があるところです。来年のTUG2017は、このバホテク湖で毎年開催されているBachoTeXというイベントと合同で5月に開催されることになっています。なんとか参加するぞ。

そしてこの記事は、第五回となるTeX&LaTeXアドベントカレンダーの24日めの記事です。 昨日はアセトアミノフェンさん(この記事を見てDejaVuSansを使うことを思いつきました)、明日の最終日はZRさんです。

2016/12/03

独立系出版社をやるという覚悟について

カナダ最大の都市であるトロントから北に向かって1時間ちょっと、荒野だか畑だか牧場だかよくわからない広大な土地を走り抜けたところに、エリンという小さな村があります。 19世紀に開拓された当時からメインストリートであったと思われる道が、川の蛇行している部分を堰き止めるように貫いていて、その両脇だけで主な商圏が形成されているような素朴な村です。

そんな小さな村に、なんと出版社があります。 その名もThe Porcupine’s Quill。 直訳すると「ヤマアラシの針」ですね。 言うまでもなく独立系の出版社で、大手からは陽の目を見るのが難しいカナダ発の文学者やアーティストの作品を手掛けているようです。

今年の7月、この《ヤマアラシの針出版》を訪問する機会がありました。 世界中のTeX関係者が集まるTUGという会合があるんですが、2016年の開催地がトロントで、その一環として《ヤマアラシの針出版》の見学会が組まれていたのです。 トロントからエリン村まで農道(もしくは牧道)を延々とかっ飛ばし、パン屋さんの前でマイクロバスを降りると、その何軒か隣の靴屋みたいな建物が《ヤマアラシの針出版》の本社でした。

SDIM0346

こんなカナダのど田舎に本社を構えているというだけで十分に話として面白いんですが、この出版社、他の多くの出版社と違って、印刷から製本まで本づくりのすべてを自前でやっています。 それも、ドイツ製のオフセット印刷機やら製本機やらを社内に一式すべて用意し、経営者であるティムさんと奥さんのエルクさんが手作業で本を作っているのです。 ちなみに、やや出来過ぎ感がありますが、お二人の姓は「インクスター」さんといいます。

これが、さっきの建物の地下にあるHeidelberg Kordというオフセット印刷機。とてもよく手入れされていて、油でてかてかしています。インクが香ばしい。

SDIM0336

こちらは建物の1階に実装されている、本をかがるための機械。ファンシーな窓の鎧戸と陽光のせいで博物館の展示物っぽいけど、むちゃくちゃ軽快に稼働します。

SDIM0333

正直なところ、訪問前にはそれほど大きな期待はしていませんでした。 自分とは畑違いの文芸系の出版社っぽいし、そもそも出版社の仕事なんてどこも大差ありません。

しかし実際に《ヤマアラシの針出版》でティムさんから「どういう考えで本を企画し、作り、それを売ってきたか」を語ってもらい、ビンテージな機械が力学を駆使して本を作り上げるようすを目の当たりにすると、いちいち唸りっぱなしでした。 出版社っていうのは、こんなふうに本を作って売るっていう仕事であり、その骨格がまさにいま自分の目の前に展開されてるんだなと。

  • 出版社の仕事なんて、確かにどこも大差ないけれど、誠実にやっていくと結局は「モノづくり」になるんだよなという気持ち。
  • 電子書籍もいいけど、モノとしての物理は単純に強いなという気持ち。
  • 年間ノルマで本の形を整えなくても、こんなふうに、やりたい人がやりたいように出版をやれるのが健全だよなという気持ち。
  • ぼくも、完全に同じやり方ではないかもだけど、こんなふうにして本にかかわっていくぞという気持ち。

なにをかくそう、ぼくも自分で出版をやりたいと思って、昨年2015年の12月1日にラムダノート株式会社という会社を作りました。 今年2016年の7月にThe Porcupine’s Quillを訪問して、自分が仕事としてやりたいことは「本を作って買ってもらうこと」なんだなと再確認しました。 来年2017年の2月ころには、最初のタイトルとして、TLSの関連書を発行する予定です。 年が明けてしばらくしたら直販サイトで予約できるようにする予定(予定)なので、ご期待ください。

そういえば、この最初のタイトルは翻訳ものなんですが、原書を発行しているロンドンの出版社もやっぱり独立系出版社でした。 そっちもそっちで4月に訪問してたくさん刺激を受けたので、翻訳発行後にあらためてどこかで話ができればいいなと思います。

なお、この記事はラムダノート株式会社の設立にあたって出資して頂いた株式会社時雨堂の社長になんか書けといわれ、pyspaアドベントカレンダー2016のエントリーとして書きました。pyspaには脱サラする直前からずっと癒されてきました。でも、昨日はイアンさん、明日はモリヨシさんだし、あきらかに場違いな記事だろこれ。

2016/07/01

主観でプログラミング言語5種類をあっさり解説

現在プログラミング言語は200種類存在していると言われてるようですが、これはたぶんLisp族の言語だけを数えた値です。

あるプログラミング言語(汎用のもの)がどんな用途に適しているかは、人によって大きく意見が分かれるので、用途を絞ったからといって適したプログラミング言語が決められるわけではありません。そもそも今日の世界における用途が明日の世界にも存在するとは限らないし。

この記事では、ぼくがHello Worldくらいは書いたことがある言語5種類をあっさりと解説しようと思ったけど、そんな知識もないので、「プログラミングしてみたい人向け、言語に関する5つのアドバイス」です。学習しない言語の選択に役立ててください。

Go

それなりに具体的で明確な「Cを使う」理由があるのでない限り、Cで学べるようなプログラミングはGoで学んだほうがいいと思います。

HaskellかOCaml

これといった目的もなくプログラミングを始めたいなら、静的型付き言語で始めるほうがいろいろ実りがあると思います。異論は認めるけど。 HaskellやOCamlであれば、現代的なアプリケーションを試しに作ってみるのに必要なライブラリもそれなりに充実しています。

Scheme

Schemeがいいのは、コンピュータがなくてもプログラミングを学べる点です。Schemeの実装は黒板だと言われるくらいです。

正規表現

特定のアプリを意識した言語でプログラミングし始めるよりも、正規表現をひととおり自在に使えるほうが、最初のうちは役立つ場面が多いと思います。 Rubyとかも、最初は正規表現全開な感じでテキストフィルタを書いてみるのがいいと思います。

先生や友だちや同僚がよく知っている言語

というわけで、ぼくの近くにいる人はTeXから学ぶことになります。

2016/06/20

特殊エンジニア向け数学ガイドツアー本『グッド・マス』の話

6月25日、つまり今週末、『グッド・マス ギークのための数・論理・計算機科学』という本が発売されます。 話せば長い事情があって、発売前だけど訳者の次くらいに書籍の内容を熟知しているので、私的な紹介を書いてみました。

計算機のプロが書いた現代数学ガイドツアー

世に数学系の読み物はたくさん出版されています。純粋数学のプロが書いたものもあれば、そうでない人が書いたものもあります。 『グッド・マス』は、後者です。著者のマークさんは計算機科学のプロであり、数学のプロではありません。そのため、本書でいう「数学」も、コンピュータエンジニア的な目線で描かれます。 たとえば、連分数の話をするときはScalaで実装し始めるし、論理学の話をすれば「Prologはいいぞ」って始まるし、計算といったらチューリングマシンとBrainfuckでありλ計算です。 本書を一言で表すと、「コンピュータエンジニア、とくにプログラミング言語とか大好きっ子にとって興味深いであろう観光名所をめぐる現代数学ガイドツアー」です。 日常の言葉で抽象数学を分かりやすく伝える系の読み物を期待して読み始めると、肩透かしを食うと思います。

ちなみにですが、そういう方向で数学ネタを気軽に味わいたいとしたら、いまなら"Cakes, Custard and Category Theory"という本が面白いと思います。 『ケーキ、カスタード、それに圏論』というタイトルどおり、後半はまるまる圏論の何がおいしいのかを説明するのに割かれています。こないだ翻訳も出たようです(邦題には「圏論」ってないけど)。

この"Cakes, Custard and Category Theory"という本の著者であるEugenia Chengは、生粋のプロ数学者ですが、ユーチューバ―として有名だったりもします。

ナイフを振り回しながら教壇に立つチェン先生かわゆす。

『グッド・マス』の話だった

閑話休題。『グッド・マス』のゴールは、日常の言葉で抽象数学を語ることではなく、コンピュータ好きなら知っていて損のない数学ネタを一通りさらうことです。 とくに重視されてるのは、公理的に、論理を使って、構成的に数学という体系を捉える方法を伝えることです。 著者のマークさんは、冒頭の第1章から、数学の対象を日常的な感覚だけで語らないよう読者に促します。 エンジニアになじみのある日常的な感覚にも頼りつつ、数とか集合、証明といった対象を、現代数学というルールで捉えるやり方を正面から見せてくれる感じです。 数学の教科書とは違う方法で、コンピュータ好きな人が「生の数学」を味見する本だといえるでしょう。 これが本書の貴重なところだと思います。

もともと単発の記事をまとめた本ということもあって、あからさまなストーリーもなく、面白そうな部分だけをつまみ読みできます。「数って何?」みたいな前半の軽めの話題だけ読んでもいいし、Prologを使って一階の述語論理を学ぶ第4部だけ眺めてもいいし、公理的な集合論のノリをさらってみるだけでもいいでしょう。 特に最後の第6部は、正規表現とか再帰、λ計算、型といったプログラミング言語好き向けの話題で占められているので、この辺だけ読むのもお勧めです。 とはいえ後半は「数学をやってる現代人が暗に共有している意識を部外者が垣間見る」ことができるような構成になっているので、論理を扱っている第4部くらいからは順番に読むことをお勧めします。 自分は、はじめて原書を通しで読んだとき、第1章の自然数の説明でのっけからペアノの公理を持ち出してきたのも後半のためのネタ振りだったのかーと納得しました。

一方、『グッド・マス』にはあまり登場しない数学の話もたくさんあります。 解析とか位相に関するネタは本書にはまったく出てきません(ε-δのわかりやすい解説はないし、ドーナツとマグカップがどうこうみたいな話もない)。圏論もないです(Haskellのコードは出てきますが、正規表現の微分を実装するのに使われます)。 このへんの話題については期待しないでください。

あと、いわゆる一般人向け数学の本で必ず引き合いに出される黄金比については完全にコケにされているので、そういうのが好きな人は注意してください。 目次を見ると黄金比を扱っている章がありますが、これはマークさんが「おれは黄金比をもてはやす連中が嫌いだ」ということを表明するためにある章です。黄金比ネタが好きな人にはこの本はお勧めできません。

もうひとつ触れておきたいのは、なるべく読み手が飽きないようにしたいと思うあまりにマークさんの筆がちょくちょく滑るという点です。 ところどころ自由すぎる解釈で書き進めてしまった内容を、コンピュータ系技術書版元であるPragProgsには編集しきることができなかったのか、原書には突っ込みどころのある箇所や単純なミスがけっこう残っています。 ただし、そんな暴走気味の部分はcocoatomoが訳注などでしっかり引き締めてくれているし、 翻訳版のレビューをしてくれた方々(計算機と数学の両方に足をかけてるプロばかり)にも細かい部分まで目を通してもらえてるので、 原文の微妙な勘違いはかなり補正されていました。 翻訳版は、私が企画時にぼんやり思い描いていた以上に、かなり安心して楽しめる内容に仕上がっていると思います。

というわけで6月25日発売の『グッド・マス ギークのための数・論理・計算機科学』、コンピュータをふだんから使っていて、もうちょっと数学的な考え方を知りたいよという人には、とっかかりとしてお勧めです。

個人的なあとがき

本書のもとになっているのは、主に「数学」に関連したネタを扱う英語圏では有名な古参のブログ "Good Math / Bad Math" です。 "Good Math / Bad Math"は、いまほどインターネット上に一般向け数学ネタが溢れていなかったころから勢いのある筆致で数学系の記事を量産してきたブログで、 幾度かの移転を経て現在でもわりと活発に更新が続いています。

"Good Math / Bad Math"
http://www.goodmath.org

過去には『マンガでわかる統計学』の英語版に対する肯定的なレビューがアップされたことなんかもありました。 『マンガでわかる統計学』は英語版もかなりよく売れたんですが、その認知度はこのブログにおける紹介記事で一気にあがった感があります。 (ただしシリーズ全体の認知度として見ると、Boing Boingで『マンガでわかるデータベース』がネタ的に扱われたことのほうが大きい)

"BOOK REVIEW: THE MANGA GUIDE TO STATISTICS"
http://www.goodmath.org/blog/2008/12/13/book-review-the-manga-guide-to-statistics/

自分はたまたま『マンガでわかる統計学』の英語版に少し関与していたこともあって、 それからしばらく"Good Math / Bad Math"の記事をちょくちょくチェックしていました。 そんなある日、「このブログをもとにして本を出すよ」という記事が掲載されます。 しかも出版社はPragmatic Bookshelf社とのこと。 Pragmatic Bookshelf社といえば、『RailsによるアジャイルWebプログラミング』とか『プログラミングErlang』とか『情熱プログラマー』といったIT系書籍で有名な版元です。 これは面白い本になるに違いないと思いながら、続報を待つこと4年、ようやく2013年にベータ版の書籍が発売開始になったのでした。

さっそくβ版を自分で買ってKindleに突っ込み、一通り目を通してみて、「間違いなくそのうちどこかで日本語版が出るだろうな」と確信しました。 と同時に、あちこちマークアップの変換結果がコケていたりして、商品としての出来には微妙なところも感じていました。Pragmatic Bookshelf社では独自形式のXML原稿から紙の書籍と電子書籍を生成しているんですが、 それなりに数式が多く含まれる本書の原稿に対し、その変換処理の調整がいまいちうまくいっていないのは明白でした。

「どうせ日本語版が出るなら訳本には自分自身が関与したい、いやむしろ、自分が関与せずに日本語版が作られたら書籍として残念な出来になってしまいかねないぞ」 というわけのわからない使命感に駆られ、当時所属していた出版社で版権を抑えたうえで翻訳に興味がある有識者がいないかなーと思ってこんなツイートをしてみたのでした。

このツイートに見事に引っかかってくれたのが、そのちょっと前に「スタート代数」という勉強会を主催していたcocoatomoさんでした。 自分もスタート代数に何回か参加していたことから、お互いに何となく面識があったこともあって、企画を通して翻訳を進めてもらうまでは実に順調に話が進みました。 原著の原稿データから日本語版のPDFを自動生成する環境はこちらで用意し、cocoatomoさんにも翻訳をこまめにgit pushしてもらっていたので、 あとは日本語版が少しずつ形になっていくのを時々眺めていればいいという、(個人的には)きわめて理想的な感じで制作が進んでいきました。

ところが、翻訳がずいぶん進んで編集もぼちぼち開始し、これからいよいよ制作も本格化しようという段階になって、自分自身が会社を辞めるしかないという不測の事態になってしまいました。 発行までの実務は会社に残った同僚に引き継げることになったし、cocoatomoさんの好意でその後も翻訳制作の作業にリモートで口を出し続けることはできたのですが、直接の担当者として最後まで携われないまま辞めるというのは正直つらい選択でした(念のため補足しておくと、もっとつらいことがあったので辞めた)。

その翻訳版が、ついに6月25日に発行されることになりました。感無量です。 数式を含むマークアップの変換についても、仕込んでおいたCI上での作業プロセスを外注で回してもらえたので、書籍として申し分ない感じに仕上がっていると思います。いまの僕には、この本がものすごく売れても特に利益的なものはないのだけど(アマゾンアソシエイトについてはよろしくお願いします)、手に取ってもらう人が増えればとてもうれしいです。

2016/06/08

Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ

これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。

とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。

しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。

まず「認識が違う」と思うのは、プレインオールドでない方法も部分的にはすでにけっこう導入されているという事実です。 とくに自分は、全面的に「マークアップ原稿を最後の最後までGitHubで管理する」ための仕組みをもう何年も実際に運用して売り物の本を作ってきました。 なので、「出版の中の人は現代的なプラットフォームを使えない」と言われると、どうしても「ぼくはちがうもん」と言いたくなるんですが、なんで自分はできてるのか、という点についてはあとで改めて書きます。

もう一つ、「出版のための現代的なプラットフォームが必要」という話に対して「うーん」って感じてしまうのは、 ルールが決まってる組版で自由な表現をするための仕組みはどうするの?という点に対する回答がないことです。 これは、原稿の形式と版管理ではどうにもならない問題です。

実際にそういうプラットフォームで売り物の本を制作してきた経験からすると、毎回いちばん頭を悩ませるのは、 プラットフォームをチューニングして、「今回のプロジェクトで作りたい形の本を作れるようにする」部分です。 毎回同じ体裁で似たような本を作るなら、yamlなどの設定を書き換えることによるシステム的なチューニングだけで済むかもしれません。というか、実際に済んでいます。 それでも、そのチューニングができる人が出版社の中に必要になるんですが、その程度なら、まあ、システムのお守りをする人がプロジェクトごとに担当者に要件を聞いて調整すればいいでしょう。 頭が痛いのは、「この本では見出しでこんな表現をしたい」とか、「強調をいくつか使い分けたい」とか、「標準的ではない構成にしたい」とか、そういう個別の本の中身に対する要求に合わせたチューニングです。

そういう要求を吸収できるようにシステムを作りたいということであれば、Markdownの原稿では絶対に無理(無理)なので、素直にLaTeXでもなんでも既存のプラットフォームを使おうよ。。(本音)

勝手が許されない「組版」と、自由な「レイアウト」と、それを吸収するプラットフォーム

出版物は、特に紙の本は、歴史がそれなりにあるので細部のルール(いわゆる組版)がわりときっちりしてます。 そのルールを逸脱していると、単純に読みにくい本になります。 このへん、ブラウザのレンダリングに任せればいいという発想でWebページを作るのとは違っているので、 たとえソースがXMLベースの原稿でも、本気のページ組版のためには、通常のブラウザエンジンではなく専用のフォーマッターが使われています。 もしブラウザのレンダリングエンジンでJavaScriptとCSSを使ってきちんと組版しようと思ったら、専門の会社を一つ作らないといけないレベルで大仕事です。

そんなわけで、出版物というのは、組版というミクロな部分の見た目についてはあまり融通が利きません。 誰でも使えるInDesignというアプリケーションがあるのにDTPがプロの仕事として成立してるのは、 一昔前の業種がいつまでも生き残ってるのでも、デザインセンスが必要だからだけでもなく、組版という仕事が本質的に専門知識を要求されるものだからです。

そうはいっても自動組版したい人、軽量マークアップの原稿を機械的に組版したい人にとっての選択肢は、いまは主にバックグラウンドでLaTeXを使うプラットフォームになると思います。 で、そのLaTeXですが、ご存じのとおり鬼門ですよね。 もっとも、Markdown+PandocやSphinx、Re:VIEWでとりあえずページ組版されたものを出すなら既成のスタイルを使うだけなので、とくに苦労はいりません。

問題は、ちょっと違った見た目にしたり、新しいレイアウト要素を追加したかったりする場合です。 これにはLaTeXのコマンドを使って自分でスタイルを書くしかありません。 しかも、新しいレイアウト要素を追加するにはそれだけでは済まず、ソースにおける構造とレイアウトとのマッピングを定義する必要があります。 自分は、このような拡張が簡単にできないと死ぬと思ったので、かなり早い段階でそのためのDSLを開発してました。 これまで十年くらい、「マークアップしたテキスト原稿を版管理」しながら「本として最後まで作り込む」という環境を実現できてたのは、こういう仕組みを作ったからです。

なお、これは自分だけでなく、「マークアップしたテキスト原稿を版管理」しながら「成果物として最後まで作り込む」を実現している人は、だいたいこのような構造とレイアウトのマッピングをする仕組みを自分たちで作り上げてるようです、というのを昔開催した「版管理+自動組版」という勉強会で知りました。

厄介なのは、そういう仕組みを「誰もが使える」ようにする点です。 GitHubのようなベースとなるプラットフォームを使い始めてもらうためのハードルが高いわけではありません。 自分の経験だと、毎回の書籍原稿における文書の構造とレイアウトを実現するメカニズムの両方をそれなりに理解しないといけないのが唯一の障壁です。 そういうことを考えたい人が中に常駐していないと、プラットフォームがあったところで、多様な個々の本に対してそれを適用し続けることができないのです。

むしろ問われてるのは出版ビジネスの考え方かも

というわけで自分は、軽量マークアップのテキスト原稿をGitで管理して本にするという簡単な仕組みが出版社の中に普及しないのは、 そういうプラットフォームを使って勝手が許されない組版かつ自由なレイアウトを実現しながら本を作り込もうとする人が足りてないことが大きな理由だと思っています。

もっとも、これは「出版する本は作りこむべきだ」という個人的な思いによる分析なので、 単純なプラットフォームで実現できる形の本だけで出版というビジネスを回してやろう、という大胆な発想もありえると思います。 そういう発想を追求したい場合は、米O'reillyのAtlas+Safariのような仕組みや、Pragmatic Bookshelf社の取り組みについて調べてみるとよいと思います。

2016/05/14

TeXと10年戦ってわかったこと

世間では「TeX」と一口に言われているけど、実際には3つの異なる側面があります。10年以上TeXで何かやってきたわけだけど、「TeXはアレ」の本質はこの3つがごちゃごちゃになってるとこかなと思ったりしているので、書いてみました。

  • マークアップ形式としてのTeX
  • 組版エンジンとしてのTeX
  • プログラミング言語としてのTeX

TeXの話をするときって、これら3つが案外と区別されていないなあと感じることがあります。具体的には、組版エンジンとしての機能について言及している場面でマークアップ形式の話を持ち出されたり、マークアップの話をしているときに名前空間がないからダメといった感じでプログラミング言語として批判されたり、ようするに、あまり建設的ではない。

もちろん、TeXというエコシステムについて何か言うときにはこの3つが不可分で、それぞれを切り出して論じてもしょうがないんだけど、まあポエムなので気にしないことにします。

マークアップ形式としてのTeX

TeXのマークアップというと\{}がやたらに出てくるアレを思い浮かべると思いますが、「いわゆるTeXのマークアップ」と見なされているものに厳格な文法とかルールはありません。 よく、「XML自体はマークアップではなくマークアップを作る仕組みを提供するものだ」と言いますが、TeXはさらにひどくて、シンタックスさえもが自分の知っているTeXでない可能性があるのです。

現状のTeXは、いろいろな人や団体が過去に考案してきた「マークアップ」を、使う人が自分のユーザ文書の用途に応じて混ぜて使っている状態だといえます。 なので、たとえば「TeXのマークアップのパーザがほしい」といった要件を満たすものがあるとしたら、それはTeXそのものになります。 この、ユーザが目的に応じていくらでも変更できる余地がある、というのが、マークアップとしてのTeXの革新的かつ悲劇的な点なのかなと思っています。

とはいえ、だいたい用途ごとに「デファクト」のマークアップはあって、たとえば文章そのものに対する基本的なマークアップの文法でいま主に実用されているのはLamportさんが拡張したLaTeXです。 この、LaTeXで導入され、現在に至るまで主に使われている「いわゆるTeXのマークアップ」は、なかなかよく考えられているなあと思います(もとをただせばScribeのアイデアだし)。 数式に対するマークアップも、Knuthが考えたオリジナルTeXにおける数式の書き方を延々と使っているわけではなく、現在ではアメリカ数学会AMSが拡張したやつが広く使われています。 TeXの中で図を使うためのマークアップは、文章や数式とは別体系で、これはいまはTikZが主流になっています。

拡張したマークアップをパーズするための仕掛けはプログラミング言語としてのTeXで作ります。 また、その出力であるレイアウトは組版エンジンとしてのTeXで実現します。

というわけで、TeXのマークアップはひどい、ふつうの人には無理、という意見は、種々のマークアップが混在していることからくる感想なのかもしれないと思います。 \{}$はオリジナルのTeXに沿って使われることが大半なので、どれも構文は緩く似た感じになり、「えー、なんでこんな一貫性がないのー」って感じますよね。 できることに制約がないので、たとえば「○○用のマークアップとかないし、別の表現にするか」という発想にならず、「○○したいだけなのにこんな複雑なことをしなければならないのかくそが」という感想になりやすいという面もあると思います。

文章に対するマークアップとして見た場合、LaTeXのマークアップは別に筋は悪くはないんじゃないですかねえ。 現代的な構造化もできるし、もちろん必要に応じて拡張もできる(←そこがアレ)。 「マークアップ形式拡張のためのAPIを設計するセンス」を養う本とかどこかにないかなあ。

組版エンジンとしてのTeX

一部のアレな人以外、TeXを使う目的は組版でしょう。これについては、あまり批判的な人はいない気がします。 TeXは当初から組版のための要件がかなり高く、しかもそれが一通り実現されています。 さらに、それなりに長い歴史のなかで、本職の組版技術を知る人たちが自分たちの必要とする付加的な要件を本気で実現してきました。 そのため、ほとんどの人にとっては、世界中の多くの言語で実用的なブラックボックスとして機能できていると思います (ふだん使っているTeXが組版についてブラックボックスに見えない人は、マークアップとしての側面と混同しているか、ただの組版のプロでしょう)。

プログラミング言語としてのTeX

なんというか、KnuthはもともとTeXをプログラミング言語として設計するつもりはさらさらなかったんじゃないかなあと思います。 自分の秘書でも使えるようなマークアップを自分で後から定義できるだけの機能を詰め込んだら、必然的にチューリング完全になってしまったというか。 あるいは、組版エンジンとして必要だろうなーと思う機能を作りこんでいて、その機能を外部からつつけるようにしたら、必然的にチューリング完全になってしまったというか。 とにかく、プログラミング言語としてのTeXにまともな設計思想はない気がするし、プログラミング言語として使いやすくする開発とかもされてこなかった。 なので使いづらいのは当然だし、使いづらさを楽しむのもまた一興かもしれません。 そもそもこれだけの機能がなかったら、後に続く人たちが「自分たちも仕事で使える」ものに魔改造できなかっただろうし(←その結果がアレ)。

とはいえ、そうも言ってられないという人たちは一定数いて、その先鋒がLaTeX3プロジェクトです。 それこそもう10年以上の歴史があるけど、過去のTeX資産を壊さないように慎重に開発が進められているので、いつになってもLaTeX3は完成しません(←だからアレ)。

とはいえ、LaTeX3のうちプログラミング言語として利用できる部分については現在のLaTeX2eでも使える状態にあります(expl3という)。 使いやすいかどうかはともかく、名前空間が実現できたり、関数っぽいものが定義できたり、プログラミング言語としてはふつうになってると思います。 次の10年に期待ですね(それまで選択肢がTeXしかないのも微妙だけど)。