Forums Bug Reports Font Linking in mIRC 6.35 not "fully capable"?

I have ALT-O > IRC -> Messages configured as follows:

[x] Multibyte display
[x] Multibyte editbox
[x] UTF-8 display
[x] Font linking

And my channel window's Font dialogue is configured thusly:
Font: Arial
Script: Western
UTF-8: Display and encode

When I input the character ㅅ into that channel window's editbox, it appears in the editbox itself correctly. However, when I press enter, it echos into the window as an "unknown glyph symbol" (the [] box character).

Yet with the same mIRC configuration, most other Unicode characters, like ❀, display properly in both locations.

My understanding is that Font Linking works like this: for each Unicode character present on a line within your window (or within its editbox), mIRC finds a font that features a glyph for it, and displays that particular character with that particular font, regardless of what your "actual" font selection for that window may be. That way, you can see all characters properly even when using fonts like Fixedsys (255 characters) or Arial (WGL-4/652 characters) which may not include glyphs for them.

Well, that effect appears to be working for ㅅ when typing it into an editbox. But not for its display within windows on lines of chat. In fact, the only way I can make ㅅ appear properly in mIRC windows is by manually setting their fonts to Arial Unicode MS (apparently so that font linking doesn't need to be invoked, as Arial Unicode MS already supports ㅅ natively).

Any ideas? (BTW, packet sniffer confirms mIRC is sending ㅅ to the server with the correct UTF-8 encoding (E3h 85h 85h).)

For what it's worth, I see the exact same behaviour here.
When first echoing the character mIRC takes a while to display it while it's probably searching for a match. The final result is a displayed box char.

CORRECTION: ❀ does not display properly in editboxes.

So in sum total:

❀ displays properly in windows but not in their edit boxes.
ㅅ displays properly in editboxes but not in their windows.

Hmph.

Both those characters display fine for me in mIRC 6.35 under Windows XP and 7 in both the editbox and display window.

Font linking is a complex process and depends on a number of issues. For example, some badly designed fonts can declare that they contain a range of characters when they actually do not. If you are using such a font on your system (I have a few on mine), they might occasionally be chosen as the font to display a particular character when in fact they only contain the unknown glyph symbol for it. So, depending on the fonts you have installed you may or may not see the wrong character.

There are ways around this issue but they are not very practical and would slow the display down considerably and I am not sure how reliable they would be. That said, the font-linking routine has been optimized in the Unicode beta version of mIRC, although I am not sure if it will help in your case.

As for the Windows editbox, it is completely under Windows control and has its own font-linking method. In the case where a character does not display correctly in the editbox, that is probably due to the issue described above as well.

Interesting. I understand. Quite a dilemma, this.

In that case, may I propose a feature for mIRC 6.36 that would empower users to correct for this problem themselves? Rather than simply allowing Font Linking to be turned on and off (as now), perhaps instead offer three choices: off, automatic (the equivalent of "on" in 6.35), and manual. "Manual" being where the user gets to enumerate his own list of fonts that mIRC will search, to the exclusion of all others detectable from the OS. I wouldn't assume this would require serious programming effort; i.e., whatever logic mIRC currently uses in 6.35 for finding "best candidates" while searching through all fonts could remain intact and even apply when "manual" mode was selected. The only difference would be, "Manual" mode would simply programmatically hide the existance of any other fonts from that logic, code outer-wrapping style. %output = $fontlink(%input_text,$windows_font_list) as opposed to %output = $fontlink(input_text,$mirc_local_font_list) in a sense. :-)

Anyway, such a function would make it possible for users experiencing these difficulties to "screen out" fonts which, as you say, misrepresent their capabilities to mIRC, via their own whitelist. Plus, with the present-day availability of fonts like Arial Unicode MS, Bitstream Ciberbit, TITUS Cyberbit Unicode, and GNU Unifont, etc., there are sufficient "extremely complete" and unbuggy fonts out there for mIRC users to obtain and add to such a list.

P.S. While I'm misplacing suggestions in your general Help forum ;-), may I make a second one, also related to Unicode? In all the Font dialogues offering "UTF-8: Default|Display|Display and encode" dropdowns, would you consider offering a fourth option, "Don't display"? Currently, it is possible to disable UTF-8 "globally" (ALT-O > IRC -> Messages > UTF-8 display=unchecked) and then specify per-window exceptions (e.g. UTF-8=Display and encode). However there is no way to do the inverse (UTF-8 on globally, UTF off per-window). I discovered this the hard way after writing a script that produces "hex editor" style dumps in custom windows (see below). As you can imagine, this triggers occasional false UTF-8 decoding. (My solution for now, since I wasn't willing to disable UTF-8 globally, was giving the window tabstops spaced every column and then writing content to the window with tabs inserted between each character to foil UTF-8 decoding attempts by mIRC. Works fine, as you can see, except now it's impossible to copy/paste from such windows -- tab characters get copied too.) Anyway, since I'm sure there are others out there besides just myself who would benefit from being able to specify "off" on a per-window basis for UTF-8 decoding, that's my second suggestion. Oh right, along with a way to control per-window UTF-8 settings with /font so it's scriptable. :-)

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).

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.

My suggestion would be that if you're using Arial ..don't. Just use Arial Unicode MS. As you said, there are proper unicode versions of most standard fontsets out there. If you want proper unicode support, simply use those- not the non-unicode versions. There's really no reason to choose Arial over its Unicode counterpart if you have it on your system. It will also save mIRC the trouble and CPU cycles of having to link glyphs from the font you should have chosen.

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.


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.


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.


I could 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.

If people want to see unicode characters, they should be using a unicode font rather than hoping that everything shows up properly on a non-unicode font. That's his point and it's a good one. Rather than forcing software to a lot of extra work that is not necessary, people should just use a font that doesn't require any extra work. Also, there are many unicode fonts out there as he pointed out... not just a few.

Also, remember that mIRC is not the only client out there. mIRC has font linking, but do all the others? Probably not. So you already have a lot of people who are likely seeing even LESS of what you're typing if they aren't using an appropriate font.

So the real fix isn't software, but font. If you use unicode, then use a unicode font. And the same for everyone else as well. Doing so will prevent such problems for you and them and cuts down on resources required to link fonts for you/them just to be lazy and avoid those fonts. And, if you just get rid of the fonts that are not implemented well (they "lie" about what characters they have), you'd solve the problem as well. Better to support only the well-made fonts than the ones that aren't.

mIRC actually already does this :-) It preloads a number of known unicode fonts and searches them in the order: Microsoft Sans Serif, Arial Unicode MS, Tahoma, Arial, Lucida Sans Unicode, Code2000, Fixedsys Excelsior 3.01. However in mIRC 6.35 it was still possible for a bad font to sneak in at one point. I have optimized the font-linking routine to try to prevent that. Once I release the Unicode beta for public beta-testing (in the next few weeks hopefully) we can see if the change resolves the issue for you.