[cairo] Cairo and ISO C++
behdad at behdad.org
Wed Jan 1 20:09:40 PST 2014
The abstractions definitely look interesting, specially the color space stuff.
I'm sure I'm not the only person who would appreciate seeing the code, if you
are releasing it under an Open Source license.
On 14-01-01 11:06 PM, Maximilian Heinzler wrote:
> I'm currently working on a similar image library. It's not just a C++ version of cairo but also does a little redesign of some methods and is written in the style of the standard libraries as far it is possible. Later it should also be able to read and write many different image file formats.
> The attached example code I just created shows a little bit of its usage and its png output.
>> -----Original Message-----
>> From: cairo-bounces at cairographics.org [mailto:cairo-
>> bounces at cairographics.org] On Behalf Of Behdad Esfahbod
>> Sent: Wednesday, January 01, 2014 10:57 AM
>> To: Herb Sutter; cairo at cairographics.org
>> Cc: 'jason zink'
>> Subject: Re: [cairo] Cairo and ISO C++
>> On 14-01-01 10:23 AM, Herb Sutter wrote:
>>> Hi, my name is Herb Sutter and I chair the ISO C++ standards
>>> committee. Behdad referred me to this list as the right place to raise this
>>> We are actively looking at the potential standardization of a basic 2D
>>> drawing library for ISO C++, and would like to base it on (or outright
>>> adopt, possibly as a binding) solid prior art in the form of an
>>> existing library. You can find a quick summary of goals and discussions to
>> date in these two papers:
>>> · http://isocpp.org/files/papers/n3791.html
>>> · http://isocpp.org/files/papers/N3825.pdf
>>> As noted in the latter paper, we are currently investigating the
>>> direction of proposing a mechanically C++-ified version of Cairo.
>>> Specifically, “mechanically C++-ified” means taking Cairo as-is and
>>> transforming it with a one-page list of mechanical changes such as
>>> turning _create functions into constructors, (mystruct*, int length)
>>> function parameters to vector<struct>& parameters, that sort of thing
>>> – the design and abstractions and functions are unchanged. This would
>>> also allow us to track Cairo as it evolves in the future, by continuing to
>> reapply the same rules to new updates to Cairo.
>> Very interesting! Looks like you already got most of it written down. I think
>> cairo is indeed a great fit for what the group is looking for.
>> During cairo's development, there were some decisions made that we
>> regretted later on. I was going to suggest that those be revisited for
>> standardization, but reading the documents you linked, I think that will go
>> down the same design-by-committee path that you are trying to avoid. So,
>> personally, I fully support the current position outlined in the N3825
>> document and am willing to help with the effort.
>>> We know about Cairomm but it seems to have languished so we are
>>> focused on current Cairo as a starting point, even though it’s not C++
>>> -- we believe Cairo itself it is very well written C (already in an OO
>>> style, already const-correct, etc.).
>> Yes, I think you can go straight to cairo itself. I'm guessing that you should be
>> able to autogenerate the binding. Perhaps, using gobject-introspection to
>> generate a typelib for cairo, then reading the typelib, transforming it, and
>> writing out the binding.
>>> We want to make sure we’re doing this in the right way and with the
>>> group’s approval, so your feedback would be much appreciated. Also, we
>>> might want to reuse parts of the Cairo documentation in our
>>> specification, which we understand is governed by MPL 1.1, and we
>>> would like to know if this would be all right with your group.
>> I sure would love to see cairo's functionality and quality be available
>> anywhere C++ is :).
>> cairo mailing list
>> cairo at cairographics.org
More information about the cairo