Sentence of Acquittal

Unistring という javascript のライブラリを公開している。これは自分で言うのも何だが本当に重要なライブラリで、web アプリケーションにおいて BMP の範囲を超えていたり結合文字が混じりまくったりした Unicode の文字列を扱うとしたら、これがないと本当にどうにもならない。絵文字ひとつ扱えない。

このライブラリは UAX #29: UNICODE TEXT SEGMENTATION で定義される、Unicode の文字列を書記素クラスタへ分割する処理(Grapheme Cluster Boundaries)と、単語に分割する処理(Word Boundaries)を行う。実は UAX#29 ではこれ以外に、文に分割する処理(Sentence Boundaries)とハングルにおける字母の分割ルール(Hangul Syllable Boundary Determination)も定義されているのだが、それらは wasavi では使わないので実装していない。

実装していなかったのだが、issue が来てしまったので Sentence Boundary をえいやと実装した。しかし実装しといてなんだが、この機能実用になるんだろうか。UAX#29 でも Sentence Boundary は「文の抜き出しは字面を追うだけでは不十分で、ほんとは構文解析しないとダメだよ。でも殆どの場合はシンプルなやり方でも抜き出せるから一応紹介しておくよ」という位置づけでしかない。

それはそれとして、ググってみても UAX#29 をだいたい実装している javascript ライブラリというものが見つからないのだが(書記素クラスタに分割するものはある)、どういうことなんだろうか。誰も興味ないのかこの手の話。

Conversations of the Beasts

けものフレンズのスレが虹裏に立ち、「○話に誰それがなんとかって言った」とか、「誰それが○話で何をした」とか、そういう話になった時、手元で簡単に確認できると嬉しいわけで、すべての会話をテキストに起こした。これがあることで、たとえば各話中に「すごーい!」的なセリフは
$ grep -c "すっ\?ご" [0-9]*.md | awk -F: '{print $1,$2;c+=$2}END{print "total",c}'
01.md 8
02.md 3
03.md 13
04.md 8
05.md 20
06.md 7
07.md 7
08.md 11
09.md 8
10.md 2
11.md 6
12.1.md 1
12.md 6
total 100

回ある…などとすぐわかる。すごい。

kemono-friends-dialogs
https://github.com/akahuku/kemono-friends-dialogs

Talk about news #3

PhoneticNews を拡張し、Yahoo! Japan が提供する500以上のフィードにも対応した。そのために、フィード一覧のページに専用の content script を仕掛けるようにした。

ところで Chrome の拡張から任意のドメインにリクエストを飛ばすには、基本的にはマニフェストの permissions にその URL パターンを予め記述しておく必要があるのだが、yahoo 上のフィードにはそれが必要ないようだ。多分 cors に対応しているんだろう。

それはそれとして、Yahoo!上のフィードのリスト上に、こんな感じに各フィードにチェックボックスが追加される。また画面右下にはコントロールパネルが表示される:

で、適用を押すとこんな感じで念を求められ:

承認すると読み上げるフィードに追加される。

GRADIUS on GAE

ここの xrea サーバでは cron に任意のコマンドを登録できるのだが、間隔に制限があり、最短 1 時間は空けないといけない(その代わり 12 個までの個別のコマンドを登録できるので、頑張れば 5 分おきにまで縮められるが、まああんまりやりたくないバッドノウハウである)。多分この制限はコンパネ上だけのものなので、ssh でログインして直接 [cci]crontab -e[/cci]すれば迂回できるんじゃないかな…と思わなくもないが、試してない。

そんなわけで、cron 代わりとして xrea とは別に Google App Engine のアカウントを利用している。こちらにも cron サービス的なものがあり、間隔の制限はないので 1 分おきに xrea サーバにちょっかいを出させるのだ。ちなみにこの GAE アカウントの表向きの顔は HTML5 版の GRADIUS なのだった。

さて、ちょっと前に Google さんからお手紙を頂いた。それによると GAE で python2.5 で動かしてるインスタンスは削除しちゃうからアップデートしてちょということだった。なるほど。確かに GAE 上の GRADIUS は python2.5 のインスタンスで動かしている。

でもそもそも GAE のアップロードの仕方とかもう全くさっぱり何もかも覚えていないよ。1 から調べ直したところ、このへんに書いてあるとおりに進めればいいようだ。以前は appcfg.py でコントロールしてた記憶があるが gcloud というコマンドに置き換わっている。

ということで、直した。

Switching audio devices

ちょっと前に iBUFFALO USBオーディオ変換ケーブル というものを買った。これはマシンのイヤホンジャックがぶっ壊れていた場合のための保険として買った。

しかしイヤホンジャックは無事だったので使わずにいた…のだが、もったいないので使ってみることにした。感慨深いことに Xubuntu であっても単に刺すだけで使える。

音質は、たしかにマシン本体のイヤホンジャック経由よりもクリアになるようだ。2000円やそこらの製品でこれなのだから、ちゃんとした USB-DAC ならもっとすごいのかもしれない。この手のデバイスで泥沼にハマる人がいるのもわかる気がする。

ところで音質よりも副作用的に嬉しい点があり、マシン内蔵のスピーカーとイヤホンの出力切り替えがソフトウェア的に行えるようになった。イヤホンジャック経由だといちいち抜き差ししないといけなかったが、サウンドの設定パネルから切り替えられる。[cci]pacmd[/cci] コマンドで端末からも切り替えられる。

Policy Violation

先週 Google Chrome web store team から、「wasavi が掲載ポリシーに違反している、1 週間の猶予をやるから直して再アップロードしろカスが」というメールが来た。

ポリシーというのはたとえば内容の表現とか、広告とか、ユーザーデータの取り扱いとか、そういうものだ。しかし wasavi が内包している内容と言ったらシンプルなエラーメッセージくらいだし、広告はないし、ユーザーデータもオプションページでいじれるもの以外にないわけで、違反ってなんのこっちゃという感じだった。そして困ったことに、どの点が問題なのかという肝心の点がメールに書いていない。

そんなわけでハドラーこれどうなってるの? というお返事をしたところ、「なんか間違いだったみたい。気にすんなカスが☆」ということであった。

なるほど。

serif or sans-serif #2

このブログにたまにスクリーションショットを上げるが、それを見てもわかる通り Chrome のフォントをTakao P 明朝に設定している。これ自体はとても良く出来ているフォントなのだが、繁体字や簡体字の文字までカバーしているわけではないので、そこだけ別のグリフになってしまうことがごくたまにあり、それが気になる。

フリーで、Unicode の多くのコードポイントに対応していて、明朝体あるいは serif のフォントというと Google Noto Fonts の Noto Serif CJK JP である。というわけで、入れてみた。

Takao 明朝に比べると若干硬い感じを受けるが、それはまあ慣れなので。もうひとつ気になるのは含まれるアルファベットが若干アセンダ・ディセンダが広く、うわ〜気取りすぎ!な感じはなくもない。まあそれも慣れなので。

とは言え、慣れではどうにもならないものもあるのです。Chrome のフォントの設定は標準フォント・sans-serif フォント・serif フォント(と、その他)に分けられている。素直に考えれば、標準フォントはページになんにも font-family が指定されていないときに使用されるフォント、sans-serif と serif は font-family 中のそれぞれの総称フォントということだろう。

しかしこの通りに標準フォントと serif フォントに Noto Serif CJK を与えても、そのとおりに表示されない web ページはたくさんある。表示されないのは意図されたもので、つまり font-style に sans-serif を含んでいるページが多い。これは悪習なんじゃないだろうか。font-family には「ぜひともこのフォントで表示してほしい」ものだけを書いてほしい。そしてそのフォントは Web フォントの技術を用いて web ページ側が提供してほしい。font-family は「どういう風に表示されるかは保証しないけどこのフォントで表示してくれたら嬉しいな〜」なフォント名を書くものではない。

Save to #4

いくつか気なる点が出始めてきた。

Kokoni のコンテキストメニューは、image/video/audio に対するものと link に対する物の両方に対して表示するようになっている。ここで、例えば img 要素を含んだ a 要素に対してコンテキストメニューを出したとき、保存対象は a.href か img.src か? という難しい判断を迫られる。

Save file to ではこういう場合、リンク先を保存というメニュー項目と画像を保存というメニュー項目を両方出現させる。しかし Chrome の拡張の場合、それは不可能なのだった。コンテキストメニューのルートに複数のメニュー項目を追加しようとした場合、ルートには拡張の名前の項目だけが追加され、拡張側から追加しようとした項目はその下に迂回されてしまう。

つまり通常はコンテキストメニューから “ここに保存” -> “Pictures” というルートを辿るのが、上記のマークアップの場合は “Kokoni” -> “ここにリンクを保存” または “ここに画像を保存” -> (いずれかの)”Pictures” というように展開されるメニューが1段増える。

リンクに対するコンテキストメニューを出した時はそういうものだと受け入れるとして、問題はどうも拡張から生成できるメニュー項目数に妙な制限があるらしいことなのだった。つまりツリーに対応するメニュー項目群を2倍定義しないといけないのだが、そうすると簡単に制限に引っかかる可能性が高くなる。メニュー項目をより動的に生成できるようなイベントが用意されていればその都度必要とされる項目だけを生成することで解決するのだが、chrome のコンテキストメニュー API はいまいちその辺の融通が効かない。

もうひとつ、参照したディレクトリの履歴をコンテキストメニューに含めるようにしているが、現状では単純に最後に参照したディレクトリを先頭に持ってくるようにしているので、例えば 9 割方 [cci]Pictures/けものフレンズ[/cci] に保存しているが、たまに [cci]Pictures[/cci] に保存しただけで履歴の順番が変わってしまう。履歴のソート順として参照回数順、辞書順などのオプションを実装する必要がある。

Save to #3

インストール手順を英語でも書いた。

Enjoy Kokoni!
https://appsweets.net/kokoni/index-en.html

同時に、basename を省略してアクセスしても、accept-language ヘッダの先頭が ja かどうかで適宜振り分けるようにしたのだが。Chrome の場合 [cci]$ LANGUAGE=en google-chrome[/cci] などとしても accept-language ヘッダの内容は変化しない、Firefox の場合は逆に言語設定で ja を先頭にしているにかかわらず accept-language には ja が追加されない…など、それぞれがなんか妙な動きをして困る。

困るといえば、テストのためにいろんな画像を虹裏から落としているのだが、割と同じ画像を保存してしまうことがある。こういう場合に Kokoni 側で面倒を見るべきだろうか。でもそれはそれで面倒くさいなあ…。

やっぱりやめた。

$ fdupes -fdN ~/ピクチャ/けものフレンズ

すればいいだけのことだ。

それにしてもこの手の拡張が Chrome にも欲しいという意見は2012年頃からあったのに、なんで誰も作らなかったんだろう…。

Save to #2

Chrome Web Storeに公開した。

それから、詳しいインストールの仕方を書いたページを作った。しかし絶対パスや相対パスというむつかしいこんぴゅーたー用語が万人に通じるのか若干不安がある。Chrome の filesystem まわりの API がフルパスの扱いに関してぶっ壊れっぱなしで、スクリプト側で良きに計らえないのが悪い。