とりあえず5万課金する前提やめろ
<path>1つで書かれた長大な図形をざっくり分割して<g>でくくってtranslateしまくることにより、よく見ると全然違うオブジェクトが同じ形になっている図形に変換されて
実際話題に登るのはそうではない事例ですし
可逆圧縮を無差別にかけるのは問題とする人そんなにいないのではというのはある
もしかしていわゆる通信の最適化でJPEGが変化するやつってSVGのdataスキーマにbase64で埋め込むことで回避できる?
XMLの異様な冗長性からしていちいちrectとかにするよりも、むしろ積極的にrectとかをpathに変えていくほうがサイズ小さくなりそう。同じ図形の繰り返しだとしてもgzip圧縮でもした方がマシな気が……
SVGのペイロードを見てこれpathで書いてるけどrectでいいじゃんみたいなのを実時間で判定して書き換えて全体の辻褄を合わせた上でサイズを有意に小さくするシステムすごそう
もしかしてSVGのペイロードいじるISPも現時点で確認されてます?(多分ない)
MarkdownScoreとかCodeHighlightScoreとか。機能発動の正規表現が比較的単純かつ出現頻度が低いからtwemojiよりはマシな速度で動きそう。その代わりMiraclePainter側で色つけたり太字にしたりする機能のサポートが必要で、そのための(bold?だのcolorだのと)メソッドチェックを全Noteに対してやると考えると逆に重いかな……?
(単にニコニコ側が攻撃的なコメントの送信元に苦情を言っただけかもしれん。)