これまで使われてきたNetscape Plugin APIというのはつまり
ブラウザ側が用意したプラグインのインターフェースにのっかるかたち。
ChromeなんかのPepper APIだとまずflashが載ることを前提に
ブラウザ側がつくられているって理解でいいのかな。
だとすれば後者のほうがflash側にとってありがたいのは自明になる。

あくまでPPAPIについては、さきほど検索して眺めてみた付け焼刃程度の知識しかありませんが、私の雑感としては、PPAPIは音声・描画(2D,3D)などを「標準的」に用意しているわけで、仰る通りそこがNPAPIとの大きな違いでしょう。

NPAPIの基本的なコンセプトは、四角い枠(=プラグイン側から見たらウィンドウ)と通信機能はこっちでやるから中身は普通の(OSネイティヴな)アプリケーションみたいに勝手に作ってくれ、というものです。大抵のプラグイン開発者はこれで十分なんだと思いますけれど、Flashのように複数のOSに向けてリリースしたい場合は二度手間な部分が多々あるのは想像に難くありません。おそらくそういう部分で「OSを問わず」に作ることができる、ということでしょう。

つまり、ChromeやFirefoxは既にOSごとの差異を吸収するため抽象化をある程度行っているはずですから、プラグインがその部分へアクセスできるようにする、というのは理に叶っています。絵と音に関しては、すごくシンプルなことをしようと思っても、OSやデスクトップ環境ごとに細かな差異があって、「実は厳密に言うとその機能は使えないんだが、代わりにこういうのがある」といった具合でどの開発者も苦労していると思います。乱暴に言うと、ミドルウェアが担うべき部分をブラウザがやる、という感じでしょうか。

「ブラウザを問わず」の部分ですけれど、NPAPIだってマイナーなアップデートを繰り返しています。その新機能が使えるのは(Operaとかが追いついてくるわずかな期間は)Mozilla系統だけですから、対応ブラウザ数が少ないのと、他のブラウザで採用不能かどうかはまた別の問題だと思います。整ったインターフェイスが公開されていれば、一応は「ブラウザを問わず」で問題ないと思います。

ただ、HTML5をのことを考えると、どうにも中途半端な気はします。本来的な意味のNPAPIプラグインはMIMEタイプ別の機能提供なので、Flashのように(あるいは今は亡きJavaプラグインのように)プラグイン自体をキッチンシンクにするのは、本来想定されていたような王道的な使い方とは言えません。あえて言うなら、その無軌道さこそがFlash成功の秘訣でもあったでしょう。しかし、今、描画や音声をHTML側で標準化しようというご時世になって、なぜ「埋め込む」方へ戻っていってしまうのか、という質問をされたらお茶を濁すしかないんじゃないでしょうか。PPAPIがいくら先進的になったとしても、「本体ができることをプラグインでやる」という発想そのものは無茶だと思います。

とはいえ、Flashには膨大なコンテンツの遺産があるわけで、「今動いている奴が偉いんだ」の原理でいくと、PPAPIには当面の利があると言えるでしょうね。逆に、だからこそ「今動いてる奴だけでいいんだよな？」＝「HTML5でFlashのラッパーを作りさえすればいい」という発想になるんだと思います。

どこにぶら下げようか迷いましたが……

このアドオンは開発者のコメント通り

1. H.264その他を再生するプラグイン
2. <video>要素を<object>要素に変換する拡張

の2つの機能がセットになっています。

前者は問題ありませんが、後者は拡張としてはかなり筋が悪い部類に入ります。だって、ウェブサイトがわざわざ指定したvideo要素は、拡張側の勝手なDOM操作で無くなってしまうわけですからね。正直、これが普及するのはあまり望ましくありません。だから、そもそもの方向性を見直さずに「今後の開発」を続けるのはどうなんだろう、と思ってしまいます。

本筋の話をするなら、Gecko側がビデオコーデック/オーディオコーデックを受け付けるようになっていないとダメなんでしょうね。でも、今のところは(MNGなんかを考えても)現実的じゃない、と言わざるをえません。両者が本気で連携する気があるなら(Operaやその他も巻き込んで)共通規格を制定する方向での道があると思うんですけどね。なかなか難しい。

# ちなみに、ここの記事はH.264の事しか書いてませんが、この拡張は「video要素のwmvを」という側面もきちんとありますよ。

実際にやってみるとわかりますけど、画像の中身が一定以上古い場合、どうしたって「拾う」ことになります。

例えば、『王の写本』の場合、キーボードで入力できるのは全体の3割くらいで、残りの文字はCollation Chartなどから1文字ずつコピペしたり、M.U.F.I.の合字の表を眺めて16進の参照入力して作成しています。尤も、そういうことをしなくて良いように、各国は正書法や常用漢字を定めているわけですが、そこを敢えてマニアックな文字コードを使ってなるべく正確に表現しよう、というのがこの遊びの本質ですからね。

漢字の場合は、Glyph Wikiのように便利なサイトがありますけど、それでもやっぱり、同じ部首の字が何百と並んでいるのを見ると、「ああ、今、私は字を拾っているな」という実感が持てることは請け合いです。

ですから、IMEにとって既知な字すら「拾う」のは、何と言うか、ちょっと上級者向け過ぎませんかね。とはいえ、欧米人のように漢字の読み方が分からない人たちがこの遊びをすれば、ほぼ、そういう状況になってしまうと思いますけど……。そうですね、出題者と回答者のように完全にホストとゲストが分かれる遊びにするのなら、漢字の表を用意してあげるのはアリかもしれません。ただ、たとえフルHDでも、部首索引なしで探すのはムリだと思いますよ。あ、「第1水準までしか使わない」といった縛りを入れたら、うーん、どうだろう。

私としては、難易度調整は画像の選び方で行う方が良いと思います。まだ未トライですが、楔形文字とかなら、「拾う」感覚に関してはバッチリだと思います。

仕様を決められるくらい偉い立場になれば、きっと役に立ちますよ。