Over the last week I:
I also started work on Imager::Graph, the base class of a set of modules meant for creating graphs of various types, starting with pie graphs.
The aim is to have Imager::Graph abstract the way the graphs look, colors, font sizes, positioning, element sizes and so on. All of this can be customized by the user, but they can get good results quickly. Since the basic looks are all controlled by Imager::Graph, Imager::Graph::Bar can use those same styles, to produce a graph that matches the pie chart produced by Imager::Graph::Pie.
I fixed a couple of bugs over the last few days.
Writing text with the tt (Freetype 1.x) driver would give chop off the left of the first character if it overlapped the left of the start of the text output, and the widths of the bounding box pre-added the the left overlap - breaking the bounding box calculations.
The C level code to write jpeg images wasn't doing any error reporting, now it does.
Next I'm going to do something I really <sarcasm>love</sarcasm> - modify the GIF writer to handle paletted images. Currently if you pass a paletted image to the GIF writer it tries to build a palette and re-quantize the image. This is very, very slow.
I finally finished adding combining fills.
Except for the two basic cases, 'none', which simply replaces the target, and 'normal', which uses the alpha channel to weight the fill, I suspect they're mostly useful for special effects.
For example, if you wanted to turn an image into a rainbow, preserving the brightness, you could use the 'color' mode, which replaces the hue and saturation of the target pixel with that of the fill pixel.
I'll put a demo up soon.
So I implemented hatched fills.
Rather than just implementing hatched versions of the current i_box_filled() and i_arc() functions I created a new Imager object - a fill object. These can currently be used with arcs, boxes and the flood fill, which Addi had implemented, but hadn't written an OO interface for.
So now we have hatched fills, I also added a solid fill object (which could merge alpha values), and took the fountain fill code to build a fountain fill. So now you can flood fill with a fountain (or gradient) fill
Today I realized the combine option could have been more powerful - currently it's just a flag, either to replace the current color, or to do basic alpha merging. When I get time (soon, I hope), I'll implement some of the types of merging you get from software like the GIMP, such as addition, hue only, value only, and so on.
Over the weekend I managed to implement most of the fountain (or gradient) fill code I wanted. So I wanted to be able to load GIMP Gradient files - and found a bunch of new features I'd have to add to support them. So I will. Eventually.
Last night I was trying to get my filters example page to work with JPEG files instead of PNG files - and bumped into a few JPEG bugs. First was a screwup left over from the exp_represent merge - the code to call i_writejpeg() had migrated up into Imager::read()! D'oh!
Second was a problem in the IO layer translation code, now fixed.
Now I just need to figure out why the transform2 demo isn't working. <sigh>
I started adding support for working with Windows BMP files, writing was easy enough (since I haven't bothered with compression - yet), but the reading is proving a pain, since I think (de)compression is needed. Maybe I'm just lazy.
One thing I'm used to from The GIMP and other paint software is fountain fills. Currently the closest Imager has to that is Addi's gradient filter, which is very different to a normal fountain fill. My only problem with trying to write fountain fill code is that my math is a bit rusty.
I just need to kick those brain cells into submission, I suppose.
I finally got around to merging the Imager exp_represent branch with the main branch. The only problem was some files that had large modifications in both branches - CVS well and truly messed them up, only to be expected I suppose. I hand merged them, fixed up the test numbers that has been broken by the merge, since new tests had been added on both branches, and it all worked.
I've discussed adding some sample code to the distribution with Addi, since Imager is getting pretty difficult for a new user to get their mind around.
So I started working based on a simple text to image to web application I wrote as a basic demo. Unfortunately it had several problems with handling fonts that have negative left-side bearings on the first character (where the left size of the glyph is to the left of the start point.) Found and fixed for freetyp2.c. Just need to figure out the clipping problems in the Freetype 1.x support code.
Now you can set the resolution of a TIFF image:
I finally got around to fixing writing text to a channel with freetype2. Then I added UTF8 support.
Back in May Mike Depot suggested that the Imager::Color class was inconsistent with the other Imager classes since it didn't take named parameters. I finally got around to fixing that. You can now use named parameters to do things that you had to write your own code for with Image: