On Sat, 12 Feb 2022 at 20:22, Behdad Esfahbod <behdad@xxxxxxxxxx> wrote: > You might find this blogpost of mine useful: > http://mces.blogspot.com/2015/05/how-to-use-custom-application-fonts.html > Hi Behdad, yes, I am really finding your article very useful and I am archiving it immediately for future reference! Actually I was very close in the sense I was already able to create a custom fontconfig configuration and add lookup folders, but I didn't understood the usefulness of using FcInitLoadConfig() and FcInitLoadConfigAndFonts() for creating a local configuration based on existing configuration files/fallback config. I guess I was confused by the "default" configuration that can be retrieved with FcConfigGetCurrent, which is really a shared singleton. On Sat, 12 Feb 2022 at 20:20, Lawrence D'Oliveiro <ldo@xxxxxxxxxxxxxxxxxxx> wrote: > Better idea: use the default config, unless the caller specifies > alternate settings for you instead. It's something I was already doing, but somehow I don't know if trusting fontconfig system settings in some architectures, especially the ones that don't use fontonfig as a common tool (eg. Windows/iOS/android). Also, since I need to alter font search paths, I will end create my custom configurations or FcInitLoadConfigAndFonts/FcInitLoadConfig as suggested by Behdad where I feel I can trust system settings/fallbacks, possibly checking first the existence of a configuration file with FcConfigGetFilename(NULL, NULL), and forget about the default configuration that can be retrieved with FcConfigGetCurrent. I think my case can be considered closed. Digressing more, I wonder if there could have been a different model where the one always copy its local configuration from a read-only singleton. There's no "FcConfigCopy" so the design was clearly different. Cheers, Francesco
