縦書き文庫の開発日誌

「和紙」についてなのですが、よくある質問に
「文章を修正するとサムネールが表示されなくなってしまう」
というものがあります。

これについては完全にこちらの説明不足でした。

和紙に関しては、文章を修正すると、サムネールの埋め込みコードも変わります。

なので、文章を修正したら、サムネールも貼り付け直す必要があるのです（ちなみに、縦書き文庫のサムネールについては、こういったことはありません）。

今はGAEのバージョンが変わったのと、アプリケーションのアップロード作法的なものを忘れてしまったので放置してますが、いずれサイトのほうにも注意書きを追記します。

＜追記＞

Googleグループの「日本発のアプリケーション」において「和紙」についても紹介されているみたいですが、「縦書きのWiki」って紹介されてるみたい。うーん…ちょっと違う気もするけれど、じゃあなんて説明が適当なのか、と問われたら自分でもよくわからないですねえ。

変更を加えてから既に2ヶ月ぐらい経ってしまったのですが、
コメントシステムの仕様変更についてお知らせします。

まずは、作者本人が「参考になったか否か」を投票できなくなりました。参考になったかどうかを、作者本人という立場から客観的に判断するのは難しいと思ったからです。

次に、コメントが参考になったと投票されたときにアップするカルマが、作品の字数に比例するようになりました。読むのにかかった時間は、作品の字数に比例するはずなので、そういう事情を加味したわけです。

以上、連絡が遅れてすみませんでした。

前回の「原稿用紙一枚分をページ送りする平均時間」は、数字としては大雑把過ぎたかもしれないです。

なので、今日は同じテーマをもう一歩進め、ジャンル別の読書スピードを公開します。
並びは読書スピードの降順で、data count は、サンプリングに使用した有効ページ送り数です。

[時代・歴史]
data count : 195
speed : 42.331390(sec/400字)

[純文学]
data count : 49
speed : 34.347409(sec/400字)

[SF]
data count : 93
speed : 33.644592(sec/400字)

[論文]
data count : 9
speed : 33.298776(sec/400字)

[自由詩]
data count : 30
speed : 32.575769(sec/400字)

[評論]
data count : 20
speed : 31.523568(sec/400字)

[ミステリ]
data count : 19
speed : 30.191761(sec/400字)

[童話・児童小説]
data count : 158
speed : 28.475131(sec/400字)

[ノンフィクション]
data count : 53
speed : 28.118389(sec/400字)

[翻訳文献]
data count : 279
speed : 25.688595(sec/400字)

[お知らせ]
data count : 52
speed : 25.402327(sec/400字)

[青空文庫]
data count : 3003
speed : 24.932490(sec/400字)

[ライトノベル]
data count : 578
speed : 24.231763(sec/400字)

[恋愛]
data count : 3613
speed : 22.800185(sec/400字)

[ファンタジー]
data count : 83
speed : 22.398569(sec/400字)

[短歌]
data count : 15
speed : 22.322235(sec/400字)

ここまで具体的になると、またまた想像力が刺激されませんか。

ライトノベル、恋愛、ファンタジーなどは、軒並みスピードが速いです。
やはり書き手さんが読者に優しい平易な文章を意識する傾向が強いのかもしれないです。

歴史ものがもっとも遅いですが、難解な漢字を使うことが多い為に、遅いのかもしれないです。

意外なのは、同じく難しい漢字が多いはずの青空文庫のスピードが速いことでしょうか。
僕が想像するに

・既に読んだことのある作品を再読している（特に国語の授業とかで既に読んでいそう）
・青空文庫の作品は、そもそも文章そのものが洗練されている
・青空文庫読みは、読書慣れしている人たちで、そもそも常人に比べ読書スピードが速い
・単にサンプルデータの分母が大きいだけ

といったところでしょうか。

詩に関しては、ちょっと意外でした。

詩って、行間を読ませたり、言葉を凝縮したり隠喩したりするので、吟味に時間がかかるものだと思うのですけど、短歌はかなり速いスピードで消化されているんですよね。一方で自由詩はまあまあ時間がかかっています。

短歌は形式が固定されているので、より読みやすいのかもしれませんね。

そう考えると、定型詩というのは、音のリズムを固定化する目的と同時に、古代の人間なりに物事を効率的に理解しようとした工夫の一環だったのかもしれないです。

とはいえ、分母が小さいので、データの揺れが大きいだけかもしれず、なんともかんとも。
もっとデータが欲しい……！

さておき、ふとおもったのですけど、仮に同じボリュームの内容を英文に訳したとして、文章の消化効率はどちらの言語の方が優れているのだろう。

約1万回のページ送り（飛ばし読み省く）をサンプリングして、読者の平均的な読書スピードを試算してみました。

結果は、

400字あたり、25.3秒

という数字でした。ふむふむ。

ページ送りのスピードは作品の性質によっても大きく変わるとは思いますが、その辺はあまり気にしないでおくとして、こういう数字が出ると、色々と丼勘定してみたくなります。

まず平均的な読書能力を持った人材の時給を大体1000円ぐらいに設定しましょうか。
（本当はもうちょっと高い気もしますが）

時給1000円は秒給で0.2778円
400文字が25.3秒だから、一文字は0.63秒
てことは、一文字読ませるのにかかる人件費は、

0.2778 * 0.63 = 0.0176（円/字）

つまり、

1万字（原稿用紙25枚）だと176円
10万字（原稿用紙250枚）だと1760円

小説ってのは原稿用紙250枚から、なんてことが多いような気がするので、一般的なボリュームの小説を読んでもらうコストってのは、平均的な読書能力を持った人材を一時間半ぐらい拘束するだけの人件費がかかるってことですね。

こういった数字を元に、今度はカルマという側面から色々と試算してみましょう。

縦書き文庫のカルマは、おおよそ400文字の読書で一つ増える計算になります。
カルマは読書だけで増えるわけではないのですが、カルマの9割はおそらく読書カルマだと思いますので（未確認）、ここではカルマ＝読んだ原稿用紙の枚数、という前提にしておきましょう。

先ほどの試算を元にすると、
400字のコストは約7円（0.0176 * 400）で、
縦書き文庫の平均カルマは現在138ですから、
縦書き文庫のユーザーさん一人当たり金額に換算すると、

138 * 7 = 966円

つまり一人当たり千円ぐらいの価値を（他人の為に）生み出してくれている、という結果。

ということは、縦書き文庫の現在のユーザー数は309人なので、全体の価値にすると

966 * 309 = 約30万円

これに加えて、非ログインユーザーのカルマが現在2万5328なので、

25328 * 7 = 約18万円

つまり合計で約50万円ぐらい。多いのか少ないのか良くわかりませんが、仮に寄付金がこんだけのサイトがあったとしたら、なかなかじゃないでしょうか。

試算した善意の総量がこれだけあるってことがわかったら、なかなかネットも捨てたもんじゃないな、という気になりました。

青空文庫の資産価値なんてものも、計算してみると楽しいかもしれませんね。

2006年頃に登録した夏目漱石の作品で、ルビに該当する部分の文章がごっそり抜けていたみたいです。全く気が付かなかったです。報告ありがとうございました。その当時の青空文庫の文章を取ってくるプログラムがバグっていたのだと思います。再登録して抜けが無いようにしておきました。

次にIE以外のブラウザにおけるバグですが、サムネールにおいて、一部の文字のリンクに枠線がついてしまう問題を修正しました。

同じくIE以外のバグで、エディタの作業アイコン経由でルビを振ったり太字にしたりリンクをつけたりするたびに、テキスト入力欄のスクロールが先頭に戻ってしまう問題を修正しました。

次に、サムネールにて、あらすじを出さない方法について。
ヘルプに追記してありますが、サムネールの埋め込みコードに

summary_enable=0;

という記述を足せば、表紙のページからあらすじの文章を消すことが出来ます。

最後に、「テキストを変えてもプレビューの表示が変わらない」という人がいたのですが、入力と同時にプレビューが自動的に更新されるような作りにはなっていないので、「プレビューする」というボタンを押さないと表示は変わりません。

Google Gears に対応したビューアを作りました。

先日リリースしたdeluxe 型のビューアーですが、やはり大き目の作品を開くときにストレスが大きい……長い作品ほど栞を挟みつつ何度も開く必要があるのに、その度に再計算で待たされるのは、ちょっとしんどいです。

で、これを何とかできないもんかと色々と試行錯誤していたら、google gears というものを見つけまして、これ使ったら一発ジャナイカ！と思いました。

gears はちょっと前に作った（そして現在は色々あって非公開にしている）P2P型の出版システム「一期一会」と似たような仕組みでして、ローカルにサーバーを作って色々なリソースをクライアント側のＰＣに保存することを可能にするものです。

これを使えば初回ロードで発生した計算結果をローカルに保存出来るので、二回目以降は高速に作品を開くことが出来そうです。テキストもローカルに保存しちゃうので、サーバーへの負荷も小さくなります。

問題なのはサーバー側でテキストを編集したときに、ユーザーがローカルのファイルを読みに行ってしまうので変更が反映されないことと、gears そのものが現在はIE と Firefox だけでしか使えないことでしょうか。

後者に関してはどうしようもないので今後のgoogleの対応を期待するとして、前者に関しては念のため最新テキストを再取得するリンクを付けときました。

ついでに、gears対応のビューアーで作品を開くブックマークレットを用意しました。

このリンクをドラッグアンドドロップでブックマークバーとかに登録してください。

作品を開いてから、このブックマークレットを起動すると、gears対応ビューアーで作品を開きます。

あるいは、作品ページのURL 欄に直接、作品名のあとに今回作成したgears対応テーマ、
「gears-black」を指定してもOKです。

http://(中略)/fview.fcgi/(作品番号)/gears-black

ちなみに、gears がインストールされていない状態で開いた場合はインストールページに飛ばされます。

またインストールした後、初めてgears 対応のビューアーを開く際にはこんなダイアログが出ますが、




「trust this site」の部分にチェックを入れて、「Allow」をクリックして下さい。
許可した直後に文章が表示されない場合は、リロードしてみてください。




これで初回の計算だけ我慢すれば、２回目以降は高速に起動するように。

青空文庫読みにはマストなビューアーと言えるかもしれませんね。

なお栞の使い方に関してはちょっと注意があります。

栞データそのものは、ビューアーとは独立しているので、デラックス型のビューアー（現在は、deluxe-black と gears-black）において共通にロードできますが、栞は現在開いているビューアーを使ってロードされる仕様なので、例えば先日公開した deluxe-black から開いた栞はdeluxe-black でロードされます。しかし、deluxe-black は gears には対応していないので、テキストは普通にダウンロードされ、ページも普通に再計算されます。

同様にgears-black で作品を開き、栞を開くと栞はgears-black で開かれます（そして計算結果やテキストがローカルに保存され、次回から高速に起動出来るようになります）。

《追記》

ユーザー投稿は3万字までなので、この機能は殆ど青空文庫の長編にターゲットを絞った機能といえます。
というわけで、青空文庫の表示に際しては下のメニューに「Gearsで読む」というリンクを設けました。

新型でもログに対応しました。
結構な大改造だったので、ちょっと不安です。
そして疲れた。

主な変更点としては、今までは1600文字（原稿用紙4枚分）の区切りでログを取っていたのが、今後は本当のページ送りでログがでます。つまりログがさらに細かくなります。

ついでに、カルマの単位も変わりました。
これまでは原稿用紙4枚単位で1つ増えていた読書カルマが、400文字単位で増えることになりました。これで短編の読書もカルマ加算出来ます。

となると、過去のカルマは4倍しないと採算が合わなくなりますね。
急にカルマがでかくなってビックリしている人もいるかもしれませんが、そういう事情です。

通常型で表示している作品を、デラックス型で開くブックマークレット。

このリンクをドラッグ・アンド・ドロップでブックマークに登録してください（ブックマークツールバーとかに登録すると便利）。

で、作品を開いた後に登録したブックマークをクリックすると、デラックス型で作品がロードされます。

URL欄に直打ちするのが面倒な人はどうぞ。