SlideShare a Scribd company logo
1 of 41
Download to read offline
書籍向け汎用マークアップのあり方
————RRee::VVIIEEWWの開発を通して
武藤 健志
@kkmmuuttoo
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へ移行 
「まーたMarkdownのパチモンかよ」という批判は心外です! 
2008/5 ReVIEW+InDesignによる最初 
の書籍『独習Java 第4版』を刊行 
2008/1 武藤健志が開発に参加 
2004/3 Markdownの最初のリリース 
2002 青木峰郎氏がReVIEW設計 
1999/10 EWB 3.1が公開 
1980年代TeX, LaTeXが公開
績んできたもの 
● プライベートでも業務でも大いに利用 
– 執筆、編集、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...
独断と偏見のマークアップ比較 
機械に優しいマークアップ 
HTML 
XML 
Web志向紙志向 
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!

More Related Content

What's hot

ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善増田 亨
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるpospome
 
TDD のこころ
TDD のこころTDD のこころ
TDD のこころTakuto Wada
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMPYusuke Kagata
 
「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)
「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)
「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)Yoshikazu GOTO
 
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門masayoshi takahashi
 
RedmineのFAQとアンチパターン集
RedmineのFAQとアンチパターン集RedmineのFAQとアンチパターン集
RedmineのFAQとアンチパターン集akipii Oga
 
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース増田 亨
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビューTakafumi ONAKA
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?Yoshitaka Kawashima
 
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Springドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring増田 亨
 
雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニングyoku0825
 
ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版Tokoroten Nakayama
 
オススメの標準・準標準パッケージ20選
オススメの標準・準標準パッケージ20選オススメの標準・準標準パッケージ20選
オススメの標準・準標準パッケージ20選Takuya Ueda
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術Takuto Wada
 
プロダクトづくりのためのソフトウェア設計スタイル
プロダクトづくりのためのソフトウェア設計スタイルプロダクトづくりのためのソフトウェア設計スタイル
プロダクトづくりのためのソフトウェア設計スタイル増田 亨
 

What's hot (20)

ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
 
TDD のこころ
TDD のこころTDD のこころ
TDD のこころ
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMP
 
「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)
「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)
「DNS浸透いうな」と言うけれど… (#ssmjp 2018/07)
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
 
はじめてのPRD
はじめてのPRDはじめてのPRD
はじめてのPRD
 
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
 
RedmineのFAQとアンチパターン集
RedmineのFAQとアンチパターン集RedmineのFAQとアンチパターン集
RedmineのFAQとアンチパターン集
 
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
 
Paxos
PaxosPaxos
Paxos
 
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Springドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring
 
雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング
 
ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版
 
Oss貢献超入門
Oss貢献超入門Oss貢献超入門
Oss貢献超入門
 
オススメの標準・準標準パッケージ20選
オススメの標準・準標準パッケージ20選オススメの標準・準標準パッケージ20選
オススメの標準・準標準パッケージ20選
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
 
プロダクトづくりのためのソフトウェア設計スタイル
プロダクトづくりのためのソフトウェア設計スタイルプロダクトづくりのためのソフトウェア設計スタイル
プロダクトづくりのためのソフトウェア設計スタイル
 

Viewers also liked

こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールdcubeio
 
今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門Masahito Zembutsu
 
書籍制作でReVIEWを使う実践ワークフロー
書籍制作でReVIEWを使う実践ワークフロー書籍制作でReVIEWを使う実践ワークフロー
書籍制作でReVIEWを使う実践ワークフローMasahiro Hidaka
 
ドキュメントシステムはこれを使え2015年版
ドキュメントシステムはこれを使え2015年版ドキュメントシステムはこれを使え2015年版
ドキュメントシステムはこれを使え2015年版Keiichiro Shikano
 
ドキュメントを作りたくなってしまう魔法のツールSphinx
ドキュメントを作りたくなってしまう魔法のツールSphinxドキュメントを作りたくなってしまう魔法のツールSphinx
ドキュメントを作りたくなってしまう魔法のツールSphinxTakayuki Shimizukawa
 

Viewers also liked (6)

こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
 
今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門
 
Docker Swarm入門
Docker Swarm入門Docker Swarm入門
Docker Swarm入門
 
書籍制作でReVIEWを使う実践ワークフロー
書籍制作でReVIEWを使う実践ワークフロー書籍制作でReVIEWを使う実践ワークフロー
書籍制作でReVIEWを使う実践ワークフロー
 
ドキュメントシステムはこれを使え2015年版
ドキュメントシステムはこれを使え2015年版ドキュメントシステムはこれを使え2015年版
ドキュメントシステムはこれを使え2015年版
 
ドキュメントを作りたくなってしまう魔法のツールSphinx
ドキュメントを作りたくなってしまう魔法のツールSphinxドキュメントを作りたくなってしまう魔法のツールSphinx
ドキュメントを作りたくなってしまう魔法のツールSphinx
 

Similar to 書籍向け汎用マークアップのあり方―Re:VIEWの開発を通して

効率10倍UP 秀丸IDE化法
効率10倍UP 秀丸IDE化法効率10倍UP 秀丸IDE化法
効率10倍UP 秀丸IDE化法将 高野
 
XPages開発におけるGit/GitHubの利用
XPages開発におけるGit/GitHubの利用XPages開発におけるGit/GitHubの利用
XPages開発におけるGit/GitHubの利用賢次 海老原
 
マークアップ言語の拡張 メリットとデメリット #hankumi
マークアップ言語の拡張 メリットとデメリット #hankumiマークアップ言語の拡張 メリットとデメリット #hankumi
マークアップ言語の拡張 メリットとデメリット #hankumiTakeshi Komiya
 
Ignite 2021秋 recap - 開発者向け新機能紹介
Ignite 2021秋 recap - 開発者向け新機能紹介Ignite 2021秋 recap - 開発者向け新機能紹介
Ignite 2021秋 recap - 開発者向け新機能紹介Kazushi Kamegawa
 
Polyglot Persistence and Graph Schema
Polyglot Persistence and Graph SchemaPolyglot Persistence and Graph Schema
Polyglot Persistence and Graph SchemaTakao Tetsuro
 
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)Colin Charles
 
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践日本マイクロソフト株式会社
 
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計Tadayoshi Sato
 
Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?Masahito Zembutsu
 
OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理Tadashi Miyazato
 
VCS - Version Control System at Security and Programming camp 2011
VCS - Version Control System at Security and Programming camp 2011 VCS - Version Control System at Security and Programming camp 2011
VCS - Version Control System at Security and Programming camp 2011 Hiro Yoshioka
 
運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み
運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み
運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み慎一 古賀
 
『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps 『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps Google Cloud Platform - Japan
 
HTML5コーディング環境を Dreamweaverで構築する
HTML5コーディング環境を Dreamweaverで構築するHTML5コーディング環境を Dreamweaverで構築する
HTML5コーディング環境を Dreamweaverで構築するAkira Maruyama
 
Programming camp 2008, Codereading
Programming camp 2008, CodereadingProgramming camp 2008, Codereading
Programming camp 2008, CodereadingHiro Yoshioka
 
プロダクトにおけるScala
プロダクトにおけるScalaプロダクトにおけるScala
プロダクトにおけるScalaYuto Suzuki
 
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-Hiroki Kondo
 
パフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したいパフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したいzaru sakuraba
 

Similar to 書籍向け汎用マークアップのあり方―Re:VIEWの開発を通して (20)

効率10倍UP 秀丸IDE化法
効率10倍UP 秀丸IDE化法効率10倍UP 秀丸IDE化法
効率10倍UP 秀丸IDE化法
 
XPages開発におけるGit/GitHubの利用
XPages開発におけるGit/GitHubの利用XPages開発におけるGit/GitHubの利用
XPages開発におけるGit/GitHubの利用
 
P4p20120408
P4p20120408P4p20120408
P4p20120408
 
マークアップ言語の拡張 メリットとデメリット #hankumi
マークアップ言語の拡張 メリットとデメリット #hankumiマークアップ言語の拡張 メリットとデメリット #hankumi
マークアップ言語の拡張 メリットとデメリット #hankumi
 
Markdown入門
Markdown入門Markdown入門
Markdown入門
 
Ignite 2021秋 recap - 開発者向け新機能紹介
Ignite 2021秋 recap - 開発者向け新機能紹介Ignite 2021秋 recap - 開発者向け新機能紹介
Ignite 2021秋 recap - 開発者向け新機能紹介
 
Polyglot Persistence and Graph Schema
Polyglot Persistence and Graph SchemaPolyglot Persistence and Graph Schema
Polyglot Persistence and Graph Schema
 
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
Percona ServerをMySQL 5.6と5.7用に作るエンジニアリング(そしてMongoDBのヒント)
 
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
 
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計
 
Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?Docker 17.06 Updates 最近何が変わったの?
Docker 17.06 Updates 最近何が変わったの?
 
OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理OSSを利用したプロジェクト管理
OSSを利用したプロジェクト管理
 
VCS - Version Control System at Security and Programming camp 2011
VCS - Version Control System at Security and Programming camp 2011 VCS - Version Control System at Security and Programming camp 2011
VCS - Version Control System at Security and Programming camp 2011
 
運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み
運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み
運用管理者のための「開発者からみたDevOps」 - Visual Studio 2015 新機能から考える開発者の取り組み
 
『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps 『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
 
HTML5コーディング環境を Dreamweaverで構築する
HTML5コーディング環境を Dreamweaverで構築するHTML5コーディング環境を Dreamweaverで構築する
HTML5コーディング環境を Dreamweaverで構築する
 
Programming camp 2008, Codereading
Programming camp 2008, CodereadingProgramming camp 2008, Codereading
Programming camp 2008, Codereading
 
プロダクトにおけるScala
プロダクトにおけるScalaプロダクトにおけるScala
プロダクトにおけるScala
 
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
 
パフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したいパフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したい
 

More from Kenshi Muto

入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実
入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実
入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実Kenshi Muto
 
スクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出し
スクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出しスクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出し
スクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出しKenshi Muto
 
write once, publish anywhere ……という夢を見た。
write once, publish anywhere ……という夢を見た。write once, publish anywhere ……という夢を見た。
write once, publish anywhere ……という夢を見た。Kenshi Muto
 
スペインExtremadura州Debian i18n会議報告
スペインExtremadura州Debian i18n会議報告スペインExtremadura州Debian i18n会議報告
スペインExtremadura州Debian i18n会議報告Kenshi Muto
 
Rarely Asked Questions
Rarely Asked QuestionsRarely Asked Questions
Rarely Asked QuestionsKenshi Muto
 
オライリー・ジャパンのePUBフォーマットを支える制作システム
オライリー・ジャパンのePUBフォーマットを支える制作システムオライリー・ジャパンのePUBフォーマットを支える制作システム
オライリー・ジャパンのePUBフォーマットを支える制作システムKenshi Muto
 
書籍制作フローを変える「ReVIEW」という解
書籍制作フローを変える「ReVIEW」という解書籍制作フローを変える「ReVIEW」という解
書籍制作フローを変える「ReVIEW」という解Kenshi Muto
 
簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望
簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望
簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望Kenshi Muto
 
商業出版物におけるReVIEW+InDesign組版
商業出版物におけるReVIEW+InDesign組版商業出版物におけるReVIEW+InDesign組版
商業出版物におけるReVIEW+InDesign組版Kenshi Muto
 

More from Kenshi Muto (9)

入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実
入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実
入稿ヨシ、ご安全に! CSS組版による商業書籍制作の理想と現実
 
スクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出し
スクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出しスクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出し
スクリプト作成のためのスクリプト支援 -検索内容の実行コード書き出し
 
write once, publish anywhere ……という夢を見た。
write once, publish anywhere ……という夢を見た。write once, publish anywhere ……という夢を見た。
write once, publish anywhere ……という夢を見た。
 
スペインExtremadura州Debian i18n会議報告
スペインExtremadura州Debian i18n会議報告スペインExtremadura州Debian i18n会議報告
スペインExtremadura州Debian i18n会議報告
 
Rarely Asked Questions
Rarely Asked QuestionsRarely Asked Questions
Rarely Asked Questions
 
オライリー・ジャパンのePUBフォーマットを支える制作システム
オライリー・ジャパンのePUBフォーマットを支える制作システムオライリー・ジャパンのePUBフォーマットを支える制作システム
オライリー・ジャパンのePUBフォーマットを支える制作システム
 
書籍制作フローを変える「ReVIEW」という解
書籍制作フローを変える「ReVIEW」という解書籍制作フローを変える「ReVIEW」という解
書籍制作フローを変える「ReVIEW」という解
 
簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望
簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望
簡易マークアップとAH Formatterによる 商業品質を満たした技術書籍制作フローの展望
 
商業出版物におけるReVIEW+InDesign組版
商業出版物におけるReVIEW+InDesign組版商業出版物におけるReVIEW+InDesign組版
商業出版物におけるReVIEW+InDesign組版
 

Recently uploaded

モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...博三 太田
 
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)Hiroshi Tomioka
 
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)UEHARA, Tetsutaro
 
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdfAWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdfFumieNakayama
 
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdfクラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdfFumieNakayama
 
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NTT DATA Technology & Innovation
 
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?akihisamiyanaga1
 
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineerYuki Kikuchi
 

Recently uploaded (8)

モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
 
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
 
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
 
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdfAWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
 
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdfクラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
 
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
 
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
 
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
 

書籍向け汎用マークアップのあり方―Re:VIEWの開発を通して

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