lstein / perl-gd Goto Github PK

libgd has included Windows Bitmap .bmp support (gdImageBmp and gdImageCreateFromBmp and associated) since libgd 2.1.0-alpha1.

This is different from WBMP support (WBMP is a monochrome format, whereas Windows BMP allows anything from monochrom to full-color images; WMBP format uses gdImageWBMP/gdImageCreateFromWBMP/etc, which you have already implemented with newFromWBMP and ->wbmp).

I have confirmed with GD 2.76 libgd 2.2.5 (strawberry perl v5.32.1) that if I output a GD::Image with $img->wbmp($fg), then no default Microsoft tool (mspaint.exe, Photo Viewer, etc) can read it as a Windows Bitmap (.bmp), because it's not a valid Windows bitmap file. But if I get a tool (like ImageMagick) that understands the monochrome WBMP format, it reads it just fine. Similarly, ->newFromWBMP cannot read a standard Windows .bmp file.

There is no GD::Image::newFromBmp() or ->bmp() pair for input/output of the Windows Bitmap format (Undefined subroutine &GD::Image::newFromBmp).

Since gdImageBmp and gdImageCreateFromBmp already exist in libgd 2.1 and newer (and are thus present in my libgd 2.2.5 or in the libgd 2.3.3 that you've supported since at least v2.74), it would be really nice if support for that feature of libgd could be added to GD::Image. (If you don't want to try to auto-identify it for GD::Image::new(), that's fine with me.)

But whether or not it gets added, the documentation for GD::Image->newFromWBMP should be changed for two things:

1. Since WBMP is not a Windows BMP, and is not compatible with the windows bitmap format, it shouldn't say it is.
2. Since WBMP is a monochrome format, a truecolor option isn't needed.

Thank you.

I need to install the GD module in a separate directory other than the default Perl modules one. The problem is that Build.PL does not seem to support a custom install prefix from command line and installing with the Makefile.PL does not seem to work since no object files are generated.

Hello,

little spelling errors:

--- a/lib/GD.pm
+++ b/lib/GD.pm
@@ -1432,7 +1432,7 @@
 =item B<$ok = $image-E<gt>contrast($contrast)>

 $contrast: a double value. The contrast adjustment value. Negative
-values increase, postive values decrease the contrast. The larger
+values increase, positive values decrease the contrast. The larger
 the absolute value, the stronger the effect.

 =item B<$ok = $image-E<gt>color($red,$green,$blue,$alpha)>
@@ -1487,7 +1487,7 @@
 format happens to be identical to the old-style MSDOS bitmap ".fnt"
 files, so you can use one of those directly if you happen to have one.

-For writing proportional scaleable fonts, GD offers the stringFT()
+For writing proportional scalable fonts, GD offers the stringFT()
 method, which allows you to load and render any TrueType font on your
 system.

Hi,

Despite having updated to latest version of GD I still get listed in the CPAN tool:

GD::Polygon undef 0.2 RURBAN/GD-2.69.tar.gz

The problem appears to be that the GD::Polygon package itself has no version, but the GD::Polyline package has a version of "0.2" and then overrides the GD::Polygon package

package GD::Polyline;

############################################################################
#
# GD::Polyline
#
############################################################################
#
# What's this?  A class with nothing but a $VERSION and @ISA?
# Below, this module overrides and adds several modules to 
# the parent class, GD::Polygon.  Those updated/new methods 
# act on polygons and polylines, and sometimes those behaviours
# vary slightly based on whether the object is a polygon or polyline.
#

use vars qw($VERSION @ISA);
$VERSION = "0.2";
@ISA = qw(GD::Polygon);


package GD::Polygon;

############################################################################
#
# new methods on GD::Polygon
#
############################################################################

I think the fix is to either remove the version or to align it with the main package version?

Thanks in advance

Running Fedora Linux GD::Image::copyRotated() appears to incorrectly throw a version error:

Environment:
matt@aslan:276% cat /etc/fedora-release
Fedora release 20 (Heisenbug)
matt@aslan:277% rpm -q gd
gd-2.1.0-8.fc20.x86_64
matt@aslan:278% perl_module_version GD GD::Image
GD : 2.49
GD::Image : 2.38
matt@aslan:279% rpm -ql gd | grep libgd
/usr/lib64/libgd.so.3
/usr/lib64/libgd.so.3.0.0

Symptom:
matt@aslan:280% perl rotate_image test.jpg 270
libgd 2.0.33 or higher required for copyRotated support at /home/matt/src/LLS/Graphics.pm line 368.
matt@aslan:281% grep copyRotated LLS/Graphcis.pm
my ($w, $h) = $image->getBounds(); $image->copyRotated($oldimage, $h/2, $w/2, 0, 0, $w, $h, 270);

What additional detail can I provide?

See https://rt.cpan.org/Public/Bug/Display.html?id=130045

On an ubuntu 24.04 with system libgd-dev installed:

TIFFFetchDirectory: Warning, Requested memory size for TIFF directory of 192 is greather than filesize 0. Memory not allocated, TIFF directory not read.
TIFFReadDirectory: Failed to read directory at offset 140.
GD Warning: Cannot open TIFF imagegdImageCreateFromTiff error at /home/cpansand/.cpan/build/2024060919/GD-2.82-1/blib/lib/GD/Image.pm line 281.
# Looks like your test exited with 255 just after 4.
t/autodetect.t ............
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 8/12 subtests
...

See https://github.com/PhilterPaper/Perl-PDF-Builder/actions

and https://rt.cpan.org/Ticket/Display.html?id=141125

Add the strawberry workflow to our GH Actions (the default)

The default download location is broken. Best interim solution is to download from http://cpan.metacpan.org/authors/id/L/LD/LDS/GD-2.53.tar.gz.

For those using cpanm:

cpanm --mirror http://cpan.metacpan.org

man reports an error to split this. Little patch:

--- a/lib/GD.pm
+++ b/lib/GD.pm
@@ -1305,8 +1305,13 @@

 Creates a new palette image from a truecolor image.

-  samplefactor The quantization precision between 1 (highest quality) and 10 (fastest).
-  maxcolor     The number of desired palette entries.
+=over 4
+
+=item samplefactor: The quantization precision between 1 (highest quality) and 10 (fastest).
+
+=item maxcolor: The number of desired palette entries.
+
+=back

 This is the same as createPaletteFromTrueColor with the
 quantization method GD_QUANT_NEUQUANT. This does not support dithering.

@eserte has a fedora system with gd 2.3.2 and GD.t still fails with GD-2.74:.
2.73 works fine

#   Failed test 'unable to generate comparison image for test 1: Can't locate object method "newFromGd2" via package "GD::Image" at (eval 16) line 1.
# '
#   at t/GD.t line 259.
Can't locate object method "newFromGd2" via package "GD::Image" at t/GD.t line 80.
# Looks like your test exited with 255 just after 3.
t/GD.t .................... Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 12/14 subtests 

overriding the libgd internal printf stderr,
and use it for perl warnings and errors.

Described in the line #546 of GD.pm (typical usage sequence) following instruction:

add_frame_data($frame);

causes an error:

Undefined subroutine &main::add_frame_data called at <programname> line <linenumber>

Consider the following:

use GD::Simple;

for (1..100)
{
    my $pid = fork;

    if(!defined($pid))
    {
        next;
    }

    if($pid == 0)
    {
        GD::Simple->new->bgcolor('transparent');
        exit;
    }
}

This fails more often than not, producing the following output:

unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856, <DATA> line 52.
unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856.
unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856, <DATA> line 55.
unknown color at /usr/local/lib/perl5/site_perl/mach/5.26/GD/Simple.pm line 856.
[...]

With some debugging put in, it becomes reasonably clear that DATA's position is literally all over the place, reading completely random stuff from completely random places in Simple.pm. The gist of this obviously comes down to DATA being a typeglob and all that, in a concurrent scenario like the above, several processes read from it, some will be missing some data, eventually one of them will also make it skip past __END__, and after a short while everything goes bonkers.

I've been playing with a couple of naive ideas for a fix, but the only real solution seems to be not building %COLORS at run-time.

Any other suggestions or observations perhaps before I put in a pull request with a static table?

Hi,

I have a legacy CGI application which depends upon GD.pm. It also depends upon a quality Text To Speech command-line tool such as 'gTTS', and also nginx.

I've created a Dockerfile based upon Ubuntu 14.04 which can build the Perl that I need and also the Python that I need. But it lacks nginx. Starting with a modern base image such as 'ubuntu/nginx' yields build errors for GD.pm 'Unable to locate package libgd2-noxpm-dev'

Has anyone figured out how to install GD.pm using a modern base image? I'm not wedded to Ubuntu. My current Dockerfile appears below. As I mentioned, it builds fine, but lacks nginx.

# Set the base image to Ubuntu
FROM ubuntu:14.04

# File Author / Maintainer
MAINTAINER Jonathan Epstein <[email protected]>

# Update the repository sources list
RUN apt-get update

# Install compiler and perl stuff
RUN apt-get install --yes \
 build-essential \
 gcc-multilib \
 apt-utils \
 perl \
 expat \
 libexpat-dev

# Install perl modules
RUN apt-get install -y cpanminus

RUN cpanm CPAN::Meta \
 readline \
 Term::ReadKey \
 YAML \
 Digest::SHA \
 Module::Build \
 ExtUtils::MakeMaker

RUN apt-get install --yes \
 libarchive-zip-perl

# Install GD
RUN apt-get remove --yes libgd-gd2-perl

RUN apt-get install --yes \
 libgd2-noxpm-dev

RUN cpanm GD


# Copy-hacked from tomersha/docker-ubuntu-14.04-python-3.6.2
# PyEnv
ENV PYENV_ROOT /root/.pyenv
ENV PATH $PYENV_ROOT/shims:$PYENV_ROOT/bin:$PATH
# Configure Python not to try to write .pyc files on the import of source modules
ENV PYTHONDONTWRITEBYTECODE true
ENV PYTHON_VERSION 3.6.2

RUN sudo apt-get update -q \
    && sudo apt-get install -y --no-install-recommends \
        build-essential \
        ca-certificates \
        curl \
        git \
        libbz2-dev \
        libreadline-dev \
        libsqlite3-dev \
        libssl-dev \
        zlib1g-dev

# Install pyenv and default python version
RUN git clone https://github.com/yyuu/pyenv.git /root/.pyenv \
    && cd /root/.pyenv \
    && git checkout `git describe --abbrev=0 --tags` \
    && sudo echo 'export PATH="$HOME/.pyenv/bin:$PATH"' >> ~/.bashrc \
    && sudo echo 'eval "$(pyenv init -)"'               >> ~/.bashrc

RUN pyenv install $PYTHON_VERSION
RUN pyenv local $PYTHON_VERSION

RUN pip install gTTS

GD Warning: gd-png error: no colors in palette
*** Error in `perl': double free or corruption (!prev): 0x00000000026851f0 ***
Aborted (core dumped)

The GD::Simple->fontMetrics() function doesn't seem to be coded in such a
way that it does what the documentation says. The documentation at
https://metacpan.org/pod/GD::Simple says that the metrics are defined in
terms of the rendering of the letters m, j, and d, but the code at
https://metacpan.org/release/GD/source/lib/GD/Simple.pm actually only
does test renderings of m and j, never d.

The documentation says that the lineheight is defined as
"the distance from the bottom of the 'j' to the top of the 'd'".
This sounds like the intention is to return the height of the string
'jd'. This would automatically be greater than the xheight. Actually
what it seems to calculate is the whitespace in the middle of "m\nm",
which is much smaller.

Here is some test code:

use GD::Simple;
use strict;
my $img = GD::Simple->new(100,100); # dummy height and width
my $font = $img->font('/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf',48);
my $metrics = $img->fontMetrics;
print "['xheight':",$metrics->{'xheight'},
",'ascent':",$metrics->{'ascent'},
",'descent':",$metrics->{'descent'},
",'lineheight':",$metrics->{'lineheight'},
",'leading':",$metrics->{'leading'},
"]\n"
;

The output is:

['xheight':38,'ascent':13,'descent':13,'lineheight':29,'leading':3]

I think the lineheight is wrong (too small), and the ascent is really
just a copy of the descent.

Here is a patch, which I think makes the code do what was intended and also clears up possible ambiguities in the documentation.

740,741c740
<   lineheight   the distance from the bottom of the 'j' to the top of
<                the 'd'
---
>   lineheight   the distance from the bottom to the top of the string 'jd'
743c742
<   leading      the distance between two adjacent lines
---
>   leading      the height of the empty space between two adjacent lines
771,773c770,773
<     my @mbounds   = GD::Image->stringFT($self->fgcolor,$font,
< 					$self->fontsize,0,
< 					0,0,'m');
---
>     my @mbounds   = GD::Image->stringFT($self->fgcolor,$font,$self->fontsize,0,0,0,'m');
>     my @jbounds   = GD::Image->stringFT($self->fgcolor,$font,$self->fontsize,0,0,0,'j');
>     my @dbounds   = GD::Image->stringFT($self->fgcolor,$font,$self->fontsize,0,0,0,'d');
>     my @mmbounds  = GD::Image->stringFT($self->fgcolor,$font,$self->fontsize,0,0,0,"m\nm");
775,778c775
<     my @jbounds   = GD::Image->stringFT($self->fgcolor,$font,
< 					$self->fontsize,0,
< 					0,0,'j');
<     my $ascent    = $mbounds[7]-$jbounds[7];
---
>     my $ascent    = $mbounds[7]-$dbounds[7];
780,786c777,780
< 
<     my @mmbounds  = GD::Image->stringFT($self->fgcolor,$font,
< 					$self->fontsize,0,
< 					0,0,"m\nm");
<     my $twolines  = $mmbounds[3]-$mmbounds[5];
<     my $lineheight  = $twolines - 2*$xheight;
<     my $leading     = $lineheight - $ascent - $descent;
---
>  
>     my $mm_height  = $mmbounds[3]-$mmbounds[5];
>     my $lineheight  = $xheight+$ascent+$descent;
>     my $leading     = $mm_height - 2*$xheight - $ascent - $descent;
788,791c782,785
< 		    descent    => $descent,
< 		    lineheight => $lineheight,
< 		    xheight    => $xheight,
< 		    leading    => $leading};
---
>                        descent    => $descent,
>                        lineheight => $lineheight,
>                        xheight    => $xheight,
>                        leading    => $leading};

add gdTransformAffineGetImage, gdTransformAffineCopy, gdTransformAffineBoundingBox

I've compiled Perl 5.38 with VS2019, then zlib, libpng, jpeglib and libgd with VS2019. I'd like to use the standard procedure for building GD, but it's failing at a few points:

Environment setup:

• Start a fresh cmd.exe.
• Pull VS2019 paths: "c:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat" x64 8.1
• Set path to Perl and a few GNU tools conveniently included in git on Windows: set PATH=C:\xyzzy\perl_538\bin;%PATH%;c:\Program Files\Git\usr\bin
• All the prerequisites are installed in C:\xyzzy\prerequisites.

Running Makefile.PL:

perl Makefile.PL --options="JPEG GIF PNG" --lib_gd_path=c:/xyzzy/prerequisites/lib --lib_png_path=c:/xyzzy/prerequisites --lib_jpeg_path=c:/xyzzy/prerequisites --lib_zlib_path=c:/xyzzy/prerequisites --ignore_missing_gd

Ends with an error:

Can't find c:/xyzzy/prerequisites/lib/pkgconfig/gdlib.pc.pc in any of /usr/local/lib/pkgconfig /usr/local/share/pkgconfig /usr/lib/pkgconfig /usr/share/pkgconfig
use the PKG_CONFIG_PATH environment variable, or
specify extra search paths via 'search_paths'
 at Makefile.PL line 557.
*** can not find package c:/xyzzy/prerequisites/lib/pkgconfig/gdlib.pc
*** check that it is properly installed and available in PKG_CONFIG_PATH
 at Makefile.PL line 557.

Why is it gdlib.pc.pc? The file gdlib.pc does exist in c:/xyzzy/prerequisites/lib/pkgconfig. If I copy gdlib.pc to gdlib.pc.pc, it still fails in the same way. By the way, --lib_gd_path has to end with "/lib" for this to work at all; using "\lib" fails in a different way.

I have to manually patch Makefile.PL with:

• Edit Makefile.PL and add "return 0;" at top of sub try_to_autoconfigure so it's never run.

Then the above flags to Makefile.PL are fine. However, probably due to the way I've compiled libpng and zlib, I also need to manually patch:

• Replace "-lpng" with "-lpng16_static"; replace "-lz" with "-lzlib".

Now a Makefile is successfully generated. Unfortunately, running:

nmake

Ends immediately with:

        "C:\xyzzy\perl_538\bin\perl.exe" lib/GD/Image_pm.PL lib/GD/Image.pm
Can't open perl script "lib": Permission denied
NMAKE : fatal error U1077: 'C:\xyzzy\perl_538\bin\perl.exe' : return code '0xd'
Stop.

Running that command in cmd.exe goes fine and produces the output Image.pm:

GD-2.79>"C:\xyzzy\perl_538\bin\perl.exe" lib/GD/Image_pm.PL lib/GD/Image.pm
Extracting Image.pm (with variable substitutions)

Then I can run nmake again, which ends with:

        "C:\xyzzy\perl_538\bin\perl.exe" "-Iblib\arch" "-Iblib\lib" bdf_scripts/bdf2gdfont_pl.PL bdf_scripts/bdf2gdfont.pl
Can't open perl script "bdf_scripts": Permission denied
NMAKE : fatal error U1077: 'C:\xyzzy\perl_538\bin\perl.exe' : return code '0xd'
Stop.

Run it manually:

GD-2.79>"C:\xyzzy\perl_538\bin\perl.exe" "-Iblib\arch" "-Iblib\lib" bdf_scripts/bdf2gdfont_pl.PL bdf_scripts/bdf2gdfont.pl
Extracting bdf2gdfont.pl (with variable substitutions)

Then run nmake again, and now the build succeeds.

For nmake test, I had to copy zlib.dll, libpng16.dll and libgd.dll to blib\arch\auto\GD, but that's fine. All the tests succeed, except:

t\windows_bmp.t ........... Can't locate object method "newFromBmp" via package "GD::Image" at t\windows_bmp.t line 11.
t\windows_bmp.t ........... 1/4 # Looks like your test exited with 255 just after 1.

That's because I omitted BMP support when configuring Makefile.PL. Looks like this test needs to be updated to not run if BMP support is excluded?

Hi,

I am trying to execute test cased for GD-2.68. with Libgd and GD module build with VS2013
But the test case fails with below error

Can't locate object method "newFromGif" via package "GD::Image" at t\transp.t line

"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t\*.t
t\fork.t .................. skipped: Test::Fork required
t\GD.t .................... 1/13 # Testing gd 2.2.5 using gd2 support.
# ignore corrupt png error messages...
t\GD.t .................... ok
t\HSV.t ................... ok
t\Polyline.t .............. ok
t\transp.t ................ Can't locate object method "newFromGif" via package "GD::Image" at t\transp.t line 13.
t\transp.t ................ 1/12 # Looks like your test exited with 255 just after 1.
t\transp.t ................ Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 11/12 subtests
t\z_kwalitee.t ............ skipped: No RELEASE_TESTING
t\z_manifest.t ............ skipped: requires a git checkout and a unix for git and diff
t\z_pod-spell-mistakes.t .. skipped: No RELEASE_TESTING
t\z_pod.t ................. skipped: No RELEASE_TESTING

Test Summary Report
-------------------
t\transp.t              (Wstat: 65280 Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 12 tests but ran 1.
Files=9, Tests=16,  2 wallclock secs ( 0.06 usr +  0.03 sys =  0.09 CPU)
Result: FAIL
Failed 1/9 test programs. 0/16 subtests failed.
NMAKE : fatal error U1077: 'C:\this_is_a_fake_path\this_is_a_fake_path\this_is_a_fake_path\this_is_a_fake_path\this_is_a_fake_path\this_is_a_fake_path\this_is_a_fake_path\bin\iwperl.exe' : return code '0xff'
Stop.

Please let me know any inputs

Thanks,
Jamey

After switching from Ubuntu 20 LTS (Perl Lib GD Version 2.71) to Ubuntu 22 LTS (Perl Lib GD Version 2.712.76) every Perl -w call of GD::Image->newFromPng() leads to the following error output:

Use of uninitialized value $pkg in concatenation (.) or string at /usr/lib/x86_64-linux-gnu/perl-base/Symbol.pm line 53.

In a web server environment this is annoying, because it creates an entry in the Apache server error log every time.

Hi,

I am creating a new image using GD::Image->new($jpg_file), where $jpg_file is a filename pointing to a file on disk.
The JPEG file on disk is valid. But the function returns undef, as the first four bytes of the JPEG image on disk does not match the pattern in the _image_type function: The fourth byte is \376.
If I create the GD image using newFromJpeg, it works fine.
Do you know if there are any issues related to this?
I see that the magic function detection was changed in v2.42. Unfortunately, I am not aware of the various patterns which can occur as the first four bytes in JPEG files.
By the way, we are using GD::Image for sizing images in various formats.

Kind regards,
Geir Myklebust

(perl /NAS4/lien/Hi-C/scripts_dekkerlab/cworld-dekker-master/scripts/perl/heatmap.pl -i K5__30000__10.matrix.gz -i GM__30000__10.matrix.gz -o K5__GM__30000__10__median)
I just want to test the script (heatmap.pl),but got error report.
The error report:
Can't load '/NAS7/home/caulien/bin/localperl/lib/site_perl/5.26.0//x86_64-linux/auto/GD/GD.so' for module GD: libiconv.so.2: cannot open shared object file: No such file or directory at /NAS7/home/caulien/bin/localperl/lib//5.26.0/x86_64-linux/DynaLoader.pm line 193.
at /NAS7/home/caulien/bin/localperl/lib/site_perl/5.26.0//x86_64-linux/GD/Simple.pm line 160.
Compilation failed in require at /NAS7/home/caulien/bin/localperl/lib/site_perl/5.26.0//x86_64-linux/GD/Simple.pm line 160.
BEGIN failed--compilation aborted at /NAS7/home/caulien/bin/localperl/lib/site_perl/5.26.0//x86_64-linux/GD/Simple.pm line 160.
Compilation failed in require at /NAS4/lien/Hi-C/scripts_dekkerlab/cworld-dekker-master/scripts/perl/heatmap.pl line 13.
BEGIN failed--compilation aborted at /NAS4/lien/Hi-C/scripts_dekkerlab/cworld-dekker-master/scripts/perl/heatmap.pl line 13.

how can I deal with it? Thank you so much!