In the constructor GlobalParams::GlobalParams(const char *customPopplerDataDir) [poppler/GlobalParams.cc], one can supply a custom poppler-data directory, which can be very useful, especially when linking to poppler statically. However, in a number of places, the global variable `globalParams` is destroyed and recreated *with customPopplerDataDir=NULL*. Typically, this happens based on some internal reference counting that can't be overridden by the application using the poppler library. Consequently, an application can provide a customPopplerDataDir, but that is overridden internally (typically when closing one document and opening another).
The only place globalParams is destroyed are frontends and the only way you can use the custom GlobalParams constructor is using the internal headers. Mixing internal headers and frontends is not supported.
Thank you for your reply. However, I don't think I can follow your argument. The file GlobalParams.h is installed in include/poppler, and it (publically) exposes the constructor. Do you consider this "internal"? In any case, if one uses a frontend, one may want to use a custom poppler-data directory (e.g., as mentioned before, if linking to poppler statically and there is no way to rely on system-wide installed poppler-data). However, there is no way to do that (persistently), as far as I know. What's the point in allowing customPopplerDataDir then if it's not used in the poppler sources and it's not (easy, as in from the front ends) to use?
The moment you have to pass --enable-xpdf-headers Install unsupported xpdf headers. to install them, yes they are internal headers. I'm not saying it does not make sense to add functionality to let you specify the custom data dir from the frontends. You can open a bug for that if you want :-) With a patch ;-)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.