その7からの続き。
編集について。同人誌でアンソロジーということもあり、全体にわたる表記やトーンの調整はせず、記事内での表記統一と、簡単な“てにをは”レベルの修正にとどめた。
序盤に脱稿いただいたものについては、ある程度しっかりと中身を読み、表現的にわかりにくいところなどについてリライト案を考えてGitHub PR内のファイルにコメントあるいはSuggestとして判断を委ねている。
ただ表記統一で逐一Suggestをするのは著者もこちらも手間 & GitHubのCommit Suggestionでのスクロール挙動が面倒なことになるので、「これらの表記統一をしますよ」と宣言して同意を得たらまずはその統一・コミットを行い、それから上記のとおりコメントやSuggestを実施した。
終盤の脱稿物については判断を仰ぐ時間がなかったので、素読みをして、表記統一、てにをは調整のみの対処となった。
いずれにおいても、Just Right!は通すようにしている。
GitHub PR内コメント・Suggestは過去に書籍でやってとてもダルかった記憶があるのだが、CRE業務で普通に記事やヘルプのレビューで慣れたのか、それとも書籍分量じゃなかったので苦にはならなかったのか……。両方かな。300pレベルの原稿をこのやり方で全部、レビューに収まらず商業品質の編集をせよ、となったら無理めな感じがする。
という話から、今回頒布する『Hatena Tech Book Vol.2』に
id:kmutoが寄稿した記事内容を宣伝しておこう。「ドキュメントを伝えやすくするための技術（校正編）」というタイトルで、せっかく書いたドキュメントの内容が受け手に正しく伝わるような文の書き方、直し方について、自分の主観的・経験的なものではあるが紙面の範囲で記してみた。
なお、書いたのは文章がより伝わるための校正・校閲技術であって、バズる記事の書き方ではないので、バズる方法をお探しの方は技術書典などでお探しいただきたい。私もぜひバズりたい。でも炎上系はいやだ。ということで@mochikoAsTechさんの新刊が滅茶苦茶気になっている。
そういえば自分的にタイトルが未だしっくりいっていなかったので、ChatGPT先生に聞いてみた。
TeXいじり
紙面固有の調整を入れたいとき、Re:VIEW原稿であれば@<embed>$|latex|\linebreak{}$などを使っていろいろできるのだが、Markdown原稿については悩ましい。
今回はEPUBを作ることはしないので、TeX PDF紙面だけを考えてMarkdown内にも直接TeX指示を混ぜていた。
次の行に送る\linebrak指示
みると\linebreak（1つを除いて）「そんなコード
アキを入れる\vspace指示
\vspace{1\Cvs}
| 演算 | 関数名 | 定義 |
改行する\clearpage指示
置き換えた式が得られたわけだ。 \clearpage
字下げ抑制の\noindent指示
\noindent 287ステップを経て
Markdownに埋め込もうとするとエスケープされてしまうものについては、TeXビルド前に実行するフックスクリプトのtex_before.rbで加工した。
rewrite('todays_mitsui.tex') do |s|
s.sub('これはいわゆる\<“', 'これはいわゆる\linebreak{}\<“').
sub('あっただろうか？と', 'あっただろうか？\<と')
end
\urlのURLが長すぎて途中の指定位置で切りたいものについては\href化するための加工をしている。
sub('（例：\url{https://perldoc.jp/func/sort}）', '（例：\href{https://perldoc.jp/func/sort}{https://perldoc.jp/\linebreak{}func/sort}）').
