On Fri, 11 Feb 2022 at 21:09, Lawrence D'Oliveiro <ldo@xxxxxxxxxxxxxxxxxxx> wrote: > > It seems to me, an application shouldn’t go messing about with a user’s > default settings. Create a custom application-specific configuration, by > all means, and base it on the default as appropriate. But don’t go > replacing the default -- leave that up to user-controlled configuration > tools. You talk about "an application" missing my use case, which I actually didn't talk about: I have a PDF manipulation library[1] that needs to use fontconfig for regular font lookups. My idea is that my library code should attempt first to check if an existing default configuration exists, and if it does it should use that. If it does not exist I want to chose to let fontconfig to default initialize one or create a custom one that fit better the purpose of my PDF library. You are probably right that I should not mess with the default configuration by pushing my custom one as the global default (even if this affects only the process where my shared library was initialized). Still a method to know the current default configuration (even if that is null) would be good to have (the mentioned FcConfigGetCurrentDirect) and allow me to better decide what to do in the library code. An "application", as you say, using my PDF library would be still able/free to push a default configuration externally, indirectly controlling the behavior of my PDF library and other user libraries using fontconfig, or it can control directly the behavior of the PDF library with regard to font lookups. I hope my use case is clear. Summarizing: I now agree with you that I should not push a custom default fontconfig configuration in my library code, but I should still be able to know if a default configuration exists or not. Regards, Francesco [1] https://github.com/pdfmm/pdfmm
