[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, 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.
 Entire forum ➜ MUSHclient ➜ General ➜ ansi 16 after ansi 256 ignores bold?
ansi 16 after ansi 256 ignores bold?

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Fiendish   USA  (2,533 posts)  Bio   Global Moderator
Date Wed 04 May 2011 08:05 AM (UTC)
Message
If I execute:

Simulate(ANSI(38,5,226).."aaa"..ANSI(31,1).."bbb")
Simulate(ANSI(33,1).."ccc"..ANSI(31,1).."ddd")

aaa and ccc are the same colors (as expected), but bbb and ddd are not. bbb is not showing up as bold even though I have ,1 in there. Why?
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #1 on Wed 04 May 2011 08:38 AM (UTC)
Message
Oh, how interesting. MUSHclient has a bad case of order-sensitivity. Try ANSI(1,31) on for size.

Also Nick, I just noticed that AnsiNote() doesn't interpret xterm-256 color codes properly. It's reading it as a normal sequence, interpreting the 5 as the italic flag.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #2 on Wed 04 May 2011 10:35 PM (UTC)
Message
Twisol said:

Also Nick, I just noticed that AnsiNote() doesn't interpret xterm-256 color codes properly. It's reading it as a normal sequence, interpreting the 5 as the italic flag.


Template:function=AnsiNote AnsiNote

The documentation for the AnsiNote script function is available online. It is also in the MUSHclient help file.



From there:

Quote:

The ANSI sequences defined in the ANSI function will be recognised.


It is behaving as documented.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #3 on Wed 04 May 2011 11:28 PM (UTC)

Amended on Wed 04 May 2011 11:29 PM (UTC) by Nick Gammon

Message
Twisol said:

MUSHclient has a bad case of order-sensitivity. Try ANSI(1,31) on for size.


Very helpful clue, thank you.

I can explain it, the tricky bit is to fix it.

If you look at the line info for that line:


Line 390 (390), Thursday, May 05, 6:59:08 AM
 Flags = End para: no, Note: no, User input: no, Log: no, Bookmark: no
 Length = 12, last space = -1
 Text = "aaabbbcccddd"

4 style runs

1: Offset = 0, Length = 3, Text = "aaa"
 No action.
 Flags = Hilite: no, Underline: no, Blink: no, Inverse: no, Changed: no
 Foreground colour RGB   : R=255, G=255, B=0
 Background colour RGB   : R=0, G=0, B=0

2: Offset = 3, Length = 3, Text = "bbb"
 No action.
 Flags = Hilite: YES, Underline: no, Blink: no, Inverse: no, Changed: no
 Foreground colour RGB   : R=128, G=0, B=0
 Background colour RGB   : R=0, G=0, B=0

3: Offset = 6, Length = 3, Text = "ccc"
 No action.
 Flags = Hilite: YES, Underline: no, Blink: no, Inverse: no, Changed: no
 Foreground colour RGB   : R=255, G=255, B=0
 Background colour RGB   : R=0, G=0, B=0

4: Offset = 9, Length = 3, Text = "ddd"
 No action.
 Flags = Hilite: YES, Underline: no, Blink: no, Inverse: no, Changed: no
 Foreground colour RGB   : R=255, G=0, B=0
 Background colour RGB   : R=0, G=0, B=0

12 columns in 4 style runs

------ (end line information) ------


Notice how the bbb and the ddd lines are both marked "Flags = Hilite"? So it has correctly processed the highlight flag.

But why doesn't it display correctly? Well ... MUSHclient has three storage modes for lines, ANSI-lookup, custom-lookup, and RGB.

The first two only store an index (palette number) and at display time that index is looked-up. So, if you are using ANSI or custom colours you can change the colour configuration and the screen redraws in the new colours (even text already received).

So if you were in those modes, the order of receiving colour/highlight or highlight/colour would not matter. The colour lookup is deferred anyway.

But by using the 256-ANSI code, it switches the style-run to RGB-colour. These colours are looked-up now, not at display time. Now the problem arises.

It gets 31 (red) and looks that up in the ANSI table (from world ANSI configuration page). It finds non-bold red (ie. 128) and stores that.

Then it gets 1 (bold), but this does not trigger a colour lookup. It just turns on the bold flag. Now this would work for ANSI/Custom colours because the colours are looked up later. But for the RGB colours, it really needs to relookup the colour. But this is the rub, it hasn't remembered 31. It remembers R=128,G=0,B=0. So it can't relookup the previously processed colour.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #4 on Wed 04 May 2011 11:41 PM (UTC)

Amended on Wed 04 May 2011 11:43 PM (UTC) by Twisol

Message
Nick Gammon said:
Quote:

The ANSI sequences defined in the ANSI function will be recognised.


It is behaving as documented.

You're technically correct, Nick... but that's one of the worst kinds of correct. I want to know why it doesn't support xterm sequences (which are ANSI sequences themselves), and why it acts any different from incoming-data processing. Does it not use the same ANSI parser? Is there any reason AnsiNote shouldn't support xterm-256? Pointing to the documentation is hand-wavy.

Also, \e[5m works but isn't documented.


Nick Gammon said:
Very helpful clue, thank you.

Sure!

Nick Gammon said:
But by using the 256-ANSI code, it switches the style-run to RGB-colour. These colours are looked-up now, not at display time. Now the problem arises.

It gets 31 (red) and looks that up in the ANSI table (from world ANSI configuration page). It finds non-bold red (ie. 128) and stores that.

Ahh, I see. When I wrote the renderer for Aspect, I delayed style lookup until the moment the text was rendered. I simply take the xterm palette as the base, and map the ANSI color sequences onto the first eight. When the stylerun is created, I check the bold flag and add 8 to the value (boosting it into the second eight of the xterm palette), and then resolve the color.

If the last color sent used the xterm sequence instead of the standard sequence, I set a flag to prevent 8 from being added, so the bold flag has no effect on xterm colors.

[...other methods...]
newStyleRun: function() {
  var fg = this.fg;
  if (this.bright && !this.xterm) {
    fg += 8;
  }
  
  var bg = this.bg;
  if (this.negative) {
    bg = fg;
    fg = this.bg;
  }
  
  if (this.concealed) {
    fg = bg;
  }
  
  var span = ["<span class=\"fg" + fg + " bg" + bg];
  if (this.italic) { span.push(" italic"); }
  if (this.strike) { span.push(" strike"); }
  if (this.underline) { span.push(" underline"); }
  span.push("\">");
  
  return span.join("");
}
[...]
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #5 on Wed 04 May 2011 11:51 PM (UTC)
Message
Twisol said:

Is there any reason AnsiNote shouldn't support xterm-256? Pointing to the documentation is hand-wavy.


Sigh. The full ANSI implementation is done with a state machine that has (rather complex) calculations for the bold/underline/RGB/non-RGB/xterm-256 and so on handling in it. And in a very similar vein to the Simulate, it isn't particularly easy to "inject" the AnsiNote stuff into it. Doing that is likely to change the state for the current incoming line. So AnsiNote just implements a subset of the more commonly-used codes. And as noted, it supports the codes you can generate with the ANSI function. So it is symmetrical.

Twisol said:

Ahh, I see. When I wrote the renderer for Aspect, I delayed style lookup until the moment the text was rendered.


Actually I can't think offhand why that particular style run can't just degrade back to ANSI lookups. After all, once we hit the 31 code, we are no longer processing RGB colours. So that particular style should switch back to ANSI (not RGB) style, and then the bold problem goes away.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #6 on Wed 04 May 2011 11:55 PM (UTC)

Amended on Wed 04 May 2011 11:59 PM (UTC) by Twisol

Message
Nick Gammon said:
Sigh. The full ANSI implementation is done with a state machine that has (rather complex) calculations for the bold/underline/RGB/non-RGB/xterm-256 and so on handling in it. And in a very similar vein to the Simulate, it isn't particularly easy to "inject" the AnsiNote stuff into it. Doing that is likely to change the state for the current incoming line. So AnsiNote just implements a subset of the more commonly-used codes.

Thanks. That's a lot more helpful to me. :)

IIRC, MUSHclient's ANSI implementation is built into the CMUSHClientDoc object, correct? I can definitely see how that would be a problem. If I were writing AnsiNote() for Aspect, I'd create a new ANSI parser object and run the text through it, so as to leave the original untouched.

Nick Gammon said:
And as noted, it supports the codes you can generate with the ANSI function.

ANSI(38,5,9) generates a perfectly valid sequence \e[38;5;9m, and in fact you can generate any arbitrary ANSI-formatted sequence using ANSI().
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #7 on Thu 05 May 2011 02:47 AM (UTC)

Amended on Thu 05 May 2011 02:48 AM (UTC) by Nick Gammon

Message
Twisol said:

ANSI(38,5,9) generates a perfectly valid sequence \e[38;5;9m, and in fact you can generate any arbitrary ANSI-formatted sequence using ANSI().


Perhaps I should clarify that. It supports the *documented* codes on the ANSI help page.



Now as for switching back from RGB mode to ANSI mode - I see I had the code to do that right here (ansi.cpp line 38 onwards):


  // switch back to ANSI colour if required
/*   obsolete
  if ((iCode >= 30 && iCode <= 37) ||
      (iCode >= 40 && iCode <= 47))
    {
    // we can't mix them - if we go back to ANSI colours we have to discard
    // the RGB codes
    if ((iFlags & COLOURTYPE) == COLOUR_RGB)
      {
      iForeColour = WHITE;
      iBackColour = BLACK;     
      }
    iFlags &= ~COLOURTYPE;  // clear RGB or custom bits
    iFlags |= COLOUR_ANSI;
    }

*/


But it is commented out with the note "obsolete". Now I don't take functionality away without a good reason. I can't remember what that reason was however.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #8 on Thu 05 May 2011 02:57 AM (UTC)
Message
Nick Gammon said:
But it is commented out with the note "obsolete". Now I don't take functionality away without a good reason. I can't remember what that reason was however.

The blame output for the file on GitHub doesn't show any changes to the file since you originally pushed it, so it must have been an old change. It doesn't look wrong, anyways, and it's apparently not obsolete any more, so...
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #9 on Thu 05 May 2011 04:21 AM (UTC)
Message
I just ported my ANSI parser to C++, in case you want to use it. The "MyParser" demo I wrote does pretty much everything except actually pass data/styles to the output area.

If you don't use it that's fine, I just felt like doing something in C++.

https://gist.github.com/956475
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #10 on Thu 05 May 2011 04:32 AM (UTC)
Message
It would be done to solve a subtle bug. One I don't particularly want to re-introduce.

Well first, how big an issue is this? Whilst you have identified a bug (Fiendish) the easy work-around is to make it bold, and then change the colour. And it only shows up in the 256-ANSI mode.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Fiendish   USA  (2,533 posts)  Bio   Global Moderator
Date Reply #11 on Thu 05 May 2011 06:09 AM (UTC)
Message
Quote:
Well first, how big an issue is this?

*shrug* :)
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #12 on Thu 05 May 2011 11:04 AM (UTC)

Amended on Thu 05 May 2011 11:12 AM (UTC) by Twisol

Message
This isn't really the place to rant, but honestly, the xterm sequences should've used an intermediate byte instead of an arcane, unusual sequence of parameters. "\e[156/m" would have made much more sense.

And just to spite the MUD gods, I'm going to implement exactly that. So nyah. >_<


(Intermediate bytes are specified in section 5.4 of the ANSI control sequence specification, found here: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf)

[EDIT]: The unallocated bit combinations are reserved for future standardization and shall not be used.
So it doesn't want me to use "/m". Mrrrrgh. Maybe I can use one of the sequences from the private-use table... Okay, standards issues aside, it makes a lot more sense than "38;5;<x>".
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Fiendish   USA  (2,533 posts)  Bio   Global Moderator
Date Reply #13 on Fri 30 Dec 2011 05:36 PM (UTC)

Amended on Fri 30 Dec 2011 08:29 PM (UTC) by Fiendish

Message
Fiendish said:

Quote:
Well first, how big an issue is this?

*shrug* :)

New answer: I just ran into this problem again because my StylesToANSI function favored 256ish equivalents for the standard 1-16 color values and I was trying to use AnsiNote instead of Simulate. I think it's weird for AnsiNote to not work the same way that Simulate does (or even in the same way that a series of consecutive ColourTells would), since re-displaying output from 256 enabled MUDs is such a useful concept.
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #14 on Sat 31 Dec 2011 04:23 AM (UTC)
Message
Do you actually want a bold font, or just the bolded colours?
- 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.

59,893 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]