[cairo] Cairo and ISO C++

[Michael McLaughlin]

Thanks for all the great feedback from everyone so far. I'm working to
finish up the initial reference implementation and get it published on
GitHub at which point the plan is to use the mechanisms there to add and
track the various ideas that have come in so far so that we hopefully don't
overlook any of them. I can't guarantee that they'll all be adopted, but I
hope that a lot of them will be (some of them I'd thought of already,
others I didn't but think make a lot of sense).

I had hoped to have the reference implementation done a few hours ago but I
got caught up in the intricacies of the raster source pattern's callbacks
and it took me a lot longer than I expected to get a handle on how they
seem to be used. I'm still working on mechanisms for them and am making
real progress again, but at this point I'm adopting an "it'll be ready when
it's ready" attitude rather than making any predictions.

Thanks again for all the great suggestions and please keep them coming!

-Mike


On Wed, Jan 22, 2014 at 7:32 AM, Tavmjong Bah <tavmjong at free.fr> wrote:

> On Mon, 2014-01-20 at 19:16 -0500, Michael McLaughlin wrote:
> > Hi!
> >
> > I wanted to give everyone an update. Earlier today a proposal that
> > Herb, Jason, and I have been working on, N3888: A Proposal to Add 2D
> > Graphics Rendering and Display to C++, was published here:
> > http://isocpp.org/files/papers/N3888.pdf . The main focus of the
> > proposal is a series of rules that enable a mechanical transformation
> > from the cairo API to an API that is in the style of the C++ Standard
> > Library (the STL).
> >
> > We expect to present the proposal for feedback at the Issaquah, WA
> > meeting of the ISO C++ Committee (PDF) which runs from Feb. 10 - Feb.
> > 15, 2014 (I will personally be there from mid-day Monday through
> > Wednesday). We do not expect that the proposal is final and we are
> > soliciting feedback on it from everyone who is interested. This
> > includes all of you. We are hopeful that you will all be receptive to
> > the approach we have taken and are supportive of the concept (even if
> > you might have some ideas about how to make technical improvements).
>
> This looks quite interesting. We (Inkscape) use Cairo to render SVG. It
> is a pretty good match for this. Firefox and Webkit also used/use Cairo
> too (see comment at end). I assume that the target "backend" is
> on-screen display so one would still need a library like Cairo to handle
> other types of output (PNG, PDF, SVG, etc.).
>
> I do have one overall observation. Cairo and other similar libraries
> seem to implement the same graphics elements that have been around since
> the beginning. Perhaps this is because those are the only elements that
> are really needed but I have a feeling this is more that they copy from
> each other. I would hope that this specification would be a bit more
> forward looking.
>
> Here are a few things that are missing from Cairo:
>
> 1. The ability to use fonts that are not installed on the system (i.e.
> user fonts) at the same time one uses system fonts. (There is a user
> font API in Cairo but isn't integrated with the other font back ends.)
>
> 2. Font selection. The world is more than 'normal' and 'bold' or
> 'normal' and 'italic'. Font families often have many more variants. This
> is a very important point for designers. For a better idea of what is
> required see: http://www.w3.org/TR/css3-fonts/
>
> 3. Pseudo 3D transforms. See: http://www.w3.org/TR/css3-transforms/
>
> 4. Arcs line-join. See:
> https://svgwg.org/svg2-draft/painting.html#LineJoin
> (I have an experimental implementation for the bitmap Cairo back-end.)
>
> 5. Color spaces and color management.
>
> 6. More than 24bit color (with alpha). The development version of Gimp
> can handle 32 bit floating point per channel (as well as archaic indexed
> color formats), see:
>
> http://libregraphicsworld.org/blog/entry/gimp-2.8-released-next-version-to-get-high-bit-depth-precision
>
> 7. Pixel operations (provided to Cairo via pixman). Including setting
> upscaling/downscaling method.
>
> 8. Filter effects. See: http://www.w3.org/TR/filter-effects/
>
> 9. Metadata (author, etc.) if this proposal is for more than on-screen
> display.
>
> I've asked the Inkscape developers mailing list and the SVG WG mailing
> list for others.
>
> A couple more comments:
>
> One should treat Canvas and SVG separately. They serve different
> purposes (one produces bitmap graphics, the other vectorized graphics;
> they are part of different standardization processes). The fact that
> Apple has hinted at IP rights with regards to Canvas should not effect
> SVG. BTW, that email is from 2007, apparently before Canvas was
> incorporated into HTML5, so Apple should have by now clarified what IP
> rights they could assert.
>
> Firefox used Cairo for all rendering at one point. They have moved away
> from it. For their rational, see:
>
> https://people.mozilla.org/~roc/Samsung/Mozilla2DGraphics.pdf
> https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/
>
> Tav
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20140123/c2627834/attachment.html>