document

はじめに

本日 zlib.js 0.1.6 をリリースしました。ここでは告知とともに 0.1.6 の更新内容などを簡単に説明したいと思います。

なお、今回から Change Log を添付したあるので概要はそちらでも確認できます。
今回のバージョンでは主にビルド環境の整理やテスト・デバッグ効率の向上を行っています。

https://github.com/imaya/zlib.js

ビルド環境の更新、最適化

zlib.js は Closure Compiler でビルドしているのですが、今までは minify したコードに余分なコードが含まれている事がありました。
今回の更新では Closure Compiler の更新とその辺りの設定を見直す事で minify したファイルのサイズを縮小しました。
例えば、Inflate だけならば約 7KB とさらにコンパクトになっています。

Raw 形式、CRC-32 の独立ビルドの追加

今までは Deflate アルゴリズム単体でのビルドはなく、ZLIB や GZIP, PKZIP などのコンテナ形式への対応だけでしたが、今回からは Deflate のみの利用が可能になりました。

以下のようにして使います。

var plain = new Uint8Array(1024);

// compression
var compressed = new Zlib.RawDeflate(plain).compress();

// decompression
var decompressed = new Zlib.RawInflate(compressed).decompress();

また、CRC-32 アルゴリズムも単体で利用する事ができるようになりました。

var plain = new Uint8Array(1024);

// CRC-32
var crc32 = Zlib.CRC32.calc(plain);

Pretty Print ビルド、Source Maps のサポート

今回から開発・デバッグ用に Pretty Print されたバージョンのビルドと、Source Maps のサポートを追加しました。
Source Maps の使い方はドキュメントに書いてありますが、とりあえず使えるようにしただけなので使いにくいかも知れません。
もっと良い構成などありましたら教えていただけると助かります。

Travis CI のサポート

今回のバージョンから Travis CI をつかって Firefox, Chrome で自動テストを行うようにしました。
…とはいっても、時々テストに使っている BusterJS の実行がささってしまうのでイマイチな時もあります。

ストリーム展開のビルドを修正

zlib.js では inflate_stream.min.js というファイルで実験的にストリーム展開に対応しています。
前回のバージョンでは手違いでストリームに対応していないままになっていたのを修正を行いました。

はじめに

JavaScript でアプリケーションを作っていると、筆圧を取得したくなることがよくあると思います。
ここでは JavaScript でタッチやペンによる筆圧の取得の仕方について簡単にまとめます。

Wacom ペンタブレットによる筆圧の取得

Wacom のペンタブレットではブラウザにプラグインをインストールすることにより筆圧の取得が可能になります。
最近はタブレットの最新版ドライバをインストールすると一緒にプラグインもインストールされるようです。

タブレットプラグインのバージョンによる API 変更

Wacom のタブレットプラグインでは元々ペンを扱う単体のものでしたが、バージョン 2 からはタッチと統合されたため API が変更されました。
基本的には統合であるため、プラグインのオブジェクトに .penAPI を付けるか付けないかの違いしかありません。

筆圧の取得

まず、以下のように Wacom タブレットプラグインをドキュメント上に設置します。

<object type="application/x-wacomtabletplugin"></object>

タブレットプラグインでは、後述する Touch Events や Pointer Events の様にイベントに筆圧がついてくるわけではないので、イベントのハンドリング自体は Mouse Events で行い、そこで筆圧を取得するのが良いと思います。

// プラグインの object 要素を取得
var plugin = document.querySelector('object[type="application/x-wacomtabletplugin"]');
var pressure;

// Pen API からペンの筆圧を取得する (pointerType:1 = ペン, 2 = マウス, 3 = 消しゴム)
if (plugin && plugin.penAPI && plugin.penAPI.isWacom && plugin.penAPI.pointerType === 1) {
  pressure =  plugin.penAPI.pressure;
}

筆圧以外の情報やタッチについても取得したい場合は Wacom の WebPluguinReleaseNote を参照。

Touch イベントによる筆圧の取得

モバイル環境 (Android) ではスタイラスと筆圧に対応した端末もいくつかあります。
Chrome や Firefox では Touch オブジェクトに筆圧のプロパティがあります。
現在 Chrome ではプレフィックス付きの webkitForce, Firefox では単に force となっています。

touchstart, touchend, touchmove などのイベントをハンドリングし、その中で TouchEvent オブジェクトの上記プロパティを参照すると良いでしょう。

このプロパティのサポート状況は以下のようになっています。

	webkitForce	force
Android Chrome 17+	O	-
Android Browser(4.1)	-	-
Firefox 6+	-	O
iOS Safari(6.0)	-	-

Pointer Events (IE10) による筆圧の取得

IE10 では Pointer Events というTouch Events とは別のイベントでタッチやペンの入力を扱う事が出来ます。
ブラウザが Pointer Events に対応しているかどうかは navigator.msPointerEnable によって判断することができます。
MSPointerDown, MSPointerUp, MSPointerMove などのイベントをハンドリングし、その中でイベントの pressure プロパティを参照することで筆圧を取得します。
また、入力がマウスなのか、ペンなのか、それともタッチなのか判別することもできます。
なお、筆圧が取得可能なのはペンのみで、タッチでは pressure は 0 に固定されるようです。

var pressure;

// PointerEvent からペンの筆圧を取得する
if (window.navigator.msPointerEnable && pointerEvent.pointerType === MSPointerEvent.MSPOINTER_TYPE_PEN) {
  pressure = pointerEvent.pressure;
}

まとめ

それぞれの環境で利用可能な筆圧の取得方法をまとめると以下のようになります。

環境	Wacom Tablet Plugin	Touch Events	Pointer Events
Windows(PC), MacOS	O	-	-
Windows Tablet + IE10	-	-	O
Android Chrome	-	O	-
Android Firefox	-	O	-

ただし、現在 WebKit で Pointer Events の実装が勧められているみたいなので、今後は Android でも Pointer Events で取得できるようになるかもしれません。

なお、筆圧はどの方法でも 0 から1 の範囲になります。

はじめに

JavaScript でバイナリから文字列を取り出したら Shift JIS だったなんてことよくありますよね。
そういう文字列もさっと表示したいことがあります。

読み込む方法はいくつかある

これらの文字列を読み込む方法はいくつかあって、自分が把握してるだけでも以下のものがあります。

1. Shift JIS と UTF-16 の対応表をつくる
   • ぽりごんさんの文字コード変換ライブラリ
2. Blob, File API を使って読み込む
   • 右京さんの javascriptのnative APIで任意の文字コードからutf8に変換
3. script, Data URL を使って変換

1, 2 の方法についてはそれぞれ解説や実装があるのですが、3 の方法については見当たらなかったので説明してみます。

準備

念のため 2 段階で文字コードの識別を試みます。

script 要素の charset 属性

script 要素には charset 属性というのがあって、この属性がセットされていた場合、指定された文字コードとして読み込みます。
仕様では Scripts in HTML documents(HTML4) や Scripts in HTML documents にかかれています。

Data URL

Data URL は The "data" URL scheme ( RFC2397 ) で定義されている、データを Web ページに埋め込むための URI Scheme です。
フォーマットはシンプルで

data:[<mediatype>][;base64],<data>

となっています。
このフォーマットの <mediatype> は以下のようなものになっています。

mediatype  := [ type "/" subtype ] *( ";" parameter )

ここから少し仕様を追っていくのが大変なので、簡単に説明すると mediatype には text/plain のような MIME Type だけではなく、text/plain; charset=Shift_JIS のように文字コードを指定する事ができます。
parameter の attribute と value について詳しく知りたい方は RFC2045 を参照してください。
ちなみに mediatype が指定されていない場合のデフォルト値は text/plain; charset=us-ascii となります。

変換を行う

script 要素と Data URL について説明したので、ここからそれを使って以下のように文字コードを変換します。

1. 変換前の文字列を文字列リテラルの文字列に変換する ( hoge という文字を 'hoge' という文字列に変換)
   • いくつかの文字は文字列リテラルとして正しくなるようにエスケープしてやる
     • バックスラッシュは \\
     • クオートは \x27
     • LF は \x0a
     • CR は \x0d
2. 変換後の文字列を受ける callback function を作る
   • 例えば以下のような感じです

   • function Callback(str) {
     console.log(str);
     }

3. 生成された文字列リテラルを引数にして callback function の呼び出しを行うスクリプト文字列を生成する

   • "Callback('hoge');"

4. 生成されたスクリプト文字列を Data URL に変換して script 要素で呼び出す
   • もちろん、Data URL と script は charset 指定する

欠点

script 要素の生成と追加を行っているので非同期でしか使えません。
同期で変換したい場合はぽりごんさんのライブラリを使うと良いと思います。

おまけ

これらをまとめてやってくれる azoth.js というのを作りました。
自分でやるのめんどくさいという人はどうぞ。

• azoth.js

ちなみに JavaScript の文字列 (UTF-16) から UTF-8 への変換と、UTF-8 からの変換は、escape/unescape, encodeURIComponent/decodeURIComponent で行う事ができるのでライブラリが必要なかったりします。

おわりに

一応簡単なテストなどもしていますが、もし考慮漏れなどありましたらお知らせください。

Emscripten で Zopfli を移植した際のメモを残します。
思ったより簡単に使えましたが、知らないとハマることも結構多かったです。

導入

自分の環境(Mac)では以下のような感じでやれば OK でした。この辺りは情報が豊富なので適当です。

• JS Engine は NodeJS だけで良いっぽいです
• 必要な環境は homebrew 環境なら brew install llvm だけ？
• あとは emscripten を clone するだけ
  • clang, clang++ の位置が llvm-link と違う場合はシンボリックリンクを張るなどして合わせる

使い方

C プログラムから JS へ変換

$ emcc *.c -o hoge.js

ライブラリの場合

通常だとリンク時最適化(LTO)によりエントリポイント(main関数)から到達可能な関数以外は省略されてしまいます。
そこで emcc のオプションに -s LINKABLE=1 をつけることでリンク時最適化を無効にし、すべての関数がそのまま変換されるようにします。
なお、この状態で -O2 なども併用可能みたいなので積極的に使った方が良いです。
不要な関数の削除などは Closure Compiler での最適化時に行うこととします。

JS から C プログラムへのデータの受け渡し

Emscripten の C の関数呼び出し用のメソッドを使う場合

Emscripten で変換したコードには ccall と ccallFunc というメソッドがグローバルスコープに作られます。
このメソッドは何をするかというと、配列や文字列などを C の関数に渡すのは面倒な手順が必要なんですが、それを引き受けてくれます。
（何が面倒かというと、Emscripten 側の JavaScript コードでは独自にメモリ管理を行っているので、JS側からそちらのメモリアロケートやコピーを行わなくては行けなかったり、スタックの管理などやることが結構煩雑だったりします。）

ccall の使い方

ccall では C の関数名がそのまま使えます。ただし、Closure Compiler などで関数名が変わると呼べなくなったりします。

var num = ccall("hoge", "number", ["array", "string", "number", "number"], [array, string, 1, 2]);

第一引数は関数名、第二引数は戻り値の型、第三引数は引数の型、第四引数は引数となります。
ちなみにここで型として "number" というのを使っていますが、実際に有効なのは "array", "string" だけでそれ以外なら何でも数値として扱われるようです。

ccallFunc の使い方

ccall, ccallFunc は第一引数以外は同じです。
ccallFunc では第一引数が function オブジェクトとなります。

var num = ccallFunc(_hoge, "number", ["array", "string", "number", "number"], [array, string, 1, 2]);

ファイルを使う場合

• Uint8Array などを仮想ファイルとして登録する
  • FS.createDataFile 参照
• C のプログラム側では fread などでファイルから読み込む

JS 側で使い終わったファイルは FS.deleteFile を忘れずに。

JS 実装例

// parent, name, properties, canRead, canWrite
FS.createDataFile('/', 'data', new Uint8Array([1, 2, 3, 4]), 1, void 0);

C 実装例

int main(int argc, char argv[]) {
  const char *filename = "/data";
  FILE *fp;
  unsigned char *buffer;

  fp = fopen(filename, "r");
  buffer = malloc(1024);
  fread(buffer, 1, 1024, fp);

  return 0;
}

Closure Compiler による最適化と Export

そのままだと実行効率もファイルサイズも良くないため、Closure Compiler で最適化を行います。

実行スコープの制限

生成された JavaScript ファイルはグローバルスコープにだだ漏れなので Closure Compiler の output_wrapper でスコープを制限する。

--output_wrapper="(function() {%output%})();"

ただし、このままだと全てスコープ制限されてしまうので、必要なものはグローバルスコープに明示的に出してやる必要があります。
今回は Export 用の js ファイルを作成することにしました。
Closure Library に乗っかるなら goog.exportSymbol, 乗っかりたくない場合は window に代入すれば良いです。

// closure library
goog.exportSymbol('Hoge', Hoge);

// vanilla js
window['Hoge'] = Hoge;

キャストされた値のポインタ参照によるメモリ境界の不具合

Emscripten ではヒープ（実態は ArrayBuffer ）を HEAP8, HEAP32 などでアクセスできるようにしています。
例えば、C でポインタの参照演算子を使用すると、unsigned char * のときは HEAP8, unsigned int * の時は HEAP32 で値を取得します。
ここでお気づきの方もいるかとは思いますが、ここに問題があって unsigned int * の場合は HEAP32[address >> 2] としてアクセスされるため、address が 4 の倍数でない場合はうまく動作しません。(4 で割ったあまりが切り捨てられている)

Zopfli では LZ77(LZSS) の最長一致を探す際に、unsigned char * の入力データを size_t が 8 バイトの時は size_t * にキャストして 8 バイトずつ、unsigned int * が 4 バイトの時は unsigned int * にキャストして 4 バイトずつ比較して高速化を試みています。
zopfli.js で使用している Zopfli では、ここの処理が上記の問題に当たっていたため Zopfli のこの最適化を行わないように変更してあります。

なお、この不具合の起こるヒープへのアクセスは emcc で -s SAFE_HEAP=1 オプションをつけることで検出できます。
自分はこのオプションを知らずに自力で調べて大変苦労しました。

はじめに

Zopfli が公開されてから zlib.js の Deflate 処理と比較したいなーと思っていたので、 Emscripten を使って JavaScript に移植してみました。
Emscripten を使うのは初めてのためいろいろ手間取りましたが、とりあえず動作するようになったのでご報告です。

zopfli.js

というわけで、JavaScript に移植したものを以下の場所で公開しています。
もし良ければご利用ください。
使い方は zlib.js と似せています。

• https://github.com/imaya/zopfli.js

zlib.js を使って簡単なテストも行っていますので使用できないほどのバグはないかと思いますが、何かあればお知らせください。

デモ

せっかく移植したので、Web ブラウザでファイル圧縮するデモを作成しました。
ちょっと Zopfli の圧縮率を見てみたいという場合に便利かもしれません。
また、言うまでもありませんがかなり処理が重いので覚悟してください。

• http://imaya.github.com/zopfli.js/
  • Web Workers, File API, Typed Array などの機能を使っていますので最近の Web ブラウザで見てください
  • 圧縮したファイルのダウンロードに download 属性を使っています

また、おまけで前回書いた PNG の IDAT を再圧縮する機能も移植しました。

おわりに

始める前は Emscripten + Zopfli とか重すぎて使い物にならないと思っていたのですが、思ったよりも高速に動作したため状況次第では使える場合もありそうな気がします。
また、現段階では Emscripten 用のパフォーマンスチューニングを行っていないので、さらに性能が向上できる可能性もあります。