[cairo] Cairo and ISO C++

[Tavmjong Bah]

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