Fansi downgrading issue

So, I’m tweaking my skin, and playing around and did the following:

think %x100^%x101:%x102-----%x103-----%x104-----%x105--------------------------------------------%xn%x104-----%x103-----%x102-----%x101:%x100^%xn

If you try this out with fansi off, you should notice the first sequences downgrade to the un-highlighted version of the xterm256 color, while the right sequences downgrade to the highlighted. I stuck a %xn in there to see if a stray highlight from the %x105 got left over, but it doesn’t seem to have helped.

You need the %xn after the 104 bit. 104 downgrades to a highlighted blue, so that’s what’s making everything to the right of it bold. This looks as expected for me:

think %x100^%x101:%x102-----%x103-----%x104-----%x105--------------------------------------------%x104-----%xn%x103-----%x102-----%x101:%x100^%xn

Curious though - do you know why some of the ANSI codes downgrade to highlighted options? I grabbed the codes from the Rhost versions you so helpfully provided last summer but now that I look at it… should bold maybe be reserved for when you use %X?


First, oops, I thought the wrong one downgraded. That said, I really think highlight shouldn’t carry over in downgrades: like, I think any fansi character that’s downgrading should emit a %xn before it anyways. The highlight carry over on color change only really makes sense when people are using ansi16.

Second, As for why, I don’t actually entirely understand the algorithm. It downgrades to highlighted options because its trying to find the ‘closest color match’, and xterm104 is a quite light blue.

I got that table by just running the xterm color codes through the Rhost colors() function with the ‘c’ argument that does the translation. Exactly how it calculates it is math that makes my head hurt :slight_smile:

I can see why the algorithm would pick ‘highlighted’ for some of the colors, since the FANSI versions are really bright.

That said, I’m going to remove the highlight from the downgrade codes. I don’t think that it’s appropriate to turn on a “sticky” format flag for a downgrade, even if it does make the color closer to its FANSI equivalent. The main goal is to avoid showing gibberish, not to really replicate 256 colors with only 8.

(Incidentally - throwing in extra %xn’s before or after the downgrade code doesn’t really fix it - it just shifts the problem. You can still end up with things accidentally bold/not-bold.)