• replaceActionStrings の1度のcallで複数の文字列を変更できるようにしました
• setActionVariables の実装

• replaceActionStrings で Push される型によって Fatal になる不具合がありました。

• AS2 Bytecode の表示改善
• sample 以下のファイル名の変更
• setShapeAdjustMode の実装を途中まで。(まだ動かない)

 SWFEditor で MC 入れ替えして一部の画像が表示できない問題が発生してる。

当初は MovieClip 間の depth の重複(仕様的には MovieClip 独立なのでプレイヤーのバグが無いか)を疑い、PlaceObject の depth をバイナリエディタで直接書き換えて、色々なパターンで実験したのですが。やはりそこは関係なくて。
MovieClip の nest も特別深くはない。メモリもまだ余裕がある。
画像の順番を入れ替えたり、サイズを変えたりの試行錯誤の末、
結論としては、携帯での Flash 再生で、透明度付きビットマップを重ね過ぎると、ある程度の深さから不透明で合成する制限でした。
しかもSWF中のSHAPEの数も(又は数が)トリガーになる謎制限。 Device Central で再現するので、Flash Lite の(多分暗黙の)制限だと思います。
考えてみれば、Alpha blending の処理は重たいので、そう何枚も重ねられないんですよね。 制限自体は妥当です。
という訳で、SWFEditor は無罪でした。
GD ライブラリの imagecopymerge を使って合成してから画像を差し込む方法を提案して、当初の目的は達成。

setActionVariables を使っていたので replaceActionStrings を勧めてきました。 実は既に試してたそうで、setActionVariables と同じように変数名を指定するものだと思って、それで動かないので使うのを諦めたとの事。
確かにわかりにくいので、マニュアルに図を追記しました。 あと、replaceBitmapData についても、単に Jpeg/PNG/GIF のどれでも指定できるだけに見えたみたいで、image id 以外にもサイズや色で指定できるという話をしたら、驚かれました。これはもっと宣伝した方がよさそう。^^;
会って直接話すことで学べる事は多いです。博多まで来て良かった。

• LLC (Low Cost Carrier) 初めて乗りました。JAL や ANA はサービス過剰だと思いました。
• お友達に勧められた、むっちゃん万十を見つけたけどテイクアウト方式で、近所で持ち込める場所見つからなかったので諦め。今度リベンジ。
• オフィスビルの前で社員の方が出迎えてくれました。感激しました。お土産も頂きました。有難うございます。
• 次、北海道辺りで困ってる人いないかな。（ドキドキ

Zlib (rfc1950)は単なる圧縮データのコンテナ((例えば、Zlib 以外のコンテナに GZIP (rfc1952)があります。))で、 圧縮自体は Deflate(rfc1951)という方式を使います。 Deflate はハフマン符号と LZ77 で圧縮を行います。

• ハフマン符号は、よく出てくる値を短いビットで、あまり出てこない値を長いビットで表現する事で、全体のビット数(つまりデータ量)を減らす方式です。
• LZ77 は、前の同じパターンがあれば、それと同じという事を示す符号だけ記録する事で、データ量を節約する方式です。

• Zlib は Big Endian です。Deflate は Little Endian です。ややこしいです。
• Deflate は bit 処理の際に 下位bitから順に切り出します。ややこしいです。
• しかも通常、上位bitが上位桁になりますが、ハフマン符号だけ下位bitが上位桁になります。ホントややこしいです。(実際処理すると合理的だと実感できますが)
• 固定ハフマン(BTYPE:1) ではLZ77の距離フィールドとして5bitを切り出しますが、これもハフマン符号同様下位bitを上位桁としたら、うまく処理できました。動的ハフマンでは、距離フィールドもハフマン符号なので、これはこれで合理的。(だけど仕様書からは読み取れないｗ)
• ハフマン符号で復元した時に出てくる値を 0〜255 でなく、0〜285 とする事で、256 を終端。257以上を LZ77 用として使えます。この 0〜255 を超えてマッピングされた値をアルファベットと呼ぶようです。(初め、わけ分からなかった)
• 固定ハフマンだと、アルファベットが287 まで範囲あるのに 285 までしか定義がなかったり、距離符号が5bitあるのに 30 までしか定義がなかったりと死に値があるので、理解になかなか自信が持てませんでした。(verify 的に)
• inflate が伸長です。(だってインフレだし)。deflate が圧縮です。(デフレね)。初め、語感から(de が戻す感じするので)逆だと勘違いしてました。

Deflate の圧縮フォーマットは３種類あります。

• BTYPE:0 無圧縮 (圧縮するとむしろ膨らむようなデータや、Zlib の体裁を保つだけで圧縮しなくて良いデータはコレ)
• BTYPE:1 固定ハフマン (決まったハフマン符号表を用います。データが小さかったり、出てくる値に偏りがなく繰り返しが多く出てくるデータに適している)
• BTYPE:2 動的ハフマン (ハフマン符号表を自分で定義出来ます。データがある程度多い場合はコレが適している。画像とか)

BTYPE:2 はカスタムハフマンとも呼ばれます。
動的ハフマンは、一般的にはハフマン符号で変換しながら、その途中でテーブルの中身を切り替える適用ハフマンの意味で使われる事が多くて、紛らわしいからです。

スライドには動的ハフマンの説明が無くて、 自分で解読しようとしましたが、やはり分からなくて、 困っていたら、7shi さんがその声を拾ってくれました。 僕でも分かった位なので、冒頭で紹介したスライドとこの記事を併せて読めば多分、猿でも Zlib inflate を実装出来ると思います！

• ハフマン符号長から符号テーブルを生成するのは、例題が示されていたので、すぐ法則が分かりましたが、3.2.2 に記述があると一言あると嬉しいかもしれません。