GD TrueType empty output

[Stefano dS]

Hello group,

This is my box:

Slackware Linux -current-
Perl 5.8.2
freetype 2.1.5
gd 2.0.12

and GD Perl module: 2.11

Lots of TT fonts in /these/ttf/

I'm checking the capabilities of TT font rendering of
GD perl module without success:

<code>

use GD;
use Data:umper ;

$im = new GD::Image(400,400);

$im->colorAllocate(255,255,238);
$brown = $im->colorAllocate(159,30,0);

$textstring = "Hello Mars!";

my @b = () ;
@b = $im->stringFT(
$red,
'/these/ttf/arial.ttf',
14, 0, 100,100,
$textstring
) ;


print STDERR Dumper(\@b) ;

open (IMAGE,"> test.png") || die;
print IMAGE $im->png;
close (IMAGE);

</code>

Every execution of the script above poduces an empty image.

No error in $@, but, and that let me wonder if it should be a bug,
the 'text box' array returned by strinfFT is filled with the same value as
if GD was busy to write everything in a single point.

I didn't succeed also with the demos/truetype_test: same empty results.

Thanks in advance for your help... if any!


stefano

 

[J. Gleixner]

use GD;
use Data:umper ;

$im = new GD::Image(400,400);

$im->colorAllocate(255,255,238);
$brown = $im->colorAllocate(159,30,0);

$textstring = "Hello Mars!";

my @b = () ;
@b = $im->stringFT(
$red,
'/these/ttf/arial.ttf',
14, 0, 100,100,
$textstring
) ;

You need to define $red.

Always:

use warnings;
use strict;

when developing code.

stringFT should probably throw an error if the fgcolor isn't defined.

 

[Martien Verbruggen]

Hello group,

This is my box:

Slackware Linux -current-
Perl 5.8.2
freetype 2.1.5
gd 2.0.12

and GD Perl module: 2.11

Lots of TT fonts in /these/ttf/

I'm checking the capabilities of TT font rendering of
GD perl module without success:

<code>

use GD;
use Data:umper ;

You forgot use strict; and use warnings;

$im = new GD::Image(400,400);

$im->colorAllocate(255,255,238);
$brown = $im->colorAllocate(159,30,0);

$textstring = "Hello Mars!";

my @b = () ;
@b = $im->stringFT(
$red,

Where did $red come from?

'/these/ttf/arial.ttf',

If I replace $red with $brown, and the font path name with one that
exists on my machine, this program works fine.

Have you tried checking what $@ contains after the previous fails? The
documentation of GD suggests that any error messages would be
contained in $@ if stringFT() returns an empty list to indicate
failure.

Every execution of the script above poduces an empty image.

No error in $@, but, and that let me wonder if it should be a bug,
the 'text box' array returned by strinfFT is filled with the same value as
if GD was busy to write everything in a single point.

Ah, you did check. If there is no error in $@, then I assume you also
didn't have an empty list returned in @b? While you talk about what
the image contains, you're a bit vague about what @b contains. if it
contains 8 elements, then from GDs point of view the write was
correct, and the problem is more likely to be the freetype library, or
a problem with the font files.

Are your font files ok? Did you check them with the freetype tools
(ftstrpnm, ftmetric, etc.)?

I didn't succeed also with the demos/truetype_test: same empty results.

That sounds more like a freetype problem.

Are you sure that the libgd that is installed was compiled against
that freetype version, and that GD was compiled with the same
settings?

You could try running a small C program linked against your gd
library, to see whether that words the same.

The following should be more or less the same as your Perl program:

#include <gd.h>
#include <stdio.h>

int main(void)
{
gdImagePtr im;
FILE *pngout;
int back, brown, b[8];
char *error;

im = gdImageCreate(400, 400);
back = gdImageColorAllocate(im, 255, 255, 238);
brown = gdImageColorAllocate(im, 159, 30, 0);

error = gdImageStringFT(im, b, brown,
"arial", 14, 0, 100, 100, "Hello Mars!");

if (error)
fprintf(stderr, "(stringFT) %s\n", error);

pngout = fopen("test.png", "wb");
gdImagePng(im, pngout);
fclose(pngout);

gdImageDestroy(im);
return 0;
}

Compile, run, check with

$ gcc -W -Wall -ansi -o foo foo.c -lgd
$ GDFONTPATH=/wherever/your/fonts/live ./foo
$ $IMG_VIEWER test.png

If this succeeds, I suggest checking that you don't have more than one
libgd around, and recompiling GD. If this fails, recompile libgd, and
then gd. If it then still fails, check the freetype library.

Martien

 

[Martien Verbruggen]

You need to define $red.

Always:

use warnings;
use strict;

when developing code.

I totally agree.

stringFT should probably throw an error if the fgcolor isn't defined.

It doesn't. It uses the background colour, i.e. the colour with index
0 in the palette. You do get a warning about undefined values, though,
which would have identified this problem, and strict, of course would
have also pointed it out.

However, it isn't the OPs problem as they indicate that they are
getting "strange" values back in @b.

Martien

 

[Stefano dS]

If I replace $red with $brown, and the font path name with one that
exists on my machine, this program works fine.

You're right... it was only a mistake in cut&paste.

Ah, you did check. If there is no error in $@, then I assume you also
didn't have an empty list returned in @b? While you talk about what
the image contains, you're a bit vague about what @b contains. if it
contains 8 elements, then from GDs point of view the write was
correct, and the problem is more likely to be the freetype library, or
a problem with the font files.

This _was_ my @b:

@b = [
100,
100,
100,
100,
100,
100,
100,
100
]

[...]

Are you sure that the libgd that is installed was compiled against
that freetype version, and that GD was compiled with the same
settings?

libgd 2.0.12 was correctly compiled against freetype 2.1.5 and GD perl
module built with freetype support switch activated, anyway the problem
has been solved upgrading libgd to 2.0.17 and rebuilding GD.


Really thanks !

Stefano

 

[Martien Verbruggen]

Ah, you did check. If there is no error in $@, then I assume you also
didn't have an empty list returned in @b? While you talk about what
the image contains, you're a bit vague about what @b contains. if it
contains 8 elements, then from GDs point of view the write was
correct, and the problem is more likely to be the freetype library, or
a problem with the font files.

This _was_ my @b:

@b = [
100,
100,
100,
100,
100,
100,
100,
100
]

Then something was wrong with your installation, I suspect. Maybe the
libgd was incorrectly linked against freetype, or freetype was
upgraded after libgd was built, introducing some incompatibility.

libgd 2.0.12 was correctly compiled against freetype 2.1.5 and GD perl
module built with freetype support switch activated, anyway the problem
has been solved upgrading libgd to 2.0.17 and rebuilding GD.

Glad to see the problem is gone now

Just out of curiosity: Did you try the C program I posted with the old
installation? I'm mainly asking so I can add this particular behaviour
to my knowledge base of symptoms related to GD and GD::Text problems.
This is the first time I've seen this behaviour, so it'd be nice to
know what caused it.

Martien