fontconfig: default cache dir is "C:\building\msys64\var\cache\fontconfig"

[Ede123]

If fontconfig is used with a fonts.conf that does not define any cache directories, fontconfig falls back to C:\building\msys64\var\cache\fontconfig.

It would be great if it would not fallback to a hardcoded path but use a sane default instead.

[stahta01]

I am looking into the package and trying to fix it. I will need someone to test it if I find a fix.

Tim S.

[Ede123]

Great! I can assist in testing, just ping me.

[stahta01]

After more than a half dozen attempts; I believe that I found out how to fix it. It should now default to /var/cache/fontconfig not sure that this is the most correct place. But, it should be easy to change in the future to a better default. I still need to finish the changes and verify it still builds and installs without error.

Edit1: More work revealed that it was defaulting to "//var/cache/fontconfig" instead of "/var/cache/fontconfig"

Tim S.

[Alexpux]

Mingw programs doesnt understand UNIX paths, need fix sources to search cahce dir relative to executable

[stahta01]

OK, I will stop trying to fix configure; and, instead edit "fontconfig/src/fcinit.c". It should be easier.

Edit: It appears that it will be harder.

Tim S.

[Alexpux]

@stahta01 view any of the packages where we do relocation of directories. For example p11-kit

[jtanx]

From my experience, fontconfig already falls back to ../share/fonts where .. is relative to the fontconfig DLL. This is what fontforge used to rely on (it's no longer the case because we use pango with the win32 backend by default now)

Although I could be wrong; I'd need to double-check if that behaviour is from pango or fontconfig

edit: ah, cache directory; hmm probably not the same thing then

[stahta01]

It is going to take at least a few days to understand the code I need to borrow from p11-kit; before I see the way to proceed. Tim S.

[stahta01]

@Ede123 I have started to try to do the fix; and, I think I will need to patch the exe which has the problem. What exe has the problem the worst? fc-cache.exe?

Tim S.

[Ede123]

While I discovered the issue while using fc-cache the problem should not be specific to any particular executable but to the way the default configuration is created. I tracked this a bit through the code and there's a central place were all fontconfig configuration code is handled (including fallbacks if not set explicitly in the configuration file).

[stahta01]

Yeah, I am planning patches to the library; but, it also needs an exe to set the proper location; since, I see no way to have the library can know the user MSys2 install path. But, the exe should be able to figure out its own path at run-time and set the path used by the library. Tim S.

[Ede123]

OK, then I misunderstood (it sounded as if you wanted to change the code of fc-cache.c).

I guess using GetModuleFileName with hModule set to NULL should be what you typically want if you're planning to make the default cache relative to the fontconfig binaries.

It might also be just as fine to use something more general (like WINDOWSTEMPDIR_FONTCONFIG_CACHE or LOCAL_APPDATA_FONTCONFIG_CACHE) and let fontconfig handle the fiddling with the path. The latter is actually supposed to be the default but I think we're overwriting that in our PGGBUILD.

[stahta01]

I decided to see what happens if I remove the configuration code that tries to set font cache; maybe fontconfig will do its job without interference. Tim S.

[stahta01]

PR #2998 and related PR #2997

@Ede123 It was a simple change; but, I have no idea how to test if it works.

Tim S.

[Ede123]

As there seem to be some questions regarding testing, I propose two easy steps to confirm proper behavior:

• To check the default (normal MSYS2 environment) behavior simply execute fc-cache -v on a MinGW shell. fc-cache then lists all font directories and after that all cache directories (and the performed actions). The first cache directory should be something useful, probably inside the /mingw{32,64} directory tree (e.g. /mingw{32,64}/var/cache/fontconfig, the current default.
• To check the behavior without cachedir specified in fonts.conf execute export FONTCONFIG_FILE=invalid and then again fc-cache -v. fontconfig will then fall back to a default location that currently seems broken.

[stahta01]

So, back to the idea of using p11-kit as the example way to fix this issue. I plan to try to put the cache like you suggest to /mingw{32,64}/var/cache/fontconfig Thanks for the testing steps.

Tim S.

[lazka]

From what I see fontconfig checks if the default matches the build time path and if that's the case builds a path relative to the fonconfig.dll (search for fontconfig_instprefix in the source).

In case that directory isn't writable it will fall back to some variant of XDG_CACHE_HOME.

@Ede123 Not too bad of a default imo, so I'm wondering what you are trying to do.

(btw a good way to debug this is FC_DEBUG=16 fc-cache -fr)

[Ede123]

@lazka I think behavior changed since I reported this issue.

When I reported this issue instead of a path relative to fontconfig.dll, it would use C:\building\msys64\var\cache\fontconfig (i.e. that exact hardcoded path), which obviously does not make a lot of sense.

Nowadays it seems to use ../var/cache/fontconfig relative to the fontconfig.dll (still not perfect if that .dll is in the root of an installation instead of in a /bin subdirectory, but reasonable)

I initially noticed this issue when overriding fontconfig settings by using the FONTCONFIG_FILE environment variable (mostly for CI to achieve an empty font list for speed reasons or alternatively a fixed font list for running tests).

[lazka]

When I reported this issue instead of a path relative to fontconfig.dll, it would use C:\building\msys64\var\cache\fontconfig (i.e. that exact hardcoded path), which obviously does not make a lot of sense.

It still does that if you delete font.conf btw, it needs the "/var/cache/fontconfig" entry to enable the relocation.

[Ede123]

Ah, indeed.

Not sure if it was this way before, but with FONTCONFIG_FILE=invalid it still seems to use a "/etc/fonts/fonts.conf" if it exists.