Recent searches
Search options
https://gogh-co.github.io/Gogh/
「Gogh」に含まれる色々な配色を JSON で貰って来て、自前で見本を作って眺めてました。「ANSI エスケープコード」の基本 16 色の話。
16 色のうち後半の八色は強調を表すというのが本来の位置付けなので、黒地に白の場合は明るくていいけど、白地に黒なら暗くすべきだと前から思ってる。やっぱり取り扱いがバラバラだなあ。
「Everforest Dark」の構造は興味深い（添付の図）。強調されない方の色は、暗くするのではなく、通常の文字色と混ぜたような色になってる。確かに本文中の文字色として使われる前提なら、本文の色と少しだけ違うのが「弱い着色」で、大きく違うのが「強い着色」だと言える。
こういった配色で何ができて、何ができないのか、まだ把握し切れてなくてずっと考えちゃう。取りあえず、
・ 基本の背景色と前景色に何を選ぶか
・ 有彩色として何を採用するか
…に分ける事はできる。有彩色には特定の色相を敢えて含めない事で独特の雰囲気が出る。例えば真っ赤がなくて、その分 青系が多めとか。あとは有彩色に明度や彩度を抱き合わせるかどうか…一定にした方が無難だけど、個性は出る。
「全体的に茶色っぽい」みたいなのを、前述の二つの観点と別に扱う必要はあるかしら。
RGB の値を単純に反転するだけで「白地に黒」と「黒地に白」が得られるようにするという制約を設けて、ANSI 16 色の配色を設計してみました。補色が HSL の色相で 180 度の差を持つように制限される。
const 配色_RGB対称暗 = { name: 'RGB 対称・暗',
color_01: '# 222b34', color_09: '# 515a63',
color_08: '# aea59c', color_16: '# ddd4cb',
color_02: '# ab7271', color_10: '# f97160',
color_04: '# a17f4c', color_12: '# e09000',
color_03: '# 6c8c50', color_11: '# 64ab00',
color_07: '# 548d8e', color_15: '# 22b2aa',
color_05: '# 5e80b3', color_13: '# 3990ff',
color_06: '# 9373af', color_14: '# c56cef',
};
const 配色_RGB対称明 = { name: 'RGB 対称・明',
color_01: '# ddd4cb', color_09: '# aea59c',
color_08: '# 515a63', color_16: '# 222b34',
color_02: '# ab7271', color_10: '# dd4d55',
color_04: '# a17f4c', color_12: '# c66f00',
color_03: '# 6c8c50', color_11: '# 3a9310',
color_07: '# 548d8e', color_15: '# 068e9f',
color_05: '# 5e80b3', color_13: '# 1f6fff',
color_06: '# 9373af', color_14: '# 9b54ff',
};
「rgb(…)」だと字数を食うから 16 進法に置換したけど、そのままではハッシュタグになっちゃうんだった…。
https://blog.ce9e.org/posts/2019-06-24-terminal-colors/
CLI の画面は歴史的に「黒地に白」だったので、近年 選択肢にある「白地に黒」の配色設定は設計が統一されていない…という問題にちょっと触れている個人の記事があった（のを昨日見た）。別に新情報はないけど「そうなのよねえ」と共感する所が多かった。
ツール開発者が利用環境として想定するのは「黒地に白」の画面だろうから、配色設定はそれを破綻なく表示できるようにするのが正解だと思うけど。色を直接指定する必要があるツールだったら、16 色ではなく 256 色を使うべきだろうし、16 色の方は絶対的な色を維持する必要ない。
弱い方の色は輝度でなく彩度を弱くするというアイデアも最後に触れられていて、これはちょうど私が採用してみた考え方。
「弱い文字色」と「弱い背景色」は使うべき色が必ずしも一致しないから、ターミナルエミュレーターはそれを区別してくれて描画してくれてもいい。背景色としては、文字との輝度差が欲しいのよね。つまり通常の背景色に近い明るさ（黒地に白なら、暗い色）がいい。配色設定は 24 色構成になる。
「明るい背景色が設定されている部分の文字色」を通常の文字と同じ色で描画する必然性も別にない。「背景が赤で文字が青の場合」とかいう組み合わせまでは対応しなくていいと思う…。
配色を捏ね回すのが好きだけど、CLI のツールを使う機会はほぼない上に、文字の着色を大いに生かしたツールを利用する事は一層ない。
JavaScript で、ペーストされた画像の中身を取り出すの結構簡単だった。イベントオブジェクトの clipboardData からファイルとして取得して、あとは input‐要素で受け取ったのと同様に使えるみたい。「File → ImageBitmap → OffscreenCanvas → ImageData → Uint8ClampedArray」というタライ回し感があるけど、これはしょうがないかな。
最初は従来通り HTMLCanvasElement を使ったけど、折角なので OffscreenCanvas を試すと同様に動いてくれた。でも比較的新しいから対応環境が減るなあ。従来の HTMLImageElement の代わりが ImageBitmap で、HTMLCanvasElement の代わりが OffscreenCanvas という感じかしら。
![window.addEventListener('paste', async (ev) => {
if(ev.clipboardData.types[0] !== "Files") return;
const file = ev.clipboardData.items[0].getAsFile();
if(!/^image\//.test(file.type)) return;
const bitmap = await createImageBitmap(file);
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
const 文脈 = canvas.getContext('2d');
文脈.drawImage(bitmap, 0, 0);
const data = 文脈.getImageData(0, 0, canvas.width, canvas.height).data;
const 配色 = { name: '貼り付け ' + new Date().toLocaleString() };
L色番号.map(x => 'color_' + x).forEach((名前, i) => {
配色[名前] = `rgb(${data[i*4 + 0]}, ${data[i*4 + 1]}, ${data[i*4 + 2]})`;
});](https://cdn.masto.host/mofu/media_attachments/files/112/454/542/455/247/157/original/e8ec3d55b25dcae1.png "window.addEventListener('paste', async (ev) => {
if(ev.clipboardData.types[0] !== \"Files\") return;
const file = ev.clipboardData.items[0].getAsFile();
if(!/^image\//.test(file.type)) return;
const bitmap = await createImageBitmap(file);
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
const 文脈 = canvas.getContext('2d');
文脈.drawImage(bitmap, 0, 0);
const data = 文脈.getImageData(0, 0, canvas.width, canvas.height).data;
const 配色 = { name: '貼り付け ' + new Date().toLocaleString() };
L色番号.map(x => 'color_' + x).forEach((名前, i) => {
配色[名前] = `rgb(${data[i*4 + 0]}, ${data[i*4 + 1]}, ${data[i*4 + 2]})`;
});")
https://superuser.com/questions/1827718/how-to-transfer-apply-gnome-terminal-colors-to-kde-konsole
KDE の「Konsole」では「普通の色」と「強調された色」と「弱化した色」の三段階をそれぞれ設定できるようになってるらしい。ANSI の制御符号がそういう構造になってるから、そういう環境もあるんぢゃないかと思ったら やはりあった。
文字色としては多様過ぎる感がある。写真や絵を表示する目的なら細かければ細かいほどいいけど、それは現代では少なくとも 256 色とか 24 ビット色とかの役割だし。（通常の文書作成なら、有彩色が六種あるだけでも多過ぎる。シンタックスハイライトなどの目的では、あり得なくはない。）
ほかの多くの環境で利用できる「普通の色」と「強調された色」の対比もあまり存在意義があるとは思えない — 特に太字フォントで区別できる環境であれば。それよりやっぱり「背景として使う場合の色」と「文字を描画する為の色」が分かれてる方が都合がいいなあ。
赤を「失敗」や「危険」の意味で、緑を「成功」や「安全」の意味で使うようなコマンドラインのツールがきっとあるだろう。編集の差分を表示する時に色を使って「削除部分」と「追加部分」みたいな意味付けをする事もあるだろう。他方、単なる色分けとして使う場合もある。色が異なりさえすればよくて、何色かは問わない。そういう役割を持ちやすい色がある。例えば、マゼンタに統一的な意味付けがあるとは思えない。
一つ一つの色に用途が定義できる環境なら、それに合わせて色を選べるんだけど。そうなってない成り行きの世界なので、要件が定まらない。