With FC_DEBUG=8191 both fc-cache and gs segfault somewhere in the run. I assume this is something common in the FC libraries that both use. I am continuing to test with various debug bits set to see what I can find. I tried commenting <cachedir>/usr/lib/fontconfig/cache</cachedir> in the config to see if running w/o cache would change things, but FC forced that cache parameter back in when it did not find it in the config. -- Michael > On Oct 29, 2021, at 03:34, Lawrence D'Oliveiro <ldo@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 29 Oct 2021 01:56:45 -0500, Michael Brennen wrote: > >> ... it finds the font in the .ttf file, NOT the .ttf.orig file. The >> difference is that in this configuration gs does not go through FC to >> find the fonts. > > OK, so the problem lies somewhere in the Fontconfig setup, but only > when running that Ghostscript installation. Therefore there must be > something different in how Fontconfig is configured when running > Ghostscript. Environment variables in Apache? > >> The difficulty is that there is a *lot* going on >> in those files, and trying to gain some idea of what they do is not >> trivial. > > Yes. And we need to do this while reproducing the problem--that is, > running Ghostscript and watching it fail to find the .ttf file and use > .ttf.orig instead. Looking at the FC_DEBUG flags, it may be worthwhile > turning on just about everything (FC_DEBUG=8191). You may end up with a > huge logfile, but at least you can search through it to see where the > .ttf.orig name is coming from.
