review-retrovert 0.9.7 → 0.9.8

data/testdata/mybook/contents/05-faq.re

@@ -12,7 +12,7 @@
 
 === コンパイルエラーが出たとき
 
-PDFファイル生成時にコンパイルエラーになったときの対処方法について説明します。
+PDFファイル生成時のコンパイルエラーについて、対処方法を説明します。
 
 PDFへのコンパイルは、内部では大きく3つのステージに分かれます。
 
@@ -73,7 +73,7 @@ Starterでは、「@<code>|review-pdfmaker|」や「@<code>|review-epubmaker|」
 
 === 文章中のプログラムコードに背景色をつけたい
 
-「@<code>|@@<nop>{}<code>{...}|」を使って文章中に埋め込んだプログラムコードに、背景色をつけられます。
+「@<code>|@@<nop>{}<code>{...}|」による文章中のプログラムコードに、背景色をつけられます。
 そのためには、「@<file>{config-starter.yml}」で「@<code>|inlinecode_gray: true|」を設定してください。
 
 //list[][ファイル「@<file>{config-starter.yml}」]{
@@ -123,11 +123,11 @@ Starterではプログラム中の長い行が自動的に右端で折り返さ
 
 このような場合、プログラムやターミナルの表示幅をほんの少し広げるだけで、右端まで文字が埋まるようになります。
 
-具体的には、ファイル「@<file>{config-starter.yml}」の中の「@<code>{program_widen: 0.0mm}」や「@<code>{terminal_wide: 0.0mm}」を、たとえば「@<code>{0.3mm}」に設定してください（値は各自で調整してください）。
+具体的には、ファイル「@<file>{config-starter.yml}」の中の「@<code>{program_widen: 0.0mm}」や「@<code>{terminal_widen: 0.0mm}」を、たとえば「@<code>{0.3mm}」に設定してください（値は各自で調整してください）。
 
 //list[][ファイル「config-starter.yml」]{
   ## プログラム（//list）の表示幅をほんの少しだけ広げる。
-  @<del>{program_waiden:   0.0mm}
+  @<del>{program_widen:   0.0mm}
   @<b>{program_widen:   0.3mm}
 
   ## ターミナル（//terminal, //cmd）の表示幅をほんの少しだけ広げる。
@@ -140,11 +140,13 @@ Starterではプログラム中の長い行が自動的に右端で折り返さ
 //image[codeblock_rpadding2][表示幅をほんの少し広げると、右端まで埋まるようになった][scale=0.7]
 
 
-=== 半角文字の幅を全角文字の半分にしたい
+=== 全角文字の幅を半角文字2個分にしたい
 
-英数字の幅が狭いフォントを使うと、半角文字の幅が全角文字の約半分になります（ぴったりにはなりません）。
+「@<code>|//list|」や「@<code>|//terminal|」の第3引数に「@<code>|widecharfit=on|」を指定すると、全角文字の幅が半角文字2文字分になります。
+すべての「@<code>|//list|」や「@<code>|//terminal|」でこのオプションを有効化したい場合は、@<file>{config-starter.yml}の「@<code>|program_default_options:|」や「@<code>|terminal_default_options:|」に、「@<code>|widecharfit: on|」を指定してください。
 
-@<file>{config-starter.yml}で、以下のうち必要なほうを設定してください。
+または英数字の幅が狭いフォントを使うと、半角文字の幅が全角文字の約半分になります（ぴったりにはなりません）。
+@<file>{config-starter.yml}で、次のうち必要なほうを設定してください。
 
 //list[][]{
   ## //list用
@@ -164,7 +166,7 @@ Starterではプログラム中の長い行が自動的に右端で折り返さ
 「@<code>|//terminal|」や「@<code>|//list|」では、小さいフォントで表示するオプションがあります。
 フォントサイズは「@<code>|small|」「@<code>|x-small|」「@<code>|xx-small|」の3つが選べます。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 /@<nop>$$/terminal[][小さいフォントで表示する][@<b>|fontsize=x-small|]{
                               Table "public.customers"
    Column   |  Type   | Nullable |                Default
@@ -213,7 +215,279 @@ Starterでは等幅フォントを複数の中から選べます。
 
 
 
-== その他
+== 画像
+
+
+=== PDFとHTMLとで画像の表示サイズを変えたい
+
+Re:VIEWやStarterでは、PDFとHTMLとで画像の表示サイズを別々に指定できます。
+たとえば次のサンプルでは、PDF (@<LaTeX>{})では本文幅いっぱい、HTMLでは本文幅の半分の大きさで画像を表示します。
+
+//list[][サンプル][]{
+/@<nop>$$/image[dummy-image][表示幅を変える][@<b>|latex::scale=1.0,html::scale=0.5|]
+//}
+
+//sampleoutputbegin[表示結果]
+
+//image[dummy-image][表示幅を変える][latex::scale=1.0,html::scale=0.5]
+
+//sampleoutputend
+
+
+
+なお「@<code>|latex::xxx|」や「@<code>|html::xxx|」のような指定方法は、他のオプションやコマンドでも使えます。
+
+
+=== 印刷用PDFと電子用PDFとで異なる解像度の画像を使いたい
+
+印刷用PDFでは解像度の高い画像を使いたい、けど電子用PDFでは画像の解像度を低くしてデータサイズを小さくしたい、という場合は、「@<file>{images/}」フォルダごと切り替えるのがいいでしょう。
+具体的には次のようにします。
+
+//terminal[][高解像度と低解像度の画像を切り替える（macOSまたはLinuxの場合）]{
+### 事前準備
+$ mkdir images_highres  @<balloon>{解像度の高い画像用のフォルダを作る(印刷用)}
+$ mkdir images_lowhres  @<balloon>{解像度の低い画像用のフォルダを作る(電子用)}
+$ mv images images.bkup @<balloon>{既存のimagesフォルダを削除するか別名にする}
+
+### 解像度の高い画像に切り替えて印刷用PDFを生成
+$ rm -f images                  @<balloon>{シンボリックリンクを消す}
+$ ln -s images_highres images   @<balloon>{シンボリックリンクを作る}
+$ rake pdf t=pbook              @<balloon>{印刷用PDFを生成する}
+
+### 解像度の低い画像に切り替えて電子用PDFを作成
+$ rm -f images                  @<balloon>{シンボリックリンクを消す}
+$ ln -s images_lowres images    @<balloon>{シンボリックリンクを作る}
+$ rake pdf t=ebook              @<balloon>{電子用PDFを生成する}
+//}
+
+切り替え作業が面倒なら、独自のRakeタスクを作成するといいでしょう。
+「@<file>{lib/tasks/mytasks.rake}」に次のようなタスクを追加してください。
+
+//list[][@<file>{lib/tasks/mytasks.rake}]{
+desc "印刷用PDFを生成"
+task :pbook do
+  rm_f 'images'
+  ln_s 'images_highres', 'images'
+  sh "rake pdf t=pbook"
+  #sh "rake docker:pdf t=pbook"
+end
+
+desc "電子用PDFを生成"
+task :ebook do
+  rm_f 'images'
+  ln_s 'images_rowres', 'images'
+  sh "rake pdf t=ebook"
+  #sh "rake docker:pdf t=ebook"
+end
+//}
+
+これにより、「@<code>|rake pbook|」で高解像度の画像を使って印刷用PDFが生成され、また「@<code>|rake ebook|」で低解像度の画像を使って電子用PDFが生成されます。
+
+
+=== 画像の解像度はどのくらいにすればいいか
+
+画像の「解像度」(Resolution)とは、簡単にいえば画像の「きめ細かさ」です。
+解像度が高い（＝きめ細かい）ほど画像のドットやギザギザがなくなり、解像度が低いほど画像のドットやギザギザが目立ちます。
+
+解像度は「dpi」(dot per inch)という単位で表します。
+この値が大きいほどきめ細かく、低いほど粗くなります。
+望ましい解像度は用途によって異なります。
+大雑把には次のように覚えておくといいでしょう。
+
+ * 安いWindowsノートPCで表示するなら、72dpiで十分
+ * MacbookのRetinaディスプレイできれいに表示するなら、144dpiが必要
+ * 高級スマートフォンできれいに表示するなら、216dpi必要
+ * 商業印刷で使うなら、カラー画像で350dpi、モノクロ画像で600dpi必要
+
+たとえば安いWindowsノートPCでスクリーンショットを撮ると、画像の解像度が72dpiになります。
+これをMacbookやスマートフォンで等倍表示すると、必要な解像度に足りないせいで画像のドットが目立ちます@<fn>{fn-v6uxm}。
+印刷すれば粗さがもっと目立ちます。
+
+//footnote[fn-v6uxm][等倍で表示すると荒い画像でも、大きい画像を縮小して表示すれば粗さは目立たなくなります。解像度の高い画像を用意できない場合は、かわりに大きい画像を用意して印刷時に縮小するといいでしょう。]
+
+では、技術同人誌では画像の解像度をどのくらいにすればいいでしょうか。
+すでに説明したように、商業印刷に使う画像は350dpi以上の解像度が必要だとよく言われます。
+しかし（マンガやイラストの同人誌ではなく）技術系同人誌であれば、そこまで高解像度の画像を用意しなくても大丈夫です。
+
+実際には、Retinaディスプレイや最近のスマートフォンで画像を等倍表示して気にならない解像度であれば、印刷してもあまり気になりません。
+つまり画像の解像度が144dpiであれば、印刷しても問題は少ないし、電子用PDFで使っても350dpiと比べてデータサイズをかなり小さくできます。
+
+印刷用と電子用とで解像度の違う画像を用意するのは面倒なので、画像の解像度を144dpiにして印刷用と電子用とで同じ画像を使うのが簡単かつ妥当な方法でしょう。
+
+
+=== 白黒印刷用のPDFにカラー画像を使っても大丈夫か
+
+白黒印刷用のPDFにカラー画像を使っても、たいていは大丈夫です。
+たとえばカラーのスクリーンショット画像を、わざわざモノクロ画像に変換する必要はありません。
+
+ただし、白黒印刷すれば当然ですがカラーではなくなるので、@<B>{色の違いだけで見分けをつけていたものは白黒印刷すると見分けがつかなくなります}。
+形を変えたり線の種類を変えるなどして、白黒になっても見分けがつくような工夫をしましょう。
+
+また図の一部を赤い丸や四角で囲んでいる場合、白黒印刷すると赤ではなくなるので、たとえば「赤い丸で囲った部分に注目してください」という文章が読者に通じなくなります。
+これもよくある失敗なので気をつけましょう。
+
+
+
+=={sec-nombre} ノンブル
+
+
+=== ノンブルとは
+
+「ノンブル」とは、すべてのページにつけられた通し番号のことです。
+ページ番号と似ていますが、次のような違いがあります。
+
+//desclist[indent=0zw]{
+//desc[通し番号]{
+ * ページ番号は、まえがきや目次では「i, ii, iii, ...」で、本文が始まると「1, 2, 3, ...」とまる。つまり通し番号になっていない。
+ * ノンブルは、まえがきや目次や本文に関係なく「1, 2, 3, ...」と続く通し番号になっている。
+//}
+//desc[用途]{
+ * ページ番号は、読者が目的のページへ素早くアクセスするために必要。
+ * ノンブルは、印刷所がページの印刷順序を間違わないために必要。
+//}
+//desc[表示位置]{
+ * ページ番号は読者のために存在するので、読者からよく見える位置に置く。
+ * ノンブルは印刷所の人だけが見られればよく、読者からは見えないほうがよい。
+//}
+//}
+
+ノンブルは、印刷所へ入稿するときに必要です。
+印刷しないならノンブルは不要であり、電子用PDFにはノンブルはつけません。
+
+ノンブルについてもっと知りたい場合は「ノンブル 同人誌」でGoogle検索すると詳しい情報が見つかります。
+
+
+=== ノンブルを必要とする印刷所
+
+たいていの印刷所では入稿するPDFにノンブルが必要ですが、必要としない印刷所もあります。
+たとえば技術書典でよく利用される印刷所のうち、「日光企画」ではノンブルが必須で、「ねこのしっぽ」では不要（だけどあると望ましい）です。
+主な同人誌向け印刷所の情報を@<table>{tbl-uyzhu}にまとめたので参考にしてください。
+
+//tsize[latex][lcp{81mm}]
+//table[tbl-uyzhu][同人誌向け印刷所ごとのノンブル必要・不要情報][hline=on,fontsize=x-small]{
+印刷所		ノンブル	参考URL
+--------------------
+日光企画	必要	@<href>{http://www.nikko-pc.com/qa/yokuaru-shitsumon.html#3-1}
+ねこのしっぽ	不要	@<href>{https://www.shippo.co.jp/neko/faq_3.shtml#faq_039}
+しまや出版	必要	@<href>{https://www.shimaya.net/howto/data-genkou.html#no}
+栄光		必要	@<href>{https://www.eikou.com/qa/answer/66}
+サンライズ	必要	@<href>{https://www.sunrisep.co.jp/09_genkou/002genko_kiso.html#title-6}
+オレンジ工房	必要	@<href>{https://www.orangekoubou.com/order/question.php#article05}
+太陽出版	必要	@<href>{https://www.taiyoushuppan.co.jp/doujin/howto/nombre.php}
+ポプルス	不要	@<href>{https://www2.popls.co.jp/pop/genkou/q_and_a.html#nombre}
+丸正インキ	必要	@<href>{https://www.marusho-ink.co.jp/howto/nombre.html}
+トム出版	必要	@<href>{https://www.tomshuppan.co.jp/manual/data.html}
+金沢印刷	必要	@<href>{http://www.kanazawa-p.co.jp/howtodata/howtodata_kihon-rule.html}
+ケーナイン	必要	@<href>{https://www.k-k9.jp/data/nomble/}
+booknext	必要	@<href>{https://booknext.ink/guide/making/}
+//}
+
+このように印刷所によって違いますが、@<B>{ノンブル不要の印刷所であってもノンブルをつけるほうが望ましい}です。
+強い理由がないなら、印刷用PDFにはノンブルをつけましょう。
+
+
+==={subsec-addnombre} ノンブルのつけ方
+
+Re:VIEWとStarterのどちらも、印刷用PDFにはノンブルが自動的につきます（電子用にはつきません）。
+Starterでは、印刷用PDFならページの右下隅または左下隅に、グレーの通し番号がついているはずです。
+これがノンブルです。
+
+ノンブルは印刷所の人だけが見られればいいので、読者からは見えにくい位置（見開きの内側）に置かれます。
+このように読者から見えにくい位置に置かれたノンブルを、特に「隠しノンブル」といいます。
+
+またStarterでは、すでに生成済みのPDFに対してあとからノンブルを追加できます。
+たとえば大扉（タイトルページ）や奥付をIllustratorやKeynoteで作成し@<fn>{fn-dv7j2}、それを使って印刷用PDFの大扉や奥付のページを手動で入れ替えるような場合は@<fn>{fn-5eb1s}、入れ替えたページにノンブルがつきません。
+このような場合は、次のような作業手順になります。
+
+//footnote[fn-dv7j2][大扉（タイトルページ）を別のソフトで作成した例が@<secref>{06-bestpractice|subsec-visualtitlepage}にあります。]
+//footnote[fn-5eb1s][昔はこうする必要がありましたが、現在のStarterは大扉と奥付をPDFファイルで用意すればそれを読み込めるので、手動で入れ替える必要はなくなりました。詳しくは@<secref>{04-customize|subsec-coverpdf}を参照してください。]
+
+ - (1) 印刷用PDFをノンブルなしで生成する。
+ - (2) 手動で大扉や奥付のページを入れ替える。
+ - (3) 生成済みの印刷用PDFにノンブルをつける。
+
+ここで(1)印刷用PDFをノンブルなしで生成するには、@<file>{config-starter.yml}で「@<code>|nombre: off|」を設定します。
+また(3)生成済みの印刷用PDFにノンブルをつけるには、ターミナル画面で「@<code>|rake pdf:nombre|」を実行してください。
+
+//terminal[][生成済みの印刷用PDFにノンブルをつける]{
+$ @<userinput>|rake pdf:nombre|          @<balloon>{PDFの全ページにノンブルをつける}
+$ @<userinput>|rake docker:pdf:nombre|   @<balloon>{Dockerを使っている場合はこちら}
+//}
+
+このRakeタスクでは、ノンブルをつけたいPDFファイル名と出力先のPDFファイル名を指定できます。
+たとえば@<file>{mybook.pdf}にノンブルをつけたものを@<file>{mybook_nombre.pdf}として出力するには、次のようにします。
+
+//terminal[][生成済みの印刷用PDFにノンブルをつける]{
+$ @<userinput>|rake pdf:nombre @<b>{file=mybook.pdf} @<b>{out=mybook_nombre.pdf}|
+//}
+
+「@<code>|out=...|」が指定されなければ、「@<code>|file=...|」と同じファイル名が使われます。
+また「@<code>|file=...|」が指定されなければ、「@<code>|rake pdf|」で生成されるPDFファイルの名前が使われます。
+
+なお「@<code>{rake pdf:nombre}」はノンブルをつけるだけであり、再コンパイルはしないので注意してください。
+また「@<href>{https://kauplan.org/pdfoperation/, PDFOperation}」を使っても、PDFファイルにノンブルが簡単につけられます。
+
+//note[ノンブル用フォントの埋め込み]{
+残念ながら、「@<code>{rake pdf:nombre}」でノンブルをつけるとそのフォントがPDFファイルに埋め込まれません（これはPDFファイルを操作しているライブラリの限界によるものです）。
+そのため、印刷所へ入稿するまえにフォントを埋め込む必要があります。
+
+対策方法は@<href>{https://kauplan.org/pdfoperation/}を見てください。
+また印刷用PDFにデフォルトでつくノンブルならこのような問題はありません。
+//}
+
+
+=== ノンブルの調整
+
+印刷所によっては、ノンブルの位置や大きさを指定される場合があります。
+その場合は@<file>{config-starter.yml}の中の、ノンブルに関する設定項目を調整してください。
+なおこの設定は、「@<code>|rake pdf:nombre|」タスクでも使われます。
+
+//needvspace[latex][6zw]
+//list[][@<file>{config-starter.yml}：ノンブルに関する設定項目]{
+  ## ノンブル（1枚目からの通し番号）の設定
+  nombre:               on       @<balloon>{on ならノンブルをつける}
+  nombre_sidemargin:    0.5mm    @<balloon>{ページ左右からのマージン幅}
+  nombre_bottommargin:  2.0mm    @<balloon>{ページ下からのマージン高}
+  nombre_fontcolor:     gray     @<balloon>{'gray' or 'black'}
+  nombre_fontsize:      6pt      @<balloon>{フォントサイズ（6〜8pt）}
+  nombre_startnumber:   1        @<balloon>{ノンブルの開始番号（3から始める流儀もある）}
+//}
+
+
+=== ノンブルの注意点
+
+印刷所への入稿に慣れていないと、ノンブルに関するトラブルを起こしがちです。
+初心者の人は次のような点に注意してください。
+
+ * すでに説明したように、ノンブルは印刷するときに必要であり、印刷しなければ不要です。
+   Starterでは印刷用PDFにのみ自動でノンブルがつきますが、電子用PDFにはつきません。
+ * ノンブルは、表紙と裏表紙には必要ありません。
+   印刷所へ入稿するとき、表紙と裏表紙の入稿は本文とは別に行います。
+   そのため、表紙と裏表紙にはノンブルをつける必要はありませんし、つけてはいけません。
+ * ノンブルは、表紙と裏表紙を除いたすべてのページに必要です。
+   たとえ空白ページであってもノンブルを省略してはいけません。
+ * 別のソフトで作った大扉（タイトルページ）や奥付をPDFに入れた場合は、それらのページにもノンブルをつけることを忘れないでください。
+ * 印刷所からノンブルの位置や大きさの指定がある場合は、それに従ってください。
+   ノンブルの調整方法は@<file>{config-starter.yml}で行えます。
+ * ノンブルは「1」から始めることがほとんどですが、印刷所によっては「3」から始めるよう指示されることがあります。
+   その場合は@<file>{config-starter.yml}に「@<code>|nombre_startnumber: 3|」を設定してください。
+ * ノンブルのフォントがPDFに埋め込まれていることを確認してください。
+   ただし本文のフォントほど重要ではないので、もしノンブルのフォントがうまく埋め込めない場合は、そのままで入稿できないか印刷所に相談してみましょう。
+
+
+
+== @<LaTeX>{}関連
+
+
+=== LuaLaTeXとjlreqを使いたい
+
+Starterでは、LuaLaTeXとjlreq.clsにはまだ対応していません。
+どうしてもこれらが使いたい場合は、Re:VIEWが対応しているのでそちらを使うといいでしょう。
+
+LuaLaTeXは好きなフォントが簡単に使えるという大きな利点がありますが、コンパイルが遅くなるという欠点があります。
+またjlreq.clsはカスタマイズ方法がよく分かっていないので、採用ができません。
+
+これらの採用は今後の課題です。
 
 
 === @<LaTeX>{}のスタイルファイルから環境変数を参照する
@@ -221,7 +495,7 @@ Starterでは等幅フォントを複数の中から選べます。
 Starterでは、名前が「@<em>{STARTER_}」で始まる環境変数を@<LaTeX>{}のスタイルファイルから参照できます。
 
 たとえば「@<code>{STARTER_FOO_BAR}」という環境変数を設定すると、@<code>{sty/mystyle.sty}や@<code>{sty/starter.sty}では「@<code>{\STARTER@FOO@BAR}」という名前で参照できます。
-想像がつくと思いますが、環境変数名の「@<code>{_}」は「@<code>{@}」に変換されます。
+この例で分かるように、環境変数名の「@<code>{_}」は「@<code>{@}」に変換されます。
 
 //terminal[][環境変数を設定する例(macOS, UNIX)]{
 $ @<userinput>{export STARTER_FOO_BAR="foobar"}
@@ -242,6 +516,10 @@ $ @<userinput>{export STARTER_FOO_BAR="foobar"}
 また値の中に「@<code>{$}」や「@<code>{\\}」が入っていてもエスケープはしないので注意してください。
 
 
+
+== その他
+
+
 === 高度なカスタマイズ
 
 設定ファイルや@<LaTeX>{}スタイルファイルでは対応できないようなカスタマイズが必要になることがあります。

data/testdata/mybook/contents/06-bestpractice.re

@@ -30,6 +30,8 @@ Re:VIEWおよびStarterでは、「@<file>{catalog.yml}」の「@<code>|PREDEF:|
 
 次のは「本書の目的」のサンプルです。
 
+//sampleoutputbegin[サンプル]
+
 ===={notoc} 本書の目的
 
 本書の目的は、SQLを初めてさわる初心者が、簡単な検索と集計をSQLでできるようになることです。
@@ -37,10 +39,13 @@ Re:VIEWおよびStarterでは、「@<file>{catalog.yml}」の「@<code>|PREDEF:|
 
 SQLのチューニングや、データベース設計といった内容は、本書の範囲ではありません。
 
+//sampleoutputend
+
 
 === まえがきに「対象読者」を入れる
 
-先ほどの話と似ていますが、「まえがき」に本の対象読者が書かれてあると、本を手にとった人は自分がその本の対象読者かどうか、判断しやすいです。
+先ほどの話と似ていますが、まえがきに「本の対象読者」を書きましょう。
+本を手にとった人が、自分がその本の対象読者かどうか判断できます。
 
 このとき、「初心者」と「初級者」をちゃんと区別するといいでしょう。
 
@@ -49,12 +54,16 @@ SQLのチューニングや、データベース設計といった内容は、
 
 次のは「対象読者」のサンプルです。
 
+//sampleoutputbegin[サンプル]
+
 ===={notoc} 本書の対象読者
 
 本書は、何らかのオブジェクト指向言語の入門書を読み終えた初級者を対象としています。
 そのため、「オブジェクト」「クラス」「メソッド」などの用語は説明なしに使用します。
 まったくの初心者は本書の対象ではないので注意してください。
 
+//sampleoutputend
+
 
 === まえがきに「前提知識」を入れる
 
@@ -66,6 +75,8 @@ SQLのチューニングや、データベース設計といった内容は、
 
 次のは「前提知識」のサンプルです。
 
+//sampleoutputbegin[サンプル]
+
 ===={notoc} 本書の前提知識
 
 本書は、Python をある程度使いこなしている中級者以上を対象にしています。そのため、Pythonの基礎知識を持っていることを前提とします。
@@ -78,6 +89,8 @@ SQLのチューニングや、データベース設計といった内容は、
  * 「@<code>|return|」と「@<code>|yield|」の違いが説明できる
  * 「@<code>|@property|」が何か分かる
 
+//sampleoutputend
+
 
 === まえがきにサポートサイトのURLを載せる
 
@@ -90,6 +103,8 @@ SQLのチューニングや、データベース設計といった内容は、
 
 次のはサポートサイト紹介文のサンプルです。
 
+//sampleoutputbegin[サンプル]
+
 ==== サポートサイト
 
 本書の正誤表は次のサイトに載っています。
@@ -97,6 +112,8 @@ SQLのチューニングや、データベース設計といった内容は、
 
  * @<href>{https://www.example.com/mygreatbook/}
 
+//sampleoutputend
+
 
 === まえがきに謝辞を載せる
 
@@ -113,7 +130,7 @@ SQLのチューニングや、データベース設計といった内容は、
 まえがきに、使用した（または動作検証した）ソフトウェアのバージョンを載せるといいでしょう。
 
 たとえばPythonの2.7なのか3.Xなのかは大きな問題です。
-またLinuxだとCentOSなのかUbuntuなのか、Ubuntuなら18.04なのか20.04なのか、といった情報を、まえがきに書いておきましょう。
+またLinuxだとCentOSなのかUbuntuなのか、Ubuntuなら18.04なのか20.04なのか、といった情報をまえがきに書いておきましょう。
 
 
 === まえがきの章タイトル以外は目次に載せない
@@ -210,14 +227,14 @@ Starterでは節ごとに改ページする設定が用意されています。
 
 == 箇条書き
 
-=== 箇条書きを正しく使い分ける
+==={sec-goodenumerate} 箇条書きを正しく使い分ける
 
 箇条書きには「番号なし」「番号つき」「ラベルつき」の3つがあります。
 
 番号なしの箇条書きは、項目に順序がないか、あっても重要ではない場合に使います。
-たとえば次の例では、公開された順に項目が並んでいますがそこはあまり重要ではなく、項目の順番を入れ替えても文章の意味は成り立つので、番号なしの箇条書きを使います。
+たとえば次の例では、公開された順に項目が並んでいるもののそこはあまり重要ではなく、項目の順番を入れ替えても文章の意味が成り立つので、番号なしの箇条書きを使います。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 スタジオジブリ初期の代表作は次の通りです。
 
  * 風の谷のナウシカ
@@ -240,7 +257,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 番号つきの箇条書きは、手順や順位など、項目の順序が重要な場合に使います。
 たとえば次の例では項目の順序が重要なので、番号つきの箇条書きを使います。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 スタジオジブリ初期の代表作を、好きな順に並べました。
 
  1. 風の谷のナウシカ
@@ -264,9 +281,9 @@ Starterでは節ごとに改ページする設定が用意されています。
 またラベルはあとから参照しやすくするために使い、順番を表すためには使いません。
 そのため、ラベルつきの箇条書きは「番号なし箇条書きにラベルをつけたもの」として使います。
 
-たとえば次の例では、項目の順序は重要ではないので番号なし箇条書きでもいいのですが、あとから項目を参照するのでラベルつき箇条書きにしています。
+たとえば次の例では、項目の順序はさほど重要でないので番号なし箇条書きでもいいのですが、あとから項目を参照するのでラベルつき箇条書きにしています。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 スタジオジブリ初期の代表作は次の通りです。
 
  - (A) 風の谷のナウシカ
@@ -291,7 +308,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 
 
 番号つき箇条書きとラベルつき箇条書きは、きちんと使い分けましょう。
-前者は順序に強い意味がある場合、後者は意味がないか弱い場合に使います。
+前者は順序に強い意味がある場合、後者は順序に意味がないまたは弱い場合に使います。
 
 
 === 箇条書き直後に継続する段落は字下げしない
@@ -301,7 +318,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 次の例を見てください。
 箇条書きの直後に「@<code>|//noindent|」を入れることで、字下げしないようにしています。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 スタジオジブリ初期の代表作には、
 
  * 風の谷のナウシカ
@@ -311,7 +328,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 @<b>|//noindent|
 が挙げられます。
 
-しかしスタジオジブリが発足したのは実はトトロからであり、ナウシカとラピュタは厳密にはスタジオジブリの製作ではないのです。
+しかしスタジオジブリが発足したのは実はラピュタからであり、ナウシカは厳密にはスタジオジブリの制作ではないのです。
 //}
 
 //sampleoutputbegin[表示結果]
@@ -325,7 +342,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 //noindent
 が挙げられます。
 
-しかしスタジオジブリが発足したのは実はトトロからであり、ナウシカとラピュタは厳密にはスタジオジブリの製作ではないのです。
+しかしスタジオジブリが発足したのは実はラピュタからであり、ナウシカは厳密にはスタジオジブリの制作ではないのです。
 
 //sampleoutputend
 
@@ -337,14 +354,14 @@ Starterでは節ごとに改ページする設定が用意されています。
 もっとも、段落の途中に箇条書きを入れること自体がよくありません。
 この例なら、次のように書き換えるといいでしょう。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 スタジオジブリ初期の代表作には、@<b>|次の3つが挙げられます。|
 
  * 風の谷のナウシカ
  * 天空の城ラピュタ
  * となりのトトロ
 
-しかしスタジオジブリが発足したのは実はトトロからであり、ナウシカとラピュタは厳密にはスタジオジブリの製作ではないのです。
+しかしスタジオジブリが発足したのは実はラピュタからであり、ナウシカは厳密にはスタジオジブリの制作ではないのです。
 //}
 
 
@@ -359,7 +376,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 日本語の文章では本文が明朝体の場合、強調箇所は太字にするだけでなく、ゴシック体にするのがよいとされています。
 そのため、強調には「@<code>|@@<nop>{}<b>{...}|」ではなく「@<code>|@@<nop>{}<B>{...}|」または「@<code>|@@<nop>{}<strong>{...}|」を使ってください。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 本文本文@<b>|@@<nop>$$<B>{強調}|本文本文。@@<nop>$$<balloon>{ゴシック体なので望ましい}
 
 本文本文@<b>|@@<nop>$$<b>{太字}|本文本文。@@<nop>$$<balloon>{明朝体のままなので望ましくない}
@@ -380,7 +397,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 
 傍点とは@<bou>{このように}文章の上についた小さな点のことであり、Re:VIEWやStarterなら「@<code>|@@<nop>{}<bou>{...}|」でつけられます。
 
-傍点は強調とよく似ていますが、強調は「重要な箇所」を表すのに対し、傍点は「重要ではないけど他と区別したい、注意を向けたい」という用途で使います。
+傍点は強調とよく似ていますが、強調は「重要な箇所」を表すのに対し、傍点は「重要ではないけど他と区別したい・注意を向けたい」という用途で使います。
 
 たとえば次の例では、否定文であることが見落とされないよう、傍点を使っています。
 ここは重要箇所ではないので、強調は使わないほうがいいでしょう。
@@ -390,7 +407,7 @@ Starterでは節ごとに改ページする設定が用意されています。
 Re:VIEW Starterではアップグレード用スクリプトを用意して@<bou>{いません}。
 //}
 
-また技術系の文書ではほとんど見かけませんが、小説やエッセーや漫画では「何か含みを持たせた表現」や「のちの伏線になる箇所」に傍点を使います。
+また技術系の文書ではほとんど見かけませんが、小説や漫画では「何か含みを持たせた表現」や「のちの伏線になる箇所」に傍点を使います。
 参考までに、『ワールドトリガー』22巻@<fn>{fn-z94o3}から傍点を使った例を（ネタバレは避けつつ）引用します。
 
 //quote{
@@ -423,13 +440,13 @@ Re:VIEW Starterではアップグレード用スクリプトを用意して@<bou
 PDFでは、読みやすさのために日本語と英数字の間に少しアキ（隙間）が入ります。
 これは内部で使っている組版用ソフト「@<LaTeX>{}」の仕様です。
 
-//list[][サンプル]{
-あいうえおABC DEFかきくけこ123
+//list[][サンプル][]{
+あいうえおABC DEFかきくけこ123。
 //}
 
 //sampleoutputbegin[表示結果]
 
-あいうえおABC DEFかきくけこ123
+あいうえおABC DEFかきくけこ123。
 
 //sampleoutputend
 
@@ -438,7 +455,7 @@ PDFでは、読みやすさのために日本語と英数字の間に少しア
 しかし記号の場合はアキが入りません。
 たとえば次の例では、「ン」と「-」の間にはアキが入っていません。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 オプション-pを使う。
 //}
 
@@ -452,7 +469,7 @@ PDFでは、読みやすさのために日本語と英数字の間に少しア
 
 このような場合は、半角空白を入れるか、またはカッコでくくるといいでしょう。
 
-//list[][サンプル]{
+//list[][サンプル][]{
 オプション -p を使う。
 
 オプション「-p」を使う。
@@ -471,7 +488,50 @@ PDFでは、読みやすさのために日本語と英数字の間に少しア
 
 === [PDF] 等幅フォントで余計な空白が入るのを防ぐ
 
-(TODO)
+Re:VIEWやStarterでは、PDFを作成するために「@<LaTeX>{}」という組版ソフトを使っています。
+この@<LaTeX>{}では、半角空白は次のように扱われます。
+
+ * 文章中の半角空白は、何個連続していても1個分の空白しか出力されない。
+ * ただし「.」と「:」と「!」と「?」の直後の半角空白は、1個しかなくても2個分の空白が出力される。
+
+このルールは、英語の文章を書くうえでは妥当な仕様です。
+そしてこのルールは、フォントに依らず適用されます。
+そのため等幅フォントを使っているときでも、「.」と「:」と「!」と「?」の直後に半角空白があると2個分の空白が出力されます。
+
+しかし、等幅フォントを使うのはたいていプログラムコードやコマンドを表す場合なので、半角空白が勝手に2個出力されてしまうのは困りものです。
+たとえば、@<br>{}
+「@<code>|{a: 1}|」と書いたつもりが、@<br>{}
+「@<code>|{a:  1}|」と表示されるのは、意図したことではないでしょう。
+
+そこでStarterでは、等幅フォントの場合はこのルールを適用しないようにしています。
+そのための「@<code>|\frenchspacing|」@<fn>{fn-2zb8y}というマクロが@<LaTeX>{}にはあるので、これを使います。
+具体的には、@<LaTeX>{}マクロを次のように上書きしています。
+
+//list[][]{
+%% 「@<tt>{}」を上書き
+\renewcommand{\reviewtt}[1]{{%
+  @<b>|\frenchspacing|%   % 「! ? : .」の直後の空白が2文字分になるのを防ぐ
+  \texttt{#1}%      % 等幅フォントで表示
+}}
+//}
+
+//footnote[fn-2zb8y][「@<code>{\frenchspacing}」というのは、「フランス流の空白の入れ方」という意味です。フランス語では「. : ! ?」の直後でも空白は1個なようです。]
+
+「@<code>|@@<nop>{}<code>{}|」が呼び出す「@<code>|\reviewcode|」マクロにも同じ変更をしています。
+このおかげで、Starterでは「@<code>|@@<nop>{}<tt>{}|」や「@<code>|@@<nop>{}<code>{}|」を使ったときに空白が2個出力されるのを防いでいます。
+
+ただし、本来このようなルール変更は「@<code>|@@<nop>{}<code>{}|」にだけ行うべきであり、「@<code>|@@<nop>{}<tt>{}|」では変更すべきではありません。
+現実には「@<code>|@@<nop>{}<tt>{}|」がプログラムコードを表すのに広く使われていることを鑑みて、Starterでは「@<code>|@@<nop>{}<tt>{}|」でもルール変更をしています。
+しかし本来はすべきでないと知っておいてください。
+
+なお「@<code>|@@<nop>{}<tt>{}|」を本来の動作に戻すには、@<file>{sty/mystyle.sty}に次のマクロ定義を追加してください。
+
+//list[][@<file>{sty/mystyle.sty}]{
+%% @@<nop>{}<tt>{} を本来の動作に戻す
+\renewcommand{\reviewtt}[1]{%
+  \texttt{#1}%      % 等幅フォントで表示
+}
+//}
 
 
 === 文章中のコードは折り返しする
@@ -481,7 +541,16 @@ PDFでは、読みやすさのために日本語と英数字の間に少しア
 
 === ノートとコラムを使い分ける
 
-(TODO)
+ノートとコラムはよく似ています。次のように使い分けるといいでしょう。
+
+ * 本文に対する補足情報は、ノートを使う。
+   あくまで補足情報なので、文章が長くなりすぎないよう注意する。
+ * 章(Chapter)の終わりに、長めの関連情報やエッセーを書く場合はコラムを使う。
+   これは節(Section)と同じ扱いにするので、「@<code>|==[column]|」を使う。
+
+ときどき、ノートで書くべきことをすべてコラムで書いている同人誌を見かけます。
+あまりよいことではないので、ノートとコラムの使い分けを検討してみてください。
+また使い分けがよく分からないと思ったら、商業の技術書籍をいくつか参考にしてみてください。
 
 
 
@@ -490,17 +559,20 @@ PDFでは、読みやすさのために日本語と英数字の間に少しア
 === 節タイトルが複数行になるなら下線や背景色を使わない
 
 Starterでは節(Section)のタイトルに下線や背景色をつけられます。
-しかしそれらは節タイトルが1行に収まる場合だけを想定しており、複数行の場合は考慮されていません。
+しかしそれらは節タイトルが1行に収まる場合だけを想定しており、複数行の場合は考慮されていません（@<img>{section_title_wlines}）。
+
+//image[section_title_wlines][節タイトルが長くて複数行になった場合][scale=0.9,border=on,pos=p]
 
-タイトルが長い節(Section)がある場合は、節タイトルに下線も背景色も使わないものがいいでしょう。
-具体的には次のどちらかを選びましょう。
+複数行になるぐらいの長い節タイトルがある場合は、下線も背景色も使わないデザインを選びましょう。
+Starterであれば、次のどれかを選ぶといいでしょう。
 
- * 「@<code>{leftline}」… 節タイトル左に縦線を引く（@<img>{sechead_design_4}上）
- * 「@<code>{numbox}」… 節番号を白ヌキ文字にする（@<img>{sechead_design_4}下）
+ * 「@<code>{numbox}」… 節番号を白ヌキ文字（@<img>{section_title_wlines}上から2番目）
+ * 「@<code>{leftline}」… 節タイトル左に縦線（@<img>{section_title_wlines}上から4番目）
+ * 「@<code>{circle}」… 大きい円に白ヌキ文字（@<img>{section_title_wlines}上から5番目）
 
-//image[sechead_design_4][タイトルが複数行でも崩れない節デザインの例][scale=0.8,border=on]
+このうち「@<code>{circle}」は、節タイトルが1行の場合でも2行分の高さを必要とするので、他のデザインと比べてページ数が若干増えることに注意してください。
 
-Starterにおける節タイトルのデザインを変更する方法は、@<secref>{04-customize|subsec-sectitle}を参照してください。
+なおStarterにおける節タイトルのデザインを変更する方法は、@<secref>{04-customize|subsec-sectitle}を参照してください。
 
 
 === 項を参照するなら項番号をつける
@@ -538,16 +610,18 @@ Starterでは、プログラムコードやターミナルの等幅フォント
 
 Starterのデフォルトでは、本文のフォントサイズに関わらず、A5サイズなら9pt、B5サイズなら10ptのフォントサイズが使われます。
 
- * A5サイズなら、本文が9ptでも10ptでも、プログラムコードはデフォルトで9pt
- * B5サイズなら、本文が10ptでも11ptでも、プログラムコードはデフォルトで10pt
+ * A5サイズなら、本文が9ptと10ptのどちらであっても、プログラムコードはデフォルトで9pt
+ * B5サイズなら、本文が10ptと11ptのどちらであっても、プログラムコードはデフォルトで10pt
+
+この調整は、「@<file>{config-starter.yml}」の設定項目「@<code>|program_default_options:|」と「@<code>|terminal_default_options:|」の中の、「@<code>|fontsize:|」で行われています@<fn>{k7dzw}。
+これらの値は、本文がA5サイズ10ptまたはB5サイズ11ptなら「@<code>|small|」に設定され、A5サイズ9ptまたはB5サイズ10ptなら「@<code>|null|」に設定されます。
 
-この調整は、「@<file>{config-starter.yml}」の設定項目「@<code>|program_fontsize:|」と「@<code>|terminal_fontsize:|」で行われています。
-本文がA5サイズ10ptまたはB5サイズ11ptならこれらが「@<code>|small|」に設定され、A5サイズ9ptまたはB5サイズ10ptなら「@<code>|normal|」に設定されます。
+//footnote[k7dzw][以前は「@<code>|progoram_fontsize:|」と「@<code>|terminal_fontsize:|」という設定項目がありましたが、廃止されました。]
 
 
 === 重要箇所を目立たせる
 
-プログラムコードが10行以上あると、読者はコードのどこに注目すればいいか、分からなくなります。
+プログラムコードが5行以上あると、読者はコードのどこに注目すればいいか、分からなくなります。
 もし注目してほしい箇所が強調されていれば、読者にとってとても理解しやすくなります。
 
 プログラムコードの中で注目してほしい箇所は、ぜひ太字にして目立たせましょう。
@@ -597,7 +671,10 @@ Starterでは「@<code>|@@<nop>{}<weak>{...}|」を使うと、プログラム
 
 === 差分（追加と削除）の箇所を明示する
 
-サンプルコードを徐々に改善するような内容の場合は、削除した行に取り消し線を引き、追加した行を太字で表示すると、差分が分かりやすくなります。
+サンプルコードを徐々に改善するような内容の場合は、次のようにすると差分が分かりやすくなります。
+
+ * 削除した行に取り消し線を引く。
+ * 追加した行を太字にする。
 
 たとえば次のようなサンプルコードがあるとします。
 
@@ -649,7 +726,7 @@ $('#button').on('click', toggleLabel);
 
 === 長い行の折り返し箇所を明示する
 
-長い行を折り返したとき、折り返した箇所が分かるような表示が望ましいです。
+長い行が右端で折り返されるとき、折り返された箇所が分かるような表示にするといいでしょう。
 そのための方法は3つあります。
 
  * 折り返し箇所に何らかの目印をつける
@@ -748,9 +825,11 @@ PythonやYAMLではインデントでブロック構造を表すので、ブロ
 これを防ぐには、何らかの方法でインデントを可視化します。
 そうすると、プログラムコードがページをまたいでもインデントが分からなくなることはありません。
 
-Starterでは「@<code>|//list[][]@<b>{[indentwidth=4]}{ ... //}|」のようにすることで、インデントごとに薄い縦線をつけられます。
+Starterでは「@<code>|//list[][]@<b>{[indent=4]}{ ... //}|」@<fn>{lvw95}のようにすることで、インデントごとに薄い縦線をつけられます。
+
+//footnote[lvw95][後方互換性のために、「@<code>{indentwidth=4}」という名前でも指定できます。]
 
-//list[][薄い縦線をつけてインデントを可視化する][indentwidth=4]{
+//list[][薄い縦線をつけてインデントを可視化する][indent=4]{
 class Fib:
 
     def __call__(n):
@@ -792,30 +871,37 @@ Starterだと「@<code>|//image[ファイル名][説明文][scale=1.0,@<b>{pos=p
 図なら「@<code>|@@<nop>{}<img>{ファイル名}|」、表なら「@<code>|@@<nop>{}<table>{ラベル}|」で参照します。
 
 
+=== 白黒印刷でも問題ないか確認する
+
+形は同じで色だけが違う図形を使うと、白黒印刷したときに判別がつかなくなります。
+
+白黒印刷するなら、形を変えたり線の種類を変えたりするなどして、白黒印刷しても判別できるような図にしましょう。
+
+
 === 表のカラム幅を指定する
 
 表に長い文章を入れると、ページ横にはみ出してしまいます。
 
-このような場合は、「@<code>{//tsize[|latex|@<b>{p{70mm\}}]}」のようにカラムの幅を指定しましょう。
+このような場合は、「@<code>{//tsize[latex][@<b>{p{70mm\}}]}」のようにカラムの幅を指定しましょう。
 
-//list[][サンプル]{
-/@<nop>$$/tsize[|latex||l|@<b>|p{70mm}||]
+//list[][サンプル][]{
+/@<nop>$$/tsize[latex][|l|@<b>|p{70mm}||]
 /@<nop>$$/table[tbl-jqqu9][長いテキストを使ったサンプル]{
 伝承地		伝承内容
 -------------------------------------------
-風の谷		その者、蒼き衣を纏て金色の野に降り立つべし。失われた大地との絆を結び、ついに人々を清浄の地に導かん。
-ゴンドアの谷	リーテ・ラトバリタ・ウルス・アリアロス・バル・ネロリール
+風の谷		その者、蒼き衣を纏て金色の野に降り立つべし。失われし大地との絆を結び、ついに人々を青き清浄の地に導かん。
+ゴンドアの谷	リーテ・ラトバリタ・ウルス・アリアロス・バル・ネトリール
 /@<nop>$$/}
 //}
 
 //sampleoutputbegin[表示結果]
 
-//tsize[|latex||l|p{70mm}|]
+//tsize[latex][|l|p{70mm}|]
 //table[tbl-jqqu9][長いテキストを使ったサンプル]{
 伝承地		伝承内容
 -------------------------------------------
-風の谷		その者、蒼き衣を纏て金色の野に降り立つべし。失われた大地との絆を結び、ついに人々を清浄の地に導かん。
-ゴンドアの谷	リーテ・ラトバリタ・ウルス・アリアロス・バル・ネロリール
+風の谷		その者、蒼き衣を纏て金色の野に降り立つべし。失われし大地との絆を結び、ついに人々を青き清浄の地に導かん。
+ゴンドアの谷	リーテ・ラトバリタ・ウルス・アリアロス・バル・ネトリール
 //}
 
 //sampleoutputend
@@ -828,8 +914,8 @@ Starterだと「@<code>|//image[ファイル名][説明文][scale=1.0,@<b>{pos=p
 表のカラムはデフォルトで左寄せ(l)ですが、右寄せ(r)や中央揃え(c)を指定できます。
 特にカラムが数値なら、右寄せにするのがいいでしょう。
 
-//list[][サンプル]{
-/@<nop>$$/tsize[|latex|@<b>{|l|c|r|}]
+//list[][サンプル][]{
+/@<nop>$$/tsize[latex][@<b>{|l|c|r|}]
 /@<nop>$$/table[tbl-o599k][左寄せ・中央揃え・右寄せのサンプル]{
 左寄せ		中央揃え	右寄せ
 -------------------------------------------
@@ -842,7 +928,7 @@ Starterだと「@<code>|//image[ファイル名][説明文][scale=1.0,@<b>{pos=p
 
 //sampleoutputbegin[表示結果]
 
-//tsize[|latex||l|c|r|]
+//tsize[latex][|l|c|r|]
 //table[tbl-o599k][左寄せ・中央揃え・右寄せのサンプル]{
 左寄せ		中央揃え	右寄せ
 -------------------------------------------
@@ -873,7 +959,7 @@ Starterだと「@<code>|//image[ファイル名][説明文][scale=1.0,@<b>{pos=p
 //image[margin_book][紙の書籍ではページ左右の余白幅が必要][scale=0.8]
 
 Starterではこのような制限を考慮しつつ、本文幅が最大になるよう設定しています。
-そのため、@<b>{印刷用PDFファイルでは奇数ページと偶数ページで左右の余白幅が違います}。
+そのため、@<B>{印刷用PDFファイルでは奇数ページと偶数ページで左右の余白幅が違います}。
 これは意図した仕様でありバグではありません。
 
 電子用PDFファイルではこのようなことを考慮する必要はありません。
@@ -882,12 +968,35 @@ Starterではこのような制限を考慮しつつ、本文幅が最大にな
 
 === [PDF] タブレット向けでは余白を切り詰める
 
-(TODO)
+Starterでは、印刷用PDFと電子用PDFを切り替えて生成できます。
+このとき、電子用PDFのレイアウトは印刷用PDFをほぼ忠実に再現しています。
+つまり電子用PDFのレイアウトは電子用として最適化されているわけではなく、あくまで印刷用のレイアウトを流用しているだけです。
 
+もし印刷用PDFを必要とせず、電子用PDFだけを必要とするなら、レイアウトをタブレット向けに最適化するといいでしょう。
+タブレット向けのPDFでは、本文周辺の余白を切り詰めると、7インチや8インチのタブレットでの読みやすさが向上します。
+余白がまったくないのもどうかと思いますが、全角1文字分ぐらいの余白があればタブレットの画面では十分です。
 
-=== 電子書籍ではページ番号の位置を揃える
+Starterでは、プロジェクト作成時にタブレット向けのレイアウトを選択できます。
+そうすると、タブレット向けに余白を切り詰めたレイアウトになります。
+印刷用PDFを必要としない人は試してみてください。
 
-(TODO)
+なおタブレット向けに余白を切り詰めたA5サイズの本文幅は、切り詰めていない通常のB5サイズの本文幅とほぼ同じになります。
+つまりB5サイズで余白を切り詰めると本文幅が長くなりすぎるので、Starterではタブレット向けとしてはA5サイズのみを用意しています。
+
+
+=== [PDF] 電子用PDFではページ番号の位置を揃える
+
+紙の書籍においてページ番号は、見開きで左右の上隅または下隅に置かれることが多いです。
+紙の書籍は見開きで読めるので、ページ番号がこのような位置でも問題ありません。
+
+しかしこれと同じことを電子用PDFで行うと、ページ番号の位置が右上だったり左上だったり（あるいは右下だったり左下だったり）一定しないので、読みづらいです。
+なぜなら、電子用PDFをタブレットで見るときは見開きではなく1ページずつ読まれるからです。
+
+つまり紙の書籍におけるページ番号は見開きであることを前提にしており、それと同じ前提を電子用PDFにしてはいけません。
+
+電子用PDFでは、ページ番号の位置は一定であることが望ましいです。
+そのため、Starterではページ番号をページ下の真ん中に置いています。
+またこの位置は紙の書籍でも通用するので、印刷用PDFと電子用PDFとで同じページレイアウトにできます。
 
 
 === 非Retina向けには本文をゴシック体にする
@@ -916,19 +1025,45 @@ Starterでは「@<file>{config-starter.yml}」の設定を変えるだけで変
 //image[multiline-title][タイトルの改行位置を指定しなかった場合（上）とした場合（下）][scale=0.7,border=on]
 
 
-=== 大扉を別のソフトで作成する
+==={subsec-visualtitlepage} 大扉を別のソフトで作成する
 
 Re:VIEWやStarterが生成する大扉（タイトルページ）は、デザインがよくありません。
 PhotoshopやIllustratorやKeynoteで作成したほうが、見栄えのいいデザインになります（@<img>{titlepage-samples}）。
 
 //image[titlepage-samples][Keynoteで作成した大扉の例][scale=0.9]
 
+Starterでは、別のソフトで作成した大扉や奥付のPDFファイルを読み込めます。
+やり方は@<secref>{04-customize|subsec-coverpdf}を参照してください。
+
+またこうして読み込んだPDFファイルにも、ノンブルがつきます。
+以前は大扉や奥付のPDFファイルを読み込む機能がなかったため、最初にノンブルなしの印刷用PDFを生成し、大扉や奥付を差し替えてから、最後にノンブルをつける必要がありました。
+今は印刷用PDF生成時に大扉や奥付のPDFファイルを読み込めるので、最初からノンブルつきで印刷用PDFが生成できます。
+
+このように、別ソフトで作成さた大扉を取り込む機能がStarterでは整っています。
+積極的に別ソフトで作っていきましょう。
+なお印刷所へ入稿するなら、大扉に背景色をつける場合は塗り足し@<fn>{fn-79q5r}もつけましょう。
+「塗り足し」が分からなければ、大扉の背景色を白にしておくと入稿時のトラブルが少なくなりま
+す。
+
+//footnote[fn-79q5r][塗り足しについては@<secref>{04-customize|subsec-bleed}を参照してください。]
+
+//note[大扉をKeynoteやPagesで作成する]{
+Keynote.appで大扉を作成しようとすると、困ったことにKeynote.appにはスライドのサイズをA5やB5にする機能がありません。
+かわりにスライドを次のようなカスタムサイズにすると、ちょうどA5やB5のサイズになります。
+
+ * A5の場合：419pt x 595pt
+ * B5の場合：516pt x 728pt
+
+またPages.appなら簡単にA5やB5にできます。
+B5にしたい場合は「JIS B5」を選んでください。
+//}
+
 
 
 == 奥付
 
 
-=== 奥付は最後のページに置く
+==={subsec-colophonlastpage} 奥付は最後のページに置く
 
 紙の本は必ず偶数ページになります。
 たとえば、ページ数が100ページの本はあっても101ページの本はありません。
@@ -940,14 +1075,14 @@ PhotoshopやIllustratorやKeynoteで作成したほうが、見栄えのいい
 
 実は素のRe:VIEWではこれが考慮されておらず、奥付が奇数ページに置かれることがあります@<fn>{fn-qzmgo}。
 Starterではこのようなことはありません。
-奥付は必ず最後の偶数ページに置かれるようになっています。
+奥付は必ず最後の偶数ページに置かれます。気が利いてますね。
 
 //footnote[fn-qzmgo][TechBoosterのテンプレートでは偶数ページに置かれるように修正されています。]
 
 
 === 奥付に更新履歴とイベント名を記載する
 
-奥付には、本の更新履歴が記載されるのが一般的です。
+一般的に、奥付には本の更新履歴が記載されます。
 
 同人誌ならそれに加えて、初出のイベント名も記載するといいでしょう。
 そうすると、どのイベントで手に入れたかが分かりやすくなります@<fn>{fn-ksg34}。
@@ -969,3 +1104,240 @@ Starterではこのようなことはありません。
 たとえば「InDesignで作った」「MS Word 2016で作った」「Pages 10.0で作った」「Vivliostyleで作った」という情報があると、これから本や同人誌を作ろうとする人にとって大きな手がかりとなります。
 
 またエディタに強いこだわりがある人なら「VS Codeで執筆した」「Vimで執筆した」のようにアピールするのもいいでしょう。
+
+
+
+=={sec-textlint} textlintによる文章チェック
+
+この章では、「textlint」というツールを使って文章をチェックする方法を紹介します。
+
+
+=== textlintとは
+
+「@<href>{https://github.com/textlint/textlint, textlint}」とは、日本語の文章をチェックして改善点を指摘してくれるツールです。
+
+たとえば、次のような内容のファイルがあるとします。
+ファイル名の拡張子は「@<file>{.rd}」ではなく「@<file>{.md}」であることに注意してください。
+
+//list[][@<file>{sample1.md}：改善前]{
+Re:VIEW Starterを使うと、きれいなPDFファイルを作成することができます。
+//}
+
+これをtextlintでチェックすると、「もっと簡潔に書けるよ」と指摘してくれます（textlintのインストールについてはあとで説明します）。
+
+//terminal{
+$ @<userinput>{textlint sample1.md}
+
+/Users/yourname/sample1.md
+  1:35  ✓ error  【dict2】 "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。
+解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict2  ja-technical-writing/ja-no-redundant-expression
+
+✖ 1 problem (1 error, 0 warnings)
+✓ 1 fixable problem.
+Try to run: $ textlint --fix [file]
+
+//}
+
+指摘された通りに改善してみましょう。
+
+//list[][@<file>{sample1.md}：改善後]{
+Re:VIEW Starterを使うと、きれいなPDFファイルを作成@<del>{することが}できます。
+//}
+
+これをtextlintでチェックすると、指摘されなくなりました。
+
+//terminal{
+$ textlint sample1.md   @<balloon>{何もエラーが出ない}
+//}
+
+もう1つ、別の例を見てみましょう。
+たとえば次のような文章があるとします。
+
+//list[][@<file>{sample2.md}：改善前]{
+ノンブルは、印刷所に入稿するときに必要です。
+//}
+
+一見すると問題がない文章ですが、textlintでチェックすると「1つの文に複数個の『に』があるよ」と指摘してくれます。
+
+//terminal{
+$ textlint sample2.md
+
+/Users/yourname/sample1.md
+  1:17  error  一文に二回以上利用されている助詞 "に" がみつかりました。  japanese/no-doubled-joshi
+
+✖ 1 problem (1 error, 0 warnings)
+
+//}
+
+指摘されたことを改善してみましょう。
+
+//list[][@<file>{sample2.md}：改善後]{
+ノンブルは、印刷所@<del>{に}@<b>{へ}入稿するときに必要です。
+//}
+
+改善後は、指摘されなくなりました。
+
+//terminal{
+$ textlint sample2.md   @<balloon>{何もエラーが出ない}
+//}
+
+このように、textlintを使うと日本語文章の改善できそうな点が分かります。
+とはいえ、textlintも万能ではありません。
+次の項で注意点を説明します。
+
+
+=== textlintの注意点
+
+textlintは似たような文章であっても、改善点を指摘してくれないことがあります。
+たとえば先ほどの1番目の例である「@<bou>{作成する}ことができます」だと改善点を指摘してくれますが、「@<bou>{作る}ことができます」だと指摘してくれません。
+前者が「作成できます」に改善できたように、後者も「作れます」に改善できます。
+
+またtextlintは「どこが改善できるか」を教えてくれますが、「どう改善できるか」は必ずしも教えてくれません。
+先ほどの2番目の例がまさにそれで、『に』が複数あることは教えてくれますが、どう直せばいいかは自分で考える必要があります。
+
+さらにtextlintの指摘がいつも正しいわけではありません。
+たとえば「血も涙もない。」という文章をtextlintでチェックすると、「1つの文章に複数個の『も』があるよ」と指摘されます。
+しかしこの指摘がおかしいことは、明らかでしょう。
+
+//list[][@<file>{sample3.md}：修正前]{
+血も涙もない。
+//}
+
+//terminal{
+$ textlint sample3.md
+
+/Users/yourname/sample3.md
+  1:4  error  一文に二回以上利用されている助詞 "も" がみつかりました。  japanese/no-doubled-joshi
+
+✖ 1 problem (1 error, 0 warnings)
+
+//}
+
+『も』が複数個現れないように修正できますが、これはさすがにやりすぎです。
+しないほうがいいでしょう。
+
+//list[][@<file>{sample3.md}：修正後]{
+@<del>{血も涙もない。}
+@<b>{血と涙のどちらも欠いている。}
+//}
+
+//terminal{
+$ textlint sample3.md   @<balloon>{何もエラーが出ない}
+//}
+
+このような過剰な指摘が起きたのは、Starterがデフォルトで用意したtextlint用の設定が、技術文章向けだからです。
+textlintは、事前に設定されたルールに従って文章をチェックするツールです。
+設定されたルールが小説向けであれば小説向けのチェックをし、技術文章向けであれば技術文章向けのチェックをします。
+
+textlintの設定は、プロジェクトフォルダの直下にある「@<file>{.textlintrc}」というファイルで変更できます。
+たとえば次のように変更すると、複数の『も』が登場してもエラーにならなくなります。
+
+//list[][@<file>{.textlintrc}]{
+{
+  "filters": {
+  }
+, "rules": {
+    "preset-japanese": false
+  @<del>|, "preset-ja-technical-writing": true|
+  @<b>|, "preset-ja-technical-writing": {|
+      @<b>|"no-doubled-joshi": {|
+        @<b>|"allow": ["も"]|
+      @<b>|}|
+    @<b>|}|
+  , "preset-jtf-style": false
+  , "preset-ja-spacing": false
+  , "preset-ja-engineering-paper": false
+  }
+//}
+
+「@<file>{.textlintrc}」についてこれ以上の解説はしません。
+詳しく知りたい人は「textlint 使い方」でGoogle検索してください。
+
+ここまでが、textlintについての一般的な説明でした。
+次の項から、Starterでtextlintを使う方法を説明します。
+
+
+=== Starterのプロジェクトでtextlintを使う
+
+Starterのプロジェクトでtextlintを使うには、次のようにします。
+
+ - (1) Node.jsとnpmコマンドをインストールする。
+ - (2) textlintをインストールする。
+ - (3) textlintで原稿をチェックする。
+
+(1)と(2)は準備なので、プロジェクトごとに一度だけ行います。
+
+それぞれ順番に説明します。
+
+
+==== (1) Node.jsとnpmコマンドをインストール
+
+textlintを実行するには、@<href>{https://nodejs.org/, Node.js}とnpmコマンドをインストールする必要があります。
+
+ * Dockerを使っている場合は、Dockerイメージの中にNode.jsとnpmコマンドがインストール済みなので、何もする必要がありません。
+ * Dockerを使っていない場合は、@<href>{https://nodejs.org/}にアクセスしてNode.jsをインストールしてください。
+   npmコマンドも自動的にインストールされます。
+
+//note[Node.jsのバージョンについて]{
+インストールするNode.jsのバージョンは、「LTS」と書かれたほうを選ぶといいでしょう。
+Current」と書かれたほうのバージョンでも動作しますが、こちらは上級者向けです。
+//}
+
+==== (2) textlintをインストール
+
+次に、textlintとその関連ライブラリをインストールします。
+StarterではそのためのRakeタスクが用意されているので、次のコマンドを実行してください。
+
+//terminal[][textlintと関連ライブラリをインストール]{
+$ @<userinput>{rake textlint:setup}         @<balloon>{Dockerを使わない場合}
+$ @<userinput>{rake docker:textlint:setup}  @<balloon>{Dockerを使う場合}
+//}
+
+これでtextlintのインストールは完了しました。
+
+==== (3) textlintで原稿をチェック
+
+textlintを使って原稿の文章をチェックするには、「@<code>{rake textlint}」（または「@<code>{rake docker:textlint}」）を実行してください。
+
+//terminal[][textlintで原稿の文章をチェックする（結果は省略）]{
+$ @<userinput>{rake textlint}         @<balloon>{Dockerを使わない場合}
+$ @<userinput>{rake docker:textlint}  @<balloon>{Dockerを使う場合}
+//}
+
+たくさんのエラーが出るので驚くでしょう。
+指摘された点のすべてを修正する必要はありません。
+自分で納得できたことだけを修正すればいいです。
+
+ただし出力結果を見ると、ファイル名と行番号が原稿とは違うことに気づくはずです。
+この理由を次の項で説明します。
+
+
+=== Starterにおけるtextlint実行の仕組み
+
+textlintは、Starterの原稿ファイル(@<file>{*.re})には対応していません。
+そこでStarterでは、次のような仕組みでtextlintを実行します。
+
+ - (1) 原稿ファイル(@<file>{*.re})をMarkdown形式のファイル(@<file>{*.md})に変換する。
+ - (2) Markdown形式のファイルをtextlintでチェックする。
+
+このような仕組みのため、textlintが報告するのはMarkdown形式のファイルにおける行番号であり、原稿ファイルの行番号ではありません。
+よってtextlintの指摘事項を反映するには、出力された行番号をもとにMarkdownファイルを見て指摘内容を確認し、原稿ファイルに戻って修正するという手順になります。
+
+これは理想的とは言い難いです。
+解決方法は3つ考えられます。
+
+ - (A) textlintを改造して、Starterの原稿ファイルを直接読んで解釈できるようにする。
+ - (B) 原稿ファイルとMarkdownファイルの行番号が一致するように変換する。
+ - (C) 原稿ファイルとMarkdownファイルとの行番号のマッピングデータを生成し、それを利用してtextlintの出力結果に含まれる行番号をMarkdownファイルの行番号から原稿ファイルの行番号に書き換える。
+
+どれも手間のかかる作業になるので、将来も含めて対応はあまり期待しないでください。
+
+もしもっといい方法を思いついた人がいたら、ぜひ教えてくださるようお願いします。
+
+
+//note[Markdownへの変換は精度がよくない]{
+StarterにおけるMarkdown形式への変換機能はtextlintで使うために実装したので、「textlintで使えればそれでいい」という割り切りをしています。
+そのため、Markdown形式への変換は精度があまりよくありません。
+
+「こう改善してほしい」と具体的に提案していただければ対応しますが、そもそもあまり力を入れた機能ではないことをご了承ください。
+//}