Emoji Keycap Sequence 対応について
-
いやー今年はほんっとに暑くてたまりませんね🥵 猫ちゃん共々お身体ご自愛くださいませ。
さて、今回書きに来たのは、「Emoji Keycap Sequence」のご報告 & 要望になります。
既にご存知であれば恐縮ですが、いつも悩ませられるUnicode仕様には、「Emoji Keycap Sequence」という仕組みがあるようです。
以下のようなもので、これを利用することで
#|*|0-9 + U+FE0F + U+20E3の組み合わせで四角囲み文字を示すようです:
https://www.emojiall.com/en/type-field/Emoji_Keycap_Sequenceこの表示にフォント側で対応していない場合に、Meryでは絵文字にフォールバックされることなく、「数字 + 四角枠が被った表示」になるようです。一方、メモ帳、VSCodeでは対応する絵文字にフォールバックされます。
Mery、メモ帳、VSCodeでの表示比較: https://imgur.com/a/Rj8o3wT
また上記キャプチャにも含めていますが、MeryでもMeiryo UIや游ゴシックを使えば、絵文字ではないものの適切に表示できるようです。(おそらくは対象の異体字セレクタにフォント側で対応しているものと推測)
可能なら対応いただけると助かります🙇♂️
| yuko | 返信 -
ご報告ありがとうございます。
ほんとに、気温 40 度超えってもうお風呂ですよね〜。yuko さんもどうか無理せず、気をつけてくださいね🫠
さて、Emoji Keycap Sequence の件ですが、残念ながらこれは DirectWrite の仕様で、絵文字にフォールバックしてくれないみたいなんです。
フォントで Segoe UI Emoji を指定すれば絵文字として描画はできているので、フォールバックさえしてくれればいいんですけどね…。
以前、Mery に隠し機能として「フォールバック フォントに Unicode の文字コードを指定して切り替える」仕組みを入れたことがありましたが…。
残念ながら DirectWrite では、
#|*|0-9 + U+FE0F + U+20E3みたいなシーケンスでフォールバックを指定することはできず、今のところはちょっと難しそうです。ちなみに、秀丸エディタさんや EmEditor さんでも DirectWrite で試してみたのですが、やっぱり同じ結果でした。
> この表示にフォント側で対応していない場合に、Meryでは絵文字にフォールバックされることなく、「数字 + 四角枠が被った表示」になるようです。一方、メモ帳、VSCodeでは対応する絵文字にフォールバックされます。
VSCode は Electron ベースなので、描画には DirectWrite を使っていますが、フォントのフォールバック機能などは Electron 側で独自に実装しているのだと思います。
Windows 11 のメモ帳はまだ詳しくわかってなくて…謎ですが😅
というわけで、Mery で対応するには DirectWrite とは別のフォント フォールバックの仕組みを作らないといけなくて、今のところは結構ハードルが高いなあ、という感じです。
| Kuro | 返信 -
気温がお風呂ｗ まさしくそうですねｗ (ﾂﾗｲ)
なるほど、DirectWrite依存なものだったんですね。
ということは、ちゃんと表示させたければフォント側で対応するようにしたほうがいいかもしれませんね。DirectWriteの問題ってことは割とポピュラーな不具合でしょうし、なんとか自前のフォントでは対応したいところ…。游ゴシックなどは流石に対応していて、きっと対応の術が何かあるはずなのですが、今はピンと来ておらず。実装するには、ちょっと夏休みの自由研究をしてみないとダメそうです。
そもそもUnicodeさん、ASCII範囲の文字に異体字セレクタ組み合わせた仕様を作っちゃおうなんて発想やめてよって感じもありますが😂
| yuko | 返信 -
ご返信ありがとうございます。
> なるほど、DirectWrite依存なものだったんですね。
そうみたいです。どうやら DirectWrite はフォント内にあるグリフを優先的に使う仕様のようで、たとえば U+0023、U+FE0F、U+20E3 の並びの場合、U+0023 は普通にフォントにグリフがあるので、フォールバックせずにそのまま「#」が描画されてしまいます。
それに、DirectWrite のフォントフォールバックのカスタマイズ機能は単一の Unicode コードポイントや範囲にしか対応していなくて、複数のコードポイントの「連続した並び」を指定することはできないんですよね😅
> DirectWriteの問題ってことは割とポピュラーな不具合でしょうし、なんとか自前のフォントでは対応したいところ…。
このあたりは不具合というより、DirectWrite の仕様って感じですね。
フォント側で対応するとしたら、「#」のグリフを削除して存在しなくすることでフォールバックさせる方法が考えられますが、さすがに現実的ではないですしね…。
> そもそもUnicodeさん、ASCII範囲の文字に異体字セレクタ組み合わせた仕様を作っちゃおうなんて発想やめてよって感じもありますが😂
ほんとそれです。Emoji Keycap Sequence に限らず、Basic Emoji でも
FE0Fが付くケースってあって…00A9 FE0F ; Basic_Emoji ; copyright # E0.6 [1] (©️) 00AE FE0F ; Basic_Emoji ; registered # E0.6 [1] (®️) 203C FE0F ; Basic_Emoji ; double exclamation mark # E0.6 [1] (‼️) 2049 FE0F ; Basic_Emoji ; exclamation question mark # E0.6 [1] (⁉️)こういう文字は HackGen などのフォントではグリフがあるので、DirectWrite はそっちを優先して、絵文字フォントにフォールバックしてくれないんですよね。
FE0F無しの場合は仕方ないとしても、FE0F付きの場合はできれば絵文字として描画したいですよね。対応するとしたら、DirectWrite のフォントフォールバックは使わずに、Mery 側で文字コードの並びを見て、該当したら一時的にフォントを Segoe UI Emoji に切り替えて描画する、といったかたちかなと思います。
ただ、その場合は Unicode のバージョンアップごとにメンテが増えそうですが…年に 1 回の更新なので、なんとかやっていけそうかなぁと。
あ、そういえばもう来月は Unicode 17.0 のリリース予定でしたね🤣 (この前やっと Unicode 16.0 に対応したばかりなのに…)
私も何とか対応できないか、引き続き検討してみます。
| Kuro | 返信 -
こんにちは。
お盆休み、ちょっと近所のスーパーに行っただけでめちゃくちゃ人が多くて、道路も大渋滞でした。こんな日は、もう夏休みの自由研究でもして過ごすのが一番ですね🫠
さて、Mery 側での対応について考えてみたので、ひとまず実現できそうな案をお知らせします。
前提
今回の対応は DirectWrite がオンのときのみとなります。
DirectWrite では一時的にフォントを切り替えて描画できそうなので、これを利用して、Mery 側で特定の文字コードの並びをチェックし、強制的に Segoe UI Emoji で描画する、いわば「なんちゃってフォールバック」を考えています。
【参考データ】https://unicode.org/Public/emoji/16.0/emoji-sequences.txt
今の状況
- Emoji_Keycap_Sequence が絵文字にフォールバックされない。
- Basic_Emoji (FE0F 付き) の一部が絵文字にフォールバックされない。
- RGI_Emoji_Modifier_Sequence の一部が絵文字にフォールバックされない。
対応予定
すべてのシーケンスを網羅するとファイルが大きくなりすぎる＆動作も遅くなるので、よく使う範囲だけ対応する感じです。
HackGen、BIZ UDゴシック、游ゴシック、メイリオあたりで確認してみた結果、以下の対応を考えています。
-
Emoji_Keycap_Sequence → Segoe UI Emoji で描画
今回のご要望対応ということで、これは対応します。Unicode のアップデートでもこの範囲は変わらなさそうですしね。 -
Basic_Emoji
00A9 FE0F～3299 FE0F→ Segoe UI Emoji で描画
この範囲はフォントによってはグリフが入っていて、Segoe UI Emoji にフォールバックされないことが割とあるので対応してもいいかなと。Unicode のアップデートでメンテが必要になります。 -
RGI_Emoji_Modifier_Sequence
261D 1F3FB～270D 1F3FF→ Segoe UI Emoji で描画
同じく、フォントによってはグリフが入っていてフォールバックされないことがあるため対応予定です。Unicode のアップデートでメンテが必要になります。
対応しない範囲
-
Basic_Emoji の
FE0F無し
従来どおり何もしません -
RGI_Emoji_Modifier_Sequence
1F385 1F3FB～1FAF8 1F3FF
こちらも従来どおり対応しません。グリフが入っているフォントは少なそうですし、データ量が膨大になるためです。 -
Twemoji Mozilla など他の絵文字フォント
対応しません。絵文字描画に使うのは Segoe UI Emoji のみです。(Windows 11 のメモ帳も、Twemoji Mozilla を指定しても上記の範囲は Segoe UI Emoji で描画されます)
検討中の範囲
- Basic_Emoji
1F170 FE0F～1F6F3 FE0F
微妙にグリフが入っているフォントがあるので、データベースのサイズとの兼ね合いで対応するかまだ考え中です。もし対応すれば、HackGen で emoji-sequences.txt のほぼすべてのデータを正しく描画できるようになります。
今のところ検討している内容はこんな感じです。
| Kuro | 返信 -
こんばんは。夏休みの自由研究の続きです…
お風呂に入っていたときに「もしかして！？」とひらめき、さっそく試してみたら「やっぱりそうか！」という面白い発見があったのでシェアします。
Emoji_Keycap_Sequence と Basic_Emoji (
FE0F付き) の対応についてですが、Windows 11 のメモ帳がどうやってるのか、ちょっと見えてきました。(たぶん)当初は「アプリ側で Unicode のデータベースを持って、文字コードの並びを判別して…」なんて難しいことを考えていたのですが、どうやらメモ帳は「
FE0Fが付いているかどうか」だけで判定しているっぽいんです。たとえば、メモ帳でフォントを HackGen にして、Emoji_Keycap_Sequence っぽい文字列を入力してみます。先頭の文字は Emoji_Keycap_Sequence の範囲外の
0025(%) です。0025 FE0F 20E3本来なら Emoji_Keycap_Sequence に該当しないので HackGen で描画されるはずですが、メモ帳では Segoe UI Emoji に置き換わります。
つまり、メモ帳は
FE0Fが付いていたらどんな文字でも Segoe UI Emoji で描画する仕様のようです。これならデータベースいらずで高速フォールバックできるじゃん！…と喜んだのも束の間、問題もあります。
たとえば、メモ帳で
3042(あ) にFE0Fを付けると…3042 FE0FSegoe UI Emoji には「あ」のグリフが入っていないため、お豆腐 (□) になってしまいます。
もちろん「あ」に
FE0Fを付ける人なんてまずいないと思いますが、「FE0Fが付いただけで Segoe UI Emoji に強制送還」っていうのも、ちょっとやりすぎかな…という気もしますよね。やっぱり、地道に Unicode データベースを持つほうが正解なのかも？
ということで、夏休みの自由研究、だんだん本格的になってきました🤣
| Kuro | 返信 -
その後いろいろ調べていただいてありがとうございます🙇♂️
> 当初は「アプリ側で Unicode のデータベースを持って、文字コードの並びを判別して…」なんて難しいことを考えていたのですが、どうやらメモ帳は「
FE0Fが付いているかどうか」だけで判定しているっぽいんです。なるほど…なかなかワイルドな対応ですね。でも天下のメモ帳がそういう対応してきたってことは、その判定方法でこの先しばらく問題ないはずだと想定しているってことですね、きっと。
> もちろん「あ」に
FE0Fを付ける人なんてまずいないと思いますが、「FE0Fが付いただけで Segoe UI Emoji に強制送還」っていうのも、ちょっとやりすぎかな…という気もしますよね。悩ましいところですね～。メモ帳に合わせているという安心感もあるけど、、、という😅
豆腐に化けるので「なにか余計な文字が入っている」というのが認識できるのは個人的にはメリットですが、こういった事情が分からない方からしたら「？」ってなってしまうでしょうしね。まぁメモ帳でも同じ表示になるので、仕様根拠としては幾分、説明はしやすいとは思いますが…| yuko | 返信 -
いえいえ、こちらこそ。お盆中にご返信ありがとうございます。
> なるほど…なかなかワイルドな対応ですね。でも天下のメモ帳がそういう対応してきたってことは、その判定方法でこの先しばらく問題ないはずだと想定しているってことですね、きっと。
そういうことにもなりますね。
> 悩ましいところですね～。メモ帳に合わせているという安心感もあるけど、、、という😅
確かに、絵文字以外に
FE0Fを付けてやろう、なんていうイレギュラーなケースを前提にして、exe ファイルの肥大化や動作速度の低下、メンテナンスの手間を抱えるくらいなら、ワイルド方式もアリな気がしてきました…😅さらに補足ですが、メモ帳では RGI_Emoji_Modifier_Sequence で使われている
1F3FB～1F3FFもFE0Fと同じ扱いのようで、「あ」とかにくっつけると Segoe UI Emoji 行き (豆腐) になりますね。となると、ワイルド方式なら、前回提案した絵文字シーケンスの…
- Emoji_Keycap_Sequence
- Basic_Emoji
- RGI_Emoji_Modifier_Sequence
これらすべて、しかも全範囲にデータベースなしで対応できてしまいます。
> 豆腐に化けるので「なにか余計な文字が入っている」というのが認識できるのは個人的にはメリットですが、こういった事情が分からない方からしたら「？」ってなってしまうでしょうしね。まぁメモ帳でも同じ表示になるので、仕様根拠としては幾分、説明はしやすいとは思いますが…
そうですよね😀 メモ帳でも同じ表示なら、誰も困らない気がしてきました…。(楽なほうに流されているわけではないですがw)
| Kuro | 返信 -
> となると、ワイルド方式なら、前回提案した絵文字シーケンスの…
>
> - Emoji_Keycap_Sequence
> - Basic_Emoji
> - RGI_Emoji_Modifier_Sequence
>
> これらすべて、しかも全範囲にデータベースなしで対応できてしまいます。おお、雑なようでいて、実は考え抜かれたワイルド (？) だった可能性、ですね😯
なんだかこうやってテキストエディター開発者の方のメモ帳談義を聞いていると、メモ帳も考え抜かれたすごい子なんだなぁって思えちゃいますね (OS標準搭載製品なんだからそりゃそうなんですけどｗ)
| yuko | 返信 -
> おお、雑なようでいて、実は考え抜かれたワイルド (？) だった可能性、ですね😯
考え抜かれた仕様なのか、それとも単なる手抜き仕様なのか、絶妙なラインですよねw
> 豆腐に化けるので「なにか余計な文字が入っている」というのが認識できるのは個人的にはメリットですが、こういった事情が分からない方からしたら「？」ってなってしまうでしょうしね。
これ、メモ帳だと豆腐になるのですが、Mery で試してみたところ、「あ」に
FE0Fを付けて Segoe UI Emoji で描画しても豆腐にはならず、さらに自動でフォールバックが発動して別のフォント (たぶん Yu Gothic UI) に切り替わるみたいです。なので、余計な文字チェックに使うには少し難しいかもしれませんが、ひとまず次のバージョンはメモ帳ワイルド仕様の方向で進めてみますね。
夏休みの自由研究ということで、データベース対応版と、Unicode の仕様データから Delphi 用のソースコードを自動生成するプログラムまで作っちゃったのですが、とりあえずお蔵入りです。
ワイルド仕様で怒られたら、切り札として使おうかなと…🫠
| Kuro | 返信
