Thanks for the reply, I can see now that the fonts are actually slightly different from each other, but only for certain unicode values which many of us would never use.
At your link - for the 2 boxes containing a line of chinese characters with 1975 mixed inside it, only Internet Explorer shows me the 2nd box having the Chinese symbols flipped 90 degrees but still listed horizontally. Chrome shows the 2nd set of symbols identically to the appearance of the first box of Chinese symbols. I'm guessing that Chrome is ignoring the @Font, and is substituting the similar fontname without the @ in the fontname. In Firefox, I just get a jumble of hearts and triangles, so my version must not be supporting either the with-@ or without-@ font they used on that page, so it's making a poor substitution choice.
Here's a replacement command that more clearly shows the english text is not altered betweeb without-@ and with-@ Fonts, but only the Chinese symbols. If you paste the following //command to the editbox, then go to the above link (this worked for me in both Chrome and I.E. even though Chrome doesn't flip 90% when it should) and highlight the row of Chinese symbols into the clipboard, this fills the picture window in a way that shows the beginning of each pair of lines in the same font shows the english text the same way as each other, but the Chinese symbols in the clipboard are displayed in the picture window horizontally, but each symbol is flipped 90 degrees.
//window -p @test | clear @test | var %x 3 | var %y 0 , %i = 1 | while ($font(%i)) { if (@* iswm $font(%i)) { var %line @test 4 " $+ $font(%i) $+ " 16 %x $base(%y,10,10,3) | var %line2 $replace(%line,4 "@,2 ",%x $base(%y,10,10,3),%x $base($calc(%y +20),10,10,3)) | drawtext %line %i %line $cb | drawtext %line2 %i $replace(%line2,2 ",2 @") $cb | var %x $calc(606- %x) | if (%x == 3) inc %y 40 } | inc %i }
Because this isn't pasting any unicode values into mIRC's editbox, it shouldn't matter whether the user has the UTF-8 box checked or not in mIRC options.
I did notice a couple irregularities which I'm pretty sure are caused by the font, and are not mIRC's fault. When I run the above //command, the majority of pairs show the red and blue lines identically except for how I flipped the "@ in the blue display, and except for how each font displays the clipboarded Chinese symbols.
Most fonts show both the red and blue line by giving the english text the same sizes and spacings. However even though Gulim and @Gulim both have a fontsize 16, they displayed size 16 with different character sizes and spacing than each other.
Also, "Fixedsys Excelsior 3.01" shows the symbols the same direction as all the other non-@ fonts, however "@Fixedsys Excelsior 3.01" doesn't support the vertical characters correctly, instead showing a series of black squares. I'm guessing the problem is simply that this font doesn't have these particular unicode symbols defined, so it shows black squares the way Excelsior always does for characters they haven't created a map for. I'm guessing either Excelsior lied by telling the system that they installed the @-style font, or else they mapped 90-degree-flipped symbols for other languages but not for this one.
I don't see a way for /drawtext to write text in any degrees orientation besides printing them in a horizontal row, so there doesn't seem to be much of a practical reason for people to choose the @-font over its sister font. Maybe there can be cases where people want individual Chinese symbols to print with a mixture of upright and sideways symobls. Like the way cattle branding-irons would have a letter branded sideways and calling it crazy or lazy.
