日本語の編集をしていてよく直すパターン15選（増えるかも）
『校正のバイトをしててよく直す箇所10選｜bxjp｜note（ノート）』という記事を読んで、よくパターン化されていて素晴らしいって思っていました。ところが、記事の趣旨を勘違いした方からの冷たい反応を受けて有料にされたということで、あまりも残念なので自分の立場で再編してみました。1～10は元記事のパターンに対してぼくの考え方を添えたもの、A以降は、元記事を見てぼくが反射的に思いついたパターンです。 まあ、こういうパターンは便利だけど、パターン化できる修正を積み重ねれば悪文がなくなるほど自然言語は簡単ではないので、編集や校正をする人はたいへんですね。 自分は、こういうパターンも直すけれど、段落の役割を整理する、みたいな修正のほうが専門です。（専門とは？） 追記：これは文の書き方指南じゃなくて、文の編集校正で何をやってるか報告です。 1. 順接の「が」が頻出 順接の「が」は撲滅を目指すべきです。
なぜ原稿をテキストで書かなければいけないのか
これは編集とライティングにまつわるアレコレ Advent Calendar 2017の23日めの記事です。 原稿をどういう形式・記法で書くべきなのか、という質問をときどき受けます。 一瞬だけ悩むけど、だいたい答えはこうなります。 「記法はなんでもいいけど、できればテキスト形式で」 今日は、この答えの背景を話します。 まずは「なんでもいい」の部分から。 記法はなんでもいい 出版社や編集者によっては細かく原稿の記法を指定しているようですが、ぼくは特に原稿の記法を決めていません。 これは、そういう記法を決めることができずにここまできた、というのが正直な理由です。 つまり、ぼくの怠慢なんですが、なにも考えずに怠慢であったというよりは、積極的に怠慢になろうと考えた結果なので、そのへんを少し吐露してみます。 原稿の記法を決めるということは、執筆者の脳内にあるものを吐き出してもらうための形を決めるという
TUG 2013で日本語の巻末索引について発表しました
TUG 2013という、世界中からTeX関連の開発者と利用者が日本に集まるイベントで、日本語書籍の索引について発表する機会がありました。「発表してみないか」と実行委員の黒木さんに誘われたときは、仕事でやってることを10分くらいで紹介すればいいのかなと思って軽い気持ちで引き受けたのですが、実は「海外からの参加者向けに用意する日本語チュートリアルの一環なのでよろしく」という話でした。当日は早口でいろいろ詰め込んでしまったせいか、話の筋を見失った方もいると聞いたので（すみません）、いまさらですが発表のストーリーをまとめておきます。（TeX & LaTeX Advent Calendar 2013の2日目の記事です。1日目はzrさん、3日目はdoraTeXさん。） いろいろな言語の本の索引を比べてみると、索引項目（一般には単語）の「自然な」並べ方がある言語とない言語がある アルファベットを使う言語
編集というサービスの内容（技術書編）
技術書の編集者が原稿に対して何を提供するものなのか、整理してみた。順番には意味があります。 原稿をDTP担当者が作業できるデータにする 誤字脱字、非標準的な表記を直す 表記を統一する 文法の間違い、不適切な言い回しを直す 構成の不備、内容の間違いを指摘する 構成の不備、内容の間違いを直す 冗長な内容、文脈から外れる記述を欄外に追い出したり、段落構成を手直ししたりする 段落や文を、文脈に合わせた相に書き直す 行間をうめる 解説画像やイラスト、索引などのメタ情報を作る 原稿を書く 【番外】企画する どこまでやってほしいか、できるか、追加料金がいくら必要なのかというのを、著者・版元編集者・下請け編集者の間ではっきりさせると、みんなが幸せになる気がする。（だいたい編集外注するときって「編集作業一式」の「ページあたりの単価」になりがちで、しかしその「一式」には上記のような幅があるわけだから、人によっ
LLイベント2017の「第2プログラミング言語鑑定団」で鹿野が話したことまとめ
プログラミング好きにもいろいろあって、仕事で使ってる道具をもっと知りたいという人もいれば、自分が使ったことない道具の話を知りたいという人もいれば、道具はなんでもいいから面白い話がしたいという人もいます。 久しぶりに参加したLLイベントは、そんな多様なプログラミング好きが「全員がアウェーな立場」で交流するという、貴重で面白い機会でした。 実際、「LL」の1つめのLには去年までは「Lightweight」という意味があり、その単語が示す特徴をもった言語のイベントのようにどうしても見えてたんですが、今年からはそういう区切りも公けになくし、Lは「Learn」の意味になったとのことです。 そのLLイベント2017で、「第2プログラミング言語鑑定団」というセッションに出させてもらいました。 司会の小山さんが「Teratail, Yahoo知恵袋などから、それらしい質問をかき集めてマージ」した6パターン
独立系出版社をやるという覚悟について
カナダ最大の都市であるトロントから北に向かって1時間ちょっと、荒野だか畑だか牧場だかよくわからない広大な土地を走り抜けたところに、エリンという小さな村があります。 19世紀に開拓された当時からメインストリートであったと思われる道が、川の蛇行している部分を堰き止めるように貫いていて、その両脇だけで主な商圏が形成されているような素朴な村です。 そんな小さな村に、なんと出版社があります。 その名もThe Porcupine’s Quill。 直訳すると「ヤマアラシの針」ですね。 言うまでもなく独立系の出版社で、大手からは陽の目を見るのが難しいカナダ発の文学者やアーティストの作品を手掛けているようです。 今年の7月、この《ヤマアラシの針出版》を訪問する機会がありました。 世界中のTeX関係者が集まるTUGという会合があるんですが、2016年の開催地がトロントで、その一環として《ヤマアラシの針出版》
Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ
これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。 とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。 しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。 まず「認識が違う」と思うのは、プレインオールド
技術書編集者として「これはやられた！」2015年の本
技術書の年間ランキング的なものについて、編集者たちに「これはやられた！」と思う他社の本を候補として出させたら面白いのでは、という会話を小耳にはさみました。これはまたとないアマゾンアソシエイトの機会！ということで、勝手に自分の候補を上げてみます。 と思ったものの、新刊の技術書をそんなにたくさん読んでいないうえに、去年「これはやられた！」と思った本はいずれも技術書ではなく、どちらかというと数学書っぽい本ばかりでした。それでも、ジュンク堂池袋本店の「新春座談会 このコンピュータ書がすごい！ 2015年版」で取り上げられた本ばかりだし、たぶん技術者が読む（べき）本としても妥当なはずです。 『コンピュータは数学者になれるのか? -数学基礎論から証明とプログラムの理論へ-』 いま自分の本棚を見返したら、この本の隣にたまたま『日本の著作権はなぜこんなに厳しいのか』が並んでいて、一瞬だけ姉妹書に見えました
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
