Unicode printing with uprint (falcon.h)

[RhoSigma]

Hi all,

this is a small tool set built around the falcon.h C/C++ library, which gives you the ability to print unicode and have text anti-aliasing. I've wrapped the whole thing into a .bi/.bm include file pair for easy use. Maybe the easy to use wrapper functions of this tool set will encourage more people to use falcon.h in their programs.

The use of the falcon.h print functions and this tool set is only useful on 32-Bit SCREENs with enabled alpha blending. As soon as you're use _DONTBLEND or 256 colors or even legacy screen modes, only ugly square blocks are printed instead of the char glyphs.
Starting with the current version (download link below the picture), I was able to remove this annoying limitation. From now on falcon.h is able to print on all legacy graphic screen modes as well as on custom (256 color) palette based screens. Also 32-Bit with disabled alpha blending (_DONTBLEND) is supported now. However, one limitation is imposed on all SCREENs without alpha blending, we can't do text anti-aliasing here.

Also the errors experienced by Steve (see replies below) regarding the use of built-in fonts, doesn't matter if its use is intended or caused as fallback by an unavailable custom font, is fixed now. The reason for the errors was the fact, that the built-in fonts usually don't have most of the unicode chars. In those cases no char was printed and this led to the "subscript out of range" error. Usually missing unicode chars are either printed as spaces or using a replacement char, so I changed the built-in font behavior to use spaces too, for any missing unicode chars.

NOTE:
Even if you use built-in fonts, a _LOADFONT is always required in a program using this library, because only this triggers including of the required FreeType part into the program. Without it the compiler will throw an error when reaching the falcon.h code.

If everything is good, then the output of the falcon-test-1.bas program should look like this:

[FellippeHeitor]

Thanks for sharing, Rho.

You may consider reducing the number of files, since the DECLARE LIBRARY block does not need to be at the top of a program. It can even be in a SUB, but still be accessible globally, like TYPEs.

Great job restoring Luke's post too, thanks for that.

[FellippeHeitor]

Another thing: I don't have arialuni.ttf in my system, but since QB64 bundles cyberbit.ttf, which is unicode enabled, I used it instead.
 

[RhoSigma]

Thanks Fellippe,

in regard of dropping the .bi file, for sure everybody can do this for his own, inserting its contents into the .bm file first. I personally like the symetry of the .bi/.bm pair and will rather keep it that way, at least for now. Maybe when adding more stuff, DIMs, CONSTs and other will go into the .bi file.

[RhoSigma]

Hi all,

I've now finalized my small falcon.h support tool set. Download it from the attachment link in the first post above. Read the SUB/FUNCTION descriptions in falcon.bm and try the examples.

What's new:
1. A user doesn't need to call any of the falcon.h functions directly anymore, just use the various QB64 SUBs and FUNCTIONs.
2. The various UPrint wrapper functions in falcon.bm are made to mimic the regular PRINT/_PRINTSTRING commands, ie. COLORs and _PRINTMODE must be set in advance.
3. As mentioned above, the UPrint wrapper functions do respect the _PRINTMODE again. The falcon.h functions do always print in _KEEPBACKGROUND mode, so the other modes are now emulated within the wrapper functions.
4. Automatic underlining is possible while printing, various functions allow to change the underline properties at any time.
5. Semi-automatic box drawing to surround one or more printed text(s), you just designate where to start a box and where to end, the coordinate tracking is done automatically.

[SMcNeill]

Just tested these, @RhoSigma.  Generates errors when ran, as is.  I don't know if this is a glitch with the recent changes to QB64, or something simple you might want to look at. 

It's a subscript out of range error, in falcon-test-2.bas, with the included falcon.bm, down on line 112.

I've did some simple testing, and if line 47 is remarked out, the rest of the code works as it should.  (I guess; this is the first time I've tested this.  It doesn't error out anywhere else, at least.) 

The code in falcon-test-2.bas which causes the error is this:

Code: [Select]

utf$ = UnicodeToUtf8Char$(26862)
COLOR &HC066CD00
UPrintLeft 50, _WIDTH - 50, 50, utf$
Now, if it's in UnicodeToUtf8Char, or UPrintLeft, or elsewhere, I can't say.  I figured the easiest way to diagnose the issue would just be to report it to you, and let you take a look at it and see what's up.  ;)

[RhoSigma]

Thanks for reporting @SMcNeill, will check it tomorrow after work.

EDIT:
A quick test with build git e8566e7 (latest) shows no problems here, both examples work as expected. The faulty line 112 indicated makes a simple substraction of two array elements. The array stores the pixel positions of all printed chars for underline/box calculation, so it could be font related, did you use the "arialuni.ttf" as given in the example? - If not, please let me know which font you tried.

[RhoSigma]

Sorry @SMcNeill,
but I can't reproduce the error here. Have tried a couple of fonts (even non-unicode enabled ones), have tried to print different texts and even empty strings, have tried it on 32bit and 64bit versions of the latest dev build and everything is just working as expected here.

Have you tried to re-download/unpack QB64/falcon.7z? - It's the only thing I could imagine, that some process in the middle introduced a quirk that changed the intended behavior, maybe an unpack error? (I use 7-zip 19.00)

[SMcNeill]

Redownloaded and tried again.  I'm still seeing the same glitch, as per the screen shot below:

Since you can't seem to reproduce it, I'm curious now if it's something with the dev version of Qb64 which I'm using, or perhaps a subtle difference in system fonts?  Can you attach the font you're using to test this?  My system has a version, as it's not tossing an error or glitching out anywhere else in the program, but it may not be the same as yours.  Word, or some system update, or SDK, or some other crappy thing may have altered one of ours to be different from the other's.  It's worth testing the font at least, just to rule it out.  ;)

[SMcNeill]

Actually, it may be a case of the font missing and tossing unexpected errors.  Apparently it's not included with Win 10 or Word, as it used to be, anymore.  https://answers.microsoft.com/en-us/office/forum/office_365hp-word/arial-unicode-ms-font-missing/3d389ec7-dfaa-4002-adfd-5b1491cea8a1/

I'll look for a copy online and report back to you.

EDIT:  Apparently there's 800 different versions of this file on the internet now, and the top searches on Google didn't find what I was looking for with it, as they contained Hebrew character sets, but no Japanese or such, as per your example.  It took several downloads, before I finally found one that displayed and worked exactly as your screenshot, without any squares for missing characters.

The glitch is definitely on the off-chance that the font is missing and someone runs it.  You're usually particular about error trapping your code (a lot more than I am, normally), so it might be something you'd want to look into.  If not, feel free to disregard the issue completely, as the problem was a lack of fontage on my part.  ;)

[RhoSigma]

Ah Steve, looking at your provided screenshot I got it immediately, seeing the 1st line obviously printed in built-in _FONT 16 instead of the arialuni.ttf shows that the font wasn't loaded.

Indeed, trying it with an inbuilt font I get the errer too.

Although that the informations given in the falcon.html let me think that inbuilt fonts are supported, this is obviously not the case. There is not much I could do here, as the array causing the error is filled by falcon.h which also returns the index of the last valid array element, so if I get wrong information from the underlying C/C++ code, then my wrapper code can't do much.

But as far I've tested now, it seems to work with any TTF font, even if it's not unicode enabled.

[RhoSigma]

The entire library got an overhaul to not longer relying on the old recursion bug, which got finally fixed in the QB64 v2.0 development builds (see https://qb64forum.alephc.xyz/index.php?topic=4209).

Please take the new updated code from the attachement at inital post here and make sure to carfully read the entire post.

[jack]

looks very nice, I wonder if this could solve that Russian member that could not display his native language

[Pete]

This is really cool, but also pretty complex. At first, I thought maybe it was Steve's system being too outdated. After all, while the rest of us have icons on our desktop, Steve's apparently has knobs. Very old fashioned.

I suppose you could do a _FILEEXISTS() routine for the font files, but for really good error checking, a compare with the font files used in development would be needed, paired with an alert to the user the font file, in the user's system, is not compliant. It gets a bit iffy to do an overwrite, and I believe in Windows, fonts involve the Registry. Again, this could get quite complicated, but a simple error trap, to inform the user of what to do when Steve's situation comes up, well that would be fairly easy to include.

Nice work on the file recover from the .net site! It's like an Easter Egg hunt, over there.

Pete

[RhoSigma]

looks very nice, I wonder if this could solve that Russian member that could not display his native language

Yes and No, it would not solve the problems he had displaying it in the IDE, but for the output of his programs, as far as it is literal text, it should work if he writes the text in any editor which supports the language in whatever codepage setting, then copy & paste this text into string variable assignments in his program (doesn't matter how ugly that text may look in the IDE then). Finally he would just need to use the AnsiTextToUTF8Text$() function, given the string variables and his used codepage when writing the text, to convert the strings into UTF-8 notation.
These UTF-8 strings can then be printed using the various UPrint functions where ever needed in his program.