Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > GD TrueType empty output

Reply
Thread Tools

GD TrueType empty output

 
 
Stefano dS
Guest
Posts: n/a
 
      01-05-2004
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,23;
$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




 
Reply With Quote
 
 
 
 
J. Gleixner
Guest
Posts: n/a
 
      01-05-2004

> use GD;
> use Data:umper ;
>
> $im = new GD::Image(400,400);
>
> $im->colorAllocate(255,255,23;
> $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.

 
Reply With Quote
 
 
 
 
Martien Verbruggen
Guest
Posts: n/a
 
      01-06-2004
On Mon, 05 Jan 2004 15:29:12 +0100,
Stefano dS <stedis@_OOPS_antartide.org> wrote:
> 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,23;
> $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, 23;
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 | If it isn't broken, it doesn't have enough
Trading Post Australia | features yet.
|
 
Reply With Quote
 
Martien Verbruggen
Guest
Posts: n/a
 
      01-06-2004
On Mon, 05 Jan 2004 12:08:01 -0600,
J. Gleixner <(E-Mail Removed)> wrote:
>
>> use GD;
>> use Data:umper ;
>>
>> $im = new GD::Image(400,400);
>>
>> $im->colorAllocate(255,255,23;
>> $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.


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
--
|
Martien Verbruggen | I used to have a Heisenbergmobile. Every time
Trading Post Australia | I looked at the speedometer, I got lost.
|
 
Reply With Quote
 
Stefano dS
Guest
Posts: n/a
 
      01-07-2004
On Tue, 06 Jan 2004 22:40:49 +0000, Martien Verbruggen wrote:


>
> 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

 
Reply With Quote
 
Martien Verbruggen
Guest
Posts: n/a
 
      01-07-2004
On Wed, 07 Jan 2004 12:54:22 +0100,
Stefano dS <stedis@_OOPS_antartide.org> wrote:
> On Tue, 06 Jan 2004 22:40:49 +0000, Martien Verbruggen wrote:
>
>> 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.

>> 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.


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
--
|
Martien Verbruggen |
Trading Post Australia | The gene pool could use a little chlorine.
|
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Use TrueType Fonts for PDF Generation & Adding Buffered Images to PDF sherazam Java 0 06-22-2012 10:53 AM
Re: Extracting hte font name from a TrueType font file Steve Holden Python 2 09-19-2008 07:25 AM
Extracting hte font name from a TrueType font file Steve Holden Python 0 09-18-2008 04:58 PM
Altova Mapforce - xml 2 xml map: empty elements output although input element is not empty Lukas XML 3 11-10-2005 02:25 PM
TrueType Fonts Esteban Java 3 11-29-2003 05:33 PM



Advertisments