wide thoughts

Just looked at search terms leading people to my blog and found a few of “wideimage problem php”. Just to let you know, there are several support channels available if you get stuck using the library or find a bug. So, please, don’t let me guess what your problems are.

It’s friday evening and I’ve just released a new version of WideImage. I’m such a geek.

I’ve just released it. You can download it here. Optionally, you can use the 1.0-beta-2 svn tag.

This is the last release before RC1, which is coming soon (Q1 2009 expected). The main purpose for this release is stabilization, new unit tests, bug fixes, and some features. The online documentation is left behind (mostly still for beta 1), but no major API changes were made. The inline docs hold a more up-to-date documentation.

Magic dimensions
WideImage now supports an extended notation of dimensions for some operations (resize, crop, merge, …). The possible uses are:

• integer/float – literal value is taken for coordinate
• percent string – the coordinate in percent of the dimension
• center-relative coordinate – specify the coordinate relative to center, rather than absolute

Examples:

// crops a 50x40 rectangle, starting at 10, 20
$cropped = $img->crop(10, 20, 50, 40);

// crops a 50% (half of the width) x20 rectangle,
//   starting at 0, 20% (20% of the height)
$cropped = $img->crop(0, '20%', '50%', 20);

// crops a 100x50 rectangle directly
//   in the middle of the image (center-relative coordinates are used)
$cropped = $img->crop('c-50', 'c-25', 100, 50);

These “magic dimensions” will acquire a less silly name (smart coordinates) in RC1, and will be developed further.

Loading from files without extension/mime-type
Is now supported. That’s it . I’ve decided to use imagecreatefromstring(file_get_contents($filename)), so now the image format is detected automatically. No more format or mime-type hinting is necessary. The other side-effect is that now WideImage suddenly supports all GD2-supported formats for reading. For writing, it’s still GIF, JPEG, PNG, GD, GD2. BMP is scheduled for RC1, but may end up in RC2.

Other stuff

• AutoCrop — See demos in the package for details.
• PS font support added
• Canvas magic supported: the Canvas object now supports all functions that start with “image”, and you don’t have to pass an image handle to it.

  For example, to draw a red line:

  // you had to do this:
  imageline($image->getHandle(), 0, 0, 50, 50, $image->allocateColor(255, 0, 0));
  // now you can do this:
  $canvas = $image->getCanvas();
  $canvas->line(0, 0, 50, 50, $image->allocateColor(255, 0, 0));
  

  At first, it may not seem much, and maybe it isn’t. But at least I can say that Canvas supports custom drawing.

All in all, this is not a feature release. If you’re annoyed by bugs in beta1, or are looking forward to try AutoCrop, then upgrade, otherwise it’s not really necessary.

I’ve been thinking a lot about this, and I’ve decided that I’ll change the class/file naming pattern in WideImage RC1 at the cost of breaking BC. There are two reasons for that: standardization and namespaces.

While I’m not really fond of PEAR-like naming (I prefer class names short and neat), it’s the current unofficial standard for user-base packages. Plus, class names can only be short and pretty if you can ensure you’ll have no class-name collisions. This means that only classes that are very specific (i.e. DirectoryIterator), or end-user can have such names, not the ones that come with libraries, or are introduced in the language itself when it’s already mature (PHP’s Date class collision, hint hint).

The other upside to this change is that it’s namespace-ready. When PHP 5.3 will be installed by most hosts, packages will start making a move towards the use of namespaces, and WideImage will be no exception. Changing the naming scheme now ensures that the users will have time to adopt the new scheme and will not have much trouble when the change towards namespaces is made.

Along with this change I’ll also drop support for autoloaders in WideImage. Autoloading is a great feature, but isn’t the right tool to use here, and caused a few problems when the library was embedded within some other project that already had autoloaders. So, the files will be included directly from WideImage.php, which shouldn’t cause much of an overhead, since the number of files is rather small.

Hopefully, I’ll also manage to put all this into a PEAR package, although for now not through the official PEAR repository. I believe these changes will make it easier for the developers to install and use this library. The price will be quite high, because backwards-compatibility will be broken by these changes, but it’s better now than never.

When are the changes expected? I’ll soon publish a beta2 version of the library, which will still have the old scheme, but will also create a RC1 branch in which I’ll make the changes. Both releases are scheduled in Q1 2009, which means quite soon.