Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of tonyc (123)

Sunday September 20, 2009
10:25 PM

Imager file format modules

[ #39652 ]

I'm considering splitting out Imager's file support for those file types that require external libraries, in particular:

  • GIF
  • TIFF
  • JPEG
  • PNG

Possibly also the font file handlers:

  • Freetype 1.x
  • Freetype 2.x
  • T1Lib
  • Win32

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

This allows:

  • just depend on Imager::Task to get the same file formats you get now (possibly some more)
  • depend on Imager::File::Foo to get the format you want and be sure they're present

Reactions?

(I suspect this is going to be more painful for packagers than anyone else.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It would make our life simpler, we've been caught out in the past because we installed Imager but didn't actually validate we could produce an image of a particular type when the code actually ran.

    • Likewise, I've been caught out by missing libraries. Not a big problem for me, but providing specific plugins would make it a little easier to confirm what support is actually available.

  • It would be great if the Imager::File::* modules could build a private copy of the required libraries in the module directory, similar to Alien::Zlib [cpan.org]. This would really simplify installation, especially for users without root access.
    • As a mechanism, I'd probably have it depend on Alien::libgif (for example) which could then could either detect or build libgif.

      My main problem with the typical Alien:: module is that it installs the module from source rather than as a native package for the current system, which means if the vendor releases any security updates Imager (or whatever) will still be using vulnerable libraries.

      One option could be to have Alien::libgif realize it was on a Debian system and then depend on say Alien::Debian::libgi

      • The purpose of Alien:: is to not necessarily to install it from source.

        It's job is to ENSURE that it is on the system, and provide access to information about the installed version.

        You can quite reasonably have the regular Alien::libgif install from Debian if you want, or use the existing installed one, as long as it still compiles as a last resort, and it returns the information about the installed module.