1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>cairo_path_t</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
<link rel="start" href="index.html" title="Cairo: A Vector Graphics Library">
<link rel="up" href="language-bindings.html" title="Appendix A. Creating a language binding for cairo">
<link rel="prev" href="bindings-fonts.html" title="Fonts">
<meta name="generator" content="GTK-Doc V1.6 (XML mode)">
<link rel="stylesheet" href="style.css" type="text/css">
<link rel="part" href="pt01.html" title="Part I. Tutorial">
<link rel="part" href="pt02.html" title="Part II. Reference">
<link rel="chapter" href="Drawing.html" title="Drawing">
<link rel="chapter" href="Fonts.html" title="Fonts">
<link rel="chapter" href="Surfaces.html" title="Surfaces">
<link rel="chapter" href="Support.html" title="Utilities">
<link rel="index" href="ix01.html" title="Index">
<link rel="appendix" href="language-bindings.html" title="Appendix A. Creating a language binding for cairo">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
<td><a accesskey="p" href="bindings-fonts.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
<td><a accesskey="u" href="language-bindings.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
<th width="100%" align="center">Cairo: A Vector Graphics Library</th>
<td> </td>
</tr></table>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="bindings-path"></a>cairo_path_t</h2></div></div></div>
<p>
The <a href="cairo-Paths.html#cairo-path-t"><span class="type">cairo_path_t</span></a> type is one
area in which most language bindings will differ significantly
from the C API. The C API for <span class="type">cairo_path_t</span> is
designed for efficiency and to avoid auxiliary objects that
would be have to be manually memory managed by the
application. However,
a language binding should not present <span class="type">cairo_path_t</span> as an
array, but rather as an opaque that can be iterated
over. Different languages have quite different conventions for
how iterators work, so it is impossible to give an exact
specification for how this API should work, but the type names
and methods should be similar to the language's mapping of the following:
</p>
<pre class="programlisting">
typedef struct cairo_path_iterator cairo_path_iterator_t;
typedef struct cairo_path_element cairo_path_element_t;
cairo_path_iterator_t *
cairo_path_get_iterator (cairo_path_t *path);
cairo_bool_t
cairo_path_iterator_has_next (cairo_path_iterator_t *iterator);
cairo_path_element_t *
cairo_path_iterator_next (cairo_path_iterator_t *iterator);
cairo_path_element_type_t
cairo_path_element_get_type (cairo_path_element_t *element);
void
cairo_path_element_get_point (cairo_path_element_t *element,
int index,
double *x,
double *y);
</pre>
<p>
The above is written using the Java conventions for
iterators. To illustrate how the API for PathIterator might
depend on the native iteration conventions of the API, examine
three versions of the loop, first written in a hypothetical Java
binding:
</p>
<pre class="programlisting">
PathIterator iter = cr.copyPath().iterator();
while (cr.hasNext()) {
PathElement element = iter.next();
if (element.getType() == PathElementType.MOVE_TO) {
Point p = element.getPoint(0);
doMoveTo (p.x, p.y);
}
}</pre>
<p>
And then in a hypothetical C++ binding:
</p>
<pre class="programlisting">
Path path = cr.copyPath();
for (PathIterator iter = path.begin(); iter != path.end(); iter++) {
PathElement element = *iter;
if (element.getType() == PathElementType.MOVE_TO) {
Point p = element.getPoint(0);
doMoveTo (p.x, p.y);
}
}</pre>
<p>
And then finally in a Python binding:
</p>
<pre class="programlisting">
for element in cr.copy_path():
if element.getType == cairo.PATH_ELEMENT_MOVE_TO:
(x, y) = element.getPoint(0)
doMoveTo (x, y);</pre>
<p>
While many of the API elements stay the same in the three
examples, the exact iteration mechanism is quite different, to
match how users of the language would expect to iterate over
a container.
</p>
<p>
You should not present an API for mutating or for creating new
<span class="type">cairo_path_t</span> objects. In the future, these
guidelines may be extended to present an API for creating a
<span class="type">cairo_path_t</span> from scratch for use with
<code class="function">cairo_append_path()</code>
but the current expectation is that <code class="function">cairo_append_path()</code> will
mostly be used with paths from
<code class="function">cairo_copy_path()</code>.
</p>
</div>
</body>
</html>
|
