読者です 読者をやめる 読者になる 読者になる

エディターに字下げ、引用、改ページ、セリフ、補足ボタンを追加

エディターに字下げ、引用、台詞、補足、改ページボタンなどを追加しました。

f:id:convertical:20150826204020p:plain

改ページについては説明不要かと思いますので、それ以外について少し補足します。

字下げ、引用の違い

字下げ、引用は選択範囲を選んでから押してみてください。

「字下げ」と「引用」の表示の違いはこんな感じです。

f:id:convertical:20150826204139p:plain

「補足」(チップリンク)について

補足を使うと、次のようにクリックで説明ダイアログが出るリンクを表示できます。

f:id:convertical:20150826204555p:plain

ここで「パソコン」をクリックすると

f:id:convertical:20150826204617p:plain

のようなダイアログが出ます。

使い方としては、対象のテキストを選択してから「補足」ボタンを押します。

すると次のようなダイアログが出るので、そこに補足説明を入力して下さい。

f:id:convertical:20150826204717p:plain

台詞(セリフ)ボタンについて

キャラクタを作成して、作品に「キャスティング」すると、エディタに次のようなドロップダウンボタンが出現します。

f:id:convertical:20150826204825p:plain

台詞を言わせたいキャラクタをクリックして、文章の部分を追加すると、次のように脚本形式のような表示になります。

f:id:convertical:20150826205008p:plain

これで各キャラクタをクリックすると、キャラクタの説明が出ます。

f:id:convertical:20150826205108p:plain

制限事項

外部への埋め込み作品では、台詞表示とチップ表示が出来ません。

いつの間にかFileAPIのreadAsBinaryStringがオワコンになっていた。今後はreadAsArrayBufferで。

タイトルで全てを言い尽くしてしまいましたが、経緯をば。

不具合報告で「IEで画像のアップロードができない」ってのがあったので調査してみたら、readAsBinaryStringでコケてました。

調べてみると、どうもIE系列ではreadAsBinaryStringそのものが存在しないらしく。

なんでなのかというと、そもそもこのAPI、将来的になくなる方向らしいのです(実際にw3cのドキュメントからも消えてる)。

というわけで、readAsBinaryStringreadAsArrayBufferに置き換えたら、IE11でも(もちろんChrome/Firefoxでも)問題なく動いたのです。

非推奨になった理由

で、なんで非推奨となったのかというと、単に効率が悪いからだそうで。

https://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1497.html

要約すると「このメソッドは型付の配列(ArrayBuffer)が標準化されるに作られた実装で、バイナリデータを文字列に変換するから効率が悪い」とのこと。

今は型付の配列は既に実装されていて、それを読み取る関数(readAsArrayBuffer)もあるわけなので、非効率的な古いAPIに存在意義はない(から削除するべきだ)、ということなんでしょうね。

というわけで、これからはreadAsArrayBufferなのです。

Blobを作らなくても、fileオブジェクトならそのまま渡せます。

RxJSとvirtual-domで、拡張可能なreactiveアプリケーションを作るフレームワーク - inga

inga(因果)は、軽量で拡張可能なリアクティブアプリケーションを作るフレームワークです。RxJSとvirtual-domを使っています。

github.com

よくあるTodo-MVCは100行ぐらいです。

inga/todo-mvc.js

特徴

  • 軽量なこと。全ソース合わせても100行ちょっとしかないです。
  • プラグインで拡張可能です。
  • 副作用の処理をthunkで扱うストリームがデフォルトで付いているので、大抵のイベント処理はこれで済みます。

簡単なサンプル

例えばクリックする度にカウンタが増える、みたいなのは次のようになります。

var Inga = require("inga");

Inga.define({
  domRoot:"#app",
  dataSource:new Inga.ActionStateStream({
    initialState:{clickCount:0}
  }),
  virtualView:function(ctx){
    return h("button", {
      "ev-click":function(ev){
        ctx.action.emitUpdater(function(state){
          state.clickCount++;
        });
      }
    }, ctx.state.clickCount);
  }
});

プラグインを使ったサンプル

例えばinga/plugins/scroll-posを組み込むと、こんな感じでレンダリング・コンテキストの状態オブジェクトにscrollPosが合成されます。

var Inga = require("inga");

Inga.define({
  domRoot:"#app",
  dataSource:new Inga.ActionStateStream({
    initialState:{scrollPos:{x:0, y:0}},
    // plugin 'scroll-pos' combines 'scrollPos' to status object.
    plugins:[
      {module:require("inga/plugins/scroll-pos"), options:{combine:true}}
    ]
  }),
  virtualView:function(ctx){
    return h("div", [
      h("p", "x = " + ctx.state.scrollPos.x),
      h("p", "y = " + ctx.state.scrollPos.y)
    ]);
  }
});

自前のストリームを合成するサンプル

デフォルトのストリームに、自分で作ったストリームを組み込む場合は次のようにcombineアクションを定義します。

var Rx = require("rx");
var Inga = require("inga");

Inga.define({
  domRoot:"#app",
  dataSource:new Inga.ActionStateStream({
    initialState:{width:window.innerWidth},
    actions:{
      // extend default stream by your own source.
      combine:function(initial_state, upstream$){
        var width$ = new Rx.Observable.fromEvent(window, "resize")
          .debounce(250)
          .map(function(event){
          return window.innerWidth
        })
        .startWith(window.innerWidth);

        return upstream$.combineLatest(width$, function(state, width){
          state.width = width;
          return state;
        });
      }
    }
  }),
  virtualView:function(ctx){
    return h("p", "current window width = " + ctx.state.width);
  }
});

その他

ライセンスはMITです。

管理画面がスマホにも対応しました

管理画面リニューアルのお知らせです。

スマホとPCでUIを統一し、どちらからも同じUIで使用できるようになりました。

エントリーの一覧には、カードUIを使用しています。

PCユーザーからすると、元のテーブルレイアウトのほうが一覧性が高いかもしれませんが、どうしてもスマホとの共存が難しくなってしまうので、今回はカードUIを採用しました。

リニューアルした背景

最近はアクセスの半分近くがスマホ経由で、執筆作業もスマホで行う人が増えてきていたので、それに対応した感じです。

注意事項

新管理画面には、まだスタイル編集画面が入っていません。

バグを見つけたら

通常のメジャーなブラウザは動作を確認していますが、古いAndroid系のブラウザなどでは、わかりません。

ちなみにIE8以下、Safari5以下のサポートはやめました

もし不具合等がありましたらメールフォームから連絡くださると助かります。

nehan.jsのセレクターマッチング処理を高速化

nehan.jsのセレクタのマッチング処理を高速化しました。

先日サポートした行末揃えは、有効にすると20%ほど遅くなりましたが、今回の修正によって15%ほど速くできたので、少し戻すことができました。

前々から、機会があったらやっておこうと思っていた処理でもあったし、ちゃんと効果があって良かったです。

最適化の内容

やっていることは単純で、セレクタのマッチング結果を(キャッシュできるものに限り)キャッシュしただけです。

ただしマッチ結果には、キャッシュしやすいものとしにくいものがあるので、その辺のことについてちょっと説明します。

属性セレクタのマッチング結果はキャッシュが困難

属性セレクタは、マークアップや親が同じでも、マークアップが現れる相対的な文脈によってマッチしたりしなかったりするので、常に同じ値が返ってくるとは限りません。

これに対応するためには、属性クラスの情報をキャッシュキーに盛り込む必要があります。

しかし例えば次のようなマークアップを考えてください。

<div>
  <p class="foo">text0</p>
  <p class="foo">text1</p>
  <p class="foo">text2</p>
</div>

<div>
  <p class="foo">text3</p>
  <p class="foo">text4</p>
  <p class="foo">text5</p>
  <p class="foo">text6</p>
</div>

ここでtext2text6を内容に含むpタグをそれぞれp2p6と名付けることにします。

さて、p2p6のキャッシュキーはどうなるでしょうか。

両者の特徴をフルに含んだキャッシュキーを設計するとなれば(擬似的な記述ですが)こんなかんじになりそうです。

// p2のキャッシュキー
div>p.foo[nth-child=2, first-of-type=false, last-child=true, last-of-type=true, ...]

// p6のキャッシュキー
div>p.foo[nth-child=3, first-of-type=false, last-child=true, last-of-type=true, ...]

殆ど同じキャッシュキーですが、nth-childの値だけが異なります。

しかし両者は木構造の位置として、性質的には殆ど同じものです(divの直下にあるpタグの最後の要素)。

なので、p2p6のどちらも、次のセレクタにマッチします。

div>p.foo:last-child{ font-size:2em }

しかし、nth-childの値が違うだけで、違うキャッシュキーとなるわけです。

これを同じキャッシュキーにするわけにはいきません。なぜなら属性クラスはnth-childを使っている「かも」しれないからです。 属性クラスをキャッシュして(他の場所で)再利用するなら、確実に属性クラスが表現しうる全ての特徴が一致している、という保証が必要なのです。

というわけで、仮にp2のマッチ結果をキャッシュしたところで、同じ結果がp6のマッチング時に再利用されることはありません。

キャッシュが効果的なのは、どれだけ再利用されるかにかかっているのですが、こうやってキャッシュが分散すると、ヒット率が落ちる上に容量も食うわけで、かえって性能を損ねるおそれが出てきます。

というわけで、キャッシュキーが分散しがちな属性セレクタについては、都度マッチする方針で統一しました。

ただし、属性クラスを含むセレクタは別の領域に保存しておくなどして、前もって検索範囲を狭めておく、というようなことはしています。

キャッシュできる属性クラスのセレクタを書く方法

しかし、上記のようなp2p6で、同じマッチ結果がキャッシュされるようなセレクタが書きたい! と思いませんか?

nehan.jsならこれができます。

nehan.jsでは、cssプロパティに関数値を設定できるので、先ほどと同じ場所(div>p.foo:last-child)を、属性クラスを使わずに指定することがでるのです。

例えば以下のように、属性クラスの判定を遅延評価の関数に追い出すことで、セレクタの詳細度が減った「キャッシュヒット率の高い」セレクタを宣言することができます。

"div>p.foo":{
  onload:function(ctx){
    if(ctx.isLastChild()){ // is last-child?
      return {fontSize:"2em"};
    }
    return null;
  }
}

大まかなものでマッチさせておくことでセレクタのマッチング結果をキャッシュさせ、last-childのような詳細で決まるスタイルについては、遅延評価で取得させるわけです。

一見すると、スタイル値の取得に際し関数呼び出しのオーバーヘッドが発生するように見えますが、これは属性クラスの条件判定をセレクタ検索時に計算するか、検索後に計算するかの差でしか無いので、性能差には結びつきません。

属性クラスバージョンと遅延評価バージョンの性能差

とはいえ、セレクタ数が少ないケースでは、どちらの書き方をしても、たいして性能の差はありませんでした。

字数が40万字、セレクタ数が5000個ぐらいのラインを超えると、さすがにキャッシュの効く遅延評価バージョンの方が22%ぐらい速かったですが…

マージ後のスタイル値はキャッシュ出来ないのか

マッチしたセレクタは、specificityの順にソートし、最終的なスタイル値へとマージされます。

この最終的なスタイル値をキャッシュできると更に良いのは言うまでもないことですが、nehan.jsではcssの値に関数を指定できる仕様がある関係上、これが難しくなっています。

関数値で指定された値は実行時に値が決まるサンクなので、ある特定のタイミングで呼ばれて返ってきた結果を、永続的な最終値としてキャッシュすることはできないからです。

そもそも仮にキャッシュしたとしても、スタイル構築で時間がかかるのは圧倒的にセレクタ検索の部分なので、大した効果は期待できないと思われます。

text-align:justify に対応

nehan.jsが、text-align:justifyに対応しました。

縦書き文庫では既に、ビューアーのbodyに対してjustifyが設定されています。

これを設定すると、例えば行末に赤い部分のような微妙なスペースがあっても…

f:id:convertical:20150720170302p:plain

揃えた後はこんな風に、行末が揃います。

f:id:convertical:20150720170313p:plain

あらゆるケースで完璧に揃うわけではありませんが…まあ大抵は揃うようになっています。

ちなみにjustifyを指定すると、少し変換が遅くなります。

自分の環境では20%ほど遅くなりました。

それだけのコストを払った結果、たまに行末がちょろっと揃うだけという状況をどう考えるか…というところなのですけど。

実のところ、自分は今回の実装をするまでずっとjustifyのことを、禁則処理って意味だと勘違いしていたぐらい意識が低いので、割りと「どっちでもいいかなあ」派です。

そもそも横文字が入らない小説だと、なにもしなくても大抵は揃っちゃうんですよね。

ちなみに禁則のことは、英語で(japanese) hyphenationというのだそうです。

余談

均等揃えとか行末揃えについては、日本語組版処理の要件を、ちょろっと斜め読みした程度ですが、ざっくりいうと

  1. まずベタ組を保つことが最優先
  2. その上で、まず削れるところを削り、次に空ける

みたいなことらしいです。

ただ自分の感覚では、カッコや句点読点の前後にあるスペースが狭くなるのは好みじゃなかったので、そのケースでは削らないようにしました。

nehan.jsが複数ページに渡る論理的な回りこみ処理(論理フロート)の解除に対応しました。

リポジトリ上のnehan.jsで、論理的な回りこみ処理(論理フロート)の解除を実装しました。

回り込みを解除するスタイル設定ですが、通常のcssでは、

.clear-left{ clear:left }
.clear-right{ clear:right }
.clear-both{ clear:both }

などと書くところですが、nehan.jsでは

.clear-start{ clear:start }
.clear-end{ clear:end }
.clear-both{ clear:both }

のように、縦書き横書きに依存しない論理方向でクリアを指定します。

leftstartに、rightendに対応している点に注意して下さい。

サンプル

例えば「あいうえお…」から始まる文字列で、回りこみを解除することを考えます。

何も解除しないとこうなるものとします。

f:id:convertical:20150718172002p:plain

ここから「あいうえお…」の文字列をclear:endすると、こうなります。

f:id:convertical:20150718172055p:plain

ここから「あいうえお…」の文字列をclear:startもしくはclear:bothすると、こうなります。

f:id:convertical:20150718172113p:plain

start方向の回り込み要素のほうが大きいので、こっちを解除すると結果的にbothと同じ結果になります。

縦書き横書きの自動リサイズに対応したページ送りのビューアー「responsivook」

縦書き横書きの自動リサイズに対応したページ送りのビューアーを公開しました。

github.com

ブログやホームページに簡単に埋め込むことができます(たぶん)。

デモ

デモページを用意しました。

» デモページを見る

上のページを開いて、ページをリサイズしてみて下さい。

ビューアーの表示領域が自動で伸縮するのがわかると思います。

スマホページなどでも使いやすいのではないかと。

インストール

必要なソースをheadなどにインクルードします。

nehan.js および nehan.css が必要なので、先にダウンロードしておいて下さい。

nehan.jsdistフォルダ、nehan.csscssフォルダに入ってます。

<!-- stylesheet -->
<link rel="stylesheet" href="/path/to/nehan.css">
<link rel="stylesheet" href="/path/to/responsivook.css">

<!-- scripts -->
<script src="/path/to/nehan.js"></script>
<script src="/path/to/responsivook.js"></script>

使ってみる

例えばページ内の<div class='post-content'> 〜 </div> を縦書きページ送りのビューアーにしたいなら、</body>の直前あたりで、次のように呼び出します。

<script>
  document.addEventListener("DOMContentLoaded", function(event){
    Responsivook.start(".post-content", {
      flow:"tb-rl" // 横書きなら"lr-tb", 左縦書きなら"tb-lr"
    });
  });
</script>

カスタマイズ

以下、色々とカスタマイズのサンプルを紹介します。

ページサイズを固定に

レスポンシブの意味がなくなりますが、どうしても固定サイズが欲しいなら、次のようにします。

Responsivook.start(".post-content", {
  flow:"tb-rl", // 縦書き
  fontSize:16,
  width:500,
  height:400
});

ただし、スマホタブレットを含む色々なデバイスで読まれることを想定するなら、ページサイズや文字サイズは何も設定しない(自動で計算させる)ほうが良いと思います。

ボタンの色とかラベルとか

たぶんこれが最も使われるオプションじゃないかなと思います。

ボタン色に指定できるのは、sea, dark-blue, red, rouge, dark, orange, sunflower, concrete です。

色の値を指定するのではなくて、用意されたテーマ名の中から選択する形になります。

Responsivook.start(".post-content", {
  flow:"tb-rl",
  
  // 左右のボタン色の設定
  // 有効な値:'sea', 'dark-blue', 'red', 'rouge', 'dark', 'orange', 'sunflower', 'concrete'
  leftColor:"darkblue",
  rightColor:"red",

  // 左右のボタンのラベル
  leftLabel:"ひだり!",
  rightLabel:"ミギー"
});

文字色、文字サイズ、フォントファミリ、背景色

文字色、背景色などは別途スタイルシートを使って設定しても構いませんが、文字サイズやフォントファミリは、ページ組版の計算に直結する大事な値なので、スタイルシートで設定することはできません。

Responsivook.start(".post-content", {
  flow:"tb-rl",
  fontSize:16,
  fontFamily"Meiryo",
  color:"#666", // 文字色
  backgroundColor:"#ccc"
});

上級者向けのカスタマイズ

以下は少し上級者向けのカスタマイズです。

ページ内のスタイル

オプションのstylesを使うと、セレクタ(下の場合.post-content)に紐付いたビューアーのページ内スタイルを、nehan.js形式で記述できます。

nehan.js形式のスタイルについては、縦書き文庫のヘルプでユーザースタイルの項などが参考になると思います。

Responsivook.start(".post-content", {
  flow:"tb-rl",
  // ページ内スタイル
  styles:{
    "h1.foo":{
      fontSize:"2em",
      margin:{before:"1em", after:"1em"}
    },
    ".important":{
      fontWeight:"bold",
      color:"red"
    }
  }
});

全ビューアーに共通のページ内スタイルを設定する

Responsivook.setStylesを使うと、画面上に存在する全ビューアーに共通するページ内スタイルを設定できます。

一つ前のやつは、マッチしたセレクタ(上の場合だと.post-content)にだけ有効なスタイルになりますが、こちらで指定すると、別のセレクタで起動したビューアーでも有効になります。

全てのビューアーで共通のスタイルを使うなら、こちらを使ったほうが効率的でしょう。

ただし、この関数は、Responsivook.start前に呼ぶ必要があることに注意して下さい。

// 先にセットしておく
Responsivook.setStyles({
  ".paragraph":{
    fontSize:"0.9em",
    margin:{after:"1.5em"}
  }
});

Responsivook.start(".post-content", {
  flow:"tb-rl"
});

表示完了後のコールバックとか

スマホなどでは、HTMLのBUTTONタグに対する反応が、300msほど遅くなることはよく知られていることです。

これはタッチとプッシュを区別するための意図的な仕様なのですが、ビューアーに関する限り、触ったらすぐに次ページへと進みたいものです。

というわけで、これを素早くさせるためには、表示完了後に呼ばれるonCompleteをフックして、クリックイベントをタッチイベントにする処理を埋め込むと良いでしょう。

下の処理では、fastclick.jsを利用しています。

Responsivook.start(".post-content", {
  flow:"tb-rl",
  onComplete:function(){
    FastClick.attach(document.body);
  }
});

圏点・傍点用の自前タグを定義

傍点タグをspanで打つのが面倒な人は、自前のタグを登録してしまいましょう。

以下のようにしておくと、sesameとか、dotという傍点のタグを定義できます。

Responsivook.setStyles({
  dot:{
    display:"inline",
    textEmphasisStyle:"filled dot"
  },
  sesame:{
    display:"inline",
    textEmphasisStyle:"filled sesame"
  }
});

Responsivook.start(".post-content", {
  flow:"tb-rl"
});

こうしておけば

ここに<sesame>ゴマ点</sesame>、ここに<dot>ドット</dot>

マークアップできます。

総括

responsivook.jsは、僅か200行ちょっとの軽量なスクリプトです。

依存ライブラリもnehan.jsだけなので、スマホサイトでも扱いやすいのではないでしょうか。