mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
This post includes a test alias to show there's still a few minor edge cases where $wrap can return extra text. I'm using Consolas 16, and made sure it's not bold, to avoid any issues related to that parm. Using the 1 or 0 on the timer's commandline causes the 'word' parm to be either 1 or 0. This alias repeats the text at 1 seconds interval, and each time it +1 increments the width of the @window, then stops when the @window reaches full width. There are occasional widths where several extra letters are returned, causing a wrap to the next line, then widening the window causes the effect to disappear for a while. It's much less common with word=1, but it's occasionally there. You can only visually see the bug if you see the extra text wrapping to the next line prior to the @window being widened again, so you might need to change the timer's interval to slow it down.

At first, I thought it was related to the issue caused by the red text containing a character which causes nearby numeric text to significantly shrink in size, but it also happens for the green text containing only normal alphanumeric which would not be font-linked. $wrap seems as likely to work/fail just as often for red and green, because whatever function is reporting to $wrap the width of the text is taking account that the text is being shrunk.

The shrinking effect can be more easily seen from these echoed lines:

//clear | var %i 3430 | while (%i isnum 255-3920) { if (%i !isnum 3555-3830) echo -ag 1234567890 $chr(%i) f %i $chr(%i) 1234567890 | inc %i }

Some characters seem more aggressive in shrinking nearby numeric text than others. I'm sure this shrinking text effect can be blamed on Windows itself's font linking, since I can see most of the issue when I paste those echoed lines into Notepad. However, it might be possible that mIRC is exerting a little control over that issue, because there are some lines which appear normal size in a mIRC @window, but Notepad shows them as shrunken. One such codepoint is the 3918, whose line appears normal in the @window text area, but is shrunken in Notepad, and also is shrunken when you paste that line into the mIRC editbox. It's also the purple line in the alias, which seems to consistently return 160% as much text as it 'should'.

/timerwraptest 999 1 wraptest 1
/timerwraptest 999 1 wraptest 0

Code
alias wraptest {
  if (@* !iswm $active) { echo -ag run this alias from a @custom window | return }
  window $active 0 0 $calc(1+$window($active).w) $window($active).h
  echo 6 -a $wrap($window($active).w $str(123 456 $chr(3918) big 789 $chr(3918) ,99) ,$window($active).font,$window($active).fontsize,$window($active).dw,$iif($1 == 1,1,0),1)
  echo 3 -a $wrap($window($active).w $str(123 456 text 789                      ,99) ,$window($active).font,$window($active).fontsize,$window($active).dw,$iif($1 == 1,1,0),1)
  echo 4 -a $wrap($window($active).w $str(123 456 $chr(3902) big 789 $chr(3902) ,99) ,$window($active).font,$window($active).fontsize,$window($active).dw,$iif($1 == 1,1,0),1)
  if ($window($active).w >= $window(-3).w) window $active 0 0 $calc($window($active).w //2) $window($active).h
}

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. I am afraid I haven't been able to reproduce your issue here. I created a custom window, set it to consolas 9 font, ran the alias, and could not see any issues.

Joined: Dec 2002
Posts: 252
T
Fjord artisan
Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
I played around with the above alias as well. each $wrap() should be returning exactly what would fit within the window. In one instance, I managed to get all 3 (purple, red, and green) to fail at a specific width, having these lines wrap within the window when they shouldn't, as $wrap() should have returned just enough text to fit.

It seems as if the purple line always returns way more text than it should, and always wrapping, but I figured I'd point out a situation where all 3 tests fail at returning a proper chomped line which should fit within the window in one line, without wrapping.

Windows 10 Pro
mIRC 7.63
@Window Font: Lucida Console
@Window FontSize: 12
@Window Width: 317px (window .dw, the text display area, not actual full window .w) (width in which all 3 lines fail)

Commands used:
Initialize: /window -dfe @WrapTest 0 0 308 480
Within the active @Window: /wraptest

This was repeated several times until I hit 352 $window().w (317 $window().dw) then I stopped and echoed out some additional lines about the failure .dw, my font and font size to be included in the screenshot below.

Screenshot showing the failure:

[img]https://ibb.co/ZWCgqmD[/img]

The last 3 colored lines illustrate the failure of returning enough text to just fit.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
I made the alias because I wasn't sure if the effect would be the same across operating systems and system configurations. The extra text bleeding onto the next line comes and goes, and depends on whether the word= is set to 1 or 0. But for Talon's font choice, where word=0 I was getting extra text at the same width he got at that Font/size, when the .dw width was all widths of the range 317-326, and then it stopped returning extra text for a few widths.

https://www.dropbox.com/sh/s4ynsopq5gelaex/AADkNXOnpJJeuSjb1-4Voj6sa?dl=0

The wraptest-0.jpg here is from my setting the font to Consolas 9, then running the timer with word=0 then waiting until the effect happened for all 3 colors, then quickly stopping the timer. The picture shows 3 different green lines having extra text wrapped to another line, even though the earlier line was requesting text with a width that was shorter by 2 pixels. Also in my link, wraptest-1.jpg is a screencap from running the timer with word=1 and font Consolas 9. From .dw width 695-701 the green word "text" is wrapped to the next row, and the green line doesn't contain any linked characters.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks, I was able to reproduce the issue with both the edge case and the font-linking. These should be fixed in the next beta.


Link Copied to Clipboard