Hi Francesco,
You might find this blogpost of mine useful:
Cheers,
On Sat, Feb 12, 2022 at 3:28 AM Francesco Pretto <ceztko@xxxxxxxxx> wrote:
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
