GraphicsMagick Draw Functions #1

merged 21 commits into from Dec 17, 2014

2 participants


I've added bindings for a pretty large subset of the draw api.

At the moment, I haven't written the path functions, most push/pop operations, and the get part of most of the get/set functions.

Example usage would be something like

withDrawContext myImg (drawSetStrokeColor r g b o >=> drawLine 10 10 30 10)

And the type of withDrawContext is

withDrawContext :: HImage -> (Ptr DrawContext -> IO (Ptr DrawContext)) -> HImage

Hi ricee,

Thank you for implementing the Draw API !

I will have a look and test/play with it a little bit. Then, I will issue a new release quite soon (~1wk) to have this api in the hackage package.

I am also wondering, for a more long term perspective, if it is not better to have one submodule per ImageMagick categories like: API categories

This will break compatibility, but for the good (as the recent switch to ForeignPtr) and require a Major version update and a transition documentation.
I would like to ask you what you think on this direction, since you obviously use and know hsmagick internals ?

I will keep you updated through this pull request of the integration of the draw API.

Thanks again,


@vincentg vincentg closed this Aug 17, 2011
@vincentg vincentg reopened this Aug 17, 2011
@vincentg vincentg was assigned Aug 17, 2011

Hi vincentg,

Separating some or all of the categories definitely crossed my mind. The draw api added a somewhat large chunk of functions to the module, and there's still a lot more left if, say, the path part of the draw api ever gets added. Now might be a good time to separate some of it so that it has room to grow without getting too cluttered. If it does get split, do you think it ought to adhere to the GraphicsMagick categories, or should some of the smaller ones be grouped together to cut down on the number of imports?

For the draw API functions, I've tried to stick as close as possible to the C api, but I've been wondering whether functions that work on points wouldn't be better as (Double,Double) rather than Double->Double. I guess it's mostly an aesthetic change, but I'm debating with myself whether it would be preferable from a clarity standpoint.


@vincentg vincentg merged commit a6ab752 into vincentg:master Dec 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment