Handling Unicode #6

そういうわけでぼちぼちと wasavi に組み込み始める。

まずは簡単そうな [cci]motionLeft()[/cci] からとりかかってみよう。

function motionLeft (c, count) {
// カウントの値を正規化
count || (count = 1);

// 現在のカーソル位置
var n = buffer.selectionStart;

// 現在行の書記素クラスタ群
var clusters = getGraphemeClusters(n);

// カーソルが位置する書記素クラスタのインデックス
var clusterIndex = clusters.getClusterIndexFromUTF16Index(n.col);

// 移動できないならメッセージを生成
if (c != '' && clusterIndex <= 0) { requestNotice({silent:_('Top of line.')}); } // 書記素クラスタ単位でカウント分戻る // ただし、0 未満にはしない if (clusters.length) { n.col = clusters.rawIndexAt(Math.max( clusterIndex - count, 0)); } // バッファのカーソル位置に上書き buffer.selectionStart = n; // キー名をコマンド列に追加 prefixInput.motion = c; // 水平移動なので、"記憶された水平位置" は更新する必要がある invalidateIdealWidthPixels(); // コマンド実行完了 return true; }

とこんなように Unicode のめんどくさい部分は全て Unistring が面倒を見てくれる。

Handling Unicode #5

GraphemeBreakProperty.txt、WordBreakProperty.txt、Scripts.txt から生成するデータの 1 エントリに従来 8 バイトを割いていたのを、5 バイトまで詰めてみた。

ただ、これで最適だというわけではない。npmjs.com 上のライブラリ grapheme-breaker では Trie 木の構造で GraphemeBreakProperty データを保持していて、そのサイズは約 3KB だ。同じデータが Unistring では約 6KB。すごい。

それはそれとして、そろそろ wasavi に組み込んでみたい。

Handling Unicode #4

やはり、漢字やタイ語云々についてはルールの中に組み入れるのはやめ、

  • 分割ルールで分割可能と判断され
  • 分割位置の左右の Scripts.txt 内のプロパティが Common でなく
  • 分割位置の左右の Scripts.txt 内のプロパティが同一である

場合には分割しないようにした。この拡張ルールは [cci]Unistring.getWords(str, useScripts)[/cci] の第 2 引数で有効にするかを指定できる。

それから、UAX#29 のルールだと、空白類を1文字ずつ分割してしまう。これはそういうようにデザインされているのかわからないが、wasavi に組み込むにあたってはとても不便そうだ。そういうわけで連続する空白類はひとまとまりの擬似的な単語として扱うようにした。

ちなみに Scripts.txt 併用ルールだと、連続する絵文字はひとまとめに扱われない。絵文字は Common スクリプトに含まれるからだ。でも、たとえば Chrome や Firefox で Ctrl+← や Ctrl+→ 使うとひとまとめにしてるんだよね。どうしようかな。

Handling Unicode #3

unistring に、UAX#29 における word boundary の定義に従って文字列を単語で分割するメソッドを追加したい。

そういうわけでやってみたところ、UAX#29 自身に書いてあることであるが、ドキュメントに例示されているアルゴリズムそのままだと、あまり実用にはならない。とてもありがちなことに、ラテン文字が処理のメインになっているのだ。なぜかカタカナだけは組み入れられているが……。ただこれは無理もないことで、日本語と中国語の場合は分かち書きをしないので単純なルールで分割することはできない。Mecab みたいな形態素解析プログラムの助けを借りなければならない。

しかしまあだとしても、例えばひらがなが1文字ずつ分割されたりするのは実際実用にならないわけで、ちょっとだけ拡張したい。

できれば実装自体は UAX#29 通りにして、分割のルールを独自に追加変更できるようなインターフェースを組み込もうかと思ったが、面倒そうなのでやめた。とりあえず UAX#29 で例示されているタイ語、ラオス語、クメール語、ミャンマー語、それから漢字とひらがなについて分割を禁止するようなルールを組み込んだ。ただこの辺はこれらのスクリプトに限定せず、WB14(なんでも分割可のルール)の直前に、同一スクリプト間は分割禁止、みたいなルールを追加するなど、ある程度一般化したほうがよいかもしれない。

そんなわけで WordBreakTest.txt の1489種のテストに全てパスするようになった。ちなみに書記素クラスタの方も GraphemeClusterTest.txt の402種のテストに全てパスする。

Handling Unicode

wasavi が正しくサロゲートペアや書記素クラスタと言った、Unicode のめんどくさいトピックを正しく処理できるようにするためにはどこをどう直したらいいのか考えている。

もちろん、これらの Unicode のめんどくさい部分が関わる個別の箇所に個別の処理を書き加えるのは正しくない。それらを統一的に処理するクラスなり関数を設けて、個別の部分では単にそれを利用するだけにしたい。

ここで、1 つのクラスを作ってみたい。このクラスは文字列を引数に取り、サロゲートペアを解決しつつ UCS4 のコードポイントの配列を生成し、さらにそれを書記素クラスタで分割する。このクラスは String に似たメソッドを持ち、String を操作するように書記素クラスタの配列を操作することができる。

例えば Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞ という文字列は UTF-16 の文字が 75 個も並んでる複雑なシーケンスだ。この中から G の部分だけ抜き出す、だとか、「ユーザが認識する文字」の数、つまり 6 を得ると言った処理は、String に対する操作では不可能なのだが、このクラスを使うことで


var us = new Unistring("Z͑ͫ̓ͪ̂ͫ̽͏̴̙̤̞͉͚̯̞̠͍A̴̵̜̰͔ͫ͗͢L̠ͨͧͩ͘G̴̻͈͍͔̹̑͗̎̅͛́Ǫ̵̹̻̝̳͂̌̌͘!͖̬̰̙̗̿̋ͥͥ̂ͣ̐́́͜͞");
us.length; // 6 が返る
us.substr(3, 1).toString(); // G̴̻͈͍͔̹̑͗̎̅͛́ が返る
us.charAt(3); // G が返る

と言ったように簡単に操作できるようになる。

というわけで、書いてみた。

実は、UTF-16 シーケンスを書記素クラスタに分割する javascript のライブラリというのはすでにあるのだが(ZALGO! もこのライブラリのドキュメントから取った)、純粋に分割するだけで String に似たメソッド群は提供してくれなかった。

tabqueue released

Opera12 の場合、各タブがアクティブになった順番を覚えていて、あるタブを閉じた時はその順番を逆にさかのぼることで、残ったタブのうちどれをアクティブにするかを判断する。これはとても賢い。しかし、Opera12 以外のタブは一切こういった動作をしない。

Firefox の場合は、まあいろいろあるんだと思うけど、とりあえず Tab Deque を入れることで同じ動作になる。

Chrome の場合はどうか。Chrome の場合は探しても見つからなかった。そんなわけで、ないものは作るの精神で、作った:

https://chrome.google.com/webstore/detail/tabqueue/pghkhbkcicjcmgobjcgcabpmngbljill

とりあえず虹裏でスレを立てて様子を見てみたのだが、TPC というものがすでにあるらしい。ほんとだ。

うーん、まあ、いいか!

a Surrogation

赤福プラスにおいて、絵文字を画像で表示する処理を追加したのだけど。

この絵文字というものはだいたいのところ、U+FFFF を超えるコードポイントを持っている。これはかなり面食らう。個人的には BMP を超える文字なんて誰が使うのかしら…などと高をくくっていたのである。しかし絵文字なんてキャッチーなものが収録され始めているわけで、ちゃんとやらないとこれは不味いのではないか? と不安になってきた。

ところが、wasavi ではこのへんの Unicode の異様にめんどくさい部分、つまりサロゲートペアと書記素クラスタの扱いはまだ一切何も考えていないのであった(更に輪をかけてめんどくさい bidi もだが)。しかしこれをちゃんとするとなると結構な大改造になる。どうしよう。

基本的には、バッファの内容の保持とそれを操作する機能は Buffer クラスが一元的に持っている。従って直すとしたらそれが主な対象になるのだけど、全てというわけではないので地道に探していじっていく他にない。

cfx to jpm #3

wasavi も 0.6.580 から jpm でビルドするようにした。ただこれらのツールは、ビルド時だけではなく実行時にも影響を及ぼす。大昔は Add on SDK のライブラリは個々の拡張に同梱されていたが(このため wasavi でも Firefox 版だけやたらサイズがでかくなるという問題がかつてあった)最近は SDK のライブラリは Firefox 自身が保持するようになっている。困ったことにこのライブラリが、cfx でビルドされたかあるいは jpm かで微妙に動作を変える。

たとえば cfx の [cci]require()[/cci] に比べて jpm のそれはより commonjs に準拠しているようになっていて、cfx では基準のディレクトリが常に lib なのだが(正確には、エントリポイントスクリプトの dirname かもしれない。未確認)、jpm では require() を実行したソースが位置するパスが基準になるのである。つまり lib/foo とか lib/bar とかだったりと可変なのだ。

これで何が困るのかといえば、wasavi や akahukuplus はソースの共通化のために require() の polyfill を定義しているのだが、ある関数を呼び出した際にその呼び出し元のソースファイルのパスを得るという標準的な方法がないことだ。

標準的な方法がないということは、標準的ではない方法を使わざるを得ないということで、具体的には [cci](new Error).stack[/cci] が返す文字列を取得して解析するしかない。しかしこれは非常に脆弱で、各ブラウザベンダがこのプロパティが返す文字列の内容をちょっとでも変えたら即破綻する。文字列ではなく、もっと構造化されたオブジェクトでスタックフレーム情報を返してくれればもうちょっとましなのだけど…。

さて、cfx から jpm への移行で最後に残ったのは赤福プラスだ。これも移行してみた。また、最近は絵文字が unicode のコードポイントにやたら導入されている状況を鑑みたり鑑みなかったりしつつ、コメント中の絵文字は twitter のそれと同様の画像で置き換えるようにしてみた。

akahukuplus-emoji

wasavi/0.6.580 released

リリースした。

Chrome: https://chrome.google.com/webstore/detail/wasavi/dgogifpkoilgiofhhhodbodcfgomelhe

Opera: https://addons.opera.com/ja/extensions/details/wasavi/

Firefox: https://github.com/akahuku/wasavi/raw/master/dist/wasavi.xpi

* * *

w/W/b/B コマンドがある。これらは vi 内の独自の文字の分類に従ってカーソルを移動させる。これ、Unicode における単語境界の仕様に準拠してもいいんじゃないかなあという気になりつつある。