The issue

During the execution of a gnuplot script, some special mathematical symbols could be correctly displayed on the X11 terminal. However, these mathematical symbols were not displayed whenever generating the same output as a png graphic file. An error concerning fonts was issued:

./prova.gnuplot_script_png > a.png
Could not find/open font when opening font LiberationSans, trying default
gdImageStringFT: Could not find/open font while printing string a with font Symbol
gdImageStringFT: Could not find/open font while printing string a with font Symbol

As shown in the next figures, the left one is the X11 terminal-output (let’s focus on the mathematical symbols on the bottom-half), and the right one shows the same script but this time it was the output png graphic file, clearly without any mathematical symbols on it:

Gnuplot and some irritating font path issue

Running gnuplot through strace

As it happens, the only way to be sure what’s going on when something goes wrong with a piece of software is to determine what’s happening behind the scenes. One feasible thing to do is to run gnuplot through strace, to have a look, firstly, at what kind of fonts it is trying to open and why it cannot accomplish something of that sort. According to the error messages, it was not gnuplot, but libgd (that is, a library) the one complaining about the font. Moreover, the error message seemed to be related not to the fact the font wasn’t there, but the font was not suitable to print some special strings:

gdImageStringFT: Could not find/open font while printing string a with font Symbol

A first running using strace, showed:

(…)

access(“/usr/share/fonts/truetype/ttf-liberation/LiberationSans-Regular.ttf”, R_OK) = 0
open(“/usr/share/fonts/truetype/ttf-liberation/LiberationSans-Regular.ttf”, O_RDONLY) = 4
(…)

So, gnuplot did open the font “LiberationSans”. This was the choosen font according to the script:

18 set terminal wxt enhanced font “LiberationSans,18″

Next step would be to check the Symbol font out:

(…)

access(“/usr/lib/X11/fonts/Type1/Symbol.dfont”, R_OK) = -1 ENOENT (No such file or directory)
access(“/usr/openwin/lib/X11/fonts/Type1/Symbol.ttf”, R_OK) = -1 ENOENT (No such file or directory)
(…)

So, according to the strace output, the Symbol font was not opened at all. That was the main problem, not the character encoding, as the error messages could suggest, but a trivial and mere font path problem issued by  libgd.

Fixing it

Libgd does have a session variable to manipulate and set up its font paths. Then:

export GDFONTPATH=/usr/share/fonts/X11/Type1:/usr/share/fonts/truetype/ttf-liberation/

Running the script again did not show any sort of error messages, and the png output file generated showed exactly the same mathematical symbols as in the X11 output.