<div>Hi Antony,<br> <br></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.</blockquote>
<div><br>Jefferson Heard is working on such a thing, called Hieroglyph. Lately I've been helping him simplify the design and shift it toward a clear, composable semantic basis, i.e. "genuinely functional" (as in the Fruit paper), meaning that it can be understood & reasoned about in precise terms via model that is much simpler than IO.<br>
<br>In the process, I realized more clearly that the *very goal* of making a purely functional wrapper around an imperative library leads to muddled thinking. It's easy to hide the IO without really eliminating it from the semantics, especially if the goal is defined in terms of an IO-based library. Much harder, and I think much more rewarding, is to design semantically, from the ground up, and then figure out how to implement the elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU architectures, ...).<br>
<br>Regards,<br><br> - Conal<br></div><br><div class="gmail_quote">On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney <span dir="ltr"><<a href="mailto:antony.courtney@gmail.com" target="_blank">antony.courtney@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan <<a href="mailto:bos@serpentine.com" target="_blank">bos@serpentine.com</a>> wrote:<br>
> On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney <<a href="mailto:antony.courtney@gmail.com" target="_blank">antony.courtney@gmail.com</a>><br>
> wrote:<br>
>><br>
>> A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or<br>
>> GDI+ on Windows ) supports things like computing tight bounding<br>
>> rectangles for arbitrary shapes, hit testing for determining whether a<br>
>> point is inside or outside a shape and constructive area geometry for<br>
>> shape compositing and clipping without dropping down to a raster<br>
>> representation.<br>
><br>
> These are the kinds of capabilities provided by Cairo, which is very<br>
> pleasant to use (PDF-style imaging model) and quite portable. There are<br>
> already Cairo bindings provided by gtk2hs, too.<br>
><br>
<br>
</div></div>Hi Bryan,<br>
<br>
Nice to hear from you! Been a while...<br>
<br>
Just had a quick look and it does indeed appear that Cairo now<br>
supports some of the features I mention above (bounds calculations and<br>
hit testing). Cairo has clearly come a long way from when I was last<br>
working on Fruit and Haven in 2003/2004; back then it looked like it<br>
only provided a way to render or rasterize vector graphics on to<br>
bitmap surfaces and not much else.<br>
<br>
It's not clear to me if the Cairo API in its current form supports<br>
vector-level clipping or constructive area geometry, and it looks like<br>
the API is still pretty render-centric (e.g. is it possible to obtain<br>
the vector representation of rendering text in a particular font?).<br>
That might make it challenging to use Cairo for something like the<br>
Haven API, but maybe one can live without that level of generality.<br>
<br>
In any case: delighted to see progress on this front! Hopefully some<br>
enterprising Haskell hacker will wrap Cairo in a nice purely<br>
functional API.<br>
<div><div></div><div><br>
-Antony<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>