I'm a not so active contributer to the Cairo Graphics Library. Cairo has alot of support in the GTK opensource community. Its not perfect, but it does most of the basic things that people need. Off the top of my head, Here is a summary of the most popular Cairo capabilities: 1) Support for multiple output devices, such as X Window System, Win32, image buffers, and PostScript, PDF, SVG, OpenGL, glitz, Quartz, and XCB. 2) Produces consistent output on all output media, taking advantage of display hardware acceleration when available. 3) Drawing operations such as: A) stroking and filling B) cubic Bézier splines C) transforming and compositing translucent images D) antialiased text rendering. E) antialiased line rendering E) Drawing operations can be transformed by any affine transformation (scale, rotation, shear, etc.)
From my perspective, the disadvantage of Cairo is that it is a typical 'C' library. While it true that many language wrappers have been written for Cairo, it will always be at its core a 'C' library.
A graphics library that was designed from the start to be a modern C++ library, that has an interface that is similar to STL is very appealing to me, such as what GIL does. Unfortunately, its probably fair to say that most graphics developers already using their own favorite graphics library. While some of these graphics libraries are forced upon the developer, such as if your using the Qt or KDE frameworks, it seems to me that easy integration with these other graphics libraries will probably be paramount to GIL's success. Any thoughts on how GIL will integrate with these other graphics libraries? Tom Brinkman