書籍向け汎用マークアップのあり方―re:viewの開発を通して
DESCRIPTION
TeXユーザーの集い2014 発表資料TRANSCRIPT
書籍向け汎用マークアップのあり方書籍向け汎用マークアップのあり方————Re:VIEWRe:VIEWの開発を通しての開発を通して
武藤 健志武藤 健志@@kmutokmuto
Re:VIEW(りびゅー)● マークアップ処理系● 保守と開発を続けています
Abstractの誤りのおわび
ツッコミ1 (@takahashimさんより)そういえばReVIEWの元になったのはRDocではなくRDなような(両者は別物)
ツッコミ2 (@mineroaokiさんより)こっそり言うけど......実は「り/びゅー」って発音するのアレ
定義
マークアップ(markup)– ①【印刷】組版される原稿に書き込まれた、活字
書体・ページ割付けなどについての指示。②【電算】テキスト中の特定の部分に、その属性を示す標識を付加すること、またその標識。
(『リーダーズ+プラス』研究社)
● 「タグ」と呼ぶことも
業務● 某制作プロダクション会社 勤務
– 出版社からの委託を受けて、書籍を制作(技術書、実用書、資格試験、マニュアル、…)
– 編集、紙面デザイン、組版(DTP)
– 原稿を受けて印刷所にお渡し(入稿)するまで
※翻訳、執筆、校正、カバーデザイン、教育、 カタログ制作、人材派遣等もございます!
入るもの、出るもの● 入力
– 原稿。フォーマットは不定(Word, 一太郎, プレインテキスト, Markdown, TeX, PowerPoint, Excel, ...)
– 要望は出すが判断の権限は当社にはない
– 整理して紙面デザインにはめ込み、売り物として通用するレベルに引き上げることがミッション
入るもの、出るもの● 出力
– 紙実際の印刷所入稿物はPDFが主流
– 出版社から最近はEPUBの要求も
● 紙面デザイン等を最終決定するのは出版社か著者– 意見は出すが判断の権限は当社にはない
組版ソフトウェアの比較● 求められるのは、紙出力を主要ターゲットと
したマークアップ● マークアップを実際に処理する、組版ソフト
の特性を把握する● (ものすごく大雑把に)TeX(LaTeX)とAdobe InDesign を比較してみる
TeX● 本当によくできてる
– 思想、設計、できあがる紙面の美しさ、……
● 比較的単純なマークアップ● テキスト形式で処理系の互換性が保持
– フリーソフトウェア
● バッチ最高!– 自動採番、相互参照、……
TeX● 紙面デザインがかなりツライ
– スタイル作成に要プログラミング
– デザインを最終決定できない立場だと、大変/困難な要求に悩まされる
● 記法やマクロ使用の裁量が大きすぎて注意しないと著者以外が整理しづらくなる– 意味のマークアップと紙面調整のマークアップが混在しがち
TeX● 紙面化機能がリッチすぎて他形式
(EPUBなど)に変換しづらい● 指定の入稿形式にするのがけっこうたいへん
– X-1aなどdvipdfmxで作れない
– そもそもAdobeソフトからじゃないと難色を示される
InDesign● 組版界のデファクトスタンダード
– Adobeの有償製品
– 印刷所への入稿も安全
● GUIで紙面デザイン、割り付け– デザイナーの自由な発想を阻害しない
– 教育コスト低い
● XML入力機能あり– 過度の期待はしてはならないが活用できる
InDesign● バージョン間のデータの互換性は保証なし
– バージョンアップは実質強制販売終了、新OSで正常に動かない、……
– 「コンテンツのほうがアプリケーションより寿命が長い」のに私企業に命運を委ねるのは避けたい
● EPUB出力機能はあるが(特にリフロー型は)現状実務に耐えない
● バッチ的な機能は少しあるけどいろいろ残念実装
Re:VIEW● そんな背景で...
– 自分の執筆活動に使いやすい
– お仕事の入出力の課題解決に役立つ
を実現してくれそうなRe:VIEWの開発に参画
Re:VIEWとは● 書籍制作にフォーカスした汎用マークアップの仕様およびその処理系
● 簡易マークアップを付与したコンテンツを、– HTML
– LaTeX
– XML(for InDesign)
などに変換
Re:VIEWとは● ワンコマンドでEPUB化
– review-epubmaker
– 書籍全体のHTMLファイルを作成し、メタ情報を付けてパッキング
● ワンコマンドで簡易PDF化– review-pdfmaker
– 書籍全体のLaTeXファイルを作成し、LaTeXコンパイラとdvipdfmxに渡してPDF作成
Re:VIEWとは● InDesignとの組み合わせ
– InDesignが受け取りやすいXMLに変換(Re:VIEWの担当はここまで)
– 書籍のテンプレート、スタイルに適したカスタムXML整形
– InDesign上のカスタムJavaScriptで自動組版
● TeXにはかなわないがイテレーティブに制作– 必要に応じてRe:VIEW原稿から組み直す
開発体制● 青木峰郎(@mineroaki)氏が2002年から
自分の執筆環境として開発● 2008年より武藤(@kmuto)が参加
– より汎用的な書籍で使えるように機能拡張
– InDesignと連携した自動組版システム開発
– 2009年から開発リードを引き継ぎ、保守・開発・拡張
開発体制● 高橋征義(@takahashim)氏、角征典(@kdmsnr)氏がコミッタに参加
● GitHubに開発リポジトリを移行– https://github.com/kmuto/review
– より広いユーザーやコントリビュータを獲得
● 先月にバージョン1.4.0をリリース● GNU General Public License Version 2.1
に基づくフリーソフトウェア
Re:VIEWヒストリー2014/10 1.4.0をリリース
2014/3 プロダクト名を「Re:VIEW」に変更
2013/3 GitHubがMarkdown拡張記法(GFM)をサポート。一躍Markdownに注目が集まる
2010/6 Ruby gemでの最初のリリース(0.6.0)
2010/1 プライベートSubversionリポジトリからGitHubへ移行
2008/5 ReVIEW+InDesignによる最初の書籍『独習Java 第4版』を刊行
2008/1 武藤健志が開発に参加
2004/3 Markdownの最初のリリース
2002 青木峰郎氏がReVIEW設計
1999/10 EWB 3.1が公開
1980年代 TeX, LaTeXが公開
Re:VIEWヒストリー2014/10 1.4.0をリリース
2014/3 プロダクト名を「Re:VIEW」に変更
2013/3 GitHubがMarkdown拡張記法(GFM)をサポート。一躍Markdownに注目が集まる
2010/6 Ruby gemでの最初のリリース(0.6.0)
2010/1 プライベートSubversionリポジトリからGitHubへ移行
2008/5 ReVIEW+InDesignによる最初の書籍『独習Java 第4版』を刊行
2008/1 武藤健志が開発に参加
2004/3 Markdownの最初のリリース
2002 青木峰郎氏がReVIEW設計
1999/10 EWB 3.1が公開
1980年代 TeX, LaTeXが公開
「まーたMarkdownのパチモンかよ」という批判は心外です!
績んできたもの● プライベートでも業務でも大いに利用
– 執筆、編集、InDesign組版
– 各社商業書籍 50冊超を刊行
● 達人出版会の基本フォーマットの1つ● TeX組版を気軽に利用できることから技術系同人誌で注目● オライリー・ジャパン、インプレス等の出版社でも
原稿・電子書籍向け記法の1つとして採用– https://github.com/kmuto/review/wiki/利用実績
根底の思想● 著者にとっての書きやすさ● 編集者にとっての編集のしやすさ● 組版システムにとっての変換結果の素直さ
● マークアップの存在が創造的思考活動をできるだけ阻害しない
Re:VIEWマークアップ概要● 基本段落
– 空行区切りで1段落(TeXと同様)
● インラインマークアップ(段落内)– @<cmd>{value}– 書体等
● ブロックマークアップ(複数段落を囲む)– //environment[param1][param2]...{paragraphs...//}
– 囲み記事、コードリスト、図表等
Re:VIEWマークアップ概要● 1行マークアップ
– 見出し: = chapter == section …
– 箇条書き: ␣*␣itemize ␣1.␣enumerate
␣:␣description
● コメントマークアップ– #@# comments...
独断と偏見のマークアップ比較
Web志向 紙志向
機械に優しいマークアップ
人間に優しいマークアップ
HTML
XML
Re:VIEW
Markdown
SGML
LaTeX
reST
Wiki
EWB
陰か陽か● マークアップ記法の選択に思想● Markdown:
– “...Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions.”(http://daringfireball.net/projects/markdown/)
– できるかぎりのマークアップ暗黙派
陰か陽か● LaTeX:
– おおむね明示派
– _や^、~、$などの暗黙マークアップが若干混在
● HTML/XML:– 完全明示派
– 開始と終了のマークアップで対象を囲む
陰か陽か● Re:VIEW:
– おおむね明示派
– 例外は行頭文字による1行マークアップただし、目視したときにそれがマークアップであることは明らか
– 「思考を阻害しない書きやすさ」とのバランスをとる
陰か陽か● 個人的見解では……
– 暗黙のマークアップは地の文との区別がつけづらく、編集作業などで混乱しやすい
– 開始/終了の明示は機械的処理には好都合。が、執筆や編集作業では冗長で可読性に難
制約か拡張か● マークアップの種類が多いと変換の負担に
– DocBook XML
● マークアップと見栄えを強く束縛すると、調整マクロや拡張パッケージで収拾困難に– TeX
● 設計で制約をかけすぎると拡張亜流だらけに– Markdown
制約か拡張か(Re:VIEWの解)● 標準提供のマークアップの数をむやみに増やさない– マークアップは固定して、書籍ごとの
スタイルシートで見栄えの変化を切り替える
● 必要なときには簡単に追加拡張できる– 「モンキーパッチ」の受け入れ
– シンプルな実装
回避● エスケープ
– マークアップ文字を地の文として使うときの例外措置
– 「\」(バックスラッシュ、または円記号)HTML/XMLでは実体参照記法を使用(&...;)
● 文中でエスケープを多用すると思考の妨げ
回避● LaTeX: #, $, %, &, _, {, }, \, ^, ~, <, >, |● Markdown: \, `, *, _, {, }, [, ], (, ), #, +, -, ., !● HTML/XML: <, >, &● Re:VIEW: } (インラインマークアップ内),
](ブロックマークアップ引数内)
– @<tt>{function() {\}}– @<m>{\frac{1\}{2\}}
「見えざるもの」の表現● コメント重要
– 最終成果物には含めない(× HTMLコメント)
– 思考過程の表現
– 翻訳の原文
– 履歴保持
– 調査記録、メモ
– 日記、愚痴、ポエム
「見えざるもの」の表現● 記述容易
– エスケープを考慮不要
● 視認容易– インラインコメントをマークアップで用意するの
は個人的に否定的
● #@# comments...(EOL)
マークアップを殺すもの● 入れ子
– インラインマークアップの入れ子、ブロックマークアップの入れ子
– 箇条書きのぶら下がり段落、番号箇条書きを分断する図表
– ...
● 構文解析器(パーザ)の頑張り+記法次第– HTML/XML, TeXは開始/終了が明確で入れ子許容
– Re:VIEWは現時点では単純な正規表現判定
マークアップを殺すもの● 表
– 全マークアップが泣いた……
– 日本社会はテーブルを愛しすぎる:セル結合、色分け、セル内複数段落、セル内箇条書き、表中表、斜線、etc...
マークアップを殺すもの● Re:VIEW: タブ区切りの単純行列テーブル
– セル結合や色分け等は後処理命令を入れ、変換後のカスタム処理ツールに委託
● Markdown: アスキーアートテーブル– 拡張表現。セル結合も可能。後からの修正に難
● TeX: &区切り+処理マークアップ– 表現の自由度は高い。読みやすくはない
マークアップを殺すもの● HTML: 行列マークアップ
– ブラウザが奮闘していると言えるが、比較的わかりやすく、ほとんどのHTMLエディタにGUIも用意されている
● XML: CALSまたはAdobeTable– CALSは冗長でGUIツールを要する(および
InDesignでは実用に耐えない)
– AdobeTableは奇妙で扱いづらい
まとめ● TeXよくできてる、すごい● みなさんTeXを使いましょう
まとめ● マークアップごとに思想あり
– そこに優劣があるわけではない
● Re:VIEWが志向するのは– 著者にとっての書きやすさ
– 書籍制作全体での作業のしやすさ
● Re:VIEW、使ってみませんか– https://github.com/kmuto/review
Happy Re:VIEWing!