Bug with Unicode fonts?

[Raven_Singularity]

When I enable the _LOADFONT option for "UNICODE", QB64 is no longer able to calculate the width of a string of text.  It displays the text on the screen fine, but it returns a width that is shorter than the real width.  I'm pretty sure my font is Unicode compatible.

Just load a font with the "UNICODE" option and the text "The quick brown fox jumped over the two lazy dogs", then try it again without the "UNICODE" option and it returns a different width.

[Petr]

Hi, this has been dealt with somewhere. MONOSPACE must be used to return the correct string width. With another choice it works badly. Another bug is known for fonts - some characters are rendered poorly - cropped from above. To enable UNICODE and map UNICODE characters to the ascii table, use _MAPUNICODE as here: https://www.qb64.org/forum/index.php?topic=1218.msg104190#msg104190

[Raven_Singularity]

Why would I use MONOSPACE when I am trying to measure the width of a variable width font?  That makes no sense, and does not address the problem I mentioned.

I am trying to measure the width of a font string, works fine without UNICODE, but does not work with UNICODE.  Nothing to do with MONOSPACE.

[SMcNeill]

If it’s a variable width character, use _PRINTWIDTH instead of _FONTWIDTH.

[Ryster]

I use the following code and it works flawlessly. After all, it's a SMcNeill job.

SCREEN _NEWIMAGE (130, 45, 0)
_SCREENMOVE _MIDDLE
X = _DESKTOPWIDTH
IF X <1,400 THEN Fontsize = 16 ELSE Fontsize = 18
_FONT _LOADFONT ("C: \ Windows \ Fonts \ lucon.ttf", Fontsize, "MONOSPACE")
_DELAY .2
_SCREENMOVE _MIDDLE
RESTORE Microsoft_pc_cp852
FOR ascii = 128 TO 255
     READ unicode &
     IF unicode & = 0 THEN unicode & = 9744
     _MAPUNICODE unicode & TO ascii
NEXT

[Raven_Singularity]

Again, this has nothing whatsoever to do with MONOSPACE!

I am trying to measure the width of a variable width string of text using _PRINTWIDTH.

It works fine without the UNICODE option of _LOADFONT, but is broken with the UNICODE option.  No other changes but that option on _LOADFONT breaks the _PRINTWIDTH calculation.


Edit:

I just tried a completely empty app with the minimal needed to produce the bug, but it didn't give me the bug.  I will have to isolate how it's behaving differently from within my app, but literally the only option I changed to fix my app was removing the "UNICODE" option to _LOADFONT.  On and off, it would produce different width numbers from _PRINTWIDTH.