pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: terminal emulator
On Mon, Jun 24, 2024 at 08:57:36PM -0700, George Georgalis wrote:
> On Sun, Jun 23, 2024 at 2:37?AM <tlaronde%kergis.com@localhost> wrote:
>
> > On Sat, Jun 22, 2024 at 10:53:46AM -0700, George Georgalis wrote:
> > > On Fri, Jun 21, 2024 at 12:08?PM Greg A. Woods <woods%planix.ca@localhost> wrote:
> > >
> > > > I'm still confused.... What's wrong with using Terminal for the mac?
> > >
> > > You say it's missing 24-bit colour support? But what for? How can you
> > >
> > > need more than 256 colours in a terminal? Xterm has the same limit.
> >
> > Having a "palette" of 256 colours doesn't mean that the colors are
> > 8bits based (3x3x2 generally). You can perfectly have only 256 colors,
> > chosen by an index in the [0,255] range, but each entry is defined by a
> > 16bits value, a 24 bits value, a 32 bits value (8x8x8 + transparency)
> > etc.
> >
>
> It's quite possible my old .Xdefaults file only mapped some 24-bit colors
> to a smaller usable space... anyway I found this cool pallet tool linked in
> the file...
> http://ciembor.github.io/4bit/#
> https://github.com//ciembor/4bit
>
> wellup, it seems my Therm setup is not working after all, at first I didn't
> notice, but 'fast' cli output,
> like ls or cat, only fills a small portion in the lower left corner of the
> window... more details here
> https://github.com/trufae/Therm/issues/82
>
> anyway, I decided it would be good to keep maintaining 216-color space
> themes and
> used AI to generate these various swatches of the space.
> awk
> 'BEGIN{for(i=0;i<6;i++){for(j=0;j<6;j++){for(k=0;k<6;k++){c=16+36*i+6*j+k;printf("\033[48;5;%dm\033[%dm%4d\033[0m",c,k<2?97:30,c)}printf("")}print""}}'
> awk
> 'BEGIN{for(t=0;t<6;t++){for(y=0;y<6;y++){for(x=0;x<6;x++){c=16+36*x+6*y+t;printf("\033[48;5;%dm\033[%dm%4d\033[0m",c,t<3?97:30,c)}printf("")}print""}}'
> awk
> 'BEGIN{for(t=0;t<6;t++){for(y=0;y<6;y++){for(x=0;x<6;x++){c=16+36*t+6*x+y;printf("\033[48;5;%dm\033[%dm%4d\033[0m",c,y<3?97:30,c)}printf("")}print""}}'
> awk
> 'BEGIN{for(t=0;t<6;t++){for(y=0;y<6;y++){for(x=0;x<6;x++){c=16+t+6*x+36*y;printf("\033[48;5;%dm\033[%dm%4d\033[0m",c,(x+y)%2?97:30,c)}printf("")}print""}}'
> awk
> 'BEGIN{for(t=0;t<6;t++){for(y=0;y<6;y++){for(x=0;x<6;x++){c=16+36*y+t*6+x;printf("\033[48;5;%dm\033[%dm%4d\033[0m",c,x<3?97:30,c)}printf("")}print""}}'
>
> amazing how different a color can look depending on what is next to it. I
> was not able to
> prompt for a rule that would always create a contrasting foreground for any
> background...
The human eye doesn't segregate blue values as much as green or red
but since 8bits values are generally 3x3x2, the coding doesn't help
for the blue shades.
So, if one wants contrasting colors, one has to augment the difference
first in green, slightly less efficiently in red for every color
space, but specially for 3x3x2 since there are less blue shades at
disposable.
And because the Earth is supposed to be dominated (out of town...)
with a majority of green, the human eye (including the processing machine
behind) deals better with green based colors, that are less aggressive for
the mind (not exactly the choices generally made for colors on
terminals; and not what is wanted for crucial informations that have
to stand up).
But this explains too why limiting colors to 256 to limit the size of
the information can be a good idea, but using more than 8bits for
defining a color in order to have colors pleasing to the eye / mind is
useful too.
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Home |
Main Index |
Thread Index |
Old Index