@tizerm そうだねえ。従来「アルバム」から投稿していたのの代替としては、もっと手軽に呼び出せるといい。

これに限らず「設定」の画面は操作性が悪い。今ちょっと触って分析してみると、第一階層のメニューは十字キーの連打で隣接項目へ進めるからまだいいけど、第二階層以降は「押しっ放しでスクロール」を強いられるので画面外の項目に辿り着くのが遅い。二次元的に並べてほしいのもある。

「そんなに大量にあるわけではない」と思ったけど、現状で画面写真が 1.7 ギガバイト、動画が 9.7 ギガバイトあるわ。

#NintendoSwitch

https://superuser.com/questions/1827718/how-to-transfer-apply-gnome-terminal-colors-to-kde-konsole

KDE の「Konsole」では「普通の色」と「強調された色」と「弱化した色」の三段階をそれぞれ設定できるようになってるらしい。ANSI の制御符号がそういう構造になってるから、そういう環境もあるんぢゃないかと思ったら やはりあった。

文字色としては多様過ぎる感がある。写真や絵を表示する目的なら細かければ細かいほどいいけど、それは現代では少なくとも 256 色とか 24 ビット色とかの役割だし。（通常の文書作成なら、有彩色が六種あるだけでも多過ぎる。シンタックスハイライトなどの目的では、あり得なくはない。）

ほかの多くの環境で利用できる「普通の色」と「強調された色」の対比もあまり存在意義があるとは思えない — 特に太字フォントで区別できる環境であれば。それよりやっぱり「背景として使う場合の色」と「文字を描画する為の色」が分かれてる方が都合がいいなあ。

https://material.io/blog/science-of-color-design
https://facelessuser.github.io/coloraide/colors/hct/

Google が、知覚的等歩度性を意図した HCT なる色空間を作ったのか（2022 年に）。「HSL よりイイ !」ってそりゃ当たり前だろう…競うべき相手は CIELAB（L*a*b*）とか Oklab とかであって、その辺の議論が足りない。

第三者（ColorAide）の記述を見ると、「色彩は CAM16 を、明度は CIELAB を使う」と説明されてる。

Google、既存の規格などを置き替えがち。その際に、別の方式に対する（超古い物でなく最近の競合に対する）優位性をあまり細かく説明しない印象がある。JPEG 2000 をサポートしないまま WebP とか言い出すし。自分トコの製品で実装するから、シェアに物を言わせて普及するんだよなあ。Open Location Code（Plus Code）も連想される。

https://news.mynavi.jp/techplus/article/jpeg-3/

2016 年の記事、インタビュアーが「JPEG 2000 をサポートしているブラウザはないようです」と書いてるのは誤情報では ? Safari が対応してる筈だけど。

掲載されている情報が「snapstream の snapstream_pvs における脆弱性」に修正されてる。

https://jvndb.jvn.jp/ja/contents/2004/JVNDB-2004-000665.html

#脆弱性

色彩に関する説明の中で「白黒に変換してみると、黄色は明るくて青は暗いのが分かる !」などと言うのは、方便にしても論理が雑過ぎてどうしょうもない。「知覚的な明度を維持しながら彩度だけ取り除くという変換をどのように行うか」が問題なのに、それぢゃ順序が逆ぢゃん。どんな方式を採用するかに依って結果の暗さが変わる。やり方を間違えると明度が崩れる。

黄色は明るいから、白っぽくなるように変換してるんだよ。黄色を黄色のまま見て考えなよ。

例えば Clip Studio Paint を使う場合、「色相・明度・彩度」で彩度を下げる操作は明度を全く維持しない。黄色は暗く、青は明るくなる。真っ黒に塗ったレイヤーを合成モード「彩度」で合成する操作はマシ。（この辺の挙動は Photoshop と同様だったと思う。）「グラデーションマップ」も明るさを保てるけど、初期状態のまま使うと線形のマッピングになってなくて偏るので、「混合率曲線」のハンドルを消す必要がある。

@ksnk なんか記事の論調への反射なんだろうけど、最近の CSS には有用な追加は多いです。

CSS は非互換変更をしないから、古くからある記法を避ける意味はあんまない。新しい書き方の方が高機能だったり書きやすかったり読みやすかったりするので、天秤に掛けて新しい方を採用する判断が合理的な場合もある。私は古い環境を気にするから、今もカンマ区切りの「rgba(…)」を使う。いつ頃まで引っ張るかは知らない。

私が行っている日本語表記は全部遊んでるだけであって、こうあるべきとかいう主張はない。好きに遊べばよい。という大前提において…

仮名使いについては、和語に限ってジとヂ、ズとヅの区別を残すようにしてる。（字音は全部ジとズでよい。）〈である〉や〈では〉に繋がる〈ぢゃ〉と、共時的にまだ連濁が見えてる複合語（〈つまづく〉の辺り）には意義を感じる。しかし〈ねぢる〉〈よぢる〉〈いぢる〉〈もぢる〉〈こじる〉〈くじる〉〈ほじる〉〈なじる〉〈にじる〉〈かじる〉〈まじる〉は頻繁に使わないから永遠に調べ直してるし、共時的に構造が見えない語幹の中の区別は放棄していいかも。〈とぢる〉だけは定着してる。

「なぁ」の類で小書きの仮名を使わない。「ティー」の類は長音記号を厳密に使う（作品名などを除く）。

漢字については、個別に調整を加えてある。〈仏〉と〈払〉は、〈沸〉と部品を不統一にする意義があまりないので〈佛〉と〈拂〉を使ってる。〈欠ける〉ではなく〈缺ける〉を使う。一方、書き分ける意義が見えない同訓の字は多少奇異でも片方を廃止する。〈換える〉は使わず、〈替える〉に統合する。〈遣う〉は〈使う〉に統合する。

当て字は可能なら避ける。〈する〉の連用形に〈仕〉を当てない…けど、〈シ事〉〈シ方〉〈シ組み〉の見映えの悪さは自覚してるので、迂回しようとして変な工夫が発生してて良くない。どうしようかな。〈試合〉や〈支拂い〉は許してるので線引きが微妙。熟字訓は原則的に避ける。

常用外の漢字の字体については、何でもいい。統一しないでいい。揺れるのが伝統だし、楽しいだろう。正式で公式な文書を書いてるわけでもない。

音読みの語は原則的に漢字で書くけど、〈ようだ〉には平仮名を使う。（昔は漢字にしてたけど已めた。）〈ヒイキ〉のように、漢字を使わないなら大抵は片仮名にする。読み仮名は積極的に振る。

擬音語・擬態語は原則的に片仮名だけど、〈ゆったり〉のように「さすがに嫌」なので平仮名にする物も時々ある。個別に好みで決める。

「若干見慣れない書き方だけど、まあ読める」くらいの線だと思う。〈已〔や〕める〉を読み仮名なしで突っ込むのがちょっと大胆だけど、文脈と送り仮名で何となく分かるぢゃん、分かるよね…という気持ち。画数少なくて いかめしくはないし。〈名宣る〉も文脈と字義で分かるだろう、多分。〈止める〉はトメル専用にしていて、ヤメルには使わない。音声言語が大事なので、どう声に出すかが定まるような書き方を理想にしてる。

漢語については〈交差〉ではなく〈交叉〉を使うというのもあります。別に〈交差〉でもいいかな…でも〈音叉〉は〈*音差〉にならないしな…。

どう声に出すか定まるようにするという意図で、記号の話をする時は名前を書き下して言及する。例えば「このフォントはピルクロウ（¶）の形が独特だ」のように、名前を書いてから記号そのものを括弧に入れるのが多い。

〈座〉と〈坐〉の区別が微妙な感じになってる。〈坐る〉と書くけど、ほかの全ての場面で分けるかというとフラフラしてる。部品の多い方に統合する事にちょっと抵抗感がある。〈御〉と〈禦〉みたいなのは〈御〉だけでいいんだけど。

ちょっと触れるだけのつもりが、色々湧いて来て長話になってしまった。

顔が描かれているから買ってしまった、パスコのホイップクリームパン。いや、最終的には「買ってもいいから買った」んですけど、顔が描かれてなかったら売り場で検討対象になってないので…。顔が描かれてるの強い。

#もふけもの

四年に一度の「浦安三社祭」が近いので、「御祭礼」と書かれた提灯〔ちょうちん〕などが道に吊られ始めました。三枚目の写真は 5 月 19 日の夜に撮った。

#浦安三社祭 #浦安 #写真

瓶入りの「オイルサーディン」が安くなってたので買ってみたけど、どんな風に食べようかな。