I'm considering splitting out Imager's file support for those file types that require external libraries, in particular:
Possibly also the font file handlers:
Unlike the current Imager package these would fail to install unless the appropriate library could be found (or built), so your code could depend on Imager::File::GIF and be sure that GIF support was available, which isn't currently the case.
I'd produce file format distributions such as Imager-File-GIF at least six months before removing them from Imager itself. Installing such distributions would add (for example) GIF support to Imager if it wasn't already present, or be ignored if it was.
I'd also release Task::Imager which would depend on Imager and each of the file format support distributions needed to match the Imager
(I suspect this is going to be more painful for packagers than anyone else.)
Imager's tiff support has been greatly extended to:
This is a large change, so I've released Imager 0.61_02 as a test release. If you use Imager with TIFF much, please give it a go.
I'm planning on a 0.62 release in a week or so.
Imager 0.57 is a security fix release.
Unfortunately Imager failed on some of the test images.
Imager 0.57 corrects this.
A new Imager development release 0.51_02 is now on CPAN.
This adds Windows Icon/Cursor file support, an interface for adding new file types, a new variant of flood_fill that fills to a given border color and the usual collection of other tweaks.
Please give it a go if you have a chance.
Something fairly similar to it will be released as 0.52 unless I see some problems reported.
Imager has been released, it fixes a few bugs.
For now work is keeping me busy, so the next feature release (file hooks, ICO support, Changes changed) is delayed for now.
I uploaded Imager 0.47_01 to CPAN last week as a pre-release to 0.48.
Imager 0.48 adds the API I mentioned last month, some other minor features and fixes.
If you get a chance to test it please let me know of any problems. If you're using the CPAN shell you can use:
Over Christmas I made most of Imager's API, such as it is, available to external modules.
This has 2 purposes:
I added a hook for Inline::C as well, which makes the API very easy to use, assuming C doesn't scare you too much.
Of course, none of this is released yet, but what's there hangs together.
Currently some of the API isn't exposed - file access, because it's not an image manipulation function, and fonts, because the C level font API is fairly chaotic.
Imager's release cycle has tended to be pretty long, but hopefully I'll get this out in the next few weeks.
Right now I'm going through the file handlers and checking they report errors correctly - in some cases the C level handlers do, but the perl level code is discarding the error <sigh>
I've uploaded a release candidate for Imager 0.46 to CPAN.
If you use Imager, please take the time to test it out, using CPAN shell this would be:
perl -MCPAN -eshell
The major changes in Imager 0.46 include:
A release candidate for Imager 0.45 is now on CPAN, though it may take a little while to get to some mirrors.
If you have time please try to run the test suite, the simplest way to do that is with the CPAN shell, if you've configured it:
perl -MCPAN -eshell
If you see test failures on OS X 10.4 in t/t20fill.t, please send me a copy of the generated fills.o and the result of:
then try running:
and attempting to build/test Imager again. You can do:
to return to the default gcc 4.0 pre-release.
At this point I'm ready to put out a test release of Imager 0.45, but... 0.44 is failing tests under OS X 10.4.
For a short time I had access to a 10.4 machine, and found that the pre-release of GCC 4.0 that Apple shipped with Tiger was generating incorrect code. When I build the released GCC 4.0 under OS X 10.3.9, and use that to build Imager, all tests pass.
To see the code in question, build Imager and run:
otool -vt fills.o | less +/^_fill_hatch # on OS X
At this point I'm wondering how to handle this.
At the moment I'm inclined to go with the first option, but all the solutions have their problems.