Windows font bugs

[neville]

OK I found the New Topic button eventually! "Read the manual, dummy"

The LC Bugzilla number I reported for various problems with using fonts in Windows (et al) was 24151.

It included: after using "stop using font" the font engine behaves erratically. On Windows "put the Fontnames" gives empty results, on Mac font metrics are not returned correctly.

I have prepared a stack listing the LC Bugzilla bugs since 2018, showing whether they have been resolved or not. Please just ask if that would be of use to anyone.

Neville

[tperry2x]

Kind of like a stack version of a bug tracker?
Yes - anything like this is always very much welcome. I take the approach that once we know what bugs are out there - we can try and do something about them. Otherwise, we might be blissfully unaware.

Some things may be out of our control at present (depends if the bug originates in the engine or not), but if it's something that can be corrected in the IDE at script-level, then I'm sure we'll do our best to look into it as soon as we can. If nothing else, it'll draw it to everyone's attention on here as there's a diverse (& growing) pool of expertise we can draw upon here. It's great to see new users and new suggestions for fixes are always welcome as far as I'm concerned. (even if they sometimes might be a bit of a headache to implement )

I do also have a bug tracker (of sorts) of known issues as I find them.
Bugs to fix
Known issues, as we find them!

[OpenXTalkPaul]

This could be considered for a more general topic of 'OpenXTalk font issues'.
That's because there appears to be font loading and/or listing glitches on all three desktop platforms.

The engine appears to use the open source library FreeType to do much of it's font loading and related stuff (at least it can on Mac, Linux, 'Unix-Like OS' cases)
https://github.com/search?q=repo%3Alive ... &type=code

This has me thinking that this should mean that we could expose more of the FreeType library to the scripting side by using FFI binding strings, and since the engine already depends on that library it should not increase the overall environment size much. Besides having a path to getting accurate font listings on Desktops, we might even be able to add a few cool new capabilities such as the ability to extract vector drawing paths of an individual character glyph from a font.
This is the sort of common tasks that I want to have common library layer for to abstract away the underlying implementation which may differ on different platforms.

To follow this thinking in the direction recently proposed again of using a common UI toolkit for 'native' controls, wxwidgets does provide a nice simple prefab 'native' font picker control:
https://docs.wxwidgets.org/stable/class ... _ctrl.html

I have to say in the screens here:
https://docs.wxwidgets.org/latest/page_screenshots.html
Some of those wx controls widgets don't look very 'native', maybe the screenshots are just outdated.

Hang on, looks like wxWidgets can also handle the font loading from font file on disk.
https://github.com/wxWidgets/wxWidgets/ ... ont.h#L387
https://docs.wxwidgets.org/latest/classwx_font.html

[tperry2x]

I initially thought the same about their wxwidgets site, but looking at their more recent examples of things built with wxwidgets on MacOS, I think the UI is followed well - note the popup menu buttons here;


Seemingly it 'degrades gracefully' too in lower versions of MacOS:


I was also looking at capy.ui
Particularly how it's used online (OSM)
(I'd been dabbling with it because my VERY elementary zig xTalk engine is using zig for cross-compiling, and this ties in nicely) - OSM zig source.

Calculator demo, and zig source - wondering if any of this can be used in your web-version of xTalk?

[OpenXTalkPaul]

I initially thought the same about their wxwidgets site, but looking at their more recent examples of things built with

It turns out that the UI element images that are on the wxWidgets web page were somehow created in a way that macOS / Safari alters their appearance on the web page when in darkMode! Crazy, probably Apple bug report worthy, it should not do that! That's to a 'Feature' that any photo editor would want applied to their images. Anyway the point is the pictures look fine and much more like macOS Native controls when browsing to that page in 'light mode' ( mode which I rarely ever use anymore).

[OpenXTalkPaul]

More discussion about fonts here:
https://openxtalk.org/forum/viewtopic.p ... 922#p10230