どもども。windowsPCで観れていれさえすれば、他の環境はどうでもいい。
もし崩れてなければラッキーだなくらいに考えて歌詞CAを投下してきましたakachunです。
だけれど、どうせCAを貼るならより多くの人にちゃんとしたものを見てもらいたいかな
という願望もあって、WindowsPCと互換性が高いと言われているiPhone、Android公式アプリ（以下スマホアプリ）で自分が投下した歌詞CAがちゃんと表示されているか、事後確認を行いました。
その結果、全体としては思っていた以上にきれいに表示されてくれていました。
ですが、ところどころ…割と要所の箇所でiPhoneアプリもAndroidアプリも
CAが崩れてしまっていることが判りました。
今回はそれらのしくじり事案をその原因と今後の対策と合わせてご報告しようかと思い筆をとりました。
【注意事項】
これは、私がこれまで実際に投下した歌詞CAでやらかしてしまった事例に基づく原因分析および対策であり、
スマホアプリでの表示、全てについてコメントアートのWindowsPCとの互換表示を保証するものでは決してありません。
その辺りのことは何卒ご承知おき下さいますよう、よろしくお願いします。ｍ(＿ ＿)ｍ
defont big ender naka と defont medium ender naka で
1文字ずつ色を変えて文字幅、文字位置を調整して貼ったCA
WindowsPC
iPhoneアプリ（イメージ）
iPhoneは職場で同僚が持っていた6Sで確認しました。
変ですね、同じ空白文字を使ったのに。
「が う」が「り」と「と」に重なるように表示され
「を」はなんだか行末のスペースが取り除かれたかのように右に移動し
流れるスピードも落ちてました。
この時、文字幅、文字位置の調整に使っていた空白文字はU+2004とU+2009です。
最大の見せ場と思って文字位置調整に時間をかけたところが、こんな無残なことになっていて軽くへこみました。。
この他にもdefont白字コメントの左右に僅かにずらしたコメを重ねて縁取りをカラーリングした部分が
ただの白字コメントのように見えていたり、表示位置を微調整したはずのところでWindowsPCとは若干ずれたりしていました。
gothicでも同様の事案が発生・・・
Find… Win7 のスクショ（左がChrome、右がIE）
Believe… Win7 のスクショ（左がChrome、右がIE）
iPhoneアプリ（イメージ）find と believe
gothic 半角英字です。半角英字に問題があるのではなく、どうやら使用した空白文字の文字幅致命的に違うみたいです。
Findはdがnに重なっちゃってるなー程度ですが、believeに至ってはもはやギャグかと。
ここでアルファベットの表示位置を微調整するために多用していたのが、U+200A（1/12幅）とU+2009（1/5幅）でした。
ことここに至りようやくではありますが、自分がよく使う空白文字について、iPhoneアプリで表示した場合の文字幅がどうなっているか確認してみました。
iPhoneアプリの空白文字幅調べました。
U+2001（漢字幅）、U+2002（1/2幅）、U+2004（1/3幅）は問題なし
U+2005（1/4幅）、U+2009（1/5幅）、U+200A（1/12幅）は
minchoだけ問題なし
defontとgothicだと文字幅が変わる
U+2009とU+200Aは全然狭くてしぬ。U+2005は1割増し程度で許容可— akachun (@akachun) September 11, 2018
iPhoneアプリとの互換を考慮するならば、より細かな位置調整で便利な U+2009（1/5幅）と U+200A（1/12幅）が
mincho以外では使い物にならないということが判りました。
U+2002（1/2幅）、U+2004（1/3幅）は大丈夫で、U+2005（1/4幅）も1割ほど広いだけなので多用しなければ許容範囲です。
iPhoneアプリだとgothicまたはdefontで、
U+2009は目視で1/23幅程度（Windows IEの1/4以下）
U+200Aは目視で1/60幅程度（Windows IEの1/5）
互換性がないという時点であまり有用な情報ではありませんが— akachun (@akachun) September 11, 2018
結論
mincho以外で、U+2009（と U+200A）は使用しないこと！
使うとiPhoneアプリでつぶれます
※余談
本コラムのテーマとは離れますが、U+200A についてもうひとつ判っていることがあるのでついでに報告しておきます。
U+200A は windowsPC で見たとき、基本的に1/12幅文字として表示されますが、mincho および gothic で chromeブラウザで見たときに限り、
1/12幅ではなく 1/16幅になるようです。（Win10にて調査）
Win10 Chrome 明朝＆ゴシック U+200A は 1/16文字幅みたい
（IE、firefox では 1/12幅、Chromeでもdefontは 1/12幅） pic.twitter.com/aYaVinqjLz— akachun (@akachun) September 5, 2018
Androidはブラウザで見たときの互換性のなさは筋金入りらしいですが、Android公式アプリは結構まともなようです。
空白文字の文字幅も、それなりに安定してたように思います。
（自分では持っていないので職場の同僚に見せてもらいました）
だがしかし
泥アプリ（イメージ） 「早」が右に飛ぶ。
泥アプリ（イメージ） 「閉」が右に飛ぶ。
リード行を使った9行固定 defont big で、Androidアプリで見た時に何故か文字が右にぶっ飛ぶという事象が起きました。
なんでじゃ？とTwitterでツイートしたらヒロス氏から指摘をいただき、以下の記事に行き当たりました。
Android版ニコニコ公式アプリのコメント幅の決定基準がおかしい件について
「Android版ニコニコ公式アプリではコメント領域（コメント幅）を決定づける行は、
実際に表示される幅ではなくて文字数によって判定されているらしい」
というのです。なるほどなるほど。
うーんでも私の場合、文字数超えてるかな？
目を閉じてメモ
リード行は「ＷＷＷＷＷＷＷＷＷ ＷＷＷＷＷＷＷＷＷ」19文字
閉の行は「 閉」16文字
あんまり画面右の方に文字を表示させちゃいけないとか他の条件とかあるのかな？
などと間の抜けた疑問を持ちながら「リード行を文字と別にする場合は要注意」くらいに思ってました。
そんな浅い理解しかしていなかったため、再びやらかしてしまったのです。
先日投下した歌詞コメ、また職場の人の借りてAndroidアプリ表示確認。
「いつだって」が「ついっだ て」になってて(ﾉ∀`)ｱﾁｬｰ
bigでリード行つかった時がヤバいというのはヒロス氏に聞いていたので
空白リード行を余計に長くしてみたら「つ っ」というコメントだけぶっ飛び回避しててこの様っ— akachun (@akachun) September 10, 2018
見かねたヒロス氏がまた教えて下さいました。
一方で「い だ て」の方のコメントはリード行が17文字、「い だ て」の行が19文字なのでこちらが基準の行として誤って認識されます。
このためＰＣ版で「い だ て」の方のコメントのリード行を抜いてみると、画像のようにAndroidアプリでの表示が再現できます。参考までに。 pic.twitter.com/6sxWrwjaNs— ヒロス (@hirosususu) September 10, 2018
やっぱり文字数かー。あらためて上の歌詞メモをコピペしてみました。
閉の行は「 閉」
あ・・・
行頭にゼロ幅文字が10文字隠れてる！
16文字じゃなくて26文字になってました。
血ロン
リード行よりも、行の文字数を多くしないこと！
Androidアプリでぶっ飛びます。
リード行と文字数が同じの場合は未確認ですが、万全を期すならリード行の文字数未満にしておくべきでしょう。
リード行にわざとゼロ幅文字（U+200Cなど）を入れるとか、U+2004（1/3幅）を多く使うとかすればよいので難しくはなさそうです。
ちなみに、何故ゼロ幅文字を10個も入れてたのかって？
それは当時の私が細かい空白文字を知らなくて、表示位置調整に苦しんだ挙句に
「ゼロ幅文字といってもいくつも入れれば少しは幅が出るんじゃねーの？」と考えて
試しに入れてみて、結局変わらなくて、そのまま放置しちゃったからに決まってるじゃないですか、いやだーん。
前回書きました歌詞CA投下記録その6（akachun）で少し言及しましたが、弾幕化しないはずと思っていたコメントがiPhoneアプリで見たら弾幕化していたという話です。
WindowsPC（イメージ）
iPhoneアプリ（イメージ）
高さ非固定でいれた「作詞:六ツ見純代 作曲:柳沢英樹」「陽」が縦にぶっ飛んでました。
これは正直全く予想していなかったのでiPhoneでこれ見た時は、驚きを通り越して爆笑してしまいました。
確かにこのコメントを投下したタイミングというのは、上下から高さ固定で入れた「RidgerP」「Azusa miura」が残っていたので
高さ非固定が弾幕化するかしないか微妙なタイミングではありました。
ですが、私は事前にコマテ動画で「コメントの積み上がり（衝突）判定は2.80秒後には消える」ことを確認していたので、
本動画でこの部分を貼るとき、高さ固定を入れてから2.85秒は確実に経過していると確信して高さ非固定コメントを入れたのです。
この件については、ツイッターや過去の記事でそれらしい情報が得られなかったので、
自身初公開となる汎用コマテ動画を上げて、iPhoneアプリは積み上がり判定を何秒後まで残してるのか？ Androidアプリはどうか？
検証してみることにしました。
白背景無音60分の動画です。（ヒツジ氏が公開してたものをダウンロードしてそのまま上げました）
投コメだと0.01秒単位にコメント投下時間を自由に調整できるので、それを利用して高さ固定コメントの上からいろんな時間差で高さ非固定コメントを入れて
何秒後だと弾幕化するのか（積み上がるようのか）視聴環境によってそれがどう変化するのか確認しました。
その結果、WindowsPCでは2.80秒以上なら大丈夫で、2.79秒だと弾幕化することが再確認できました。
またツイッターから鍵氏が泥アプリで見た結果、同じく2.79秒で弾幕化すると教えてくださいました。
んで、iPhoneはというと、6S と 7 両方で、2.95秒以下だと弾幕化するということが確認できました。
ふむふむ。ということは。
iPhoneアプリで弾幕化や積み上がりを避けたい時は、2.96秒以上間隔をあけて投下するようにっ
ということですかね。
いや、正直言って0.16秒も積み上がり判定が消える時間が長いというのは、あまり許容できない仕様の相違です。
ここぞという時には高さ非固定を使いたい私のような者にとっては「コメントの表示時間がiPhoneアプリは0.16秒長い」と言われてるのとインパクトに違いがないんですね。
そこに差があるの？
と。
（おまけ）
WindowsPC（イメージ）
はるるんかわいいですはるるん
先日、ふとHTML5版（ただし高さ非固定、非full）を投下したくなって投下した7アピールクロック（7アピクロック）です。
スペーサーの積み上がり判定も2.80秒で消えることを前提に、昔より遅めに投下しました。
iPhoneアプリ（イメージ）
案の定、崩れてました。
このCAに関してはスペーサーを入れるタイミングは0.36秒を狙えばよいので、iPhoneアプリを配慮したとしても0.20秒の余裕はあります。
最初から知っていたら、どっちで見ても崩れないタイミングを狙うことも可能でした。（自分は0.05秒までは狙って投下できます）
悔しいっす。
まあ、最後のやつは高さ固定コメントだけ使うとか、積み上がり判定の消え際を狙うようなことをしなければいいだけなので、これで困る人はあまり多くはないでしょう。
対策も容易と言えば容易です。知ってさえいれば、対応はできます。
でもやっぱり、こういう視聴環境による仕様の差異はもっと無くしていって欲しいな、とも思います。公式アプリなんですから。
以上です。
最後までお読みくださりありがとうございました。
（記事の内容に誤まりなどございましたらコメントやTwitterなどでご指摘いただけると幸いです。）
