第 3 章 Re:VIEW の書き方 み込みます。 たとえばサンプルコード foo. rb を読み込む場合、リスト 3.32 のように記述します。 リスト 3.32 コンパイル前の mapfile 記述 //list [sample-code] [ サンプルコード ] { #@mapfile(foo.rb) #@end リスト 3.32 は review-preproc コマンドの処理後にリスト 3.33 のようになります。 Re:VIEW は #@~ の行を PDF や HTML ファイルなどの最終的な成果物には出力せず、 foo. rb の内容だけを出力します。 リスト 3.33 コンパイル後の mapfile 記述 //list[sample-code] [ サンプルコード ] { #@mapfile(foo.rb) puts ” f00 " #@end tabwidth オプション review-preproc コマンドは tabwidth オプションを使うと、プリプロセッサ命令で読 み込むファイルのタブ文字を任意の数のスペースに置換します。 紙面の都合上、 TechBooster ではサンプルコードのインデントは 2 スペースとしていま す。しかし、サンプルコードを最初から 2 スペースのインデントで書くというのはあまり やりたくありません。タブ文字でインデントしておけば原稿に反映する際に自動でインデ ントの文字幅を置換できます。サンプルコードを編集するエデイタ上ではタブ文字を好み の幅で表示しましよう。 tabwidth オプションは --tabwidth=WIDTH という形式で指定します。たとえば、 sam- ple. re に対して review ー prepr 。 c コマンドを実行しタブ文字を 2 スペースに置換するに は、次のようにします。 このオプションが効くのは、あくまでプリプロセッサ命令で読み込むファイルの内容の みです。 mapfile などを使わず list プロック内に直接コードを書いている場合は、 revi $ review—preproc —r ——tabwidth=2 sample. re 36

第 3 章 Re:VIEW の書き方 コメントの内容は、出力に影響しません。 #@# この行はコメントです。 Re:VIEW は、複数行コメントには対応していません。 複数行をコメントとして扱うには、すべての行に純 # を記述する必要があります。 番号なし箇条書き 「番号っき箇条書き」に対応しています。 項目を列挙する際に、箇条書きを利用できます。 Re:VIEW は、「番号なし箇条書き」と 箇条書き * の前後には、半角スペースが必要です。半角スペースがない場合は、 Re:VIEW はそ 現できるようになっていて、 * の数がそのまま深さになります。 * に続けて項目を記述すると箇条書きになります。番号なし箇条書きはツリー構造も表 マリスト 3.10 番号無し箇条書き の行を本文として取り扱います。 ー 2 層目 ・箇条書き * 箇条書き * * 2 層目 * * * 3 層目 * * 2 層目 * 箇条書き リスト 3.10 のマークアップは、次のように出力されます。 番号あり箇条書き ・箇条書き ー 2 層目 * 3 層目 24 v リスト 3.11 番号付き箇条書き ていません。 先頭とピリオドの後に半角スペースが必要です。番号あり箇条書きは、人れ子に対応し 1 . に続いて項目を続けると箇条書きになります。

3.1 記法の紹介 たとえば、 Wikipedia などで使われる Wiki 記法も軽量マークアップ言語です。 文章を記述するための軽量マークアップ言語は Re : VIEW の他にもいくつもあります。 //quote{ マリスト 3.22 コマンドライン ウエプサイトや書籍などから引用した文章を示す構文です。 引用 また、コマンドラインは、本文中からの参照はできません。 Re:VIEW は、コマンドラインの中の改行やスペースをそのまま出力します。 $ git commit —m "first commit" $ git add . gitignore リスト 3.21 のマークアップは、次のように出力されます。 $ git commit —m "first commit" $ git add ・ gitignore //cmd{ リスト 3.21 引用 コマンドラインの人出力などを示す構文です。 コマンドライン 29 らの参照はできません。 Re : VIEW は引用の中の改行やスペースをそのまま出力します。また、引用は本文中か があります。 す。 IT 技術者業界では、他にも Markdown,reStructuredText,Textile といった例 ます。たとえば、 Wikipedia などで使われる Wiki 記法も軽量マークアップ言語で 文章を記述するための軽量マークアップ言語は Re:VIEW の他にもいくつもあり リスト 3.22 のマークアップは次のように出力されます。 IT 技術者業界では、他にも Markdown,reStructuredText ,Texti1e といった例があります。

3.1 記法の紹介 Re:VIEW では、リード文のマークアップは文章のどこにでも置くことができます。し くなります。 このように リード文としてマークアップした内容は、本文に比べて左側の余白が大き いて解説します。 本章では Re:VIEW で執筆をする上でもっとも重要となる Re:VIEW 記法につ かし、基本的には見出し、特に章見出しの直下に置くことを想定しています。 段落と改行 文章と文章の間に空行を挟むと、それぞれが個別の段落として処理されます。 2 つ以上空行を人れても段落分けには影響しません。 また、 Re:VIEW では、空行を挟まない改行は無視され、出力には影響しません。 1 つ 以上の半角スペースも、出力には影響しません。 @ < br > { } を使うと、強制的に 改行 できます。 sections 擘 Re : VIEW 記法の段落は、空行を挟んで文章を続けます。 2 つ以上空行を入れても段落分けには影響しません。 また、 Re:VIEW では、 空行を挟まない改行は無視され、出力には影響しません。 は影響しません。 @く br > { } を使うと、強制的に@く br > { } 改行@く br > { } できます。 コメント 1 つ以上の半角スペースも、出力に 行が #@# から始まる場合、その行についてはコメントとして扱われ、最終出力には影響 しません。 Re:VIEW は、複数行コメントには対応していません。複数行をコメントとして扱うに は、すべての行に #@# を含める必要があります。 comments ツ 23

第 3 章 Re:VIEW の書き方 インライン命令 インライン命令は @く命令 > {... } のように、 @ ( アットマーク ) に続けて括弧 < > 内に 命令名を指定します。続く括弧 { } の中が、インライン命令の効果が及ぶ範囲になります。 インライン命令は、文章の装飾やリストや図の参照など表示や内容に影響します。文中 に直接記人することができますが、改行をまたぐことはできません。 / / 命令 { マリスト 3.2 プロック命令 プロック命令 プロック命令はリスト 3.2 のように、スラッシュ 2 つ ( / / ) に続けて命令名を指定しま す。続く括弧 { から、次の / / } までが、プロック命令の効果が及ぶ範囲になります。 プロック命令はリストや図など本文とは独立した内容を掲載する際に使います。 / / 命令 [ オプション 1 ] [ オプション 2 ] [ オプション 3 ] { V リスト 3.3 プロック命令 指定可能なオプションの数や省略の可否は、命令によって違います。 に続けて括弧 [ ] の中に記述します ( リスト 3.3 ) 。 プロック命令には複数のオプションを指定できる場合があります。オプションは、命令 20 リスト 3.4 キャプションと対応 の 5 段階に対応します ( リスト 3.4 ) 。 = の数によって見出しの深さが変わります。数に応じてそれぞれ章、節、項、段、小段 = は、必ず行頭から開始します。また、 = の後ろには、必ず半角スペースを入れます。 見出しは、 = から始めて、キャプションを続けます。 見出し 行をプロック命令として扱いません。 は、必ず行頭に記述します。行頭に半角スペースなどが人った場合、 Re:VIEW は、その プロック命令を文の途中から開始することはできません。プロック命令の開始と終了

3.1 記法の紹介 1 . 番号つき箇条書き 2. 番号つき箇条書き 3. 番号つき箇条書き 3. 番号っき箇条書き 2. 番号っき箇条書き 1. 番号っき箇条書き リスト 3.11 のマークアップは、次のように出力されます。 また番号部分の連番を誤った場合でも自動的に連番に置き換わります。 リスト 3.12 番号付き箇条書き リスト 3.12 のマークアップは、次のように出力されます。 2. 番号つき箇条書き 2. 番号つき箇条書き 1 . 番号つき箇条書き 3. 番号っき箇条書き 2. 番号っき箇条書き 1. 番号っき箇条書き 25 連番つきリストにすると Re:VIEW は、リストごとに一意な番号を割り振ります。 種類があります。 Re:VIEW のリストには、連番付きと連番無しの 2 種類、行番号の有無を含めると計 4 どはそのまま出力する必要があります。このような場合にリストは有用です。 本文には影響しません。しかし、プログラムなどを掲載したい場合、改行やインデントな 「段落と改行」で述べたとおり、 Re : VIEW では本文中の複数の半角スペースや改行は、 の中の改行やスペースはそのまま出力されます。 プログラムコードなど、本文とは分けて掲載する内容を「リスト」と言います。リスト リスト ることで、組版や校正時のミスを予防できます。 時に文書上の項番が中途半端に振られていると、ミスの原因となるからです。これを避け は、可能な限り番号を書き換えることをお勧めします。本文中で 3 番は ~ などと言及した このように、番号部分は自動的に連番に置き換わります。しかし、行の追加や削除の際

第 7 章役に立つ豆知識 古い生成ファイルを消す ( 消さないとエラーになる場合がある ) 最低限必要なのは次のコマンドと同様の動作です。 rm -rf artic1es/C89—FirstStepReVIEW-v2-pdf/ \ articles/* . pdf \ articles/* . epub \ articles/* . tml \ articles/* . xml \ articles/* . txt それぞれ、 pdf 、 epub 、 html 、 idgxml (Adobe InDesign 用 XML) 、 text 生成時に作成され る一時ファイルまたは最終出力ファイルです。一番最初の行の C89-FirstStepReVIEW- v2-pdf 部分は articles/config. yml の bookname の設定により変化します。特に、最初の 行は必ず行わないと PDF を生成しようとした時にエラーになるので PDF 生成処理前に は必ず消すようにします。 ・ review-preproc コマンドを実行する 最低限必要なのは次のコマンドの実行です。 # articles ディレクトリ内で実行する想定 $ review—preproc ーて——tabwidth=2 * . re review-preproc コマンドは Re:VIEW の仕組みの中で、もっとも便利な、愛すべきコ マンドといえます。 review-preproc コマンドは文書中に埋め込まれた pragma を処理し、 サンプルコードを文書中に展開したり指定のコマンドの実行結果を文書中に展開してくれ たりします。 C 言語のマクロとだいたい同じものだと思えばよいでしよう。 文書にソースコードを貼りこむ時、インデントは 2 スペースとします。このため、 4 ス ペース派の人はサンプルコードではタブを使うようにして、エデイタ上では 1 タブ = 4 ス ペースで作業し、文書中に貼りこむ時にタブを 2 スペースに変換するとよいでしよう。 詳細は第 3 章「 Re:VIEW の書き方」に譲ります。 各ターゲット向けのビルド用コマンドを実行する 最低限必要なのは次のコマンドの実行です。 # 全て、 articles ディレクトリ内で実行する想定 # text の生成 $ review—compile ー a11 ¯target=text 68

第 6 章ワークフロー 文体の統一 ・文章中の記号は全角が基本 ( 特にカッコ ) 思いますなど感想にならないようにする ですます調と、である調を混在しない ・体言止め、話し言葉は利用しない ネガテイプな表現を利用しない 段階で変更しています。 文体は著者の味となるため過剰な編集は好みませんが、それでも次のような表現は編集 62 * 7 https : //github. com/vvakame/prh TechBooster では原稿をみんなが書き終えた後、羊 (@mhidaka 、サークル主催 ) くん ためにはこのような書き換え処理をたくさんこなす必要があるわけです。 一般的な表現を用いることで文章を読みやすくする効果があります。文章の質を高める 「開く」操作といいます。 と書いた時に「たとえば」に置き換えるよう促してくれます。これを漢字をひらがなに prh は単純にルールに従い、文字列を置き換えるだけのものです。たとえば、「例えば」 read で 1 単語だから略したら ph だろ ! とか言ってはいけません。 校正支援用ツールとして pr に 7 があります。 prh は proofread helper の略です。 proof- 6-5 校正支援ツール prh を導入する 全角カッコを利用するようにしてください。 とくに半角カッコはフォントの高さが全角文字と異なるため、沈んだ印象を受けます。 ラムのソースコードからの引用はその限りではありません。 す。文章中で表現として使う場合、記号は全角を利用してください。メソッド名、プログ 見た目に影響する話では、半角記号は基本的に英字に合わせてフォントが作られていま 編集時には想定読者になりきって読みやすい文章を追及しましよう。 することができます」という表現であれば簡潔に「 ~ できます」と縮めています。 い程度に調整します。「 ~ だと思います」という文章であれば「です」と編集したり、「 ~ 術書であれば平易な表現を心がけて読者の理解に努める方針のもと、著者の文体を壊さな リットだけでなくメリットも感じてもらえるように表現をポジテイプに改めます。また技 ネガテイプな表現は読者の心証を悪くします。期待して本を読んでいる読者に、デメ ・文章中の英単語は前後にスペースを人れないで空きを詰める

第 6 章ワークフロー 変検プリセット 任意のオプジェクト .8 ⅵ *. プロファイル変宿 上に移動 下に移動 色を置換 削除 オプジェクトタイプ 最小テキストサイズ 最大テキストサイズ 一致条件 出力インテント 任意のカラースペース 任意の RG 日 キャリプし一ションされた RGB De 、・に eRGB 任意の CMYK キャリプレーションされた CMYK Lab グレースケール を . eCMYK キャリプレーションされたグレースケール キャリプレーション済み : フリセットを読み込み トを保存 変強属性 変コマンド : 変検のプロファイル : レンダリングインテント : プロファイ元変換日 、文書のインテントを用 ~ . 日 : 出力インテント : Co ユ t00FOGRA390S0 12647 ・ 2 : 2004 ) ー 0 0 理め込み , カラーを出力インテントに変換プロファイル : 変検のオプション 0 黒を第持 ページを変 0 すべて インキ 出力インテント グし一を CMYK プラックに変更 現在のページ 開始ページ : : 1 OOt Gain 15 % CMYK 原色を第持 終了べージ : 1 う . 図 6.5 キャンセル 色を置換では、 DeviceCMYK を選択する 0 朝カラーを出力インテントに変換フロファイル : 変のオプション 0 黒を第持 ページを変検 0 すべて「 1 現在のページ′、開始ページ : 「 1 インキ : グし一を CMYK プラックに変更 Dot Gain 15 % に一 1 CMYK 原色を第持 終了ページ : 文書のカラー OK 0 ド 直図 6.6 カラーを出力インテントに変換をチェック カラーを出力インテントに変換にチェックをいれて、 Dot Gain 15 % を選択します。 また変換のオプションで黒を維持もチェックします。 この設定で色を置換すると無事、モノクロ化できます。 こまでで本文の人稿データ作 成は完了です。 6.4 紙面構成 本を作るうえで苦労することのひとつに統一感があります。文章が途中で変わっていな いか、主張が変わっていないか、タイトルと内容が変わったり、本の最後のほうで文体が 変わったりするとやはりもったいないなあ、という風になりますよね。 技術書として注意したらよいポイントをいくっか列挙していきます。粒度に差はありま すが、重要だと思う項目からの紹介です。 60