FWIW it also works fine here under Windows 7.
Your workaround seems like a pretty complex implementation for what is essentially a temporary bandaid to deal with your lack of proper unicode font (and unicode *fonts* on your system).
I wasn't requesting a personal, temporary bandaid.
And I do
have proper Unicode fonts on my system. (Remember, I pointed out having Arial Unicode MS?) I also have Bistream Cyberbit and GNU Unifont installed. All three have been installed for a long time, in fact.
The problem, as Khaled explained it, is that other
font(s) on my system are lying to mIRC about which glyphs they offer. mIRC apparently searches one-at-a-time through all installed fonts when Unicode character display becomes necessary, looking for a font that features the needed glyphs. Consequently, during its one-at-a-time search, if mIRC encounters a font that "lies" about its capabilities before
it encounters any of those which truly offer the needed glyphs, you end up with broken text display.
That's not a problem specific to me. It's a problem that would affect anyone else who also has one or more "lying" fonts on their systems.
Maybe you would suggest that to solve this problem, those people identify and remove all such "lying" fonts from their systems. But how? There's no way to tell which fonts mIRC has chosen when rendering Unicode characters. Identifying them would therefore require lots of trial and error experimentation while changing which fonts are installed in the OS. That's an unreasonable expectation. Furthermore, even if the culprit fonts could
be easily identified, they might turn out to be fonts those people are unwilling to discard. E.g., fonts frequently used by designers whose foundries have never released "fontlinking compatible" versions of, and never will.
That is why I suggested an optional "fontlinking font whitelist" feature, which would allow anyone in this predicament to solve the problem quickly and easily by just identifying a few
well-behaved Unicode fonts, and adding them to said whitelist. Then if a mIRC user configured mIRC to restrict its fontlinking searches to just that whitelist, the problem would be neatly solved for them.
Also, your scripted suggestion couldn't work. The data is the same data in any font, so using $fontlink wouldn't do anything to the %input_text. The only way to give advice to mIRC about font linking would be to provide some complex switch to mIRC about which glyph should be linked as which font, which, even if implemented fully, would still require you to (a) figure out which characters (and their respective positions) need to be linked as which fonts and (b) override any event where mIRC echo's text and substitute your own /echo. If that sounds extremely complex, it is.
You misinterpreted my words (or I'm misinterpreting yours?).
I wasn't suggesting a fix done with actual mIRC scripting. I was simply utilizing the mIRC scripting language's syntax as a "commonly understood language" to conceptually
demonstrate how my suggestion might be implimented in mIRC's own source code in a relatively effortless way -- in whatever
langauge mIRC's source code is written.
I'll try to explain again. At some point in mIRC's source code (in the portion that deals with font linking), there must be a function that requests a list of installed fonts from Windows. I.e., so the font linking code can then know which fonts to begin searching.
Well, I was suggesting that the implementation of my idea (a whitelist) might be as simple as altering that single location in the source code: so it *either* fetches Windows' master font list (as now), *or* fetches the font whitelist maintained by mIRC's user.
Then no other changes to mIRC's font linking code would be necessary, because the existing code would simply be lead to believe that the host OS had
no fonts installed to choose from other than those coincidentally on the user's whitelist.
Reason I suggested it that way? Before I posted my reply to Khaled, I found a post he made elsewhere, talking about his struggles implementing font linking long ago ("took several months"). So to be helpful, I was not only suggesting a possible fix to the problem itself (whitelisting), but pointing out that the idea itself probably wouldn't require revisiting that coding headache minefield he worked so hard on long ago.
Just feed it a reduced list of fonts, and then let it work as usual.
Anyway. No, I've never seen mIRC's source code. But writing in a number of languages myself, it's easy to imagine how things might be done by others, and tailor suggestions accordingly. That's all I was trying to do.
My suggestion would be that if you're using Arial ..don't.
Normally, I don't. My favorite font for IRC is actually Bitstream Vera Sans. But for the sake of testing this issue to gather as much information as possible about it before reporting it on this forum, I tested it with a standard font that many others are likely to use, Arial.
Just use Arial Unicode MS. As you said, there are proper unicode versions of most standard fontsets out there.
just use Arial Unicode MS, sure. The problem is, I don't want to.
Because it's not a real solution. The adoption of Unicode shouldn't mean that people be forced to restrict themselves to using just the few Unicode fonts available out there, just because they coincidentally happen to have one or more "lying fonts" installed that cause problems.
Furthermore, forcing a window to use a Unicode font for everything still wouldn't solve the problem when it occurred in window title bars (e.g. channel topics containing unicode, being displayed in the channel window's title bar). The only way to fix that
would be additionally forcing Windows
to use a Unicode font for all your window title bars systemwide. No way. Ick.
Besides, even if I did restrict myself to using a Unicode font, and
configure Windows to use a Unicode font for all window title bars, then I'd still be unsure of what others were seeing. For all I know, someone else in the channel I'm in is not seeing things exactly as I'm typing them, because they're
using Arial and also have "lying" fonts installed, etc.
Alas, the solution is letting people use their preferred fonts, and offering Font Linking for the display of any individual characters their chosen fonts cannot themselves display. As it happens, mIRC does exactly that already. The only problem is, that fontlinking is vulnerable to fonts that lie. Which brings me back to the whitelisting suggestion for solving it -- to eliminate this one last "catch".
P.S. You say that selecting a Unicode font in the first place would "save mIRC the trouble and CPU cycles of having to link glyphs from the font you should have chosen". Well, might I point out, most of those same CPU cycles would also be saved in a whitelisted environment. I.e., if mIRC only searches 3-4 whitelisted fonts specified by the user (versus searching possibly hundreds of fonts installed in the host OS itself), then things are sped up nearly as dramatically, and
the user still gets to enjoy using the font of his choice for the display of non-Unicode characters.