Added xterm's 256 colors #3189

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

ThomasCantonnet commented Dec 9, 2012

implemented todo according to http://www.frexx.de/xterm-256-notes

+ const HEX_D0D0D0 = 253;
+ const HEX_DADADA = 254;
+ const HEX_E4E4E4 = 255;
+ const HEX_EEEEEE = 256;
@Maks3w

Maks3w Dec 10, 2012

Member

I'm not sure but seems that this list should end with 255

@ThomasCantonnet

ThomasCantonnet Dec 10, 2012

Contributor

It should yes, but Color::Black has been coded to 1 already, because of Color::Normal and Color::Reset, hence causing the +1 on all values. Shall I fix this ?

@weierophinney

weierophinney Dec 11, 2012

Owner

@h3daz -- will it cause confusion if we have the offset-by-one present? If so, we should fix; if not, document and move forward.

@ThomasCantonnet

ThomasCantonnet Dec 11, 2012

Contributor

@weierophinney The values are never used, they are only there to fill the constants with a value. It won't matter much if i decrement the values, guess I will then.

@ThomasCantonnet

ThomasCantonnet Dec 11, 2012

Contributor

Only issue I see with this is that since the argument for write() doesn't require a ColorInterface for $color and $bgcolor, one might have been using an integer value directly, causing a theoretical BC break.

Member

Maks3w commented Dec 10, 2012

Probably is better use some kind of function to calc the color equivalent instead of load all that vars to memory

Contributor

ThomasCantonnet commented Dec 10, 2012

I was thinking about this too, but the fact is that it has been implemented like this so I was just following the logic. I could code a function yes, but I can't think of a good way to implement it, especially without causing a BC break.

@ghost ghost assigned weierophinney Dec 11, 2012

Owner

weierophinney commented Dec 18, 2012

@h3daz write() requires simply a string, IIRC -- which means that we could do something like:

$console->write($message, Color::calc('some value'));

This should be BC -- thoughts?

Contributor

ThomasCantonnet commented Dec 19, 2012

@weierophinney That should be BC yes, but Color::calc() isn't possible, it would be more like Color::map() since apparantly X11 colors are just names mapped to arbitrary values. The only way to get the from RGB value to an X11 value is to reverse the map. And from what I've read also, color 15 may be #ff00ff on a terminal but #3300DD on another.

So we're still on a mapcolor / unmapcolor logic.

Owner

weierophinney commented Dec 19, 2012

@h3daz "calc" was just a suggestion; if "map" is sematically better, that's fine. Additionally, it sounds like if the mapping may vary based on platform, having some sort of way to dynamically calculate it makes sense. Is this something you feel comfortable implementing?

Member

Maks3w commented Dec 19, 2012

Maybe is possible to use a linear relation between hex values and integer values. Hex values has a step of 40 (integer) for each integer up to the right. Doing a division and rounding the value seems possible to make a simple arithmetic operation.

Contributor

ThomasCantonnet commented Dec 19, 2012

@weierophinney @Maks3w Right so I managed to come up with a calculation algorithm for 16 - 231 but I have yet to figure out 231-256 which is grayscale. Where do you suggest we put Color::calc() ? We will still need to use the map for each adapter though.

Owner

weierophinney commented Jan 2, 2013

@h3daz I suggest Zend\Console\Color\Xterm256

Contributor

ThomasCantonnet commented Jan 2, 2013

@weierophinney will do!

@ThomasCantonnet ThomasCantonnet deleted the ThomasCantonnet:xtermcolors branch Jan 4, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment