This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

ANSI Bleed

Posted by Mercutio on Fri 17 Oct 2014 03:37 PM — 28 posts, 102,746 views.

Mercutio USA #0
I can only assume this to be a Client issue, as other clients display the following correctly:

(MUSHclient 4.94)

http://i.imgur.com/tlkLOWC.png (How it shows on MC)
http://i.imgur.com/s8gr9fR.png (How it should look - using Potato)
http://pastebin.com/9NfVwPeV (Debug Packets)

The same has also been tested on TF - which shows the same as Potato.
Meerclar USA #1
What exactly is the problem here? The only difference I can see in those pictures is that the client you said displays correctly uses a muted color palette. Color progression from 0 to 100 is otherwise identical as is the overall color selection. It is a client difference but it's 16 bit color (potato) vs 256 bit color (MC) rather than anything being handled incorrectly.
Mercutio USA #2
I should probably have pointed out the issue a bit better.

Spot the four lines of '2nd Class Exp' until 'Job Class 3 Exp'.

Note that 'non-highlight' bleeds into the pipe characters and HP-DP - until it hits the ansi definition for the colored bar.

It's not supposed to do that. The 'region' above it shows how it should look normally. It has nothing to do with the color progression.

The idea is that '2nd Class Exp' until 'Job Class 3 Exp' (that area, not the numbers! See the other screenshot for how it should look) - are being colored 'non-highlight', which is correct. But the numbers past them etc should not be getting colored.

(Also, both are using 256 color. Including Potato. I'm not sure why you think Potato is showing only 16 colors)
Amended on Fri 17 Oct 2014 04:24 PM by Mercutio
Meerclar USA #3
The region above is all highlight so if that's how it's supposed to be, the formatting in the muds code is off (which it is anyway, missing : at the end of class 1). Your paste bin has been removed so all we have to go by is your pictures and they're of very limited help with finding a color/highlight switch that might be missing or misinterpreted.

Bah, I picked up the leading ( with the pastebin link and didn't catch it on the address.

Ok, now that I've had a chance to look at the packet info, it looks like MC is the client that's actually properly processing the info being sent. If you look at the tags proceeding the lines for Wave Sword and Activity ratings, there's whitespace between the code tags and the start of the actual text. That's missing from the entire section you complained isn't being displayed correctly. If Nick followed the protocol specs with a strict enforcement (and he usually does) MC doesn't know where the tags end and the actual text begins so the tags are simply being discarded until it sees one it can process properly.
Amended on Fri 17 Oct 2014 05:00 PM by Meerclar
Mercutio USA #4
I'll pass it along to PENNMUSH folk re: ansi codes. But I thought the 'm' was the closing tag, not a space.
Meerclar USA #5
Honestly, it depends on how the standard was written. If the standard was a space between closing tags and text, that's how Nick wrote MC to read input and anything without that space is going to be discarded. The only functional difference I see in the incoming packet info between those display sections is the lack of separation between the closing tag and the beginning of the text and pretty much every other time something like this has come up, it's been that Nick writes his code for a strict protocol format where other clients are far looser in how they'll handle tags.
Mercutio USA #6
So what you are saying is, you are just guessing at this. There is something to say about the Robustness Principle here, but that is besides the point.
Meerclar USA #7
Without the ability to see Nick's code, all I really can do is guess based on the packet info and historical info with similar issues between MC and other clients. I frankly don't the time to look up the ANSI standard and the codebase for the mud you're playing to attempt to track down the issue without the code for either client being available.

Nick could probably tell you at a glance if my guess is accurate but it's his code and I'd only be surprised if that wasn't the case.

*edit* I have got to replace this mouse, these double posts are driving me crazy
Amended on Fri 17 Oct 2014 07:09 PM by Meerclar
Nick Gammon Australia Forum Administrator #8
Meerclar said:

Without the ability to see Nick's code, all I really can do is guess ...


Yes but the code is available. For output window viewing see this file:

https://github.com/nickgammon/mushclient/blob/master/mushview.cpp

Code in general: https://github.com/nickgammon/mushclient

Having pointed that out, I'll take a look at what this is about.
Nick Gammon Australia Forum Administrator #9
Duplicate posts deleted.

Congratulations on a comprehensive problem report. They aren't usually that good.
Fiendish USA Global Moderator #10
Meerclar, can you delete your double posts in the future please? :p
Amended on Fri 17 Oct 2014 08:19 PM by Fiendish
Mercutio USA #11
P.S. Not sure if this'll help any, but Mike points out line numbers.


<Hardcode> [({<>})] Mike says, "The pipes should definitely be highlighted. MUSHclient issue."
<Hardcode> [({<>})] Mike says, "Looking at your pastebin, line 93 has 'ansi highlight', then there's numbers, and going onto line 94, the pipes and 'HP', with no other ansi tag to turn off the highlight."
Nick Gammon Australia Forum Administrator #12
Meerclar said:

Ok, now that I've had a chance to look at the packet info, it looks like MC is the client that's actually properly processing the info being sent. If you look at the tags proceeding the lines for Wave Sword and Activity ratings, there's whitespace between the code tags and the start of the actual text.


I don't see any problem in that part.

Mercutio said:

The idea is that '2nd Class Exp' until 'Job Class 3 Exp' (that area, not the numbers! See the other screenshot for how it should look) - are being colored 'non-highlight', which is correct. But the numbers past them etc should not be getting colored.


Looking at that line:


(ESC)[1;37m(ESC)[48;5;24m   | (ESC)[0m(ESC)[37m(ESC)[48;5;24mJob Class 2 Exp:(ESC)[1m    200/1000    |  |


So from the left we are expecting:


Bold / white / Background colour: Ansi256: (dark blue)
Then the vertical bar: |
Then: reset / Background colour: Ansi256: (dark blue) - so not bold basically
Then: Job Class 2 Exp
Then: bold
Then:     200/1000    |  |


I see what you are talking about now. You are saying that " 200/1000 | | " should be bolded when it is not.

Now here's the issue. If you turn on "Show bold" in the output configuration then that text will indeed be shown in bold. So it is respecting the bold sequence, and obeying it. Now what MUSHclient does for ANSI characters (the usual "original" 8 colours) is that it also makes them brighter, in accordance with what lots of programs do (especially since old terminals couldn't change to a bold font).

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.

Now do you have a reference supporting the idea that 256-ANSI colours should be brighter when bolded, and if so, how much?




I have an extensive discussion about the 256 colour ANSI codes here: http://www.gammon.com.au/forum/bbshowpost.php?id=7761

In particular on page 3 is this colour chart:



According to my calculations my background blue is the more correct one.
Nick Gammon Australia Forum Administrator #13
Mercutio said:

P.S. Not sure if this'll help any, but Mike points out line numbers.


Could you ask Mike (whoever he is) why not just choose another, brighter, colour if that is what the intent is? Then you have clearly specified the colour, rather than hoping that bold+original colour is the target colour.
Mercutio USA #14
If I turn on Show Bold, it doesn't show up as Bold.


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?

That makes some sense.

(But other than the background color and the bars, isn't the rest all non-256?)
Amended on Fri 17 Oct 2014 09:18 PM by Mercutio
Nick Gammon Australia Forum Administrator #15
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.
Fiendish USA Global Moderator #16
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. :)
Fiendish USA Global Moderator #17
Quote:
In other words, we should be getting bold white. My error.

Related?
http://www.gammon.com.au/forum/bbshowpost.php?id=11075
Nick Gammon Australia Forum Administrator #18
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.
Mercutio USA #19
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.
Amended on Fri 17 Oct 2014 10:14 PM by Mercutio
Nick Gammon Australia Forum Administrator #20
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.
Mercutio USA #21
Good luck!
Nick Gammon Australia Forum Administrator #22
This is what the revised code is producing, I presume this is what you want?

Mercutio USA #23
That looks right!
Nick Gammon Australia Forum Administrator #24
Fixed in version 4.95.

https://github.com/nickgammon/mushclient/commit/97eeb41
Nick Gammon Australia Forum Administrator #25
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:


red=0 green=95 blue=135


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:



red=0 green=51 blue=102


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?
Mercutio USA #26
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.
Nick Gammon Australia Forum Administrator #27
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.