With fontconfig 2.17.1-3, I now get the following warning when
running xpdf (even without any argument):

Fontconfig warning: using without calling FcInit()

Other PDF viewers (atril, qpdfview, zathura) do not have such an issue.

Hi Vincent,

We just found the relevant fontconfig bug at the same time - your
comment popped up there while I was reading it!
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/472

It's not a bug in xpopple as we don't use fontconfig directly there;
it'll be indirect through Poppler and Motif. But I'm more inclined to
think of this as a regression in fontconfig, since it's never required
explicit FcInit/FcFini calls in the past, and they can't be added to
libraries because previous releases of fontconfig don't do reference
counting, so multiple calls to FcFini would cause breakage.

Thanks,

Hi Adam,

There are other PDF viewers that are based on Poppler and such
a warning is not output. Perhaps FcInit is called in Poppler
and the xpdf issue comes from Motif (since it comes first).

If a call to FcInit wasn't required, that's an API change and
an ABI breakage in fontconfig.

That's something that they would have to solve.

If I understand correctly, the new fontconfig version was not
ready yet for Debian, and it would also require a soname bump
(when ready).

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/448

this was fixed in May 2025.

Summary: Before some use of Fontconfig, Motif needs to call FcInit().
This has always been required, but without any consequence until now.
With libfontconfig1 2.17.1-3, which is now in unstable, one gets a
warning on stderr. It is bad for a library to send debug messages to
stderr, but... This just announces more important changes in future
versions of Fontconfig, which would mean a breakage in case of such
a missing call to FcInit(). So this bug must be fixed ASAP.

I've added an abort() after the warning in Fontconfig, and I confirm
that this is obtained via Motif. I've attached the backtrace.

This happens via the ValidateAndLoadFont call:

[...]
#6  0x00007f172b316b89 in FcObjectFromName (name=name@entry=0x7f172b051b24 "encoding") at ./src/fcname.c:110
No locals.
#7  0x00007f172b319888 in IA__FcPatternAddString (p=0x55bb07356dc0, object=object@entry=0x7f172b051b24 "encoding", s=0x55bb0731f41
0 "iso10646-1") at ./src/fcpat.c:825
No locals.
#8  0x00007f172afa4b23 in ValidateAndLoadFont (rend=rend@entry=0x55bb07356d50, display=<optimized out>, display@entry=0x55bb07308550) at ./lib/Xm/XmRenderT.c:2107
[...]

and this function is defined in "lib/Xm/XmRenderT.c", and if
I understand corretly, this is "case XmFONT_IS_XFT:".

The code in ValidateAndLoadFont() is the following:

[...]
                    _XmRendPattern(rend) = FcPatternCreate();
                    if (_XmRendFontName(rend))
                      FcPatternAddString(_XmRendPattern(rend), FC_FAMILY,
                                         (XftChar8 *)_XmRendFontName(rend));
                    if (_XmRendFontFoundry(rend))
                      FcPatternAddString(_XmRendPattern(rend), FC_FOUNDRY,
                                         (XftChar8 *)_XmRendFontFoundry(rend));
                    if (_XmRendFontEncoding(rend))
                      FcPatternAddString(_XmRendPattern(rend), XFT_ENCODING,
                                         (XftChar8 *)_XmRendFontEncoding(rend));
                    if (_XmRendFontStyle(rend))
                      FcPatternAddString(_XmRendPattern(rend), FC_STYLE,
                                         (XftChar8 *)_XmRendFontStyle(rend));
                    if (_XmRendFontSize(rend))
                      FcPatternAddInteger(_XmRendPattern(rend), FC_SIZE,
                                         _XmRendFontSize(rend));
                    if (_XmRendPixelSize(rend))
                      FcPatternAddInteger(_XmRendPattern(rend), FC_PIXEL_SIZE,
                                         _XmRendPixelSize(rend));
                    if (_XmRendFontSlant(rend))
                      FcPatternAddInteger(_XmRendPattern(rend), FC_SLANT,
                                         _XmRendFontSlant(rend));
                    if (_XmRendFontWeight(rend))
                      FcPatternAddInteger(_XmRendPattern(rend), FC_WEIGHT,
                                         _XmRendFontWeight(rend));
                    if (_XmRendFontSpacing(rend))
                      FcPatternAddInteger(_XmRendPattern(rend), FC_SPACING,
                                         _XmRendFontSpacing(rend));
                    p = XftFontMatch(display, 0, _XmRendPattern(rend), &res);
[...]

It is the FcPatternAddString() call with XFT_ENCODING that triggers
the warning on my machine.

Note that XftFontMatch() will internally call XftInit(), which will
call FcInit(), but this occurs after the above FcPatternAddString()
call.

Hi Vincent

Do you have a reference for this? (that is has always been required)

You could file a bug against fontconfig 2.17.1-3 to prevent it from
migrating to testing for now.  Other packages might also be affected.

Regards
Graham

Hi Graham,

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/472

(it was given by Adam Sampsonin an earlier message). I'm currently
discussing there about this issue with the developer Akira Tagoh.

I've done testing with various applications, including gucharmap
and gnuplot, for which one can see complaints about this warning
on the web (several months ago), but I cannot see a warning with
them. For gnuplot, the user made the warning disappear by
recompiling the cairo library:

https://sourceforge.net/p/gnuplot/bugs/2817/

So I suspect that there were such bugs in other software, but they
have been fixed in the mean time.

For GTK3, this has been fixed:

https://gitlab.gnome.org/GNOME/gtk/-/issues/7639

Ditto for Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1974722

Concerning xpdf and Motif, I suppose that there hasn't been a report
before because they are little used.