GD TrueType empty output

Discussion in 'Perl Misc' started by Stefano dS, Jan 5, 2004.

  1. Stefano dS

    Stefano dS Guest

    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::Dumper ;

    $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
     
    Stefano dS, Jan 5, 2004
    #1
    1. Advertising

  2. Stefano dS

    J. Gleixner Guest


    > use GD;
    > use Data::Dumper ;
    >
    > $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.
     
    J. Gleixner, Jan 5, 2004
    #2
    1. Advertising

  3. 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::Dumper ;


    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 | If it isn't broken, it doesn't have enough
    Trading Post Australia | features yet.
    |
     
    Martien Verbruggen, Jan 6, 2004
    #3
  4. On Mon, 05 Jan 2004 12:08:01 -0600,
    J. Gleixner <> wrote:
    >
    >> use GD;
    >> use Data::Dumper ;
    >>
    >> $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.


    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.
    |
     
    Martien Verbruggen, Jan 6, 2004
    #4
  5. Stefano dS

    Stefano dS Guest

    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
     
    Stefano dS, Jan 7, 2004
    #5
  6. 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.
    |
     
    Martien Verbruggen, Jan 7, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Esteban

    TrueType Fonts

    Esteban, Nov 28, 2003, in forum: Java
    Replies:
    3
    Views:
    508
    bOOyah
    Nov 29, 2003
  2. John

    empty/non-empty element

    John, Jul 15, 2003, in forum: XML
    Replies:
    1
    Views:
    1,035
    Klaus Johannes Rusch
    Jul 16, 2003
  3. Lukas
    Replies:
    3
    Views:
    817
    spiff
    Nov 10, 2005
  4. Steve Holden
    Replies:
    2
    Views:
    371
    Steve Holden
    Sep 19, 2008
Loading...

Share This Page