Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ ANSI Bleed
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #15 on Fri 17 Oct 2014 09:17 PM (UTC) |
| Message
| That may depend on the font.
Quote:
But basically what you are saying is, instead of using 'ansi(hw,...)' as a wrap around, I should be using a specific color like #ffffff?
No, wait, I'm talking nonsense. ;)
I confused myself. We aren't bolding the background - that stays the same. It's a bug that the foreground colour isn't changing.
In other words, we should be getting bold white. My error.
I'll look into that now. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Reply #16 on Fri 17 Oct 2014 09:23 PM (UTC) |
| Message
|
Nick Gammon said:
However when I did the 256-ANSI colours I decided that if you wanted a brighter shade of a colour, you could just pick it (after all, there is a large colour range) and that brightening the base colour up was not necessary.
Except when choosing one of the original 8 colors, though, right?
Otherwise you've just changed display behavior if a 16 color MUD converts their codebase to support 256 colors like Aardwolf did.
Quote:
the idea that 256-ANSI colours should be brighter when bolded
Colors above 7? No. Colors below 8? Probably.
Quote:
and if so, how much?
By 8, of course. :) |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Reply #17 on Fri 17 Oct 2014 09:26 PM (UTC) |
| Message
| |
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #18 on Fri 17 Oct 2014 10:01 PM (UTC) |
| Message
| Definitely. I'm looking at that now.
At present the 256-colour ANSI is turned into a RGB colour lookup at that point (for foreground and background) and it can't then work out what bold is afterwards. And we can't just add some brightening to the colour, because what if you have two bolds in a row? You don't want it twice as bright. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Mercutio
USA (18 posts) Bio
|
| Date
| Reply #19 on Fri 17 Oct 2014 10:13 PM (UTC) Amended on Fri 17 Oct 2014 10:14 PM (UTC) by Mercutio
|
| Message
| Well, since a color will never go over 16, you can just bound it with a simple ternary logic.
newvalue = if( oldvalue+8 > 16, oldvalue, oldvalue+8)
Based on assumptions: you only ever bold non-256 colors. Actual font-boldness is a Boolean thing, so that should be a non-issue if it was started twice. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #20 on Fri 17 Oct 2014 10:32 PM (UTC) |
| Message
| | That part isn't the issue. It's that once I get a 256-colour ANSI sequence it switches to a different mode. I'm going to have to undo that. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #22 on Fri 17 Oct 2014 11:26 PM (UTC) |
| Message
| This is what the revised code is producing, I presume this is what you want?
 |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #24 on Sat 18 Oct 2014 02:33 AM (UTC) |
| Message
| |
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #25 on Sat 18 Oct 2014 11:01 PM (UTC) |
| Message
| I'm still a little puzzled about the colours you showed in your linked files from Potato:
Measuring with a eye-dropper that background colour (which is different to what I showed above) is:
And we know from page 1 of this thread that this is ANSI-256 colour number 24.
Now from my page about those colours ( http://www.gammon.com.au/forum/bbshowpost.php?id=7761&page=3 ) I actually have that as colour 24 in this table:
16 (black) R= 0 G= 0 B= 0 #000000 &h000000 0x000000
17 R= 0 G= 0 B= 95 #00005F &h5F0000 0x5F0000
18 R= 0 G= 0 B=135 #000087 &h870000 0x870000
19 R= 0 G= 0 B=175 #0000AF &hAF0000 0xAF0000
20 R= 0 G= 0 B=215 #0000D7 &hD70000 0xD70000
21 (blue) R= 0 G= 0 B=255 #0000FF &hFF0000 0xFF0000
22 R= 0 G= 95 B= 0 #005F00 &h005F00 0x005F00
23 R= 0 G= 95 B= 95 #005F5F &h5F5F00 0x5F5F00
24 R= 0 G= 95 B=135 #005F87 &h875F00 0x875F00
25 R= 0 G= 95 B=175 #005FAF &hAF5F00 0xAF5F00
26 R= 0 G= 95 B=215 #005FD7 &hD75F00 0xD75F00
27 R= 0 G= 95 B=255 #005FFF &hFF5F00 0xFF5F00
But I eventually realized this was silly. Look at the gaps in the sequences (for blue in this case):
0 95 135 175 215 255
Gap: 95 40 40 40 40
Why the initial gap of 95?
This does not give an evenly-spaced colour cube.
I eventually settled on an even gap of 51:
16 (black) R= 0 G= 0 B= 0 #000000 &h000000 0x000000
17 R= 0 G= 0 B= 51 #000033 &h330000 0x330000
18 R= 0 G= 0 B=102 #000066 &h660000 0x660000
19 R= 0 G= 0 B=153 #000099 &h990000 0x990000
20 R= 0 G= 0 B=204 #0000CC &hCC0000 0xCC0000
21 (blue) R= 0 G= 0 B=255 #0000FF &hFF0000 0xFF0000
22 R= 0 G= 51 B= 0 #003300 &h003300 0x003300
23 R= 0 G= 51 B= 51 #003333 &h333300 0x333300
24 R= 0 G= 51 B=102 #003366 &h663300 0x663300
25 R= 0 G= 51 B=153 #003399 &h993300 0x993300
26 R= 0 G= 51 B=204 #0033CC &hCC3300 0xCC3300
27 R= 0 G= 51 B=255 #0033FF &hFF3300 0xFF3300
That makes colour 24:
Which is exactly what is shown in the MUSHclient output.
5 gaps of 51 = 255, like this:
0 51 102 153 204 255
Gap: 51 51 51 51 51
Doesn't that make more sense? Then you have an even colour spacing from which to choose colours.
Perhaps you better fire off a message on the Potato forum. ;)
In their defence, there is a chart that supports their system:
http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html
But that's just one person's opinion isn't it? Where is the supporting documentation? |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Mercutio
USA (18 posts) Bio
|
| Date
| Reply #26 on Sat 18 Oct 2014 11:05 PM (UTC) |
| Message
| | The whole ansi scale is always a tad messed up in regards to what the best transition is. I can throw this Mike's way (the creator of Potato). But do note that the color may also be a bit off since I'm running Flux. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #27 on Sat 18 Oct 2014 11:14 PM (UTC) |
| Message
| I found a reference:
https://github.com/robey/antsy/blob/master/docs/xterm-256.md
Quote:
Color cube
Unlike the netscape color cube, the xterm-256 color cube is weighted toward brighter colors, with more fidelity in the visible range. The encoding is a base-6 RGB, with the 6 values being:
0x00 (0)
0x5f (95) +95
0x87 (135) +40
0xaf (175) +40
0xd7 (215) +40
0xff (255) +40
So it looks like I might be wrong, and Potato right, although I suppose it depends on whether we are officially using the xterm colour cube. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
99,228 views.
This is page 2, subject is 2 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top