gnuplot & gd: Could not find/open font when opening font "arial"

[mojca (Mojca Miklavec)]

When running gnuplot with png terminal, it still reports problems:

> set term png
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal non-scalable font

(I plan to look into the issue and do some more extensive tests, I would only like to collect all the problems & pointers at a single place and make sure that I don't forget about it. Of course anyone is welcome to help.)

Related tickets: #26897, #14999, r76048

Gnuplot uses the following trick on Windows (and could do something similar on Mac OS X; I'm not sure if it is the right way to do that or if it is better to make sure that fontconfig works properly):

#ifdef _Windows
    /* Set the default search path for fonts to something useful. */
    if (getenv("GDFONTPATH") == NULL) {
        const char fonts[] = "\\fonts";
        char *windir = getenv("windir");
        if (windir) {
        char *gdfontpath = (char *)
            gp_alloc(strlen(windir) + strlen(fonts) + 1, "GDFONTPATH");
        if (gdfontpath) {
           strcpy(gdfontpath, windir);
           strcat(gdfontpath, fonts);
           SetEnvironmentVariable("GDFONTPATH", gdfontpath);
           free(gdfontpath);
        }
        }
    }
#endif

That might (to some extent) avoid the need to patch gd2 with DEFAULT_FONTPATH, see #26897, even though I'm not sure if gnuplot is the only program that has problems with GD's "bad defaults". Gnuplot's "show fontpath" sometimes reports font path inside /usr/X11R6/ only.

Ethan Merritt suggested the following patch (see ​http://comments.gmane.org/gmane.comp.graphics.gnuplot.devel/8477):

/* First try the old GDFONTPATH mechanism for locating fonts */
        gdFTUseFontConfig(0);
        err = gdImageStringFT(NULL, &brect[0], 0,
                png_state.ttffont, (double)png_state.default_ttfsize,
                0.0, 0, 0, "test");

        /* If that didn't work, try again using fontconfig mechanism */
        if (err && gdFTUseFontConfig(1)) {
            err = gdImageStringFT(NULL, &brect[0], 0,
                png_state.ttffont, (double)png_state.default_ttfsize,
                0.0, 0, 0, "test");
            fprintf(stderr,"fontconfig %s font %s\n",
                err ? "did not find" : "found",
                png_state.ttffont);
        }

        /* If we still haven't found the font, punt to the internal non-TTF default set */
        if (err) {
            fprintf(stderr,"%s when opening font \"%s\", using internal non-scalable font\n",
                        err, png_state.ttffont);
        }

but doesn't want to include it into Gnuplot until GD 2.0.36 with a fix (see #26897) gets released. Citing him:

There seem to be bugs in the libgd function gdFTUseFontConfig(), in that once you turn it on you can never turn it off again. Unless that is fixed, it means that gnuplot scripts using a mixture of self-supplied fonts and fontconfig-installed fonts will fail. That would break most of my web tools, for example, which provide private font files.

Since MacPorts now has the necessary patch in gd2 (r92005), we could fix gnuplot in MacPorts before the patch is included in gnuplot upstream. But I would like to do some additional testing with both PostScript and GD (png) terminals before committing anything.

I would also like to understand better the exact consequences of patch r76048. If it is needed and if it is the right way to specify font paths without recursive search, it should be included upstream. Else we need to figure out what exactly is needed to avoid the problem that the patch was trying to solve in the first place.

[anddam (Andrea D'Amore)]

Replying to mojca.miklavec.lists@…:

When running gnuplot with png terminal, it still reports problems:

> set term png
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal non-scalable font

I cannot reproduce, I get

gnuplot> set term png
Terminal type set to 'png'
Options are 'nocrop font arial 12 size 640,480 '

I have

~ $ port -v installed gnuplot gd2
The following ports are currently installed:
  gd2 @2.0.35_11 (active) platform='darwin 11' archs='x86_64'
  gnuplot @4.4.4_0+luaterm+pangocairo (active) platform='darwin 11' archs='x86_64'

will check without luaterm and pangocairo variants.

[mojca (Mojca Miklavec)]

I have

gnuplot @4.6.0_0+luaterm+pangocairo+qt+wxwidgets_devel (active) platform='darwin 11' archs='x86_64'
gd2 @2.0.35_11 (active) platform='darwin 11' archs='x86_64'

but as I said, I need more extensive checking/research. I remember that I saw it working earlier and I have no idea why it still complains. But anyway, Ethan's patch might be worth exploring even if this particular issue with "arial not found" goes away. I can still imagine that users put fonts to exotic places and change fontconfig's configuration. In those cases simply setting the three default paths to fonts doesn't suffice anyway. Feel free to set the priority of this ticket to low (I don't have permissions to do that).

slightly offtopic: Two particular requests for you (Andrea): I would really like to know where exactly that exclamation mark (r76048) makes a difference (this was the main reason that I added you to CC; I would like to see a tiny minimal example or something similar) and I would be very grateful if you would be willing to review #33596. I volunteered to take over maintainance of gnuplot, but I need somebody to review the patches, fix mistakes or ask more questions, and finally do the commit when/if patch converges to some usable state.

[anddam (Andrea D'Amore)]

Replying to mojca.miklavec.lists@…:

I have

> gnuplot @4.6.0_0+luaterm+pangocairo+qt+wxwidgets_devel (active) platform='darwin 11' archs='x86_64'
> gd2 @2.0.35_11 (active) platform='darwin 11' archs='x86_64'

but as I said, I need more extensive checking/research.

I checked without the variants (that you have anyway) and I cannot reproduce.

I remember that I saw it working earlier and I have no idea why it still complains. But anyway, Ethan's patch might be worth exploring even if this particular issue with "arial not found" goes away. I can still imagine that users put fonts to exotic places and change fontconfig's configuration. In those cases simply setting the three default paths to fonts doesn't suffice anyway.

In that case it would be the user's task to set the software accordingly. Default path values are for default case.

slightly offtopic: Two particular requests for you (Andrea): I would really like to know where exactly that exclamation mark (r76048) makes a difference (this was the main reason that I added you to CC; I would like to see a tiny minimal example or something similar)

IIRC I had issues with the recursive paths so I removed the exclamation marks, if you think those are not needed we can remove the patch for sure. I'm not a gnuplot user so I'm not aware how to list/test available fonts.

Since MacPorts now has the necessary patch in gd2 (r92005), we could fix gnuplot in MacPorts before the patch is included in gnuplot upstream. But I would like to do some additional testing with both PostScript and GD (png) terminals before committing anything.

I wouldn't suggest to patch it in Macports if upstream is aware of the issue and ready to patch. I'd rather ask for GD to release a new patched version so gnuplot can push the updated version too.

Back to this ticket:

what does show fontpath output at gnuplot's prompt?

can you reproduce the issue with fresh install of gd and gnuplot ports?

[mojca (Mojca Miklavec)]

Replying to and.damore@…:

I remember that I saw it working earlier and I have no idea why it still complains. But anyway, Ethan's patch might be worth exploring even if this particular issue with "arial not found" goes away. I can still imagine that users put fonts to exotic places and change fontconfig's configuration. In those cases simply setting the three default paths to fonts doesn't suffice anyway.

In that case it would be the user's task to set the software accordingly. Default path values are for default case.

But if GD is able to use fontconfig (and gnuplot links against fontconfig anyway), there is no reason why it shouldn't listen to user's configuration of fontconfig out of the box. I mean: if there is a trivial patch to enable that behaviour. I certainly wouldn't try to reinvent the wheel to get it working.

IIRC I had issues with the recursive paths so I removed the exclamation marks, if you think those are not needed we can remove the patch for sure.

Is there any way that you could recall what issues exactly? I have fonts in /Library/Fonts/Microsoft for example. I don't claim that I would want to use them in Gnuplot, but there is a valid reason why one would not want to exclude subfolders.

I'm not a gnuplot user so I'm not aware how to list/test available fonts.

I will try to find some example using subfolder.

Since MacPorts now has the necessary patch in gd2 (r92005), we could fix gnuplot in MacPorts before the patch is included in gnuplot upstream. But I would like to do some additional testing with both PostScript and GD (png) terminals before committing anything.

I wouldn't suggest to patch it in Macports if upstream is aware of the issue and ready to patch. I'd rather ask for GD to release a new patched version so gnuplot can push the updated version too.

The main problem is: how do you convince GD to release a new version? They don't even have a working webpage and it doesn't seem like they are going to release a new version any time soon. I'm not exactly sure (website isn't working), but some sources suggest that last stable version was released in 2007, five years ago.

Back to this ticket:

what does show fontpath output at gnuplot's prompt?

> show fontpath

	fontpath is 
	system fontpath is "/System/Library/Fonts" "/Library/Fonts" "/Users/myusername/Library/Fonts" 

However I have a question for you. I'm not sure if it is relevant, but what does fc-list arial return you? I get

/Library/Fonts/Microsoft/Arial Bold.ttf: Arial:style=Krepko,Negreta,tučné,fed,Fett,Έντονα,Bold,Negrita,Lihavoitu,Gras,Félkövér,Grassetto,Vet,Halvfet,Pogrubiony,Negrito,Полужирный,Fet,Kalın,đậm,Lodia
/Library/Fonts/Microsoft/Arial Italic.ttf: Arial:style=Poševno,Cursiva,kurzíva,kursiv,Πλάγια,Italic,Kursivoitu,Italique,Dőlt,Corsivo,Cursief,Kursywa,Itálico,Курсив,İtalik,nghiêng,Etzana
/Library/Fonts/Microsoft/Arial Bold Italic.ttf: Arial:style=Krepko poševno,Negreta cursiva,tučné kurzíva,fed kursiv,Fett Kursiv,Έντονα Πλάγια,Bold Italic,Negrita Cursiva,Lihavoitu Kursivoi,Gras Italique,Félkövér dőlt,Grassetto Corsivo,Vet Cursief,Halvfet Kursiv,Pogrubiona kursywa,Negrito Itálico,Полужирный Курсив,Tučná kurzíva,Fet Kursiv,Kalın İtalik,nghiêng đậm,Lodi etzana
/Library/Fonts/Microsoft/Arial.ttf: Arial:style=Navadno,Normal,obyčejné,Standard,Κανονικά,Regular,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,thường,Arrunta

can you reproduce the issue with fresh install of gd and gnuplot ports?

I'll try to uninstall gnuplot 4.6.0 first and try it without upgrading gd2, then upgrade gd2, and report back. I will also try if I can disable gd2 ("set term png" can also result in pngcairo if gd2 library is missing). It is unlikely that you are using pngcairo when you switch to png (you probably also disabled pango/cairo during testing), but it might be worth checking, just in case.

[mojca (Mojca Miklavec)]

Using the latest gd2 and gnuplot from macports doesn't change anything.

I have Arial.ttf at the following two locations:

/Library/Fonts/Microsoft/Arial.ttf
/Library/Fonts Disabled/Arial.ttf

Maybe the main difference between your and my mac is location of Arial.ttf.

I realized that the problem goes away if I use

export GDFONTPATH=/Library/Fonts/Microsoft

before running Gnuplot (but output of show fontpath doesn't change even if I change GDFONTPATH). The behaviour is "confirmed" on an "almost clean" mac where "set term png" doesn't complain at all, but on that machine the font is under /Library/Fonts without any subfolder. Most likely Microsoft Office has moved Arial.ttf under /Library/Fonts Disabled/.

Yet another reason why using fontconfig for gd2 would help.

[mojca (Mojca Miklavec)]

A new version of GD2 is out (#39550). The bug in gnuplot is still present. I didn't test the new gd2, but I keep my fingers crossed that the problem will go away after upgrade.

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

According to Mojca, this should be fixed by updating to gd2 @2.1.0 and rebuilding gnuplot against it (r109417).