How do you set it so the text blinks? Its shows Italic instead...
Blinking text
Posted by Zeno on Wed 06 Nov 2002 11:55 PM — 17 posts, 66,825 views.
I'm going to hazard a guess that you can't (correct me if I'm wrong here, Nick).
Blinking text is a sonofabitch to implement in win32, which leads me to guess that Nick's used italics to display this, rather than messing around trying to implement blinking.
This is purely speculation though; I don't use mushclient myself (I have my own) so I haven't even had opportunity to hunt around in the options to see if there is such an option hidden somewhere.
Blinking text is a sonofabitch to implement in win32, which leads me to guess that Nick's used italics to display this, rather than messing around trying to implement blinking.
This is purely speculation though; I don't use mushclient myself (I have my own) so I haven't even had opportunity to hunt around in the options to see if there is such an option hidden somewhere.
Yeah, I thought it was hard to code in...
Yes, it is a pest to implement, and it deliberately renders blink as italics.
Is there anything you could code in to make it different from italics? So I know the difference of whats italic and blinking? That'd be great if you could.
Yes.. This would be nice.. Sadly there is no 'direct' means to do so. :p Unless you: Replaced it with a different font (may not be visually effective and probaby still causes a problem with fixed width). Used different background/foreground colors (pointless). Etc.. About the only solution that 'could' work would be to use a gradient fill on the letters instead of a solid fill, but this is also not possible. We are after all using Windbloze here and such useful ideas as the MAC's ability to set a fill pattern on 'anything' including fonts has been left out to make things more convenient to somebody (they would like us to believe 'we' are the ones being 'helped' by this...). Unless you can think of some option that can be implimented without recoding the entire truetype font support code in the OS, I am afraid we are stuck with seriously limited options. :p
In general, some attributes like blink, bold, etc. 'cannot' be translated to font attributes with 'expected' results and linking the true font tag effects to those attributes in ANSI has serious design drawbacks. The italics messing with visual spacing being a major one. If the result was the same width it would be acceptable, but short of cropping the letter or trying to change the point size for that bit of blinking text, there is no way to properly use blink=italic and have it work right. :p
However, as I said... No one has as of yet found a viable solution and MS inconveniently failed to provide one.
In general, some attributes like blink, bold, etc. 'cannot' be translated to font attributes with 'expected' results and linking the true font tag effects to those attributes in ANSI has serious design drawbacks. The italics messing with visual spacing being a major one. If the result was the same width it would be acceptable, but short of cropping the letter or trying to change the point size for that bit of blinking text, there is no way to properly use blink=italic and have it work right. :p
However, as I said... No one has as of yet found a viable solution and MS inconveniently failed to provide one.
> Is there anything you could code in to make it different from italics? So I know the difference of whats italic and blinking? That'd be great if you could.
But ANSI formatting doesn't have an "italic" field. If by some miracle he changed the italic text so it blinks, there would be no more italic text to confuse it with.
At least, so far as I know. I can't find documentation *anywhere* for what to do with values 3 or 6. For all I know one of these may have been recently been "promoted" to italics.
This is my understanding (plus colours, but they're not really relevant to this discussion).
0 Reset all attributes
1 Bright
2 Dim
3
4 Underscore
5 Blink
6
7 Reverse
8 Hidden
Can anyone fill the blanks? I wouldn't be at all surprised if 3 and 6 are "reserved for future expansion".
But ANSI formatting doesn't have an "italic" field. If by some miracle he changed the italic text so it blinks, there would be no more italic text to confuse it with.
At least, so far as I know. I can't find documentation *anywhere* for what to do with values 3 or 6. For all I know one of these may have been recently been "promoted" to italics.
This is my understanding (plus colours, but they're not really relevant to this discussion).
0 Reset all attributes
1 Bright
2 Dim
3
4 Underscore
5 Blink
6
7 Reverse
8 Hidden
Can anyone fill the blanks? I wouldn't be at all surprised if 3 and 6 are "reserved for future expansion".
3 : italic
5: slow blink
6: rapid blink
9: overstrike
See this file: ftp://ftp.ecma.ch/ecma-st/Ecma-048.pdf
There are a few others:
51: framed
52: encircled
53: overlined
etc. ;)
5: slow blink
6: rapid blink
9: overstrike
See this file: ftp://ftp.ecma.ch/ecma-st/Ecma-048.pdf
There are a few others:
51: framed
52: encircled
53: overlined
etc. ;)
Wow.
Guess which ones I'm /not/ going to bother implementing in my client. :P
Guess which ones I'm /not/ going to bother implementing in my client. :P
Actually, until I get around to re-writing my client in C++ (rather than the VB it's currently in ^_^;;), I don't think I'm going to bother with any of those. I really can't be bothered modifying my ansi to rtf converter. It can wait for the re-write. :)
Well most other clients do implement blink. And blink is certainly more obvious than italics. Though it's not really crucial, it would be good if you could get it implemented. Maybe see how other clients do it.
How about changing the text colour to the background colour and back again? Or can't you change colours after it's been drawn? Not sure on this.
It can be done, it is just tedious. Imagine a text window with dozens of lines, hundreds of style runs, in a proportional font. In the middle somewhere is one blinking letter.
Now, every second (or whatever the blink rate is) I would have to:
Call me lazy, but I'm not in a hurry to do that. :)
Now, every second (or whatever the blink rate is) I would have to:
- Work out how much of the output buffer is actually visible (you might have scrolled back for instance)
- Scan through that section looking for blinking text
- Work out where that text is on the screen (allowing for pixel offets from the LH and top edge), and proportional fonts
- Work out if we are in blink "on" or blink "off" mode
- Redraw the background for that part
- Redraw the letter if we are in blink "on"
- Repeat for every other blinking style run (which might span line breaks)
Call me lazy, but I'm not in a hurry to do that. :)
If you do add support for blinking, ever, please add a nice, easy checkbox somewhere to the effect of, "Obliterate user who dares to use obnoxious blinking text that I wish never was implemented.". The preferrable method of obliteration is a gunshot to the head, but if nothing else, a tactical nuke is acceptable.
Take that as a lesson-- don't use or ask for blinking text! The innocent lives which will be destroyed for the next ten thousand years or so will be on your head!
Brought to you by the Honorable Society for the Preservation of the Eye through Proper Use of Decoration and Obliteration of Unholy Blinking Artifacts.
HSPEPUDOUBA is a not-for-profit organization.
Take that as a lesson-- don't use or ask for blinking text! The innocent lives which will be destroyed for the next ten thousand years or so will be on your head!
Brought to you by the Honorable Society for the Preservation of the Eye through Proper Use of Decoration and Obliteration of Unholy Blinking Artifacts.
HSPEPUDOUBA is a not-for-profit organization.
Perhaps something less radical? This is a GUI environment after all, so you could 'fade' the blinking text in and out and not have it be 'too much' worse than trying to make it blink in the first place. Unless it was set to fast blink, which is like 10 times a second of something, the result would be significantly less eye straining. ;)
But the fact is that using Italic seriously sucks, since the italic version of the font invariably breaks the fixed width restriction and destroys the maps and graphics that are 'usually' the place you most want to use them. This is also why I considered linking the 'bold' attribute, that on old DOS systems 'only' switched color modes to high color, is also a mistake. These things are quite reasonable for a 'font', but where never intended for fixed width terminals, which last I checked including all telnet systems, except those supporting MXP. I turned all that mode stuff off, but I suspect that it may effect 'any' use of <b> or <i> as well, which means having to turn back on the damn things if I ever play on an MXP mud, thus ending up with the pure ansi used on there all messed up again.
Of course I could be wrong about what those settings effect, but if not then it makes far more sense to have those settings in the MXP configuration for MXP and as a 'seperate' setting in ansi to determine 'which' one, if either, actually use those attributes. Underline is the only 'valid' one in all modes, though italics is also a terminal attribute (for some terminals), but imho until someone finds a way to prevent it from stretching the size of the letters to work and breaking the fixed width limit in the process, it is a broken one.
But the fact is that using Italic seriously sucks, since the italic version of the font invariably breaks the fixed width restriction and destroys the maps and graphics that are 'usually' the place you most want to use them. This is also why I considered linking the 'bold' attribute, that on old DOS systems 'only' switched color modes to high color, is also a mistake. These things are quite reasonable for a 'font', but where never intended for fixed width terminals, which last I checked including all telnet systems, except those supporting MXP. I turned all that mode stuff off, but I suspect that it may effect 'any' use of <b> or <i> as well, which means having to turn back on the damn things if I ever play on an MXP mud, thus ending up with the pure ansi used on there all messed up again.
Of course I could be wrong about what those settings effect, but if not then it makes far more sense to have those settings in the MXP configuration for MXP and as a 'seperate' setting in ansi to determine 'which' one, if either, actually use those attributes. Underline is the only 'valid' one in all modes, though italics is also a terminal attribute (for some terminals), but imho until someone finds a way to prevent it from stretching the size of the letters to work and breaking the fixed width limit in the process, it is a broken one.
Fade in? So rather than checking every second, which would be time-consuming, you would like a check every 10th of a second? I think not.
Perhaps a compromise would be a choice of how to render "blink". eg.
* ignore
* italic
* inverse
* bold
* underline
* different colour (eg. white on blue)
Then you can make the "blink" text stand out without too much time-wasting on the client's part.
Perhaps a compromise would be a choice of how to render "blink". eg.
* ignore
* italic
* inverse
* bold
* underline
* different colour (eg. white on blue)
Then you can make the "blink" text stand out without too much time-wasting on the client's part.
That's true, cycling though every 1/10th of a second could slow things down a lot... The only way it would work is if the client could 'know' that the text was 'in' the window and only cycle stuff then. At some point if/when you include inline graphics, you will end up with someone insisting you provide support for animated GIF too though, so... lol There is probably a hardware solution, but it wouldn't work for every system and/or would require that the client verify if the acceleration hardware was there to do it.
Having the option to use a different color background would be helpful for the time being, but eventually blinking would be nice to see, especially if you could specify whether to use a substitute behaviour, for those people that can't stand it. lol
Having the option to use a different color background would be helpful for the time being, but eventually blinking would be nice to see, especially if you could specify whether to use a substitute behaviour, for those people that can't stand it. lol