Re: [Tuxpaint-devel] Windows & Android (& others?) FontConfig `fonts.conf` parsing

[Bill K. <nb...@so...>]

On Sat, Feb 22, 2025 at 11:18:50PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> I added the specific code to load fonts stored in user's profile because I had
> thought like AI does that Windows does not use fontconfig to load fonts.
> 
> However, 
> 
<snip>
> 
> once reading this part, I thought you may be right.
> 
> Therefore I pulled your hack and disabled the code to read user's font directory.
> Then, unfortunately,  Tuxpaint does NOT load user's font ;-<
> 
> Just a brief report so far.

I actually decided to NOT mess with your system- and user-font loading
routines, and am just allowing the "fonts.conf" parsing code to just
'fail' when it comes across the special "WINDOWSUSERFONTDIR" and
"WINDOWSFONTDIR" strings (in the <dir> path)...  specifically because
you're already loading directly with your method.  :-)
I think this is fine, at least for now. [1]

I think a good test for you would be to place some new fonts in a folder
somewhere _outside_ of the places Tux Paint is already explicitly searching
(which seems to only be those two locations above).

Launch Tux Paint.  It should NOT find the new fonts, since it has no
reason to be searching the folder where you put them.

Then, add the path of that folder to a "<dir>" section of the "fonts.conf"
that Tux Paint is loading.  So far -- assuming I did it right -- it should
be looking in the "etc/fonts/fonts.conf" inside Tux Paint's own folder
(C:\Program Files\TuxPaint\, I guess?)

Launch Tux Paint again.  It should now find the new fonts... hopefully!

If that works, then we're moving in the right direction.
And in the end, perhaps our OWN "fonts.conf" is the only one we need
to look for, on Windows...? [2]

We could consider looking for them via environment variables [3], but
I suppose until a power user comes along asking for that, it's
probably fine to just keep doing the basic thing we're doing so far.

In the end, refactoring all of this and trying to do it more
consistently would probably be a good idea.  For example on Linux/Unix,
we've got 9 hard-coded paths (mostly in "/usr/share/...") where we
look for fonts, from back in the "SDL_ttf" days (before "SDL_pango").
(And on my laptop, most of them no longer exist... see the
"#define DIRWALK_DEBUG" I just added to `dirwalk.c`, it might be helpful!)

[1] Here's someone using GIMP on Windows who did not want the Windows
    fonts loaded, and the trick was to comment out the "<dir>" entry
    in the "fonts.conf" that ships with GIMP:
    https://www.gimp-forum.net/Thread-Where-the-fonts-come-from

[2] Potentially interesting reading?
    https://blob.pureandapplied.com.au/solved-ffmpeg-fontconfig-woes-on-windows/

[3] "Fontconfig error: Cannot load default config file on Windows"
    https://github.com/bleachbit/bleachbit/issues/901 and related fix:
    "Unset FONTCONFIG_FILE on Windows to always use shipped fonts.conf"
    https://github.com/bleachbit/bleachbit/pull/958/commits/3385952b37d7814c13d5b2619150d34a37c77f20


-bill!