Support for SGR 10 - 19 m codes

[SlySven]

I code/develop for a different MUD Client which is also a GUI one and I was looking to include support for the 10 - 19 SGR ("Set Graphics Rendition") codes (<ESC> + [ ... m, primary + up to 9 Alternate ones).

However there does not appear to be an obvious way to specify what those fonts are. I was considering an <OSC> "Operating System Command" (<ESC> + ] ... <ESC> + \, where the last two bytes are the "String Terminator") approach but I was wondering whether any other clients - such as yours already support those <SGR> sequences and have a means for the Game Server to specify what they are/mean? If not - is it something that you'd want to consider and collaborate on?

[nickgammon]

Are you referring to ESC [ ... m ? Which is where you specify the font colour? MUSHclient supports the normal 16 ANSI colours, plus 256-colour ANSI (foreground and background).

I don't support changing fonts in the middle of a line (or indeed in the main output window) because that screws up calculations for where you are in the line if you wave the mouse over it. It's bad enough allowing for proportionally-spaced fonts without also allowing for font changes.

If you wanted to specify a font change I would suggest a telnet sub-negotiation sequence, which other clients (if you support that) could just ignore.

I do support multiple fonts in "miniwindows" which are floating frames on top of the main output window, but there is no support for entering text into those (with the mouse and keyboard). They are just written to by scripts, and it is simple enough to change the font in a script.

See: http://gammon.com.au/mushclient/mw_intro.htm for details.

---

If you are writing a new client (and a server to support it) I would be inclined to ditch trying to parse telnet sequences, and just send "messages" to the client, perhaps encoded in JSON. This is how World of Warcraft works (excepting the JSON part, at least for the early clients, I can't speak for the recent ones).

The advantage of the message approach is that the client can easily tell what is a SAY or TELL, compared to a room description or a movement message, because they would all have their own message types. This would make writing a swish client much easier. For example, you could have an inventory window, and have it automatically populated when a message comes down to tell the client you have added/removed an item from your inventory.

If you trying to be compatible with existing clients, then you don't want to rely too much on non-supported features like font changes in the middle of a line, because other clients won't render them.

---

I have a part of my forum for discussing MUD design ideas, if you want to kick off a discussion there:

http://www.gammon.com.au/forum/index.php?bbtopic_id=116

[SlySven]

I am referring to ESC [ ... m type codes. I have been looking over the options available there (according to Wikipedia and other sources - including the reference document: T-REC-T.416 1993/03) and the font selection ones have been making me itch for a while now so I thought I would try and scratch it.

I don't support changing fonts in the middle of a line (or indeed in the main output window) because that screws up calculations for where you are in the line if you wave the mouse over it. It's bad enough allowing for proportionally-spaced fonts without also allowing for font changes.

We alert our users that they have chosen a proportional font and that it might not look that good and that it could mess up some of the display that a MUD Server generates if it depends on a mono-spaced display. As it happens though, Mudlet enforces a duo-space display anyhow (mono-spacing is just not workable for Far-Eastern / CJK writing systems) so even if the end-user does select a font that is proportional the glyphs are laid out based on a uniform (1 or 2 "spaces" per glyph) layout. Far enough we are having to tweak one or two color emojis (and getting those to work on Linux was a PITA) but things are working well enough at the moment.

As for alternate fonts I have prototype code that adjusts the sizes used for each one so that it is rendered at approximated the same size as the primary one - and the user can only set the size of that primary...

If you trying to be compatible with existing clients, then you don't want to rely too much on non-supported features like font changes in the middle of a line, because other clients won't render them.

Well, I was trying to establish which other clients did, if any, support alternate fonts and how, if they did, they specified what they should be. It doesn't look as if it is a feature supported by others - and given the environment it is not surprising that TUI clients, like TinTin++ could not hope to. Obviously clients that don't handle <SGR>10m ...<SGR>19m codes should just ignore them - which is fine - the text should just be displayed in the only font set in the client. I would expect that Servers that want to use these codes would be checking the client that they are talking to can handle them before sending them. I had not considered using a Telnet sub-option to specify fonts so that is something to think about - though I can't help thinking that a "Negotiate About Font Features" NAFF protocol is just begging to be proposed for April 1st! 🤣

If you are writing a new client...

I've been contributing code for it, the Mudlet client for over ten years now...! 😆

[nickgammon]

We alert our users that they have chosen a proportional font and that it might not look that good and that it could mess up some of the display that a MUD Server generates if it depends on a mono-spaced display.

Just to be clear, MUSHclient supports proportional fonts, but just not font changes in the middle of text. The font is set for the "world". You can change it, but then it changes it for everything in the output window.

I'm pretty sure some users are using a Chinese MUD with it.