mIRC Home    About    Download    Register    News    Help

Print Thread
#260926 04/07/17 05:47 PM
Joined: Jul 2013
Posts: 27
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
I experienced twice a bug when selecting text in a channel window, the problematic lines are of the format:

&#9940; &#128338; [18:04:55] &#9733;@nickname <message>

I use the font Tahoma, which does not have this black star character, from this thread, it looks like the font used for my system would be ms sans serif.
In some cases that character can appear using two differents glyphes.
On a clean install of mIRC 7.49, with /font > Tahoma > 16, using this:
Code:
ascii return $regsubex($1-,/(*UTF8)(.)/sg,$asc(\1) $asc($mid(\1,2)) $+ $chr(32))
nfill {
  var %n $iif($1,$1,1)
  while (%n) {
    var %r $regsubex($str(a,10),/a/g,$iif($r(0,1),$chr(3) $+ 07 $+ $iif($r(0,1),$chr(32)),$chr($r(1,65535))) $+ $iif($r(0,1),$chr(9733),$chr(15)))
    echo -a $ascii(%r) -- %r
    dec %n
  }
}
in alias, you can see in the following video it is easy to get both.
It is not clear how but usually, when I start a clean 7.49, I'll get only one version of the glyph (usually small), and using /nfill, it will always change either all of them or some of them to the bigger version at some point (look at 00:16 secs in this video).


The bug in itself, which I have yet to capture on videos happens when selecting text with the mouse, sometimes the bigger version of the glyph is rendered and vice vera, creating a shifting effect.

kikuchi #260927 05/07/17 10:14 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. This is due to the way font-linking works. If you are using a font that cannot display a string of characters, mIRC asks Windows for a font that can optimally display all of them and then alternates between fonts where necessary when rendering the text. mIRC caches the fonts it is using while running. At some point, Windows may decide that a different font is optimal and will tell mIRC to use that font instead. If you exit mIRC and run it again, the cache is built again for that session, so the fonts used could be different again.

mIRC also bitmap caches some displayed text for speed, which is updated in certain contexts, which may be what you are seeing. mIRC clears this cache when fonts change, however it sounds like it is not doing it in the specific situation you are seeing. If you can provide a step by step method that reproduces this, I will try to reproduce/fix it.

Khaled #260950 07/07/17 11:04 PM
Joined: Jul 2013
Posts: 27
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
Right, but in the context of IRC and mIRC, using different fonts for a character in the same window, on the same/different line(s), is not optimal; it only creates an unpleasant effect. I think the look of a character in a window should not change just because you added some more lines/characters, especially because the way it works is not consistent at all.
I know you wanted to use Windows to do the font-linking process, where mIRC was doing this job in the past, but do you actually think this behavior is ok?
Is it possible to make it so that once a glyph is found/displayed for a character, mIRC will keep using thas glyph?

As far as the bug itself is concerned, I'm afraid I don't have such steps, I reproduced twice in one day but couldn't since I made the report, it seems that mIRC has to run for a certain period of time for it to occur, maybe related to reaching the maximum number of lines allowed in a window.

kikuchi #260953 08/07/17 11:13 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
I know you wanted to use Windows to do the font-linking process, where mIRC was doing this job in the past, but do you actually think this behavior is ok?

mIRC did not support font-linking in any way before font-linking support was added. The purpose of adding font-linking support in 2006 was to display Unicode characters. The implementation turned out to be incredibly complicated and took several years to refine. mIRC depends entirely on Windows to decide which font to use, so there is no alternative currently. In the future, mIRC may switch to Uniscribe (which has its own issues) or DirectWrite (which is limited to Windows Vista/7 onwards), however this will require a complete rewrite of the display routines.

Khaled #261018 17/07/17 11:09 PM
Joined: Jul 2013
Posts: 27
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
Ok, I finally caught the bug on video, I reproduced on two different machines, both running with 7.49 and win10, with a system uptime of 7h+ and mIRC uptime of 1h so it does not require mirc to be running for a long period of time. I didn't try on a clean mIRC because I use a script to get these lines into the window anyway, both scripts are using a COM (to create a strawpoll) and a dll: dcx.dll, I'll try with a clean install and just this script loaded in the future.

Edit: when the bug occurs, I figured that if I right click the treebar, uncheck the 'lock' item, the bug goes away.

Last edited by kikuchi; 17/07/17 11:26 PM.

Link Copied to Clipboard