Skip to content

Latest commit

 

History

History
373 lines (210 loc) · 16.3 KB

novel.md

File metadata and controls

373 lines (210 loc) · 16.3 KB

ぼくのかんがえたさいきょうの小説執筆環境

時々小説書くので、これについて言及してみた。

ライトノベル作法研究所

また僕が参考にしたライトノベル作法研究所というサイトには、小説執筆用ソフトの解説というページが存在する。とりあえずは、ここに出てくる環境から紹介していこうかと思う。

Microsoft Word 君、一太郎君

上記のページの先頭に書かれているので、使えるソフトなんじゃねーのみたいな感じですけど、ライトノベル作法研究所では全然勧めてませんね。一部を引用します。

だがその際、実は『Microsoft Word』で作成されたデータの受け渡しは、あまり薦められない。

『Word』は広く普及したワープロソフトだ。ワープロソフトとは何か。文書作成ソフトである。 そんな勘違いをして、今でも律儀に文書作成と言うと『Word』を使っている人は少なくない。 だが逆に訊きたいのだが、本当にWordはそんなに使い勝手の良いソフトだろうか。 Wordは英語入力を前提として開発されたソフトである。 だから、日本語での入力をしていると、どうしても回避不能なトラブルが起こったり、不便が起こったりする。

これじゃあ一体何が不便なんですかね、って感じですが、ちゃんとライトノベル作法研究所で紹介されています。

『Word』も『一太郎』も、高額なソフトである。 全てのパソコンにインストールされているとは限らない。 それなのに『Word』や『一太郎』で作ったファイルを無自覚に、誰にでも渡したらどうなるか。 開くことすらできない。 そもそも、データを渡す相手がMacパソコンの場合はどうするのか。

MS-Officeとほぼ同程度の機能と互換性を持つフリーウェアが開発・配布されている。 だがその一方で、マイクロソフト社は新しいバージョンの『MS-Office』を発表するごとに、 過去のWordと互換性のない機能を次々と付け加えている。 すると、バージョンによっては、同じWord文書でも、ファイルを開けない事態が頻発している。 だから『Word』で作られた文書は、長期間の保存には向かない。

『Word』で作成した文書には、文字データだけが保存されているわけではない。 Word文書には文字データだけでなく、文字装飾のデータまで一緒に保存してしまう。 文字装飾のデータとは例えば、文字の色や大きさとか、フォントの形とか、段組とか。 そのような文字データ以外の他の様々なデータが付随するため、 Word文書はデータ量が大きくなりやすい。

まあこんな感じに書かれていますね。ライトノベル作法研究所が、これらを否定する理由をまとめると次の三点ですね。

  • 英語前提な動作が気になる(Word君のみ)
  • ソフトが高いし、インストールされていないパソコンでは開けない
  • 下位互換が切り捨てられるので、開けないファイルになる
  • 修飾データ(フォントなど)を内包するので、サイズがデカくなる

この主張に関しては、まあデータが多少膨らんだところで今となっては些細な問題かなとも思うけど、それ以外についてはほぼ同意。やはり、Word君や一太郎君はそのソフトを持ってないと編集出来ないってのが痛すぎる。

ライトノベル作法研究所では言及してないけど、Word君や一太郎君が作るファイルは差分が取りにくい。つまり実際にファイルを開いてみないと、何処が編集されたのか分からない。

さらには、たぶんファイルの分割も出来ない。一つのファイルに数百ページ分も書くと、管理が死ぬほど面倒になる。

テキストエディタ君

誰でも開ける(編集出来る)というなら、テキストファイルが一番でしょ、というノリでライトノベル作法研究所はテキストエディタを推してくる。ライトノベル作法研究所には次のような説明がある。

エディタと言うソフトをご存じだろうか。エディタとは、テキストファイルを作成するためのソフトである。 例えば、Windowsパソコンなら『メモ帳』と言うソフトが必ず付属している。 『メモ帳』とはもっとも簡単なエディタソフトだ。 だから、まぁ、エディタとは便利な『メモ帳』くらいに考えてくれて構わない。

もともとエディタの開発された理由は、プログラミングのためだった。 つまりエディタは、長時間、延々と文字を入力するために開発されたソフトである。

はい、僕も長時間延々文字を入力してますね。

ライトノベル作法研究所では秀丸というテキストエディタが紹介されている。情報の畑に足を踏み入れた僕が迂闊なことを言うと、刺される可能性があるけど、僕はMacVimというテキストエディタを使っている。

僕の周りではSublime Textとか、Emacsというエディタも人気があるみたい。

どのみちテキストエディタで小説を書くというのが良いだろうと思う。

フォーマット君

さて、テキストエディタで書くと決まったけど、テキストでは限界があるとすぐに気がつくと思う。例えばテキストファイルでは次のようなものを記述出来ない。

  • 挿絵
  • ルビ
  • 見出し、小見出しなどの構造
  • 脚注
  • 太字、斜字
  • 箇条書き
  • 目次
  • 数式
  • 縦書き

こんな感じで無理矢理タイトルなどを書いてるのを見たことがあるけど、ちょっとねー。

*******************
   タイトル
*******************

      見出し
==================

   小見出し
------------------

本文……
……

そんな訳で、少なくとも、まともに見えるかもしれないフォーマットを紹介してゆく。

青空文庫君

ライトノベル作法研究所には、テキストエディタの特殊機能として次のようなものを挙げている。

青空文庫に対応していてテキストデータでもルビを振れるエディタなどが、 フリーソフトとして配られている。

青空文庫とは、恐らく大抵は知っていると思うけど、著作権が切れた本をデータ化して、無料で読めるようにしようという試み。その際小説を書く時と同様に、どのようにして本の体裁を保ったままデータ化(テキスト化)すればよいかという問題に直面し、本の体裁を記述するためのルール(フォーマット)を定義したわけですね。

だったら我々もこのフォーマットに乗っかれば、iPadや電子書籍リーダなどの青空文庫リーダーで、自分で書いた本を読めるようになる。

一見、青空文庫で全て解決するかに思えるけど、まあそんなには上手くゆかないのですね。

青空文庫フォーマットの詳細を見ると、なんか良さそうな感じだけど、試しに見出しを見ると、たかが見出しなのに凄いことになってるのが分かるかと思います。

[#2字下げ]上 先生と私[#「上 先生と私」は大見出し]


[#5字下げ]一[#「一」は中見出し]

たぶん、本によって見出しの字下げが曖昧なので、このようにN字字下げ、などと記述出来るようにしたのかもしれないけど、そもそも「字下げ」というスタイルと「見出し」という構造は関係を持つ情報なのに、青空文庫ではそれがバラバラになっている。

やはり青空文庫は出版された本のレイアウトを、忠実に再現するために作られたフォーマットなので、今から新たに小説を書くにあたっては、正直煩雑すぎると思う。

ぼくがつかってみたフォーマットたち

青空文庫フォーマットに嫌気が差して、フォーマット探しの旅に出た僕の感想。

HTML君

ウェッブサイトの構造を記述する言語として有名だと思う。現在のきらびやかなウェッブサイトを観れば分かるように、これを使えば大概はなんとかなるだろうと考えて使ってみた。

しかも、HTMLならばウェッブブラウザで見れば即刻確認出来るし、自分のホームページにも掲載しやすいし一石二鳥では。

こんな感じになった。

<html>
<head>
	<title>タイトル</title>
</head>
<body>

<h1>見出し</h1>

<h2>小見出し</h2>

<p>本文がだらだらだらーーーー</p>

</body>
</html>

まあ、タグ書くのがめんどいよね。これは人間の書くものにあらず、コンピュータが書くものである。つまり、もっと簡単なサムシング(フォーマット)から、HTMLに変換するプログラム(もちろん、誰かが作った物)を使えばいいんじゃね、という発想へ。

POD君

PODというフォーマットを聞いたことがある人は、たぶんそういないと思う。Perl君というプログラミング言語で、取説を記述するために作られたフォーマット。Plain Old Documentationの略で、その名の通りシンプルなフォーマット。

こんな感じ。

=head1 見出し

=head2 小見出し

本文

=over

=item 箇条書き

=item 箇条書き

=back

これは結構良かったんだけど、ルビを記述出来ないんだよね。アメリカ語にはルビが必要ないみたい。

採用したもの

そしてなんとか納得出来る(?)フォーマットに出会った。

LaTeX君

そもそもHTMLでは綺麗な組版は無理では、と考え始め邪悪なLaTeXへの道へ入る。

LaTeXは論文などを書くために使われる組版処理システムで、これはPDFなどを吐く。PDFも、コンピュータを始め最近はスマートフォンなど、様々なプラットフォームで閲覧可能なので、閲覧はPDF、編集はテキストであるLaTeXフォーマット、という感じでゆこうと思った。

現在、僕はこのフォーマットで小説を書いている。

\documentclass[10pt,b6paper]{jsbook}

\title{タイトル}
\author{著者}

\begin{document}

\maketitle

\part{}

\section{見出し}

\subsection{小見出し}

\subsubsection{小小見出し}

本文

おい、てめー冗長さは青空文庫と変わりねーぞ、って言われそう。はい。だけどこいつをLaTeX処理系に食わせて変換すると、とても美しいPDFが生成される。

http://db.tt/5hM0atUS

ソースコード

つまり、手間をかけるだけの美しさがあるのがLaTeXだけだったので、もうそれ以外に選択肢がないような感じ。それ以外を使った瞬間に妥協した気分になる。

めんどすぎでは……

よろしい、ならばOMakeだ。

OMakeとはコンパイルなどを自動化するために開発されたソフトウェア。こいつは依存するファイルを自動的にスキャンして、それらに変更があった瞬間、直ちに自動でコンパイルを行うように出来るの。僕は次のようなOMakeの設定をした。

OMakeroot

open build/LaTeX

DefineCommandVars()

FindDirs(basename) =
	dirs = $(set $(dirname $(ls $(basename)[1-9]*)))

	return $(dirs)

DepsUpdate(dirs) =
	deps =
		foreach(dir, $(dirs))
			foreach(file, $(ls $(dir)))
				value $(file)

	return $(deps)

.SUBDIRS: .

設定ファイル地獄はまだまだ続くよ。

OMakefile

dirs = $(FindDirs ./chapter)

TEXDEPS = $(DepsUpdate $(dirs))
LATEX = platex
DVIPDFM = dvipdfmx
DVIPDFMFLAGS = -p b6

body.tex : :value: $(DepsUpdate $(dirs))
section
fp = $(fopen $@, w)
	foreach(dir, $(dirs))
		fprintln($(fp), $""\chapter{}"")
		foreach(file, $(set $(ls $(dir))) )
			fprintln($(fp), $""\section{}"")
			fprintln($(fp), $""\input{$(file)}"")
			fprintln($(fp), $""\clearpage"")

LaTeXDocument(main, main)

.DEFAULT: main.pdf

これ作るのには相当かかったと思う。

はぁ? 何これナメてんの?

そうですねー。こんなことしないとマトモに使えないとか、やめて欲しいですよねー。

環境整えるだけで満足して、小説書く気力失せる。

ぼくのかんがえたさいきょうのかんきょう

ではこういう経緯を踏まえて、僕が考える最強の環境を紹介する。

現状僕の頭はこのようになっているという前提です。

  • LaTeXは美しいPDFを吐く
  • LaTeXは数式などありとあらゆるものを記述出来る
  • LaTeXはテキストエディタで記述出来る
  • LaTeXくらいのPDFが吐けないと負けた気がする
  • LaTeXフォーマットは冗長なので避けたい
  • コンパイルも面倒

translate Something into LaTeX

LaTeXは数式や縦書きなど多彩なことが出来るが、あまりにも書くのが面倒なので、やはり小説には向かないのではないかと思う。

そこでさきほど出たPODなどから、LaTeXフォーマットを吐くような処理系を新たに作るというが最善と思う。こうすれば、後はそのLaTeXファイルを既存のLaTeX処理系でコンパイルすれば、綺麗なPDFが手に入る。

ニッチなユーザのためにインラインTeXをサポートしておけば、ありとあらゆることが可能になる。

コンパイル

コンパイルは先程も挙げたように面倒だし、OMakeを使うなども避けたい。

僕はもはやウェッブ上でやるのが最適であると思う。

つまり、上記の何かLaTeX以外のフォーマットで書かれた小説を、小説コミュニティサイト(SNS)みたいな場所にアップロードした瞬間、コンパイルされてPDFが作られる。

コミュニティサイトにしておけば、その場で直ちに小説を公開することも出来る。

Git

小説は営々と書き溜めた大切なデータなので、パソコンが水に沈んだくらいで全て失われるというのは困る。

また小説を書くと、登場人物を増やすとか、展開を変えるとか重大な変更をすることがある。こういう時クイックセーブみたいに、即座にある状態に戻したいという状況は容易に想像出来る。

そこで、そのコミュニティサイトの裏側にはGitを搭載する。複雑なコマンドは隠蔽し、コミットやブランチはウェッブUIからも行なえる。

もちろんコマンド操作もGitHubのように出来る。つまり、ウェッブのUIを使って小説を管理することも出来れば、git commitgit pushみたいに小説を管理することも出来る。

もちろんどちらの方法であっても、Gitのフックによってコンパイルが走るようにしておく。

まとめ

こんな小説SNSみたいなものがあったらいいなーと思うので、誰か作ってくれませんか。