画像を現時点の最新バージョンのソフト等に更新、最終的な編集を実施

articles/configure.re

@@ -15,12 +15,14 @@ Re:VIEWでは書籍に関する情報を章を設定する@<tt>{catalog.yml}と
 //list[catalog_yml_sample][５つの章をもつcatalog.yml]{
 PREDEF:
   - preface.re
+
 CHAPS:
   - writing-book.re
   - environment.re
   - workflow.re
   - publishing-book.re
   - distribution.re
+
 APPENDIX:
   - tips.re
 
@@ -29,6 +31,7 @@ POSTDEF:
 //}
 
 @<tt>{catalog.yml}の各項目の内容は次のとおりです。
+CHAPSのみを必須として前書き、付録、後書きなど本を構成する構造を定義しています。
 
  : PREDEF
    前書きなど目次の前に記載するものを指定します
@@ -134,15 +137,16 @@ colophon: true
 目次として抽出する章や節の深さを変更するには、@<tt>{config.yml}の@<code>{toclevel}項目を設定します（@<list>{toclevel}）。
 
 //list[toclevel][抽出レベルを設定]{
+# 目次として抽出する見出しレベル
 toclevel: 2
 //}
 
 抽出レベルを変更すると、値に応じた深さの見出しを出力します（@<img>{toclevel2}および@<img>{toclevel3}）。
 
-//image[toclevel2][toclevel:2を指定した場合の目次][scale=0.75]{
+//image[toclevel2][toclevel:2を指定した場合の目次][scale=0.85]{
 //}
 
-//image[toclevel3][toclevel:3を指定した場合の目次][scale=0.75]{
+//image[toclevel3][toclevel:3を指定した場合の目次][scale=0.85]{
 //}
 
 =={layout} 用紙サイズやデザインを変更する

articles/distribution.re

@@ -27,7 +27,7 @@
 ニッチな技術書だからといって遠慮することはありません。書籍の表紙やサンプルページなど画像とともに訴求していきましょう。
 XやblueskyのようなSNSであればハッシュタグ@<fn>{hash}を活用して告知してください。
 
-//footnote[hash][技術書典であれば#技術書典、コミックマーケット103であれば#C103などの略称が使われます]
+//footnote[hash][技術書典であれば@<tt>{#技術書典}、コミックマーケット103であれば@<tt>{#C103}などの略称が使われます]
 
 いずれの告知方法も一朝一夕で効果がでるものではないのですが、やらないよりはずっと効果が期待できます。
 もっとも確実な告知は継続的な参加とアウトプットです。即効性はありませんが一度読んで面白かった本のことは良く覚えてるものです@<fn>{power}。
@@ -65,15 +65,16 @@ XやblueskyのようなSNSであればハッシュタグ@<fn>{hash}を活用し
 //}
 
 表ではよく使われてるものを中心に集めています。また必須の項目には◯をつけました。これらの準備は前日までに終わらせておくとベターです。
-技術書典では電子決済をサポートしているので現金をもってこない出展者も見かけるようになりましたが、それ以外のイベントでは現金もまだまだ現役です。
+技術書典では電子決済をサポートしているので現金を特別用意しない出展者も見かけるようになりました。それ以外のイベントでは現金もまだまだ現役です。
 
 イベントでは180センチ長の机を使います。技術書典の場合は机1本の180cmが割り当てられます。それ以外のイベントであれば多くの場合、机半分の90cm幅が自由に使える展示スペースです。
 出展者は開場の１～2時間前には入場して自分のスペースをレイアウトします。周りも展示の準備をしていますのでスペースのはみ出し、
 通路を塞ぐような荷物には注意してマナーを守って過ごしてください@<fn>{eyes}。
 
 //footnote[eyes][時間帯によっては通路が混雑します。貴重品の管理は厳重に！]
 
-今回、必須としていませんがポスターはコスパよく訴求できるのでおすすめしたい準備物です。どんな読者に読んでほしいか、目に付きやすいキャッチコピーやPRを記載しておくといいでしょう。
+#@# prh:disable
+今回、必須としていませんがポスターはコスパよく訴求できるのでお勧めしたい準備物です。どんな読者に読んでほしいか、目に付きやすいキャッチコピーやPRを記載しておくといいでしょう。
 よくできたポスターには眼の前を素通りさせないパワーがあります。
 
 展示物にあわせてタブレットをつかったり、ハードウェアの実演、パネルやイーゼルで見やすく配置して工夫してもよいでしょう。

articles/planning-book.re

@@ -50,8 +50,8 @@
 //footnote[techbookfest][@<href>{https://techbookfest.org/}]
 
 本が集まるもっとも有名なイベントはコミックマーケットでしょう。いわゆるサブカルチャーが集まる即売会です。
-8月と12月の年2回、約25万人の参加者が集う巨大マーケットです。参加者はそれぞれの趣味を楽しみにきており、その一角に技術書が居ます。コミックマーケットにはジャンルというくくりがあり、ジャンル毎に何日目のどのあたりの場所、とざっくり決まっています。技術書であれば、「同人ソフト」または「評論・情報」のどちらかで応募している場合が多いです。
-ちなみに、TechBoosterは同人ソフトジャンルでモバイルアプリ関連技術で本を出しています。
+8月と12月の年2回、約25万人の参加者が集う巨大マーケットです。参加者はそれぞれの趣味を楽しみにきており、その一角に技術書が居ます。コミックマーケットにはジャンルというくくりがあり、ジャンル毎に何日目のどのあたりの場所とざっくり決まっています。技術書であれば、「同人ソフト」または「評論・情報」のどちらかで応募している場合が多いです。
+ちなみにTechBoosterは同人ソフトジャンルでモバイルアプリ関連技術で本を出しています。
 
 == 書きたいものを書こう
 

articles/publishing-book.re

@@ -29,7 +29,7 @@
 印刷所へ最終的な印刷用データを渡すことを@<kw>{入稿,にゅうこう}と呼びます。
 本節では入稿手順を解説しますが入稿には専門的な注意点も多いため専門用語は出てきたタイミングで説明を補います。
 
-@<chapref>{writing-book}で述べたとおり、同人誌向けのRe:VIEWプロジェクト構成を使用する前提です。TechBoosterのテンプレートリポジトリをcloneしている場合、@<kw>{ノンブル,通し番号}のような同人誌特有の問題を回避できます。
+@<chapref>{writing-book}で述べたとおり、同人誌向けのRe:VIEWプロジェクト構成を使用する前提です。TechBoosterのテンプレートリポジトリをCloneしている場合、@<kw>{ノンブル,通し番号}のような同人誌特有の問題を回避できます。
 
 #@# prh:disable
  * @<href>{https://github.com/TechBooster/ReVIEW-Template}
@@ -43,7 +43,7 @@
 今回は日光企画さんの事例に限って入稿に必要な知識をみていきましょう。実際には入稿予定の印刷所が指定するフォーマット、注意点を熟読して挑んでください。
 
 とはいえ困ったことばかりではありません。
-繰り返すようにテンプレートリポジトリを使っている限り、大きな問題には合いませんし、印刷所のスタッフさんも表紙や本文を目で確認してくれるため
+繰り返すようにテンプレートリポジトリを使っている限り、大きな問題にはあいませんし、印刷所のスタッフさんも表紙や本文を目で確認してくれるため
 誤字や脱字、はみ出しや印刷の問題が見つかって教えてくれるボーナスイベントも発生します。安心してください。
 
 注文に先立って知っておく知識として、部数に応じて適した印刷手法が異なります。
@@ -124,10 +124,11 @@ review-pdfmaker config.yml
 基本的にページ数が４の倍数になるように揃えて入稿します。ならない場合は無理やり白いページを挟むこともあります。
 
 またページごとにノンブル（ページの通し番号）は、たとえ白いページであっても必ず番号をいれます。同人誌以外では見ない制約ですし、印刷所によっても異なります。
-乱丁を防ぐ意図もありますがページ数がわかると純粋に参照しやすいのも事実です。
+乱丁を防ぐ意図もありますがページ数が分かると純粋に参照しやすいのも事実です。
 ノンブル不要な印刷所であっても念のため入れておくのもよいでしょう。なおノンブルのレイアウトは紙面の下側が一般的です。
 
-#@# TODO 作図する
+//image[nombre][ノンブル位置の例]{
+//}
 
 本の紙面は綴じている側（本の中心）の余白をノドと呼び、左右の端側の余白を小口と呼びます。本を読むとき、小口と地に指がかかりやすいため、わたしたちの提供するレイアウトでは見やすいよう余裕を持った設定をしています。
 
@@ -175,6 +176,7 @@ review-pdfmaker config-ebook.yml
 //}
 
 大きな違いはフォントと余白です。紙面ではのりで本を綴じるため、手で持って読むために余白を広く取ってあります。
+
 一方の電子書籍用に最適化したレイアウトでは余白を最小限に、PCやスマートフォンで読みやすいようにフォントも変えています。
 小さな違いにみえるかもしれませんが、快適に読むための工夫がたっぷり含まれています。
 
@@ -249,14 +251,13 @@ EPUBとPDFはフォーマットの違いから設定できる項目にも違い
 epubmaker:
   # HTMLファイルの拡張子
   htmlext: xhtml
-  stylesheet: ["style.css", "epub_style.css"]
+  stylesheet: ["epub_style.css", "epub_style.scss"]
 //}
 
 @<code>{epubmaker}に続く設定はEPUBフォーマット専用の項目です。PDF等と共用できるものは引き継いでいるので安心してください。
-ただEPUBの設定項目は専門的な知識が求められるので、変更する場合は表紙を最初のページとして表示するか決める@<code>{cover_linear}ぐらいに留めておいてください。
+ただしEPUBの設定項目は専門的な知識が求められるので、変更する場合は表紙を最初のページとして表示するか決める@<code>{cover_linear}ぐらいに留めておいてください。
 フォーマットごとに出力し、複数の成果物を管理するのは想像異常に大変です。慣れてきたり、必要に迫られたら考えましょう。
 
-
 GitHub ActionsのRe:VIEW-build-artifact-actionは現時点でEPUB出力に対応していません。
 ローカルPC上にRe:VIEWの実行環境を用意して@<code>{review-epubmaker}コマンドでビルドしてください。
 
@@ -268,12 +269,12 @@ review-epubmaker config.yml
 
 成功したら@<tt>{bookname.epub}ファイルを出力します。EPUBファイルはApple Books等で表示してみましょう（@<img>{epub}）。
 
-//image[epub][iBooksでの表示例]{
+//image[epub][Apple Booksでの読書例]{
 
 //}
 
 EPUBリーダーで柔軟にレイアウトし、読者の環境に合わせて読める特徴は他のフォーマットにない利点です。
-世の中にはApple Books以外のEPUBリーダーも存在しています。それぞれのリーダーごとに表示が異なるため、可能な限り多くの電子ブックアプリで動作確認してください。
+世の中にはApple Books以外のEPUBリーダーも存在しています。それぞれのリーダーで表示が異なるため、可能な限り多くの電子ブックアプリで動作確認してください。
 これはPDFとEPUBのフォーマットの違いをよく表しています。EPUBはレイアウトやフォントサイズなどの表示品質はリーダーに委ねているのです@<fn>{why_epub}。
 
 //footnote[why_epub][委ねたほうがデバイスや読者の要望ごとに最適な読書環境が提供できるとの考えからです]
@@ -286,6 +287,7 @@ EPUBリーダーで柔軟にレイアウトし、読者の環境に合わせて
  2. PDFファイルのフォーマット変換
  3. 画像等のモノクロ化
 
+#@# prh:disable
 実は３つともReVIEW-Templateリポジトリをデフォルトで使っている限り、ほぼ気にしなくていい内容です。
 ひとつめのフォントの埋め込み確認は入稿時の確認という意味では必須です。しかし残りのふたつは印刷所のノウハウ蓄積もありほぼ問題にならなくなりました。少なくとも技術書典のバックアップ印刷所では作業の必要はありません。
 
@@ -323,9 +325,9 @@ PDFファイルであれば大丈夫じゃないのと感じるかもしれま
 
 === 原稿のモノクロ化
 
-入稿の最終段階です。作成したPDFデータをモノクロ化します。モノクロ化にあたってはPDF/Xフォーマットであることが前提ですので、前述のフォーマット変換作業を忘れずにおこなってください。
+入稿の最終段階です。作成したPDFデータをモノクロ化します。モノクロ化にあたってはPDF/Xフォーマットであることが前提ですので、前述のフォーマット変換作業を忘れずに行なってください。
 
-ツールから印刷工程を選ぶと色を置換というサイドメニューが表示されています（前述の@<img>{pdfx}のPDF/Xとしての保存の２つ上です）。
+ツールから印刷工程を選ぶと色を置換というサイドメニューが出ます（@<img>{pdfx}のPDF/Xとしての保存の２つ上です）。
 
 ここではオブジェクトのうち、DeviceCMYKカラータイプのプロファイルを変換します（@<img>{replace-color}、@<img>{replace-color-dot-gain}）。
 
@@ -335,9 +337,9 @@ PDFファイルであれば大丈夫じゃないのと感じるかもしれま
 //image[replace-color-dot-gain][カラーを出力インテントに変換をチェック]{
 //}
 
-@<b>{カラーを出力インテントに変換}にチェックをいれて、@<b>{Dot Gain 15%}を選択します。
-また変換のオプションで@<b>{黒を維持}もチェックします。
+@<strong>{カラーを出力インテントに変換}にチェックをいれて、@<strong>{Dot Gain 15%}を選択します。
+また変換のオプションで@<strong>{黒を維持}もチェックします。
 
 この設定で色を置換すると無事、モノクロ化できます。ここまでで本文の入稿データ作成は完了です。
 
-本手法に限らずモノクロ変換の際には、カラー画像の際には全く違う色だったものが同じような色味に変わってしまうケースがあります。図やグラフでありがちなのでモノクロで見ても視認性が高く保たれているかという観点で変換後のPDFファイルを確認してください。
+本手法に限らずモノクロ変換の際には、カラー画像の際にはまったく違う色だったものが同じような色味に変わってしまうケースがあります。図やグラフでありがちなのでモノクロで見ても視認性が高く保たれているかという観点で変換後のPDFファイルを確認してください。

articles/review-introduction.re

@@ -609,6 +609,9 @@ Re:VIEWでは、見出しキャプションとは別に参照用のラベルを
 
 //list[refer_section_label][見出しの参照]{
 ＠<hd>{commandline}
+
+別の章からの参照
+＠<hd>{chapter_filename|commandline}
 //}
 
 通常の節の参照同様、違う章の節を参照できる優れものです。