i have attached a very simple test case; libdg uses up all available memory when trying to open the attached tiff image.
Hi,
I recently started working with gd and I used the precompiled binaries of the 0.34 version. I noticed that I can get the SX sizes of images with GD, but somehow the SY (gdImageSY) function is always 0. The imagePtr→sx is always a value while sy is always empty. Can anyone tell me what I am doing wrong?
Jan
configure.ac should be using pkg-config to check for libpng, because with libpng 1.4.2 you get libpng14-config and libpng14.so instead of libpng12-config and libpng12.so.
and then when libpng 1.6 will be released in a future, it will break again.
it would be best to switch to using pkg-config to check for libpng presence now, to fix the issues now and for the future.
consider this,
Install libpng-1.2.43, have libpng12-config (this is installed for backward’s compability for certain non-libgd related issues) install libpng-1.4.2, have libpng14-config, and libpng-config –libs that will return -lpng14
then ./configure, and it will find libpng12-config and prefer it over the newer libpng14-config and libpng-config.
you end up with libgd linked against old libpng, or not linked to libpng at all.
i’d guess using libpng.pc (the generic pkg-config file name) would be the best here.
6 byte memory leak in function call of gdImageTrueColorToPalette from C++. let me know if you need more info. Thanks
Maggie gd version: Installed Packages: gd-devel.x86_64 2.0.33-9.4.el5_4.2 installed Available Packages: gd-devel.i386 2.0.33-9.4.el5_4.2 updates
valgrind memory check result: [root@tilesgen-dev gd_maps_mlin]# valgrind -q -v –tool=memcheck –leak-check=full –show-below-main=yes –num-callers=40 ./fimage fuseimage1.def city_ir.txt -ir noaaport_satir/201005101210 ==12871== Memcheck, a memory error detector. ==12871== Copyright (C) 2002-2006, and GNU GPL‘d, by Julian Seward et al. ==12871== Using LibVEX rev 1658, a library for dynamic binary translation. ==12871== Copyright (C) 2004-2006, and GNU GPL‘d, by OpenWorks LLP. ==12871== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==12871== Copyright (C) 2000-2006, and GNU GPL‘d, by Julian Seward et al. ==12871== For more details, rerun with: -v
==12871== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1) ==12871== malloc/free: in use at exit: 1,584 bytes in 264 blocks. ==12871== malloc/free: 2,393,832 allocs, 2,393,568 frees, 5,381,428,108 bytes allocated. ==12871== For counts of detected errors, rerun with: -v ==12871== searching for pointers to 264 not-freed blocks. ==12871== checked 530,184 bytes.
==12871== 1,584 bytes in 264 blocks are definitely lost in loss record 1 of 1 ==12871== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==12871== by 0x4C306A3: (within /usr/lib64/libgd.so.2.0.0) ==12871== by 0×407444: langCropImage(gdImageStruct*, char const*, std::string const*, int, int, int const*, int const*, std::string const*, std::basic_ofstream<char, std::char_traits<char> >*, bool) (in /var/www/html/gd_maps_mlin/fimage) ==12871== by 0x4085CA: drawFuseImage(std::basic_ofstream<char, std::char_traits<char> >*, double const*, double const*, int const*, int const*, int const*, std::string, std::string, bool) (in /var/www/html/gd_maps_mlin/fimage) ==12871== by 0x40959D: main (in /var/www/html/gd_maps_mlin/fimage) ==12871== by 0x373F81D8A3: (below main) (in /lib64/libc-2.5.so) ==12871== by 0×402258: (within /var/www/html/gd_maps_mlin/fimage)
==12871== LEAK SUMMARY: ==12871== definitely lost: 1,584 bytes in 264 blocks. ==12871== possibly lost: 0 bytes in 0 blocks. ==12871== still reachable: 0 bytes in 0 blocks. ==12871== suppressed: 0 bytes in 0 blocks. ==12871== Reachable blocks (those to which a pointer was found) are not shown. ==12871== To see them, rerun with: –show-reachable=yes
In fonts like VINERITC.TTF where some letters have tails to the left beyond their (bounding box?), such as the letters ‘f’ and ‘p’, gd renders these with way too much space to the left, and they also seem to be jammed up against the letter to the right.
See the attached image and PHP code which generated it. Notice the line at the bottom of the image that goes out to the left. If you change the image boundaries to 200,200 (allowing the arc to fit entirely in the image), the line will go away.
I’ve seen this in both 2.0.35 and also 2.0.36RC1. Not that it should matter, but the same thing is happening in my C program.
Hi..
I’m installing webalizer in my home directory. It requires libgd and libgd requires libpng, none of which are installed.
I successfully installed libpng using “./configure –prefix=$HOME”, and I’m installing libgd using “./configure –prefix=$HOME –with-png=$HOME”. The configure script reports it found libpng, but the compile fails:
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT gd_png.lo -MD -MP -MF .deps/gd_png.Tpo -c gd_png.c -fPIC -DPIC -o .libs/gd_png.o gd_png.c:16:53: error: png.h: No such file or directory (followed by tons of errors)
I found another libpng compile error in the bug database, but that problem wasn’t even finding libpng.
Thanks!
The following code:
#include <stdio.h>
#include <stdlib.h>
#include "gd.h"
int main (int argc, char** argv)
{
char* font = "/usr/share/fonts/truetype/msttcorefonts/arial.ttf";
gdImagePtr img = gdImageCreate(500, 50);
int white = gdImageColorAllocate(img, 255, 255 ,255);
int black = gdImageColorAllocate(img, 0, 0, 0);
int brect[8];
gdImageStringFT(img, brect, black, font, 8, 0, 10, 20, "al ol el farmor
hamtar skolan");
FILE* out = fopen("test.png", "w");
gdImagePng(img, out);
fclose(out);
return 0;
}
Produces the following png:
Hi, With indexed images anti aliasing doesn’t seem to work. Added a small code change that will make this work atleast for lines.
Can u please have a look at this ?
Thanks
I was building png and gd on a win32 platform with visual c 6 and it refused to allow compilation until the following patch was applied. Notice that the png_check_sig has been removed from libpng is provided at http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt