Ok, payment received, thanks for doing business with us.
So, the problem is a relatively recent design change in Microsoft Windows 10 Release 1809 in October 2018, apparently too quietly introduced in the middle of a stable OS release, which surprised many and so there’s a lot of software out there that isn’t prepared for this new way of handling fonts.
If you install your own non-system fonts into C:\Windows\Fonts, e.g., by going to that folder in the file explorer, then Windows gives you the illusion of installing fonts there, but in reality it installs your fonts into the (e.g., for a user with name “mario”) C:\Users\mario\AppData\Local\Microsoft\Windows\Fonts folder instead - it virtualizes the folder. So far so good, it allows to install new fonts as a regular non-admin users. Where “well intended, badly done” starts is that this illusion is only kept up for users interacting with the C:\Windows\Fonts folder via the GUI, not for applications actually operating on that folder, they need to be adapted to deal with this new way of doing things.
Software that uses some MS Windows proprietary api’s for font enumeration will be in on the illusion, e.g., software that uses the MS legacy GDI text renderer, like apparently PsychoPy or our old legacy GDI based text renderer. → Finds the fonts, but lower performance, lower quality, less flexibility and functionality, problems with not-quite standard fonts as you saw when trying this TextRenderer 0, and inconsistent text appearance across different operating systems and hardware. Any other software will not find these fonts in their special locations, unless updated/rewritten accordingly.
Our normal cross-platform high quality text renderer uses libfontconfig for more flexible font enumeration that is consistent across operating systems, and we use the libfontconfig dll included with Octave if PTB for Octave is used, or the one included with GStreamer if PTB for Matlab is used. libfontconfig, as shipping with those, doesn’t support searching the new font folder locations by default yet. Support for this + a couple related bug fixes and workarounds for MS-Windows problems, was added to libfontconfig version 2.13.96, released about a month ago as a beta release. See Fonts installed in the user directory are not detected (#144) · Issues · fontconfig / fontconfig · GitLab
Finding out what went wrong required going through the GStreamer repo git commit logs to find what libfontconfig version and config is used, the corresponding Octave repo, the source code of libfontconfig to understand how the MS-Windows implementation works and differs from the Linux and macOS method, the commit logs and bug trackers of libfontconfig to find clues what it could be. That MS-Windows doesn’t install fonts where it pretends to do and lies to the user about it and half-asses the virtualization, wasn’t the first hypothesis, so i had to explore various other way more plausible explanations first. The final clue came when installing a font in the Windows/Fonts folder myself, right clicking on its icon → Properties and finding the install path to be not Windows/Fonts. That made the connection for me to bug reports and commits in the libfontconfig git repository. Then correlating released fontconfig versions against what GStreamer/Octave are shipping, assessment of the likelihood of them fixing this in an update very soon themselves – not high. Then coming up with a potential workaround and testing on Octave 6.4 and GStreamer 1.18 on Windows-11 with custom installed font…
So this may explain to you why it took more than 4 hours to find the likely solution, which is to edit the fonts.conf file to manually add the path to the true font folder, until some future GStreamer updates will hopefully bundle an upgraded libfontconfig and the problem should resolve itself - or introduce new bugs, who knows?
If you are using Octave 6.4, edit the top section of:
C:\Program Files\GNU Octave\Octave-6.4.0\mingw64\etc\fonts\fonts.conf
If you are using Matlab, edit the top section of:
After the line…
… add the line …
… with “loris” replaced by your user name on your machine if that isn’t the correct one.
Then, and whenever you installed new fonts, quit Matlab/Octave and delete the …
…folder again, to force reenumeration of all fonts. The cache folder will contain an additional .cache-7 file with all your fonts.
You could install fonts wherever you wanted and add such extra dir entries, but ofc. other Windows apps may not find them there.
In the future, libfontconfig v2.13.96+ should have an additional default entry in its config file called
<dir>WINDOWSUSERFONTDIR</dir> to automatically search fonts in that user specific path.
This also means that your fonts will only be available on your user account, not those of other users of the machine and one would need to add a proper entry for every users private folder location, and install those fonts again for every user, unless filesystem permissions are set to allow other accounts to read your own folder.
This problem wouldn’t have happened on Linux, btw., just like many other problems that go away when upgrading to Linux.