テレワーク。早くもなく遅くもなく。
東京都コロナ感染者。新規は 14399人。
Emacs 29.0.50+pdf-toolsでハング状態に陥る件。
どうやらpdf-info.elの中の関数pdf-info-query 内で 関数accept-process-output を使って非同期プロセスの応答待ち合わせを
行っているっぽいのですが、これがいつまで経っても終わらない為、待ち合わせが無限ループしているのが現象そのものの原因っぽい。
確かにプロセスが終了していない模様。
tq-createっていう関数で生成された非同期プロセスに tq-enqueue っていう関数を使って コマンドを送って その応答を待っているけど
何故か終わらないという感じみたい。とは言え ELISPで動く範囲みたいなので再現コードを書けるのか?
それにしても C-gで強制停止できないのは辛い🥺
pdf-toolsの関数pdf-info-query はサーバーとなる epdfinfoに コマンドを送ってその応答を得るという仕組みのようです。
例えばスクラッチバッファで
「(pdf-info-query "number-of-pages" "/pathto/foo.pdf")」
と実行してみると、foo.pdfのページ数が返ってきたり、
「(pdf-info-query "renderpage" "/pathto/foo.pdf" "1" "600")」
と実行するとレンダリングされたPNGデータが返ってくるので
「(insert-image (create-image (pdf-info-query "renderpage" "/pathto/foo.pdf" "1" "600") 'png :data))」
みたいにすれば画像として表示できます。
問題はスクラッチバッファで順番に実行している限りは特にハング状態には陥らず。まるでダメって事ではないみたい。
うーむ🤔
テレワーク。早めに終了。
東京都コロナ感染者。新規は 14680人。
Emacs 29.0.50+pdf-toolsでハング状態に陥る件。そういやパッチ無しで試してなかったなと思い確認してみたのですが
やっぱりハング状態に陥りました。うーむ。
gdbでデバッグプリントを仕込んだりブレークポイントで止めては進めたりしてみていたところ、
keyboard.cの中の read_decoded_event_from_main_queue() という関数実行でハングする事が判りました。
中に潜ると今度は 関数read_event_from_main_queue()の中から呼び出される kbd_buffer_get_event()でハング
していたり。更に関数 process.c:wait_reading_process_output()の中でハングるようなのですが追いかけきれず。
ただ、29.0.50特有の問題と思われるので gitリポジトリの更新状況を少し様子を見てみるか....
と書いたところで git pullしてみたら emacs-29 のリリースブランチが生成されてた模様
(Release branch emacs-29)。
pdf-toolsでハングする件は 誰か同様の状況に遭遇して直して貰えないと困った事になりそうな予感。
もう少し調べてみたところ、どうやら何かしら条件が成立すると脱出できる無限ループを
脱出できない状態に陥っているみたい?と思って調べてみるも、ループじゃないのに関数は無限に実行されていると
いう謎な状況🤔 再帰ループ的な状態に陥っているのか???
テレワーク。気持ち遅めに終了。
東京都コロナ感染者。新規は 5767人。
Emacs 29.0.50+pdf-toolsでハング状態に陥る件。
gdbの-pオプションでアタッチできそうだったので、ハング状態に陥った所でアタッチしてみたのですが、ntdll.dllの中で
止まってうまくステップ実行もできずで、gdbでなんとかするのは一旦諦め😔
epdfinfoの方で何か突っかかっていないかをデバッグコードを仕込んで確認してみたのですが、こちらの方が原因で
止まっている感じでは無さげ。
やはりgdbでうまく止めるのが良さそうですが、PDFを表示し始めるまでのステップが長すぎてうまく止められず。
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は 10346人。
Emacs 29.0.50。image-diredが激変していて色々ダメになっている予感。
リモート画像ファイルのサムネイルを生成する時にTRAMPバッファが変になってハングる件
(参考)は、
関数を記したファイルが変わっていたのでそちらにパッチを適用する事で対応。
ただし、何故か画面が更新され始めるまでに時間がかかるようになってしまっています。
あと 「C-u RET」でオリジナルサイズで表示する事ができない件
(参考)は、仕様が変わって画像を表示してから
image-modeと同じ操作「s o」で操作するという事になってるみたいです。これは良いかなと思います。
その他に気づいた点は以下。
起きたら午後もいい時間。寝すぎ。
東京都コロナ感染者。新規は 13569人。そういや今感染している人ってどういう原因なのだろう?
Emacsのmasterブランチ(29.0.50相当)を何気にCygwinビルドしてみたり。
とりあえずパッチ無しでビルドして起動もできるのですが、パッケージの読み込みで色々突っかかりました。
テレワーク。早くもなく遅くもなく終了。
東京都コロナ感染者。新規は 12938人。
Web巡回して終了。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は 5639人。
唐突ですがクリケット。サッカーよりも競技人口が多いスポーツらしいのですが、そういやビデオゲームって
あるんだっけ?と思ったり。Web検索してみると意外と存在しているみたい。日本では見たことありませんが😅
AM中に起床。
東京都コロナ感染者。新規は 12850人。比例増加しているな。
Emacsのorg-modeで下付き文字/上付き文字表現を Emacs上で表示できるってのを知りました。
ほぅ...。Emacs-24.3に含まれるorg-modeには既に org-toggle-pretty-entities はあったみたいなので、
大分前から表示する仕組みはあったっぽい。emacs-w32でも前から表示できたかどうかは判りませんが。
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 12758人。
emacs-w32でカラー絵文字。一週間ほど普段使いも含めてテストしてみて、いきなりズッコケたりはしないようなので
テスト版を放流してみます(emacs-w32_28.2_20221122test.patch.xz)。
御興味ありましたら遊んでみてください。
ビルド方法などはこちらに準拠します。
ただし、DirectWriteを扱うコードがC++となっている為、追加で g++などのコンパイラをインストールしておく必要があります。
configureオプションによる切り替えなどはありませんのでカラー絵文字表示は常に有効でビルドされます。
emacs-w32_28.2_20220917.patch.xzとの差分は以下の通りです。
(set-fontset-font "fontset-default" 'emoji '("Segoe UI Emoji" . "iso10646-1") nil 'prepend)を.emacsに足せば良いかと思います。各自環境都合もあるかと思いますのでうまく設定していただければと思います。
テレワーク。気持ち遅めに終了。
東京都コロナ感染者。新規は 4619人。
Web巡回して終了。
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は 7777人。
「☀(#x2600)」がSegoe UI Emojiで表示されない件。Webを散策していて
use-default-font-for-symbols って組み込み変数を nilにセットすれば良いらしいというのを知ったり。
tだとデフォルトのフォントで表示ができる場合、フォントセット指定よりも優先されるという事らしい。
これが先日「どうやってもオーバーライドできない」って結果に繋がっていた模様。
設定が無視されるんじゃそうなるわな。
そんな訳で設定してみたところ「☀☁☂☃☄」がカラーで表示されるようになりました。
htmlで文字コード指定して ewwで表示してもカラー表示されます(☀☁☂☃☄) 🙂。
ただ、副作用の有無については判らず。ちゃんと設定しないとシンボルが表示されないとかあるかも知れません。
てか設定が難しすぎるんですけど...🥺
そういえば、Segoe UI Emojiでは 雪だるまの絵文字が ☃(#x2603)と ⛄(#x26c4)の二つあって少しデザインが違います。
因みにブラウザでは ☃(#x2603)の方は文字フォントの方に含まれる絵で表示されるようです。
さておき、describe-charで見てみると ☃(#x2603)は「SNOWMAN」で、⛄(#x26c4)は「SNOWMAN WITHOUT SNOW」
となっています。雪無しをわざわざ定義しているが故に☃(#x2603)は雪有りにしなくてはならないのか?
と思ったのですがどうなんだろう?🤔
また、「☀(#x2600)」をカラー絵文字で表示されるようにしてみたものの説明は「BLACK SUN WITH RAYS」と
なっているので、説明と合わなくなるなぁ?と思ったりも。うーむ、絵文字...闇が深い...🤔
AM中に起床。
東京都コロナ感染者。新規は 9457人。
Emacsで絵文字を「M-x describe-char」で調べると name: の項に絵文字の説明のような英文が表示されています。
例えば「🍥(ナルト)」は「FISH CAKE WITH SWIRL DESIGN」となってます。
これってどうやって表示しているんだ?と思って調べてみたり。ソースアーカイブ内に
admin/unidata/unidata.txt という文字コードに対応するプロパティの一覧となるファイルがあり
この中に文字の説明が含まれているようです。これを元にした表がEmacs本体に組み込まれているっぽいですがそこはよく判らず。
ただ、合字については一意の表で求めるのが難しいのもあってか、表示上は単一文字っぽく見える
「👨🌾(男性の農夫)」や「👩🌾(女性の農夫)」もZWJ前の👨や👩の説明となるようです。
組み合わせの数から考えると仕方が無いのかも知れません。
合字の絵文字入力。MS-IMEだと「かぞく」を変換すると合字のバリエーションも含めた絵文字が変換候補に挙がりますが、
「のうふ」のように絵文字が変換候補に出てこないものもあります。コピペ以外で入力ってどうやるんだ?と思い調べてみたら
「Winキー + .」で絵文字パネルが開くのでそこから選んで入力するという方法があるのを知りました。
表示可能な合字バリエーションも一覧の中に含まれているので、探すのはちょっと面倒臭いですが一応入力可能になりました。
describe-charで気になった絵文字を少し調べてみました。Segoe UI Emoji表示での感想です。
違う絵文字フォントだとまた様子が違うのかも知れません。
🍜 | STEAMING BOWL | ラーメン(Ramen)じゃないらしい |
🥓 | BACON | 言われてみればそう見えるような見えないような… |
🥨 | PRETZEL | ドイツ発祥の焼き菓子パンらしい |
🥮 | MOON CAKE | 月餅って中国のお菓子だったんだ |
🦪 | OYSTER | 上に乗ってる丸いの何?って思ったら牡蠣も真珠を作るらしい。へぇ |
🥫 | CANNED FOOD | 流石に外見だけでは食料缶詰とは判らない |
💾 | FLOPPY DISK | 「なにこれ?」ってなる日が来るとは思ってなかったよね |
💽 | MINIDISC | これも古代アイテム入りしてるね |
💿 | OPTICAL DISC | こちらはまだイケてるかも |
📀 | DVD | OPTICAL DISCと分けたのは失敗な気も |
🖲 | TRACKBALL | 今もあるっちゃあるか?(ブラウザではカラー表示されず?) |
🖇 | LINKED PAPERCLIPS | 何故これを絵文字化しようと思ったのか謎(ブラウザではカラー表示されず?) |
🥎 | SOFTBALL | モノクロだと⚾(BASEBALL)と区別が付きません(若干SOFTBALLの方が大きい) |
テレワーク。気持ち遅めに終了。
東京都コロナ感染者。新規は 8292人。
以前、絵文字フォントの表示比較を行ってみたのですが、
一応 カラー絵文字対応 emacs-w32で確認してみたり。
Segoe UI Emojiがカラーで表示される事よりも、Emacs-28.xではデフォルトで
絵文字のフォントがSymbolaになってて、propertizeの face指定で任意のフォントにオーバーライド
できなくなっているのを調べる方に時間がかかってしまいました😓。
そういやこの表示では「☀(#x2600)」(一番左の晴れマーク)が それぞれのフォントで表示できてるな🤔。
先日の通り普通のテキストでは表示できてないのですが。
どうやらテキストプロパティを保持できるモード(fundamental-modeなど)であれば、
表示できているものをコピーする事は可能みたい。でもデフォルトフォントとして表示する事はできず。
テレワーク。気持ち遅めに終了。
東京都コロナ感染者。新規は 9755人。
IDWriteGdiInterop::ConvertFontFaceToLOGFONT()が失敗するフォントを調べたり。
どうやら「Modern」、「Roman」、「Script」が失敗する模様。これらはWindowsの「設定→個人用設定→フォント」
では何故か使用可能なフォントに出てきませんが、フォント選択ダイアログには一応表示されます。
フォント選択ダイアログで見て共通しているのは「文字セット」が「OEM/DOS」となっているところ。
こちらの説明によると
OEM文字セットは「画面表示用の全画面 MS-DOSセッションで使用されます。」と記されていて、
Windows文字と異なるとも記されています。しかしながらExtTextOutW()では表示できるので問題は無いかなと思います。
ビットマップフォントなのかと思ったらストロークフォントのようです。
テレワーク。気持ち遅めに終了。
東京都コロナ感染者。新規は 10114人。
Emacsで絵文字表示。絵文字表示とは関係ないフォントで表示するテストを行っていたところ
Segfaultでずっこけるケースに遭遇したり。DirectWrite の IDWriteGdiInterop::ConvertFontFaceToLOGFONT() による
LOGFONTへの逆変換が失敗する場合があるっぽい。変換失敗時をハンドリングして対応。
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 11196人。多いな。
Emacsで絵文字表示。例えば「☀(#x2600)」の文字は Segoe UI Emoji にカラー絵文字として含まれているようなのですが、
どうやっても オーバーライドできなくて 今の設定では MeiryoKe_Consoleで表示されます。
って書いた所でChromiumEdgeやChromeで表示しても Segoe UI Emoji では表示されないなぁ?こういうものなのか?🤔
テレワーク。気持ち遅めに終了。
東京都コロナ感染者。新規は 4025人。
そういや日曜の夜に日テレで放送されていた「霊媒探偵・城塚翡翠」。先日の放送で長い伏線回収。
ファンタジーなのかと思ったら全然違いました。全部観てから振り返ると 最初から仕込みという体では
最初の入り(作家先生が後輩に連れられた先で翡翠と出会ったあとで後輩が殺人事件の被害者になる)は
ちょっと無理があるような気がしなくもありませんが おもしろかったです。
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は 6922人。
emacs-w32でカラー絵文字。初期立ち上げからの確認をしていたところ何故か
フォントを「MS Gothic-10」に設定した時だけカラー絵文字の表示が変になるという現象に遭遇。
「MS Gothic-9」も「MS Gothic-11」も大丈夫なのに何故か「MS Gothic-10」だけがダメ。えー?🤔
ちょっとソースコードを弄って反応を見てみた結果、グリフの描画を実行するメソッドDrawGlyphRun()の
DWRITE_MEASURING_MODEって引数を DWRITE_MEASURING_MODE_GDI_NATURAL から DWRITE_MEASURING_MODE_GDI_CLASSIC に変更したら大丈夫になりました。
一応 説明
は読んだのですがイマイチ意味が判っていません😓
以前 Cygwinの emacs-gtk上での vtermはカラー絵文字を表示できる
ターミナルとして使える事は判っていました。で、カラー絵文字対応したemacs-w32で試してみたり。
vim と emacs -nw を同時に表示する為に screenコマンドを挟んでます😅。vimの方は合字では表示しないようですが、
ZWJも含めた編集は問題無くできるみたいです。一方 emacs -nw の方は合字の表示はされますが、カーソル位置が
合っていなくて編集がうまくできないようです。auto-composition-mode を nilにすれば合字での表示は行われなくなりますが
その代わりに編集はvimと同レベルで可能になるようです。ほぅ...
そういえば Windows10と Windows11とでは Segoe UI Emojiのデザインが違うっぽい
(参考)。
Windows11の方でも グラデーションは未使用みたいなので、単色のカラーレイヤーを重ねて表示する感じなのかなと想像してみたり。
ところで、Windows11の方は細かい描画になっているように思えますが、文字列の一部に含むには細かすぎるようにも思ったりも。
実際どうなのかは判りませんが。
AM中に起床。
東京都コロナ感染者。新規は 8021人。
emacs-w32でカラー絵文字。Emacsで表示確認するのに「C-x +」とかで表示拡大していたのですが、拡大率が大きいと
アンチエリアスがかからないなぁ?と思ったり。
左はカラー絵文字対応したもの、右はカラー絵文字対応無しのものですが アンチエリアスについてはどちらも同じ 且つ絵文字じゃなくても同じみたい。
ClearTypeなのでアンチエリアスの質についてはここでは問わないとします。
さておき、「:height 32.0」以外はアンチエリアスがかかっているのですが、32.0だけはアンチエリアスがかかってません。
あるサイズよりも大きくなるとアンチエリアスがかからなくなるという仕組みのようです。
でもこれは合理的に思います。例えば 二種類のディスプレイがあったとして 物理画面サイズは同じだけど DPIが異なるような場合、
見た目の文字サイズを同じにしようと思うと DPIの高い方はフォントサイズを大きくすることになるかと思います。
あくまでディスプレイに文字として表示するのであれば 非常に高いDPIのディスプレイではアンチエリアシングは無くても事実上問題無い
(アンチエリアスされてても肉眼では識別できない)のかなと思います。
Cygwin 3.4.0-0.1というテストリリースが行われているみたい
(アナウンス)。
32bitサポートが止まるのは先日も記した通りなのですが、
「Drop support for Vista and Server 2008.」となっていて、Windows7はまだサポート範囲に入っているのかと思ったり。
確かに 有償サポートで2023年1月までは使えるようですが それもあと数か月だよなぁ?と思ったりも。
テレワーク。早くもなく遅くもなく終了。
東京都コロナ感染者。新規は 6052人。
そういえばカラーの絵文字フォントの中に「EmojiOne Color」っていうのがあります。
OpenType-SVG のカラーフォントっていうものらしい(参考ページ)。
Web検索していて
こちら
のサンプルコードを知ったのですが SVGのグリフをレンダリングする方法があるみたいです。
ただ、Direct2Dデバイスコンテキストにレンダリングする方法しかないようで GDIにレンダリングする術は無いっぽい。
ベクターグラフィックス画像をGPUを使って高速にレンダリングするって考え方だと思うのですが、
画面に占める絵文字の量や CPU性能から考えてもGDIにレンダリングするのはそんなにダメなものなのだろうか?
Cygwin x86のEOL。「[ANNOUNCEMENT] Cygwin x86 end-of-life」
というアナウンスがありました。約1年程前に予告はされていましたが
予定通り3.4以降は Cygwin64のみアップデートされる模様。
Windows11のシェア。Windows7よりも低いらしい(参考ページ)。
本当に Windows7よりもシェアが低いとすれば ほぼ周りに使っている人が居ないという感じに思えるのですが、
Web検索しているとWindows11の話題は割と目に付くように思えます。いわゆる「声がでかい」って現象なのかも知れません。
とは言え、結局PCのリプレースと共にWindows11に新陳代謝していく感じなのかもなぁ?とは思ったりも。
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 7969人。
emacs-w32でカラー絵文字。MinGWでビルドできるか一応確認してみたり。随分前に入れてあったMSYS2で試そうとしたのですが、
pacman同期がどうにもうまくいかなくて最新版を再インストールする所から行う羽目に😓。
Emacsのビルドに必要な最低限のパッケージを入れてビルド。ビルドはできて 表示も大丈夫そう。
普段使いしていないのでちょろっと確認して終了。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 9012人。
emacs-w32でカラー絵文字。C++対応の為にsrc/Makefile.inと configure.acと src/verbose.mk.inを書き換える
必要がありました。オプションで切り替えとかは無しで configure実行から makeでビルドできるようになりました。
ただ、Emacs-28.2向けには専用に足した感じです。次の Emacs29では Haiku向けの configure.acや Makefile.inの
記述とうまくひっつけないとダメかもなと思ったりも。
それにしても Cygwinは configure実行がとてつもなく遅いのでデバッグが捗りませんでした。
Windowsアップデートで再起動したついでに カラー絵文字対応したemacs-w32を普段使いでテストしてみる事に。さてどうなるか。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 8665人。
emacs-w32でカラー絵文字。昨日の結果から察するにどうやらx,yを中心として マイナスの座標位置に
レンダリングされる場合があるんじゃないか?と思ったり。それだと色々と辻褄が合います。
という訳でD言語の実験コードで確認。うまくいきました🙂 ついでに背景との重ね合わせについては、
元のGDI背景をbitblt()でDirectWriteのメモリDCにコピーしてから文字をレンダリングしてまたbitblt()で
戻せばよくね?と思い試してみたらこちらもうまくいきました😄 そしてEmacsに移植。よき。
因みに右側の赤い四角はBoxカーソルです。さておき、カーソルが乗った場合、カーソル色で塗りつぶした上に絵文字をレンダリングする事になるのですが、
一人ずつ描いているので途中の経過が表示される事があって微妙にちらつきます。
全ての文字描画に対してカラー絵文字か否かの判定が入るようになったのですが、
体感的にはそんなに遅くはないかな?という感じです。全面絵文字で埋めればそれなりに重くはなるのですが、
カーソルが全く動かないという事はありませんでした。
マシン性能にもよるかも知れませんが GDIでも意外と大丈夫かも?と思ったりも。
デバッグコード山盛りのソースコードを整理。DirectWriteを使うコードはC++なのですが、28.2のMakefile.inには
CXXを使う例が無くてどうしたもんか。29系では Haikuサポート対応でCXXを使うようになっているみたいなので
それを参考にするしかないか....?🤔
テレワーク。早くもなく遅くもなく終了。
東京都コロナ感染者。新規は 3489人。
emacs-w32でカラー絵文字。デバッガで観察してみたり。
周りでやってる事が影響しているのか?と思い ExtTextOutW() 実行前にデバイスコンテキストを操作しているコードを
コメントアウトしてみたけど特に反応無く意図通りにレンダリングできている模様。やっぱ座標は正しいのか?🤔
D言語の実験コードでEmacsと同じコードを再現してみたところ、カラーの方のレンダリング位置がマズい気がしてきました。
ただ、正解はまだよく判っていない。
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は 6264人。
emacs-w32でカラー絵文字。ちまちま調節したり修正したり。でも、今の作りではどうしようも無い所に突き当たっている状況。
背景色の情報自体はすぐ参照できる所にあったので、グレー固定だった背景色を都度変更することで対応できました。
アンダーラインや取り消し線は フォントをレンダリングした後にGDIで別に行っているのでフォントレンダリング時に対応する必要はありませんでした。
もしGDIを使わない仕組みにした場合はがんばる必要がある所なのかも知れません。
問題は合字で、「👨🌾(農夫)」みたいなのは大丈夫そうなのですが「👨👩👧👦(4人家族)」は壊滅的にダメな状況です。
そもそもどうやってグリフコードが渡されて来ているのかを調べてみたところ、人のグリフをひとつず4人分レンダリングする必要が
あるようなのですが、前の文字の位置とかを覚えておく必要があるみたい?
しかし、今の作りでは グリフ列をレンダリングすると前の事はすっかり忘れる感じになっている為、位置が変になり且つ
背景色の余白が重なるといった状態になっています。
そもそもD言語のテストコードでもどうやればレンダリングできるのかよく判らない感じ。うまくいかないなぁ🤔
もう少し観察してみたり。グリフ毎に指定される座標の値やオプションを見ても、これじゃ思うような位置に
絶対レンダリングできないんじゃないか?という気がしたり。
でも、ExtTextOutW()はこの情報だけでやってるんだよなぁ? 一体どうやってんだ?謎🤔
D言語のテストコードで確認してみたところ、グリフコードだけではExtTextOutW()でも合字は思った通りに
レンダリングされなかったり。
DirectWriteと同じになったのでExtTextOutW()に渡される座標の値だけではこのようにしかならないと考えられます。
という訳で何かしら手順が抜けているんじゃないかと推測したり。
AM中に起床。
東京都コロナ感染者。新規は 7967人。増えてるな...
もそもそと実験コーディング。D言語でなんとなくうまくいったコードを C++(てかほぼC)にそのまま移植
しているつもりなのに想定した結果にならず。あれぇ?
原因判明。構造体のメンバー変数が初期化されていない為、異常な値を食って変になってました。
D言語では構造体メンバーは0とかnullとかに初期化されるので気づくのに時間がかかってしまいました。修行が足りません。
そんな訳で試しに emacs-w32に組み込んでみました。
w32apiの ExtTextOutW() に似せた関数を作って、カラーグリフの場合は DirectWriteでGDIにレンダリングし、
そうでなければ ExtTextOutW()にフォールバックするという単純な方法で実験してみました。
しかしながら問題は色々あります。DirectWriteのレンダリング先は透明度無しのメモリDCの為、レンダリング結果を
BitBlt()でコピーする時に重ねられないので背景色ってどうすりゃいいんだ? みたいなのに始まり、
絵文字の合字がうまくレンダリングできない場合があったり、アンダーラインや取り消し線とかもどうなるか判っていないなど問題は山積みです🥺。
面倒臭いので ExtTextOutW()を カラー絵文字がレンダリングできるようにしてくれればそれで十分なのにと思わなくはありません。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 3090人。
実験コーディング。まだ謎は多いけど手順は解った気が。気のせいかも知れませんが。
AM中に起床。
東京都コロナ感染者。新規は 6686人。
実験コーディング。やっと解ったようなそうでもないような。
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 6346人。
実験コーディング。やっぱりよく解らん。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 6520人。なぜ跳ねる。
「日付」というWikipediaの存在を知ったり。
年月日の順番が国や文化によって異なる事がありますが、それに対して
ビッグエンディアン(年月日)、リトルエンディアン(日月年)、ミドルエンディアン(月日年)ってのが定義(?)されているのを知りました。
年月日以外はソートが面倒臭いのでコンピュータを使っていれば自然と年月日に移行されそうなものですが そういうものでも無いみたい。