Would be my first guess as well. Perhaps you’ve updated imagemagik (the cli bits and/or some of its dependencies) and those are now looking somewhere else that an older build of the XS bits in the Perl bindings isn’t?

We're using the distro build of ImageMagick and PerlMagic. There was a newer build available from the vendor, but it didn't seem to fix anything

ImageMagick-6.9.10.97-1.28.amzn1.x86_64
compat-ImageMagick-6.2.8.0-4.2.amzn1.x86_64
ImageMagick-devel-6.9.10.97-1.28.amzn1.x86_64
ImageMagick-perl-6.9.10.97-1.28.amzn1.x86_64
ImageMagick-c++-6.9.10.97-1.28.amzn1.x86_64
ImageMagick-c++-devel-6.9.10.97-1.28.amzn1.x86_64
[download]

Well foo. So much for the (maybe) easy solution.

At this point what I'd try next is to use strace (sample man page here but your local copy of course is more relevant) and watch what font files it's actually trying to open. Prefix your script with something along the lines of strace -ff -e trace=%file -o foo.out YOUR_CMD_HERE OPT OPT... and then do the same to a different output file with your test cli command (swapping to output in a different file -o cli.out) and then look at the output produced for the font file names. What you're looking for is to see if the cli version is reading the same ones as your perl usage is looking at. That'll at least let you know you're comparing kumquats to kumquats and not kiwi to dragon fruit.

If they are using different files it's something about either the font paths baked in or coming from the environment (and maybe there's an ENV var you can try playing with to get them to match</handwaving>); if they're not different . . . uh . . . good question.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Download imagemagick from cpan, run the test suite