I was wondering if it would be possible to display different fonts on the same screen, if they were the same size. I was thinking about making a plugin to intercept some kind of code from the server and switching to an alternate font.
Multiple Fonts
Posted by Cage_fire_2000 on Thu 05 Jul 2007 01:13 AM — 7 posts, 31,841 views.
Not with the way that MUSHclient currently displays text on the screen. You have to pick one font and stick with it. I personally find that just changing the colours a bit and using underline and/or italics does wonders for making text stand out, but I'd like to change up fonts a bit here and there myself.
It's not that, the game I'm on uses text based graphics, and I thought that if it was possible to switch between fonts it would add to the possible characters that could be used. Unicode was considerd so we'd have thousands of characters, but that would take like a total rewrite of everything, and we only use extended character sets for graphics, and just use normal ASCII the other 90% of the time, so it'd be a waste. So I figured if we could switch fonts on the fly it'd give us more characters only when we needed them.
Well, you can just plain change the font in total... And there are programs out there which will let you create and edit font files. You could feasibly take a font which you like, change it around a bit to keep all the characters you use, and replace the others with ones that you don't use. I know it's a pretty odd hack, but it would work.
Unicode shouldn't be a total rewrite. With UTF-8 it is a sequence of 8-bit characters, so you can just use special sequences where you want them (eg. maps).
I don't see how you can easily change fonts anyway - you would need to send some sort of "font change" sequence, that the client would have to detect, and then draw, and it would be a bit of a mess.
I don't see how you can easily change fonts anyway - you would need to send some sort of "font change" sequence, that the client would have to detect, and then draw, and it would be a bit of a mess.
Ah, you mean like the font change codes in MXP? Or did I just imagine that? lol
Frankly, I really wish there where more fixed width ones, with better fixed width italics support and some other issues. Of course, italics wouldn't be a problem, if we had actual "blink". I still say it was a horrible idea to treat bold/italics, etc. as "the same" as italic, bold, etc. in the font characteristics. Italic doesn't work right and mangled fixed width maps, etc. And bold just gets real ugly imho, and can produce the same size shift in some cases, and they **mean** entirely different things. If at some point someone rewrite the output system to handle font tags, we will *have to* fix this, since bold in ANSI should more accurately be called "bright", not "bold", and obviously "blink" must be different than "italics", if you start supporting font tags as well. Heck, it is different now, since I am sure I have seen ANSI extensions that include "italic" support, and they definitely *don't* use blink to do it. I would have rather imho, not have blink do "anything" if its not supported, not translate it or other ANSI functions into stuff that it shouldn't be doing.
As it is, I simply disabled the italics. But, as I said, this isn't an option if someone codes true font support into the client.
Frankly, I really wish there where more fixed width ones, with better fixed width italics support and some other issues. Of course, italics wouldn't be a problem, if we had actual "blink". I still say it was a horrible idea to treat bold/italics, etc. as "the same" as italic, bold, etc. in the font characteristics. Italic doesn't work right and mangled fixed width maps, etc. And bold just gets real ugly imho, and can produce the same size shift in some cases, and they **mean** entirely different things. If at some point someone rewrite the output system to handle font tags, we will *have to* fix this, since bold in ANSI should more accurately be called "bright", not "bold", and obviously "blink" must be different than "italics", if you start supporting font tags as well. Heck, it is different now, since I am sure I have seen ANSI extensions that include "italic" support, and they definitely *don't* use blink to do it. I would have rather imho, not have blink do "anything" if its not supported, not translate it or other ANSI functions into stuff that it shouldn't be doing.
As it is, I simply disabled the italics. But, as I said, this isn't an option if someone codes true font support into the client.
My understanding is that to have "true font support" would require a total rewrite of the output buffer. If somebody felt like doing that, it would be a good opportunity to get stuff like images in there.