tonycoz / imager Goto Github PK
View Code? Open in Web Editor NEWImager - image manipulation from perl.
Home Page: http://imager.perl.org/
imager's People
Contributors
Stargazers
Watchers
imager's Issues
the crop() method should allow relative values for the right and bottom borders [rt.cpan.org #7582]
Migrated from rt.cpan.org#7582 (status was 'open')
Requestors:
From [email protected] on 2004-09-08 15:25:02
:
For example it should be possible to do:
my $out = $img->crop(left=10, top=10, right=-10, bottom=-10);
to remove a 10 pixel border from the image.
segfault in Imager 0.43 [rt.cpan.org #7467]
Migrated from rt.cpan.org#7467 (status was 'resolved')
Requestors:
From [email protected] on 2004-08-25 08:21:20
:
----- Forwarded message from tony -----
Date: Wed, 25 Aug 2004 09:50:28 +1000
To: [email protected]
Subject: Re: [Imager-devel]: segfault in Imager 0.43
Mail-Followup-To: [email protected]
> When converting to GIF the image is first converted to a paletted
> image, first a scan is done to produce a color table, then Imager
> does a translation from RGB to paletted using that table.
>
> It's crashing in the translation stage.
>
> I get the same result if I use a PNG file as input.
>
> I also get a crash if I call $thumb->to_paletted, so it's not a libungif
> problem.
>
> I'll try to debug this and put a fix in CVS.
Ok, this is three different bugs:
1) scale() doesn't ensure that the output image is at least 1 pixel by 1
pixel. The scale(type=>'min', xpixels=>1, ypixels=>1) resulted in an
image 0 pixels high (since 1/118 = 0.00847 truncates to 0).
2) the low level image creation code doesn't ensure images are at least
1 x 1 pixels
3) the translation code (which takes an RGB image and a palette),
doesn't handle the case when an empty palette is passed in. Since the
image generated by scale has no pixels, the generated palette is empty,
and so the translation stage fails because it expects at least one color
in the palette.
I'll fix these as time permits.
Tony
----- End forwarded message -----
RGB file format has only a trusting read function, and no write, and no tests [rt.cpan.org #8666]
Migrated from rt.cpan.org#8666 (status was 'resolved')
Requestors:
From [email protected] on 2004-11-30 09:53:13
:
see subject
From [email protected] on 2005-06-17 08:18:15
:
The RGB file format code currently called from anywhere unless you
explicity call the undocumented internal function, so this isn't a
security issue at this point.
From [email protected] on 2007-07-31 12:27:11
:
fixed in svn
From [email protected] on 2007-08-30 08:19:02
:
fixed in 0.60
open() method is used in examples in Imager.pm but not documented [rt.cpan.org #11431]
Migrated from rt.cpan.org#11431 (status was 'resolved')
Requestors:
From [email protected] on 2005-02-08 22:26:52
:
the open() method is used in Imager.pm in an example, and the user is
referred to Imager::Files.
The examples should use the read method.
The method index should include open() and refer the user to
Imager::Files
Imager::Files should mention the open() method as an alias for read().
i_xres and i_yres values are stored at floating point precision rather than the precision of the source1 [rt.cpan.org #8520]
Migrated from rt.cpan.org#8520 (status was 'resolved')
Requestors:
From [email protected] on 2004-11-19 05:14:49
:
For example:
testimg/comp8.tif
i_format: tiff
i_xres: 71.9835968017578125
i_yres: 71.9835968017578125
when the precision is probably much lower.
Documentation suggestions [rt.cpan.org #5608]
Migrated from rt.cpan.org#5608 (status was 'open')
Requestors:
From [email protected] on 2004-03-09 23:46:15
:
----- Forwarded message from Dave Rolsky <[email protected]> -----
Date: Tue, 9 Mar 2004 17:10:48 -0600 (CST)
From: Dave Rolsky <[email protected]>
To: Tony Cook <[email protected]>
cc: mason <[email protected]>
Subject: Re: [Mason] Working with PerlMagick [now way OT]
On Wed, 10 Mar 2004, Tony Cook wrote:
> On Tue, Mar 09, 2004 at 11:37:12AM -0600, Dave Rolsky wrote:
> > On Tue, 9 Mar 2004, Randal L. Schwartz wrote:
> >
> > > As you can tell, I have a great love/hate relationship with
> > > ImageMagick.
> >
> > Mine is mostly hate ;)
> >
> > Argh, what a poorly documented monstrosity. And the API is just awful
> > once you figure it out. I'd really like to see Imager replace it, though
> > it's docs are terrible too. But at least the API is reasonably sane ;)
>
> What do you are the main problems with the Imager documentation?
There's just no list of methods! Look at the SYNOPSIS, which references
methods like "scale". But where is scale documented besides the synopsis?
Basically, you need to list every method and exported constant/var (like
%Imager::formats) and say what they do, what arguments they take, and what
they return. A few quick examples is simply not sufficiient.
It also needs a lot more high-level "here's how you do task X" type of
documentation. Right now it's mostly very low-level, and doesn't make
much sense unless you already know what the method you want is named.
An Imager::Cookbook would be really helpful. Here's a list of things you
could cover (taken from the Image Magick home page ;):
Convert an image from one format to another (e.g. TIFF to JPEG)
Resize, rotate, sharpen, color reduce, or add special effects to an image
Create a montage of image thumbnails
Create a transparent image suitable for use on the Web
Turn a group of images into a GIF animation sequence
Create a composite image by combining several separate images
Draw shapes or text on an image
Decorate an image with a border or frame
Describe the format and characteristics of an image
Obviously, Imager may not do all of these things, but I know it does some
of those. That'd be a great start for a cookbook, I think. Browsing the
rest of the Image Magick docs and example will probably give you more
ideas for cookbook topics.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
----- End forwarded message -----
From [email protected] on 2004-09-27 01:05:11
:
I'm using http://wiki.imager.perl.org/cgi-bin/wiki.pl?ImagerWiki to
slowly build up both a cookbook and a tutorial.
If you have any ideas for the tutorial (or the cookbook) please add them
to the appropriate page.
From [email protected] on 2005-03-16 14:07:29
:
Some progress is being made with this over time. 0.44 includes a method
index. 0.45 will include a concept index and the start of a cookbook,
and some sample code.
Short examples of use are being added to method descriptions over time.
From [email protected] on 2006-07-24 12:27:57
:
added a cookbook entry for converting image files.
From [email protected] on 2007-04-03 13:19:20
:
Imager's documentation has improved a lot since I added this, but it's
still and ongoing process.
What else should there be?
- lots more example code inline
- more detail on the filters where possible
Patch for systems w/o rgb.txt [rt.cpan.org #2593]
Migrated from rt.cpan.org#2593 (status was 'resolved')
Requestors:
Attachments:
From [email protected] on 2003-05-16 19:13:38
:
Systems that run headless often don't have rgb.txt or Gimp's Palette file on them. This patch adds the GPLed contents of Gimp's Named_Colors as a __DATA__ section.
From [email protected] on 2003-05-19 00:41:45
:
On Fri, May 16, 2003 at 03:13:38PM -0400, via RT wrote:
>
> This message about Imager was sent to you by MAHEX <[email protected]> via rt.cpan.org
>
> Full context and any attached attachments can be found at:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=2593 >
>
> Systems that run headless often don't have rgb.txt or Gimp's Palette file on them. This patch adds the GPLed contents of Gimp's Named_Colors as a __DATA__ section.
While this would be nice, Imager is distributed under both the GPL and
the Artistic license. Including material distributed only under the GPL
would restrict Imager's licensing to just the GPL.
Tony
From [email protected] on 2004-01-04 10:46:36
:
Would it work to use a color file released under a BSD license?
From [email protected] on 2004-01-05 00:45:17
:
On Sun, Jan 04, 2004 at 05:46:36AM -0500, via RT wrote:
>
> This message about Imager was sent to you by ADDI <[email protected]> via rt.cpan.org
>
> Full context and any attached attachments can be found at:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=2593 >
>
> Would it work to use a color file released under a BSD license?
That should work.
Tony
From [email protected] on 2004-09-05 09:50:06
:
I've added a new module which includes an X licensed rgb.txt as the
source for color information. This module is then used to determine the
color if the name is not found as a gimp or xname color.
It's also possible to use the built-in table directly with the 'builtin'
keyword.
The X license is compatible with both the GPL and the Artistic licenses,
and so doesn't cause license problems with Imager.
This is currently in CVS.
Thanks for supplying this patch, it provided the impetus for the
inclusion of the facility in Imager (eventually anyway :)
the default IM_INCPATH and IM_LIBPATH should include the contents of $Config{locincpth} and $Config{loclibpth} [rt.cpan.org #2942]
Migrated from rt.cpan.org#2942 (status was 'resolved')
Requestors:
From [email protected] on 2003-07-14 00:05:24
:
<merlyn:#perl> it also needs to add freetype{,2} to those names as well
<merlyn:#perl> or anything that would be sub that dir
methods that return a new image should warn in void context [rt.cpan.org #9672]
Migrated from rt.cpan.org#9672 (status was 'resolved')
Requestors:
From [email protected] on 2005-01-13 02:51:58
:
The scale() method was modified to warn when called in scalar context,
other methods that return the result image should do the same.
ie.
convert()
crop()
copy()
rotate()
matrix_transform()
to_paletted()
to_rgb8()
Makefile.PL's detection summary should be more obvious [rt.cpan.org #9675]
Migrated from rt.cpan.org#9675 (status was 'resolved')
Requestors:
From [email protected] on 2005-01-13 03:32:44
:
Makefile.PL produces output like:
tiff: includes found - libraries found
T1-fonts: includes found - libraries found
png: includes found - libraries found
ungif: includes found - libraries found
if you're not paying attention it's easy to miss that libraries are not
found when the includes are. The output should include something to
indicate that the option will/won't be supported as well as the
detection info.
0.45 will include detection via freetype-config/pkg-config where
appropriate, this should be included too, for example:
Feature Support Summary
------- ------- -------
TT-fonts: DISABLED disabled via --disable
w32: NO includes not found - libraries not found
gif: NO includes found - libraries not found
jpeg: YES includes found - libraries found
freetype2: YES configured via freetype-config
tiff: YES includes found - libraries found
T1-fonts: DISABLED disabled via --disable
png: YES includes found - libraries found
ungif: YES includes found - libraries found
From [email protected] on 2011-03-14 12:28:26
:
This has been done differently to the way it was envisaged when the
ticket was opened.
We now display a short list of the found libraries and the not found.
To find why a problem failed the user can scroll back.
Inconsistent bounding box information/letter sizing [rt.cpan.org #11291]
Migrated from rt.cpan.org#11291 (status was 'resolved')
Requestors:
Attachments:
From on 2005-01-31 10:35:58
:
As you can see in the attached image, I'm using Imager and Freetype to create some kind of diagram. The Letters in the Columns should fill the whole width of the column. Thus, I use the $bbox->total_width to get the width, find the difference between target width and effective visible width and rescale/adjust the letter. This normally works fine, but since I switched to the OO interface to bbox, I get these wrongly sized letters every now and then. Upgrading from 0.43 to 0.44 changed the position of the bug, i.e. other letters where affected. Changing the Image size changes which letters are affected.
I use Perl 5.8.1 on a Mac, Imager 0.44, Freetype 2 v. 9.2.3 and the Arial TT font for the letters.
Thanks for your help,
Benjamin
From [email protected] on 2005-01-31 14:11:49
:
On Mon, Jan 31, 2005 at 05:35:59AM -0500, Guest via RT wrote:
> As you can see in the attached image, I'm using Imager and Freetype to create some kind of diagram. The Letters in the Columns should fill the whole width of the column. Thus, I use the $bbox->total_width to get the width, find the difference between target width and effective visible width and rescale/adjust the letter. This normally works fine, but since I switched to the OO interface to bbox, I get these wrongly sized letters every now and then. Upgrading from 0.43 to 0.44 changed the position of the bug, i.e. other letters where affected. Changing the Image size changes which letters are affected.
Hi, I've looked at this problem. It seems to be a long standing issue
with the calculation of the right side bearing for glyphs.
- the calculated right-side bearing wasn't being scaled from FT2's
fixed point convention to an integer
This was not a problem with the OO interface to bbox.
There's another problem which will stop glyphs with a non-zero right-
side bearing from filling the width. Currently the width value
returned by the bounding box functions will include the right-side
bearing of the final glyph, this means that you will see
space to the right of characters like "b" in the Arial font.
This isn't quite so simple to fix, since it requires some change
in common to all of the font drivers, but it is something I plan to
change (compatibly) in 0.45.
Included below is a patch to freetyp2.c that calculates the right-
side bearing correctly.
Tony
Index: freetyp2.c
===================================================================
RCS file: /cvsroot/Imager/freetyp2.c,v
retrieving revision 1.20
diff -u -r1.20 freetyp2.c
--- freetyp2.c 24 Jan 2005 13:18:48 -0000 1.20
+++ freetyp2.c 31 Jan 2005 13:59:07 -0000
@@ -388,7 +388,7 @@
/* last character
handle the case where the right the of the character overlaps the
right*/
- rightb = gm->horiAdvance - gm->horiBearingX - gm->width;
+ rightb = (gm->horiAdvance - gm->horiBearingX - gm->width)/64;
if (rightb > 0)
rightb = 0;
}
bmp reader inconsistent in how it handles short files [rt.cpan.org #8426]
Migrated from rt.cpan.org#8426 (status was 'resolved')
Requestors:
From [email protected] on 2004-11-14 12:31:20
:
Sometimes it returns success (see the default: handler for the
compression code), and sometimes it fails (the BMPRLE_DELTA handler).
It should be modified to set i_incomplete and return success
From [email protected] on 2005-06-24 03:43:46
:
There's 2 problems here:
- defining a consistent policy for Imager handling incomplete files
- how to tell if a compressed BMP is incomplete
From [email protected] on 2007-02-06 00:19:29
:
On Sun Nov 14 07:31:20 2004, TONYC wrote:
> Sometimes it returns success (see the default: handler for the
> compression code), and sometimes it fails (the BMPRLE_DELTA handler).
>
> It should be modified to set i_incomplete and return success
Fixed in svn for the next release.
I've made i_incomplete only be set when the caller specifically requests it.
From [email protected] on 2007-04-02 02:08:58
:
On Sun Nov 14 07:31:20 2004, TONYC wrote:
> Sometimes it returns success (see the default: handler for the
> compression code), and sometimes it fails (the BMPRLE_DELTA handler).
>
> It should be modified to set i_incomplete and return success
Fixed in Imager 0.56
t/t50basicoo.t relies on files created by earlier tests [rt.cpan.org #9798]
Migrated from rt.cpan.org#9798 (status was 'resolved')
Requestors:
From [email protected] on 2005-01-17 02:01:04
:
this means you can't run the test in isolation, which might be a problem
in some cases.
From [email protected] on 2010-08-12 01:55:32
:
Fixed in Imager 0.77
first paragraph of crop() documentation needs some rework [rt.cpan.org #11430]
Migrated from rt.cpan.org#11430 (status was 'resolved')
Requestors:
From [email protected] on 2005-02-08 22:19:56
:
It should mention the left, right, top, bottom coordinates specifically
and maybe give a reference list of those parameters.
configured image size limits when reading image files [rt.cpan.org #8706]
Migrated from rt.cpan.org#8706 (status was 'resolved')
Requestors:
From [email protected] on 2004-12-02 03:41:17
:
a caller should be able to set a limit on width and height on images
read from files.
this prevents someone from maliciously supplying a large image file that
requires allocation of huge amounts of memory.
From [email protected] on 2006-01-18 07:06:24
:
Added in 0.46
Dr. Watson/GPF when accessing TIFF images on WinXP [rt.cpan.org #1513]
Migrated from rt.cpan.org#1513 (status was 'resolved')
Requestors:
From on 2002-09-13 13:37:52
:
Whenever I try to read a TIFF image using Imager, Dr. Watson pays me a visit (ie, the program GPFs). I am using Windows XP Professional, ActiveState Perl 5.6.1.633, and a PPD of Imager version 0.41.
All I am trying to do is deliver a multi-page TIFF to a client browser. I'm not sure if this code is correct, but seeing as how I can't even read the image it's difficult to work with ;) If I use a JPEG instead of a TIFF in the first block of code below, it works great. If I could get TIFF to work, I'd be in hog heaven.
The code I have tried thus far includes:
my $file = 'd:\test.tif';
my $img = Imager->new();
$img->open(file=>$file) or die $img->errstr(); # This line crashes
binmode STDOUT;
print $request->header(-type=>'image/tiff');
$img->write(type=>'tiff', fd=>fileno(STDOUT)) or die $img->errstr();
# First line crashes
my @images = Imager->read_multi(file=>$file,type=>'tiff');
binmode STDOUT;
print $request->header(-type=>'image/tiff');
Imager->write_multi({fd=>fileno(STDOUT),type=>'tiff'}, @images);
I have provided a sample image at http://www.devnetinc.com/~crome/test.TIF.
From [email protected] on 2002-11-05 22:41:37
:
[guest - Fri Sep 13 09:37:52 2002]:
> Whenever I try to read a TIFF image using Imager, Dr. Watson pays me a
> visit (ie, the program GPFs). I am using Windows XP Professional,
> ActiveState Perl 5.6.1.633, and a PPD of Imager version 0.41.
TIFFLIB was attempting to produce a warning about an unknown tag in the
image, and crashing in the process.
I'm not sure why it crashes.
I have added a workaround to Imager CVS by setting a TIFFLIB warning
handler while reading tiffs. Currently this just discards the message,
but could be modified at some point to call back to a user supplied
function (at the C level). The XS code could then supply a function
which did a warn, or perhaps did a callback into perl.
This file also revealed a problem when an input TIFF file had more than
five images. Added a test and a fix.
I'm not entirely happy with dropping the warnings into the bit bucket,
so I'm leaving this ticket open for now.
add controls to allow alpha blending of all drawing operations [rt.cpan.org #1986]
Migrated from rt.cpan.org#1986 (status was 'open')
Requestors:
From on 2003-01-24 20:53:29
:
Hi,
I think it would be nice to have the possibility of blending color with Imager. In my case, I am plotting graph with Imager::Plot and the line for the last dataset rendered cover the previous one. I would like the color to blend where line cross instead. Apparentely, recent GD have the alphaBlending function which could permit this.
I swear I saw something about about accessing the gd object directly in the doc but I can't remember where. If it is possible at all, let me know !
From [email protected] on 2003-07-14 00:00:56
:
[guest - Fri Jan 24 15:53:29 2003]:
> Hi,
>
> I think it would be nice to have the possibility of blending color
> with Imager. In my case, I am plotting graph with Imager::Plot and
> the line for the last dataset rendered cover the previous one. I
> would like the color to blend where line cross instead.
> Apparentely, recent GD have the alphaBlending function which could
> permit this.
>
> I swear I saw something about about accessing the gd object directly
> in the doc but I can't remember where. If it is possible at all,
> let me know !
Imager does not use GD in any form. Hence there is no access to an
underlying GD object.
Tony
From [email protected] on 2003-07-16 00:59:21
:
[[email protected] - Tue Jul 15 14:10:32 2003]:
> Sorry for the mistake. Color blending would still be nice.
You're right. I've chanaged the subject of the ticket to indicate this.
It's a big change, but a useful one.
The only way I can see to do this right now would be to draw to a temp
image and use that as a pattern fill with the appropriate combining mode.
Of course, if we enable alpha blending, we should allow all the other
combining modes that the fill objects allow ;)
Tony
From [email protected] on 2020-12-13 07:00:42
:
Ticket migrated to github as https://github.com/tonycoz/issue-move-test/issues/1
Imager doesn't respect $Config{ld_flags} [rt.cpan.org #1471]
Migrated from rt.cpan.org#1471 (status was 'resolved')
Requestors:
Attachments:
From on 2002-08-24 22:30:48
:
See the discussion in the attachment.
Makefile.PL / make fails if spaces are in paths (Win32) [rt.cpan.org #7286]
Migrated from rt.cpan.org#7286 (status was 'resolved')
Requestors:
Attachments:
From [email protected] on 2004-08-07 16:43:14
:
If the library search paths contain spaces (as is the case with the MSVC7 default install), Makefile.PL does not find the referenced libraries and creates invalid Makefile commands because the parameters are not quoted properly. The following diff is what I had to do to get "nmake" to work. On an aside, it seems that Imager does not build properly if no imaging library out of jpeg/tiff/png/gif is available. This could be detected in Makefile.PL ... Anyway, here's the diff:
53,54c53,54
< $F_INC = join(" ",map { (exists $definc{$_})?'':'-I'.$_ } @incs);
< $F_LIBS = join(" ",map { '-L'.$_ } @libs).' '.$F_LIBS;
---
> $F_INC = join(" ",map { (exists $definc{$_})?'': do {/ / ? qq{"-I$_"} : '-I'.$_} } @incs);
> $F_LIBS = join(" ",map { / / ? qq{"-L$_"} : qq{-L$_} } @libs).' '.$F_LIBS;
267c267
< @libs=(qw(/sw/lib), split(/\Q$Config{path_sep}/,$LIBPATH) , split(/ /, $Config{'libpth'}));
---
> @libs=(qw(/sw/lib), split(/\Q$Config{path_sep}/,$LIBPATH) , split(/\Q$Config{'path_sep'}/, $Config{'libpth'}));
269,270c269,270
< push(@incs, split /;/, $ENV{INCLUDE}) if exists $ENV{INCLUDE};
< push(@libs, split /;/, $ENV{LIB}) if exists $ENV{LIB};
---
> push(@incs, split /\Q$Config{path_sep}\E/, $ENV{INCLUDE}) if exists $ENV{INCLUDE};
> push(@libs, split /\Q$Config{path_sep}\E/, $ENV{LIB}) if exists $ENV{LIB};
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DE
S_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"c:\perl\5.8.5\lib\CORE
" -machine:x86'
libpth=C:\Programme\Microsoft Visual C++ Toolkit 2003\lib
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib sh
ell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib o
dbc32.lib odbccp32.lib msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.li
b shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.l
ib odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"c:\perl\5.8
.5\lib\CORE" -machine:x86'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT PERL_IMPLICI
T_SYS
Built under MSWin32
Compiled at Aug 6 2004 13:59:40
@INC:
c:/perl/5.8.5/lib
c:/perl/site/5.8.5/lib
.
From [email protected] on 2004-08-08 04:12:41
:
On Sat, Aug 07, 2004 at 12:43:16PM -0400, via RT wrote:
>
> This message about Imager was sent to you by CORION <[email protected]> via rt.cpan.org
>
> Full context and any attached attachments can be found at:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=7286 >
>
> If the library search paths contain spaces (as is the case with the MSVC7 default install), Makefile.PL does not find the referenced libraries and creates invalid Makefile commands because the parameters are not quoted properly. The following diff is what I had to do to get "nmake" to work.
Thanks for this, I'll look at integrating it in the next few days.
>On an aside, it seems that Imager does not build properly if no imaging library out of jpeg/tiff/png/gif is available. This could be detected in Makefile.PL ... Anyway, here's the diff:
I've built and tested Imager with not image format libraries available a
few times. You will see it skip tests for the image format libraries
it can't find but it still builds and tests correctly.
If you're seeing a build failure with Imager under those circumstances
please give me a log of the failure. If you can, please try the version
currently in CVS:
cvs -d :pserver:[email protected]:/u02/cvsroot co Imager
Tony
>
> 53,54c53,54
> < $F_INC = join(" ",map { (exists $definc{$_})?'':'-I'.$_ } @incs);
> < $F_LIBS = join(" ",map { '-L'.$_ } @libs).' '.$F_LIBS;
> ---
> > $F_INC = join(" ",map { (exists $definc{$_})?'': do {/ / ? qq{"-I$_"} : '-I'.$_} } @incs);
> > $F_LIBS = join(" ",map { / / ? qq{"-L$_"} : qq{-L$_} } @libs).' '.$F_LIBS;
> 267c267
> < @libs=(qw(/sw/lib), split(/\Q$Config{path_sep}/,$LIBPATH) , split(/ /, $Config{'libpth'}));
> ---
> > @libs=(qw(/sw/lib), split(/\Q$Config{path_sep}/,$LIBPATH) , split(/\Q$Config{'path_sep'}/, $Config{'libpth'}));
> 269,270c269,270
> < push(@incs, split /;/, $ENV{INCLUDE}) if exists $ENV{INCLUDE};
> < push(@libs, split /;/, $ENV{LIB}) if exists $ENV{LIB};
> ---
> > push(@incs, split /\Q$Config{path_sep}\E/, $ENV{INCLUDE}) if exists $ENV{INCLUDE};
> > push(@libs, split /\Q$Config{path_sep}\E/, $ENV{LIB}) if exists $ENV{LIB};
>
> Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
> Platform:
> osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
> uname=''
> config_args='undef'
> hint=recommended, useposix=true, d_sigaction=undef
> usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define
> useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
> Compiler:
> cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DE
> S_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
> optimize='-MD -Zi -DNDEBUG -O1',
> cppflags='-DWIN32'
> ccversion='', gccversion='', gccosandvers=''
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
> d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
> alignbytes=8, prototype=define
> Linker and Libraries:
> ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"c:\perl\5.8.5\lib\CORE
> " -machine:x86'
> libpth=C:\Programme\Microsoft Visual C++ Toolkit 2003\lib
> libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib sh
> ell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib o
> dbc32.lib odbccp32.lib msvcrt.lib
> perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.li
> b shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.l
> ib odbc32.lib odbccp32.lib msvcrt.lib
> libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
> gnulibc_version='undef'
> Dynamic Linking:
> dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
> cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"c:\perl\5.8
> .5\lib\CORE" -machine:x86'
>
>
> Characteristics of this binary (from libperl):
> Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT PERL_IMPLICI
> T_SYS
> Built under MSWin32
> Compiled at Aug 6 2004 13:59:40
> @INC:
> c:/perl/5.8.5/lib
> c:/perl/site/5.8.5/lib
> .
From [email protected] on 2004-08-11 12:02:57
:
I've applied a change similar to your to current CVS.
If you want to give it a go, please try building from CVS:
cvs -d :pserver:[email protected]:/u02/cvsroot co Imager
Let me know if you have any problems.
--
Thanks
Tony Cook
crop() method does not preserve the type of image [rt.cpan.org #7578]
Migrated from rt.cpan.org#7578 (status was 'resolved')
Requestors:
From [email protected] on 2004-09-08 14:44:19
:
The crop() method does not preserve the bits/sample, direct/paletted
state of the image.
Perhaps it could use i_sametype() to do that.
I suspect we'd be better off using a new C level function to do it, since
we'd be better off copying palette indexes than RGB values for a
paletted image.
package Imager::Font::Win32; [rt.cpan.org #1748]
Migrated from rt.cpan.org#1748 (status was 'resolved')
Requestors:
From on 2002-10-31 19:56:56
:
Error using Bounding box with Win32 Fonts. I found the problem, please see below:
sub _bounding_box {
my ($self, %opts) = @_;
my @bbox = i_wf_bbox($self->{face}, $opts{size}, $opts{string});
}
Should be:
sub _bounding_box {
my ($self, %opts) = @_;
my @bbox = Imager::i_wf_bbox($self->{face}, $opts{size}, $opts{string});
}
From [email protected] on 2002-11-05 00:15:47
:
Fixed for the next release.
Added a smoke test to t/t37w32font.t that should have detected this in
the first place :)
Thanks for your report.
Tony Cook
audits for allocation integer overflows in progress over time [rt.cpan.org #8213]
Migrated from rt.cpan.org#8213 (status was 'resolved')
Requestors:
From [email protected] on 2004-11-02 14:16:57
:
The following code causes a segmentation fault:
# check for handling of memory allocation of very large images
use Config;
my $uint_range = 256 ** $Config{ivsize};
print "# range $uint_range\n";
my $dim1 = int(sqrt($uint_range));
my $im_b = Imager->new(xsize=>$dim1, ysize=>$dim1, channels=>1);
$im_b->box(filled=>1, color=>'#000000');
which seems to be due to incorrect handling of the multiplication
when calculating the space needed for image data.
The log shows:
[2004/11/02 23:48:01] image.c:270 1: ((nil)) <- IIM_new
[2004/11/02 23:48:01] image.c:266 1: IIM_new(x 65536,y 65536,ch 1)
[2004/11/02 23:48:01] image.c:351 1: i_img_empty_ch(*im (nil), x 65536, y
65536, ch 1)
[2004/11/02 23:48:01] io.c:236 1: mymalloc(size 128) -> 0x83d2860
[2004/11/02 23:48:01] io.c:236 1: mymalloc(size 0) -> 0x83d28e8
[2004/11/02 23:48:01] image.c:378 1: (0x83d2860) <- i_img_empty_ch
[2004/11/02 23:48:01] image.c:270 1: (0x83d2860) <- IIM_new
when creating the image - so the size allocated is zero bytes.
From [email protected] on 2004-11-03 14:16:23
:
Code for each of the image types has been changed to check that the
multiplcation doesn't overflow, and then fail image creation if it does.
Various pieces of code that create new image objects (especially the
file readers) need to handle the possibility of failure.
In some cases they should also have checks added for similar integer
overflows (eg. for buffers they use).
From [email protected] on 2004-11-09 04:10:26
:
Need to check that other image data allocations allocate the correct
amount, for example the quantization image allocation
From [email protected] on 2011-08-15 09:26:21
:
The types code review covered this.
From [email protected] on 2011-08-29 22:47:25
:
Fixed in 0.85
Imager::i_glin() doesn't return the pixel values [rt.cpan.org #11860]
Migrated from rt.cpan.org#11860 (status was 'resolved')
Requestors:
From [email protected] on 2005-03-14 02:35:10
:
--- Imager.xs.~1.85.~ Tue Jan 25 00:18:54 2005
+++ Imager.xs Mon Mar 14 10:18:43 2005
@@ -3785,6 +3785,7 @@
for (i = 0; i < count; ++i) {
SV *sv;
i_color *col = mymalloc(sizeof(i_color));
+
*col = vals[i];
sv = sv_newmortal();
sv_setref_pv(sv, "Imager::Color", (void *)col);
PUSHs(sv);
This also needs to be checked for i_glinf() and tests need to be added
(or fixed) to detect the problem.
freetype problems [rt.cpan.org #1723]
Migrated from rt.cpan.org#1723 (status was 'resolved')
Requestors:
Attachments:
From on 2002-10-26 20:05:23
:
Imager-0.41
This is perl, v5.6.1 built for i386-freebsd
FreeBSD thetasigma.com 4.6-STABLE FreeBSD 4.6-STABLE
When compiling Imager.c, make errors out with:
> In file included from Imager.xs:12:
> image.h:259: freetype.h: No such file or directory
Both freetype1 and freetype2 are installed.
was able to install by using
> IM_MANUAL=1 IM_CFLAGS=-I/usr/local/include/freetype2/freetype perl Makefile.PL
and answering the manual questions, saying yes to everything except win32, gif, TT and ungif.
missing simple examples [rt.cpan.org #1521]
Migrated from rt.cpan.org#1521 (status was 'resolved')
Requestors:
From on 2002-09-16 18:41:25
:
First, thanks for writing Imager. Very cool.
I want to create a new image that is the pixel-wise product of two images.
I had a look at using transform2 but was unable to have any success:
i_ft2_glyph_name implementation tries to store a unicode code point in an unsiged char [rt.cpan.org #7949]
Migrated from rt.cpan.org#7949 (status was 'resolved')
Requestors:
From [email protected] on 2004-10-11 03:45:55
:
This needs a test written and then to be fixed.
From [email protected] on 2004-10-13 12:06:43
:
In the original bug report I was referring to the XS implementation - it
looks like the C implementation has the same problem - accepting an
unsigned char when it should really accept an unsigned long (for unicode).
From [email protected] on 2004-10-13 14:35:41
:
Fixed for freetype 2 after some messing around (FT_Has_PS_Glyph_Names()
seems to always return false for truetype fonts <sigh>)
Still need to check the FT1.x code and the T1lib code (though it's more
a problem for the FT1.x code - T1 only allows 256 chars anyway)
From [email protected] on 2004-10-18 15:00:52
:
The FT1.x and T1 code had similar problems. Both have been fixed.
Tests have been added.
Fixed in CVS for 0.43_02
the pnm reader ignores the maxval that it reads from the pnm file [rt.cpan.org #7465]
Migrated from rt.cpan.org#7465 (status was 'resolved')
Requestors:
Attachments:
From [email protected] on 2004-08-25 01:56:38
:
if you run the following against the attached file:
perl -MImager -e '$im = Imager->new->read(file=>shift);
$im->write(file=>shift)' endgame3-small.ppm endgame3-small-out.ppm
the output image is much darker than the input image.
This happens because the ppm reader ignores the maxval field from the
PPM file.
The image was produced with the pnmquant utility.
Imager::Plot : division by 0 in Axis.pm when all Y are equal [rt.cpan.org #1985]
Migrated from rt.cpan.org#1985 (status was 'resolved')
Requestors:
From on 2003-01-24 20:47:35
:
Hi,
There is a division by 0 in Imager::Plot::Axis (line 130 and 449) when all Y are equal. This is pretty self-explantory if you read the code. For exemple, I worked around the code by overloading the make_yrange() function of Axis.pm :
---
$graph->{'AXIS'}{'make_yrange'} = sub {
$self = shift;
my @bbox = $self->data_bbox();
if ($bbox[2] == $bbox[3]) {
$min = $bbox[2] - 1;
$max = $bbox[2] + 1;
$self->{YgridNum} = 1;
} else {
$min = $bbox[2];
$max = $bbox[3];
}
$self->{YRANGE} = [$min, $max];
}
---
Thanks for your good code !
From [email protected] on 2003-02-16 14:13:49
:
This has been fixed in CVS. See development webpage for information on
how to
access CVS.
Imager io,h is not included under cygwin [rt.cpan.org #7948]
Migrated from rt.cpan.org#7948 (status was 'resolved')
Requestors:
From [email protected] on 2004-10-11 03:44:39
:
The system io.h is included instead, causing problems with the malloc
functions not being declared amongst other things.
The Imager io.h should be renamed.
"make test" fails on RedHat ES: "undefined symbol: FT_Get_Postscript_Name" [rt.cpan.org #5286]
Migrated from rt.cpan.org#5286 (status was 'resolved')
Requestors:
From on 2004-02-11 13:35:39
:
0.42 fails "make test" with repeated "undefined symbol: FT_Get_Postscript_Name" errors. 0.41 passes cleanly.
[Imager-0.42]$ IM_VERBOSE=1 perl Makefile.PL
Verbose mode
pathcheck
Include paths:
/sw/include
/usr/include/freetype2
/usr/local/include/freetype2
/usr/include
/usr/local/include
/usr/include/freetype
/usr/local/include/freetype
/sw/include doesnt exist or is unaccessible - removed.
/usr/local/include/freetype2 doesnt exist or is unaccessible - removed.
/usr/include/freetype doesnt exist or is unaccessible - removed.
/usr/local/include/freetype doesnt exist or is unaccessible - removed.
Library paths:
/usr/include/freetype2
/usr/include
/usr/local/include
/sw/lib doesnt exist or is unaccessible - removed.
done.
freetype2: includes found - libraries found
gif: includes found - libraries found
png: includes found - libraries found
jpeg: includes found - libraries found
ungif: includes found - libraries found
T1-fonts: includes not found - libraries not found
w32: includes not found - libraries not found
tiff: includes found - libraries found
TT-fonts: includes not found - libraries found
ungif and gif can not coexist - removing ungif support
You have libgif or libungif installed. They are both known to have
bugs. Imager can crash or display other strange behaviour after
reading or writing gif images. Some of the gif tests can even fail
since they stress some parts of the buggy code.
Do you want to remove gif support? [Y/n]
n
$VAR1 = {
'VERSION_FROM' => 'Imager.pm',
'DEFINE' => '-DIM_GIFMAJOR=4 -DIM_GIFMINOR=0 -DHAVE_FT2 -DHAVE_LIBGIF -DHAVE_LIBPNG -DHAVE_LIBJPEG -DHAVE_LIBTIFF -DIMAGER_LOG -DOS_linux ',
'OBJECT' => 'Imager.o draw.o polygon.o image.o io.o iolayer.o log.o gaussian.o conv.o pnm.o raw.o feat.o font.o filters.o dynaload.o stackmach.o datatypes.o regmach.o trans2.o quant.o error.o convert.o map.o tags.o palimg.o maskimg.o img16.o rotate.o bmp.o tga.o rgb.o color.o fills.o imgdouble.o freetyp2.o gif.o png.o jpeg.o tiff.o',
'ABSTRACT' => 'Perl extension for Generating 24 bit Images',
'LIBS' => ' -lm -L/usr/local/lib -L/lib -L/usr/lib -lfreetype -lgif -lpng -lz -ljpeg -ltiff',
'clean' => {
'FILES' => 'testout'
},
'NAME' => 'Imager',
'INC' => ' -I/usr/include/freetype2 -I/usr/local/include',
'AUTHOR' => 'Arnar M. Hrafnkelsson, [email protected]'
};
MakeMaker (v6.17)
Writing Makefile for Imager::plugins
Writing Makefile for Imager
[Imager-0.42]$ make test
make[1]: Entering directory `/home/edaly/Imager-0.42/dynfilt'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/edaly/Imager-0.42/dynfilt'
PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/t00basic........Can't load '/home/edaly/Imager-0.42/blib/arch/auto/Imager/Imager.so' for module Imager: /home/edaly/Imager-0.42/blib/arch/auto/Imager/Imager.so: undefined symbol: FT_Get_Postscript_Name at /usr/local/lib/perl5/5.8.1/i686-linux/DynaLoader.pm line 229.
at /usr/local/lib/perl5/5.8.1/i686-linux/DynaLoader.pm line 153
BEGIN failed--compilation aborted at /home/edaly/Imager-0.42/blib/lib/Imager.pm line 153.
Compilation failed in require at t/t00basic.t line 11.
BEGIN failed--compilation aborted at t/t00basic.t line 11.
t/t00basic........dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
[Imager-0.41]$ IM_VERBOSE=1 perl Makefile.PL
Verbose mode
pathcheck
Include paths:
/usr/include/freetype2
/usr/local/include/freetype2
/usr/include
/usr/local/include
/usr/include/freetype
/usr/local/include/freetype
/usr/local/include/freetype2 doesnt exist or is unaccessible - removed. /usr/include/freetype doesnt exist or is unaccessible - removed. /usr/local/include/freetype doesnt exist or is unaccessible - removed.
Library paths:
/usr/include/freetype2
/usr/include
/usr/local/include
done.
T1-fonts: includes not found - libraries not found
TT-fonts: includes not found - libraries found
png: includes found - libraries found
freetype2: includes found - libraries found
w32: includes not found - libraries not found
ungif: includes found - libraries found
tiff: includes found - libraries found
jpeg: includes found - libraries found
gif: includes found - libraries found
ungif and gif can not coexist - removing ungif support
You have libgif or libungif installed. They are both known to have
bugs. Imager can crash or display other strange behaviour after
reading or writing gif images. Some of the gif tests can even fail
since they stress some parts of the buggy code.
Do you want to remove gif support? [Y/n]
n
$VAR1 = {
'NAME' => 'Imager',
'AUTHOR' => 'Arnar M. Hrafnkelsson, [email protected]',
'INC' => ' -I/usr/include/freetype2 -I/usr/local/include',
'LIBS' => ' -lm -L/usr/local/lib -L/lib -L/usr/lib -lpng -lz -lfreetype -ltiff -ljpeg -lgif',
'DEFINE' => '-DIM_GIFMAJOR=4 -DIM_GIFMINOR=0 -DHAVE_LIBPNG -DHAVE_FT2 -DHAVE_LIBTIFF -DHAVE_LIBJPEG -DHAVE_LIBGIF -DIMAGER_LOG -DOS_linux ',
'OBJECT' => 'Imager.o draw.o polygon.o image.o io.o iolayer.o log.o gaussian.o conv.o pnm.o raw.o feat.o font.o filters.o dynaload.o stackmach.o datatypes.o regmach.o trans2.o quant.o error.o convert.o map.o tags.o palimg.o maskimg.o img16.o rotate.o bmp.o tga.o rgb.o color.o fills.o imgdouble.o png.o freetyp2.o tiff.o jpeg.o gif.o',
'clean' => {
'FILES' => 'testout'
},
'ABSTRACT' => 'Perl extension for Generating 24 bit Images',
'VERSION_FROM' => 'Imager.pm'
};
MakeMaker (v6.17)
Writing Makefile for Imager::plugins
Writing Makefile for Imager
[Imager-0.41]$ make test
make[1]: Entering directory `/home/edaly/.cpan/build/Imager-0.41/dynfilt'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/edaly/.cpan/build/Imager-0.41/dynfilt'
PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/t00basic........ok
t/t01introvert....ok
t/t020masked......ok
t/t021sixteen.....ok
t/t022double......ok
t/t05error........ok
t/t07iolayer......ok
t/t101jpeg........ok
t/t102png.........ok
t/t103raw.........ok
t/t104ppm.........ok
t/t105gif.........ok
t/t106tiff........ok
t/t107bmp.........ok
t/t108tga.........ok
t/t15color........ok
t/t16matrix.......ok
t/t20fill.........ok
t/t21draw.........ok
t/t30t1font.......ok
5/6 skipped: t1lib unavailable or disabled
t/t35ttfont.......ok
2/3 skipped:
t/t36oofont.......ok
6/7 skipped:
t/t37w32font......ok
3/4 skipped: not MS Windows
t/t38ft2font......ok
t/t40scale........ok
t/t50basicoo......ok
t/t55trans........ok
4/5 skipped:
t/t56postfix......ok
t/t57infix........ok
6/7 skipped: - no Parse::RecDescent
t/t58trans2.......ok
t/t59assem........ok
t/t60dyntest......ok
t/t61filters......ok
t/t64copyflip.....ok
t/t65crop.........ok
t/t66paste........ok
t/t67convert......ok
t/t68map..........ok
t/t69rubthru......ok
t/t70newgif.......ok
t/t75polyaa.......ok
t/t90cc...........ok
All tests successful, 26 subtests skipped.
Files=42, Tests=995, 14 wallclock secs (10.56 cusr + 3.11 csys = 13.67 CPU)
make[1]: Entering directory `/home/edaly/.cpan/build/Imager-0.41/dynfilt'
\/bin/sh -c true
No tests defined for Imager::plugins extension.
make[1]: Leaving directory `/home/edaly/.cpan/build/Imager-0.41/dynfilt'
$ uname -a
Linux www 2.4.9-e.37smp #1 SMP Mon Jan 26 10:53:54 EST 2004 i686 unknown
$ perl -v
This is perl, v5.8.1 built for i686-linux
From [email protected] on 2004-03-10 12:56:48
:
[guest - Wed Feb 11 08:35:39 2004]:
> 0.42 fails "make test" with repeated "undefined symbol:
> FT_Get_Postscript_Name" errors. 0.41 passes cleanly.
0.42 added a new method to retrieve the face name of a font.
I've only managed to reproduce the above undefined symbol error by using
an older version of freetype2 (2.0.4), which is only reasonable since
FT_Get_Postscript_Name was introduced in 2.0.5.
Are you using an older version of freetype2?
I've made some changes to freetyp2.c to attempt to detect older versions
and handle the missing function correctly, and changed the test code to
handle that, but if you aren't using an older version of freetype2 then
this problem will require more work.
Tony Cook
From [email protected] on 2004-03-18 23:55:14
:
I think RT treated my reply as a comment and didn't pass it on.
Hi,
This has been fixed in CVS, but hasn't been released in a new release
yet.
I've made the fixed freetyp2.c available at:
http://www.develop-help.com/freetyp2.c
for now.
Tony
[[email protected] - Thu Mar 18 12:11:07 2004]:
> FYI, Imager version 0.43 still fails with repeated
> "undefined symbol: FT_Get_Postscript_Name" errors when using
> freetype 2.0.3-7 under the RedHat Enterprise installation.
>
t1lib always creates a logfile [rt.cpan.org #369]
Migrated from rt.cpan.org#369 (status was 'resolved')
Requestors:
Attachments:
- [F:\SC\contiller\install\src\pm\Imag er-0.39\font.c.patch](https://rt.cpan.org/Ticket/Attachment/68415/1610/F:\SC\contiller\install\src\pm\Imag er-0.39\font.c.patch)
From on 2002-03-18 14:20:07
:
The attached patch removes LOGFILE from the init of t1lib, however the correct solution might be to let the user control the logfile. (However that is an API change and is up to you ;).
From [email protected] on 2002-03-19 00:22:17
:
I've made the log optional, defaulting to off.
If someone does want it they can call Imager::init():
Imager::init(t1log=>1);
Tony
Memory Fault with .40pre2 on HP/UX with wide TIFFs [rt.cpan.org #1207]
Migrated from rt.cpan.org#1207 (status was 'resolved')
Requestors:
Attachments:
From on 2002-06-28 19:50:42
:
I'm trying to crop a wide TIFF image generated from a HPGL image using hp2xx. The image is too wide for us, so we plan
to split it into two images using crop. This is a J16 size sheet. We have J24 and J32 that will be split into 3 and 4 sheets
respectively - we hope (-:
Am I misusing Imager, or is this a bug? Appreciate your help.
Glen
Using Perl 5.61. The script I'm running is:
---
#!/opt/perl5/bin/perl -w
use strict;
use Imager;
Imager::init(log=>"logfile.txt");
die "Usage: crop.pl filename\n" if !-f $ARGV[0];
my $file = shift;
my $img=Imager->new();
$img->read(file=>$file) or die "error on \"$file\": ".$img->{ERRSTR}."\n";
my $newimg = $img->crop(width=>50, height=>50);
$newimg->write(file=>"1_$file");
---
The logfile output is:
---
[2002/06/28 15:41:11] log.c:35 0: Imager - log started (level = 1)
[2002/06/28 15:41:11] Imager.xs:125 1: Imager 0.40pre2 starting
[2002/06/28 15:41:11] iolayer.c:980 1: io_new_fd(fd 4)
[2002/06/28 15:41:11] io.c:236 1: mymalloc(size 60) -> 401c0cc0
[2002/06/28 15:41:11] iolayer.c:992 1: (401c0cc0) <- io_new_fd
[2002/06/28 15:41:11] iolayer.c:828 1: io_glue_commit_types(ig 401c0cc0)
[2002/06/28 15:41:11] iolayer.c:829 1: io_glue_commit_types: source type 0 (FDSEEK)
[2002/06/28 15:41:11] tiff.c:327 1: i_readtiff_wiol(ig 401c0cc0, length -1)
[2002/06/28 15:41:11] tiff.c:118 1: i_readtiff_wiol: width=26408, height=10208, channels=1
[2002/06/28 15:41:11] tiff.c:119 1: i_readtiff_wiol: not tiled
[2002/06/28 15:41:11] tiff.c:120 1: i_readtiff_wiol: not byte swapped
[2002/06/28 15:41:11] image.c:352 1: i_img_empty_ch(*im 00000000, x 26408, y 10208, ch 1)
[2002/06/28 15:41:11] io.c:236 1: mymalloc(size 128) -> 40015a30
[2002/06/28 15:41:11] io.c:236 1: mymalloc(size 269572864) -> 401c1808
[2002/06/28 15:41:12] image.c:369 1: (40015a30) <- i_img_empty_ch
[2002/06/28 15:41:12] io.c:236 1: mymalloc(size 200) -> 400a5840
[2002/06/28 15:41:12] io.c:236 1: mymalloc(size 20) -> 401bec28
[2002/06/28 15:41:12] io.c:236 1: mymalloc(size 7) -> 40122830
[2002/06/28 15:41:12] io.c:236 1: mymalloc(size 4) -> 400686ac
[2002/06/28 15:41:12] io.c:236 1: mymalloc(size 7) -> 40122828
[2002/06/28 15:41:12] io.c:236 1: mymalloc(size 4) -> 400686a8
[2002/06/28 15:41:12] tiff.c:264 1: i_readtiff_wiol: rowsperstrip=-888414101
---
From [email protected] on 2002-06-29 15:45:55
:
Hey Glen,
I generated an image of that size and ran imager on it and it seemed to
work quite ok...
My guess is that the problem is either with the libtiff on the machine or
the thing that generates the images. Can you run tiffinfo on the file in
question and send me the output?
-- Arnar
On Fri, 28 Jun 2002, Guest via RT wrote:
>
>
> This message about Imager was sent to you by guest via rt.cpan.org
>
> Full context and any attached attachments can be found at:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=1207 >
>
> I'm trying to crop a wide TIFF image generated from a HPGL image using hp2xx. The image is too wide for us, so we plan
> to split it into two images using crop. This is a J16 size sheet. We have J24 and J32 that will be split into 3 and 4 sheets
> respectively - we hope (-:
>
> Am I misusing Imager, or is this a bug? Appreciate your help.
>
> Glen
>
>
>
> Using Perl 5.61. The script I'm running is:
> ---
> #!/opt/perl5/bin/perl -w
> use strict;
> use Imager;
> Imager::init(log=>"logfile.txt");
> die "Usage: crop.pl filename\n" if !-f $ARGV[0];
> my $file = shift;
> my $img=Imager->new();
> $img->read(file=>$file) or die "error on \"$file\": ".$img->{ERRSTR}."\n";
> my $newimg = $img->crop(width=>50, height=>50);
> $newimg->write(file=>"1_$file");
> ---
>
> The logfile output is:
> ---
> [2002/06/28 15:41:11] log.c:35 0: Imager - log started (level = 1)
> [2002/06/28 15:41:11] Imager.xs:125 1: Imager 0.40pre2 starting
> [2002/06/28 15:41:11] iolayer.c:980 1: io_new_fd(fd 4)
> [2002/06/28 15:41:11] io.c:236 1: mymalloc(size 60) -> 401c0cc0
> [2002/06/28 15:41:11] iolayer.c:992 1: (401c0cc0) <- io_new_fd
> [2002/06/28 15:41:11] iolayer.c:828 1: io_glue_commit_types(ig 401c0cc0)
> [2002/06/28 15:41:11] iolayer.c:829 1: io_glue_commit_types: source type 0 (FDSEEK)
> [2002/06/28 15:41:11] tiff.c:327 1: i_readtiff_wiol(ig 401c0cc0, length -1)
> [2002/06/28 15:41:11] tiff.c:118 1: i_readtiff_wiol: width=26408, height=10208, channels=1
> [2002/06/28 15:41:11] tiff.c:119 1: i_readtiff_wiol: not tiled
> [2002/06/28 15:41:11] tiff.c:120 1: i_readtiff_wiol: not byte swapped
> [2002/06/28 15:41:11] image.c:352 1: i_img_empty_ch(*im 00000000, x 26408, y 10208, ch 1)
> [2002/06/28 15:41:11] io.c:236 1: mymalloc(size 128) -> 40015a30
> [2002/06/28 15:41:11] io.c:236 1: mymalloc(size 269572864) -> 401c1808
> [2002/06/28 15:41:12] image.c:369 1: (40015a30) <- i_img_empty_ch
> [2002/06/28 15:41:12] io.c:236 1: mymalloc(size 200) -> 400a5840
> [2002/06/28 15:41:12] io.c:236 1: mymalloc(size 20) -> 401bec28
> [2002/06/28 15:41:12] io.c:236 1: mymalloc(size 7) -> 40122830
> [2002/06/28 15:41:12] io.c:236 1: mymalloc(size 4) -> 400686ac
> [2002/06/28 15:41:12] io.c:236 1: mymalloc(size 7) -> 40122828
> [2002/06/28 15:41:12] io.c:236 1: mymalloc(size 4) -> 400686a8
> [2002/06/28 15:41:12] tiff.c:264 1: i_readtiff_wiol: rowsperstrip=-888414101
> ---
>
Storging 1 channel gif images results in red images [rt.cpan.org #365]
Migrated from rt.cpan.org#365 (status was 'resolved')
Requestors:
From on 2002-03-17 06:24:53
:
When storing a 1 channel direct type image
the resulting image had zero GB components
but the R component is correct.
From [email protected] on 2002-03-25 11:59:56
:
I've gone through the quantization code and it now handles 1 channel
images when writing GIFs.
Added new tests, which I tried on an unmodified tree, which failed, and
successful after the changes. We now have 992 tests :)
warning produced by tifflib when reading an image are discarded [rt.cpan.org #8722]
Migrated from rt.cpan.org#8722 (status was 'resolved')
Requestors:
From [email protected] on 2004-12-03 13:42:52
:
as per subject.
convert() documentation needs an example of setting a channel to a given value [rt.cpan.org #8231]
Migrated from rt.cpan.org#8231 (status was 'resolved')
Requestors:
From [email protected] on 2004-11-04 00:16:53
:
Maybe presets should be added for setting given channels to different
values too (most useful for alpha)
From [email protected] on 2006-02-27 02:38:27
:
fixed in 0.47_01 and later
basic coordinate system needs a little more detail [rt.cpan.org #11429]
Migrated from rt.cpan.org#11429 (status was 'resolved')
Requestors:
From [email protected] on 2005-02-08 22:17:51
:
The basic co-ordinate system is documented in Imager::Draw, but
doesn't include information about the location of the origin or the
direction of the positive co-ordinates.
From [email protected] on 2006-07-24 12:11:01
:
added a note on the direction of co-ordinates, the origin was covered
well enough.
Will be in 0.52, I'll resolve this ticket when that is released.
From [email protected] on 2006-07-25 10:59:46
:
fixed in Imager 0.52
scaleX()/scaleY() documentation needs to be expanded [rt.cpan.org #11328]
Migrated from rt.cpan.org#11328 (status was 'resolved')
Requestors:
From [email protected] on 2005-02-01 23:19:16
:
Expand the scaleX() and scaleY() documentation, especially with some
examples.
some tests check ivsize when they should check intsize [rt.cpan.org #8645]
Migrated from rt.cpan.org#8645 (status was 'resolved')
Requestors:
From [email protected] on 2004-11-29 10:13:14
:
The t01introvert, t021sixteen, t022double, t023palette test files check
ivsize to check integer size rather than intsize. (it should be using
intsize)
Allow a background color to be set for the rotate() method. [rt.cpan.org #6140]
Migrated from rt.cpan.org#6140 (status was 'resolved')
Requestors:
From [email protected] on 2004-04-27 00:41:31
:
From a message on the imager-devel list:
In rotating an image by a couple of degrees, and then writing the
result out as a JPEG, the extra pixels around the edge of the new,
rotated image are set to black. I really need to be able to set them
to a custom background colour, and I'd rather not have to achieve this
by using a fountain fill.
From the structure of the code it shouldn't be too hard to add.
(mostly meant as a reminder to myself...)
install bug in Imager 0.41 on FreeBSD (see body for uname output) [rt.cpan.org #1476]
Migrated from rt.cpan.org#1476 (status was 'resolved')
Requestors:
From on 2002-08-27 17:59:34
:
uname -a output FreeBSD ripper.netorbit.com 4.6-STABLE FreeBSD 4.6-STABLE #0: Fri Aug 2 11:03:37 CDT 2002 [email protected]:/usr/obj/usr/src/sys/RIPPER i386
ripper# perl -v
This is perl, v5.6.1 built for i386-freebsd
Copyright 1987-2001, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
ripper#
make output as follows:
ripper# cd Imager-0.41
ripper# perl Makefile.PL
/usr/include/freetype2 doesnt exist or is unaccessible - removed.
done.
TT-fonts: includes found - libraries found
w32: includes not found - libraries not found
gif: includes found - libraries not found
jpeg: includes found - libraries found
freetype2: includes found - libraries found
tiff: includes found - libraries found
T1-fonts: includes found - libraries found
png: includes found - libraries found
ungif: includes found - libraries found
You have libgif or libungif installed. They are both known to have
bugs. Imager can crash or display other strange behaviour after
reading or writing gif images. Some of the gif tests can even fail
since they stress some parts of the buggy code.
Do you want to remove gif support? [Y/n]
Checking if your kit is complete...
Looks good
MakeMaker (v5.45)
Writing Makefile for Imager::plugins
Writing Makefile for Imager
ripper# make
cp lib/Imager/Draw.pod blib/lib/Imager/Draw.pod
cp lib/Imager/Font.pm blib/lib/Imager/Font.pm
cp lib/Imager/Files.pod blib/lib/Imager/Files.pod
cp lib/Imager/Filters.pod blib/lib/Imager/Filters.pod
cp lib/Imager/Font/FreeType2.pm blib/lib/Imager/Font/FreeType2.pm
cp lib/Imager/Transformations.pod blib/lib/Imager/Transformations.pod
cp lib/Imager/Font/Type1.pm blib/lib/Imager/Font/Type1.pm
cp lib/Imager/Expr/Assem.pm blib/lib/Imager/Expr/Assem.pm
cp lib/Imager/Font/Win32.pm blib/lib/Imager/Font/Win32.pm
cp lib/Imager/regmach.pod blib/lib/Imager/regmach.pod
cp lib/Imager/Color.pm blib/lib/Imager/Color.pm
cp lib/Imager/Color/Float.pm blib/lib/Imager/Color/Float.pm
cp lib/Imager/ImageTypes.pod blib/lib/Imager/ImageTypes.pod
cp lib/Imager/Matrix2d.pm blib/lib/Imager/Matrix2d.pm
cp lib/Imager/Expr.pm blib/lib/Imager/Expr.pm
cp lib/Imager/Fill.pm blib/lib/Imager/Fill.pm
cp lib/Imager/Transform.pm blib/lib/Imager/Transform.pm
cp lib/Imager/Regops.pm blib/lib/Imager/Regops.pm
cp lib/Imager/Font/Truetype.pm blib/lib/Imager/Font/Truetype.pm
cp lib/Imager/Engines.pod blib/lib/Imager/Engines.pod
cp lib/Imager/Fountain.pm blib/lib/Imager/Fountain.pm
cp lib/Imager/interface.pod blib/lib/Imager/interface.pod
cp Imager.pm blib/lib/Imager.pm
/usr/bin/perl -I/usr/local/lib/perl5/5.6.1/i386-freebsd -I/usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/5.6.1/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap -typemap typemap Imager.xs > Imager.xsc && mv Imager.xsc Imager.c
cc -c -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/include/freetype -I/usr/local/include/freetype -fno-strict-aliasing -I/usr/local/include -O -DVERSION=\"0.41\" -DXS_VERSION=\"0.41\" -DPIC -fpic -I/usr/local/lib/perl5/5.6.1/i386-freebsd/CORE -DHAVE_LIBTT -DHAVE_LIBJPEG -DHAVE_FT2 -DHAVE_LIBTIFF -DHAVE_LIBT1 -DHAVE_LIBPNG -DIMAGER_LOG -DOS_freebsd Imager.c
In file included from Imager.xs:12:
image.h:263: syntax error before `TT_Instance'
image.h:275: syntax error before `TT_Face'
image.h:278: syntax error before `TT_CharMap'
*** Error code 1
Stop in /usr/src/Imager-0.41.
ripper#
From [email protected] on 2002-11-15 00:30:03
:
Current CVS moves everything but a structure declaration for the FT1
types into font.c where it belongs.
If you have access to Imager CVS (see
http://www.eecs.umich.edu/~addi/perl/Imager/devel/) could you please see
if that solves the problem?
If not, please let me know and I'll create a distribution for you to
test with.
Thanks
Tony Cook
crop() documentation says width/height takes precedence, but is unclear [rt.cpan.org #7581]
Migrated from rt.cpan.org#7581 (status was 'resolved')
Requestors:
From [email protected] on 2004-09-08 15:24:35
:
The handling of left/right/width and top/bottom/height parameters
and how they relate to each other is badly documented and probably
buggy for crop().
From [email protected] on 2004-09-11 14:59:02
:
crop() doesn't seem to range check it's arguments either - so right can
be bigger than the image width and so on.
From [email protected] on 2004-09-27 00:55:03
:
Fixed in local CVS for the next release.
paste() method should allow you to specify the width/height of the source [rt.cpan.org #11858]
Migrated from rt.cpan.org#11858 (status was 'resolved')
Requestors:
From [email protected] on 2005-03-13 22:51:49
:
as per subject
The underlying i_copyto() function supports this, but always supplies
the width/height of the image.
From [email protected] on 2006-01-24 01:00:07
:
Fixed in 0.48, I'll close this when I release it.
Imager leaks memory somehow [rt.cpan.org #197]
Migrated from rt.cpan.org#197 (status was 'resolved')
Requestors:
Attachments:
From on 2002-01-24 04:42:50
:
Imager runs out of memory over time. Might be a
GC problem or related to freetype.
From [email protected] on 2002-04-21 05:08:26
:
This bug was fixed in 0.40. The font cache was not properly freeing
all resources.
read() method attempts to call format read functions without checking the format is supported [rt.cpan.org #9618]
Migrated from rt.cpan.org#9618 (status was 'resolved')
Requestors:
From [email protected] on 2005-01-11 11:36:55
:
For example, if Imager is built without JPEG support and you do:
$im->read(file=>'somejpeg.jpg')
the Imager crashes since it can't find i_readjpeg_wiol().
It's possible write() has the same problem.
compare in Imager::Color [rt.cpan.org #2238]
Migrated from rt.cpan.org#2238 (status was 'resolved')
Requestors:
From [email protected] on 2003-03-16 21:44:00
:
Currently, you have to manually compare colors by comparing the
output of the rgba method of two colors. It would be nice if you
could just do $c1->compare ($c2); and probably
$c1->compare ($c2, ignore_aa => 1); too
From [email protected] on 2004-09-05 10:05:49
:
I've added an equals() method to the Imager::Color class.
This hasn't been released yet, and it only in CVS currently.
Imager-0.41 5.8.0 test segfault in tga test [rt.cpan.org #1388]
Migrated from rt.cpan.org#1388 (status was 'resolved')
Requestors:
From on 2002-08-04 06:32:51
:
Hi, the t/t108tga.t test generates a segfault for me using 5.8.0. It
works fine under 5.6.1 so I'm not sure what you're tickling.
Here's a stack trace, output of perl-v attached:
Starting program: /usr/local/perl5.8.0-g/bin/perl -Mblib t/t108tga.t
1..16
ok 1
ok 2
ok 3
ok 4
not ok 5 #
not ok 6 #
not ok 7 #
not ok 8 #
not ok 9 #
not ok 10 #
ok 11
not ok 12 # Targa Image has none of 15/16/24/32 pixel layout: could
not read targa colourmap
not ok 13 # Targa Image has none of 15/16/24/32 pixel layout: could
not read targa colourmap
not ok 14 # could not read targa colourmap: could not read targa
colourmap
Program received signal SIGSEGV, Segmentation fault.
0x0fe36e18 in free () from /lib/libc.so.6
(gdb) bt
#0 0x0fe36e18 in free () from /lib/libc.so.6
#1 0x0fe3766c in realloc () from /lib/libc.so.6
#2 0x0fe37104 in realloc () from /lib/libc.so.6
#3 0x1006c3c0 in Perl_safesysrealloc (where=0x1035fdf0, size=26) at util.c:122
#4 0x10089f10 in Perl_sv_grow (sv=0x1017c8bc, newlen=26) at sv.c:1580
#5 0x1009a7fc in Perl_sv_catpvn_flags (dsv=0x1017c8bc,
sstr=0x1019bf10 "3553974", slen=7, flags=271997336) at sv.c:4270
#6 0x1007fcb0 in Perl_pp_concat () at pp_hot.c:187
#7 0x1006b624 in Perl_runops_debug () at dump.c:1398
#8 0x100176ec in S_run_body (oldscope=1) at perl.c:1681
#9 0x100172a0 in perl_run (my_perl=0xfeedcc0) at perl.c:1600
#10 0x10014174 in main (argc=3, argv=0x7ffff884, env=0x10365998) at perlmain.c:85
#11 0x0fddac30 in __libc_start_main () from /lib/libc.so.6
From [email protected] on 2002-08-05 06:48:57
:
I couldn't reproduce this with current CVS.
The original reporter could try to set IM_DEBUG_MALLOC and see if that
catches anything.
Given the stack trace it could be anything from an out of bounds write
to a double-free, in either perl or Imager. IM_DEBUG_MALLOC would give
us some idea which.
Tony
From [email protected] on 2002-11-15 00:02:39
:
[guest - Sun Aug 4 02:32:51 2002]:
> Hi, the t/t108tga.t test generates a segfault for me using 5.8.0. It
> works fine under 5.6.1 so I'm not sure what you're tickling.
I can't reproduce this with 5.8.0 built under Debian 3.0 with Imager
0.41 either.
The original report mentioned perl-v (hopefully -V) information, but
didn't include it. Is it available?
From [email protected] on 2004-09-29 04:19:55
:
given the failures in the write tests (and the types of failures in the
read tests) I wonder if the user ran out of disk space.
From [email protected] on 2005-06-24 03:35:39
:
Could not reproduce.
Fax images inverted [rt.cpan.org #1340]
Migrated from rt.cpan.org#1340 (status was 'resolved')
Requestors:
From on 2002-07-26 17:15:41
:
It seems that for CCITT Fax there is an implied photometric interpretation
so for fax images that needs to be reversed.
From [email protected] on 2005-06-08 02:07:08
:
Local tests with fax images couldn't reproduce this. Closing it.
No test images were supplied with the report.
test t70newgif.t locks up under cygwin [rt.cpan.org #7950]
Migrated from rt.cpan.org#7950 (status was 'resolved')
Requestors:
From [email protected] on 2004-10-11 03:45:56
:
When running tests t70newgif.t locks up immediately after running test
20.
From adding debug code this seems to happen in the call to mymalloc()
at the beginning of the io_new_cb() XS code.
Using IM_DEBUG_MALLOC makes no difference.
Imager bug w32 Font bounding box [rt.cpan.org #3093]
Migrated from rt.cpan.org#3093 (status was 'resolved')
Requestors:
From on 2003-07-29 21:45:38
:
Using Imager v.041 (which I think it's awesome)
perl, v5.6.1 built for MSWin32-x86-multi-thread
Binary build 635 provided by ActiveState Corp. http://www.ActiveState.com
My box: Win 2000 Professional Edition
Got an error using the bounding box function, I got this error:
Undefined subroutine &Imager::Font::Win32::i_wf_bbox called at C:/Perl/site/lib/Imager/Font/Win32.pm line 18, line 213.
My Code:
--------------------
use strict;
use Imager;
use Imager ':handy';
my $font1 = NF(face => 'Arial Bold Italic', size=> 15);
my @bbox_data = $font1->bounding_box(string=>"Hello",size=>15);
--------------------
I *humbly* modified the Font/Win32.pm module to the following and seems to be working...
sub _bounding_box {
my ($self, %opts) = @_;
return Imager::i_wf_bbox($self->{face}, $opts{size}, $opts{string});
#my @bbox = i_wf_bbox($self->{face}, $opts{size}, $opts{string});
}
Thanks for Imager!
From [email protected] on 2003-07-30 01:28:31
:
[guest - Tue Jul 29 17:45:38 2003]:
> I *humbly* modified the Font/Win32.pm module to the following and
> seems to be working...
> sub _bounding_box {
> my ($self, %opts) = @_;
> return Imager::i_wf_bbox($self->{face}, $opts{size}, $opts{string});
> #my @bbox = i_wf_bbox($self->{face}, $opts{size}, $opts{string});
> }
Thanks for reporting this.
This problem has been reported before and fixed in current CVS.
Tony
From [email protected] on 2004-09-10 02:15:34
:
On Thu, Sep 09, 2004 at 08:04:41PM -0400, Guest via RT wrote:
>
> This message about Imager was sent to you by guest <> via rt.cpan.org
>
> Full context and any attached attachments can be found at:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=7602 >
>
> Hey Arnar,
>
> This may actually be a bug in xsubpp. I don't know XS well enough to know.
>
> During the compilation process Imager.xsc is created with a "c" syntax error that causes gcc to abort.
>
> It appears that when xsubpp converts Imager.xs to Imager.xsc it converts the line "int rc, i;" in the "i_wf_bbox" function (in Imager.xs) to "int rc,;" (in Imager.xsc). This obviously is wrong and causes gcc to die.
Actually, this is a bug in Imager.xs, since the declaration is in the
arguments area of the function rather then the PREINIT clause.
Changing the definition of i_wf_bbox() to:
void
i_wf_bbox(face, size, text)
char *face
int size
char *text
PREINIT:
int cords[BOUNDING_BOX_COUNT];
int rc, i;
PPCODE:
if (rc = i_wf_bbox(face, size, text, strlen(text), cords)) {
EXTEND(SP, rc);
for (i = 0; i < rc; ++i)
PUSHs(sv_2mortal(newSViv(cords[i])));
}
fixes the problem.
This was fixed in CVS in July, along with some other windows platform
bugs.
Hopefully there will be a new release soon, since there are a few bugs
fixed in CVS.
Tony
i_readbmp_wiol() ignores offbits it reads from bmp file [rt.cpan.org #8311]
Migrated from rt.cpan.org#8311 (status was 'resolved')
Requestors:
From [email protected] on 2004-11-09 04:12:43
:
i_readbmp_wiol() reads offbits (the offset to the start of image data)
but doesn't use the value
From [email protected] on 2004-11-19 02:13:19
:
[TONYC - Sun Nov 14 08:26:31 2004]:
> the bmp reader reads but ignores the dwImageOffset from the file header.
not dwImageOffset, the bfOffBits (called offbits in bmp.c)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.