Thanks for the suggestion. I realized last evening that since FPDF is open source I could try to debug inside it too. I'll try and get at that today. Re the difference between the font names, I tried this since spaces inside file names give some problems in Linux I was just trying to see if that might have been the problem. The font files are identical as proved by 'diff -s'. Also regenerated the font files from the .ttf source, same result. ====== On Thu, 2025-01-16 at 09:51 +0000, Jānis Elmeris wrote: > > You may try adding debugging: in fpdf.php on line 1136, at the beginning of the function: > > > error_log(print_r(['$path' => $path, 'content' => file_get_contents($path),], true)); > > > And see whether you get the expected output in the log. > Compare what you get when you run it with CLI and with the webserver. > > > Also, I see there is a difference between "Garamond Pro-Regular.php" and "garamond-pro.php" in > your examples. I guess it is because you collected the examples from different times when you were > experimenting with the code? > > > Regards, > Janis > No: John Iliffe <john.iliffe@xxxxxxxxx> > Nosūtīts: trešdiena, 2025. gada 15. janvāris 18:08 > Kam: Jānis Elmeris <janis.elmeris@xxxxx>; PHP Help <php-general@xxxxxxxxxxxxx> > Tēma: Re: Unable to load a file > > > > > In php.ini the error reporting is already set to: > error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT > > and there are no other errors emitted other than what I included in the original note. No errors > from the command line version of the same script, that runs as expected. Only the online (php- > fpm) > version used by the web server fails and that used to work before I updated the system from Rocky > 9.3 to Rocky 9.5. That's why I'm so confused and I can't see anything I missed in the setup. > > Thanks for responding. > > John > ====== > On Wed, 2025-01-15 at 08:20 +0000, Jānis Elmeris wrote: > > > > Can you turn on "error_reporting( E_ALL )" and see if the "include" emits any warnings trying to > > include the file? It should, if the problem is an inaccessible file. (The error message you gave > > comes from the FPDF script, not PHP.) > > > > > > Regards, > > Janis > > No: John Iliffe <john.iliffe@xxxxxxxxx> > > Nosūtīts: otrdiena, 2025. gada 14. janvāris 23:16 > > Kam: PHP Help <php-general@xxxxxxxxxxxxx> > > Tēma: Re: Unable to load a file > > > > > > > > > > On Mon, 2025-01-13 at 16:26 -0500, John Iliffe wrote: > > > On Mon, 2025-01-13 at 20:30 +0000, AllenJB wrote: > > > > On 13/01/2025 19:51, John Iliffe wrote: > > > > > Since the script works in one place and not another I suspect that there is some > > > > > difference > > > > > between > > > > > php-fpm and php on the command line but I haven't been able to find it yet. Any ideas > > > > > where > > > > > to > > > > > look? > > > > > > > > Do you have chroot configured, either Linux level or in the php-fpm pool > > > > config? > > > > > > > > Is open_basedir enabled? (for web requests - these may use a different > > > > php.ini than commandline. Check the output of phpinfo() from a web > > > > request - in particular the top section will tell you what ini files > > > > were read) > > > > > > > > Are containers (eg. Docker, podman) involved at all? > > > > > > > according to phpinfo the ini file is /etc/php.ini > > > > > > I checked open_basedir and it has no value (commented) in the .ini file and "no value" in > > > phpinfo. > > > The instructions in the file make it look like this should NOT be set since I don't want to > > > restrain > > > php-fpm from loading external files like this font file. Am I not seeing something here? > > > > > > No containers involved; php-fpm is called from httpd (apache) as a proxy based on the script > > > file > > > extension (.php). > > > ProxyPassMatch "^/.*\.php(/.*)?$" fcgi://127.0.0.1:9002/usr/httpd/(example) > > > > Any further ideas anyone? Also, am I correct in thinking that the open_basedir parameter should > > left blank for my setup? >
