File: fo-area-c-file.xml

package info (click to toggle)
xmlroff 0.6.2-1.1
  • links: PTS, VCS
  • area: main
  • in suites: wheezy
  • size: 36,456 kB
  • sloc: ansic: 178,247; xml: 109,155; sh: 8,973; makefile: 1,331; perl: 30
file content (143 lines) | stat: -rw-r--r-- 4,988 bytes parent folder | download | duplicates (5)
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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
<section id="fo-area-c-file">
<sectioninfo>
<title>Anatomy of a Formatting Object area source code file</title>
<subtitle>FO -area.c File</subtitle>
<abstract><para>Anatomy of a Formatting Object area source code file</para></abstract>
</sectioninfo>

<para>These files are not autogenerated.</para>

<para>Some, but not all, formatting objects generate areas. Those that
do generate areas and are implemented in xmlroff have an -area.c and
area.h file.</para>

<para>The -area.[ch] files exist to implement fo_fo_area_new2() for
the GObject class for the formatting object (or, for formatting
objects implemented early and not yet brought up to date, to implement
fo_fo_area_new()).</para>

<para>The _area_new2() or _area_new() function creates an area of the
type appropriate for the formatting object and adds it to the
formatting object tree.</para>

<para>The differences between the _area_new2() and _area_new()
functions are really just in their interface: the _area_new2()
functions get most of their inputs in a FoFoAreaNew2Context structure
rather than as individual arguments. The _area_new2() functions also
have a GError argument for error reporting.</para>

<para>The least straightforward -area.c file is fo-block-area.c, since
that's where FoText and inline formatting objects are made into Pango
layouts. The rest are mostly straightforward.</para>

<section id="fo-area-initial-comment">
<title>Initial comment</title>

<programlisting>/* Fo
 * fo-table-body-area.c: Generate area for 'table-body' formatting object
 *
 * Copyright (C) 2001 Sun Microsystems
 *
 * $Id: fo-area-c-file.xml,v 1.1 2006/03/14 19:42:57 tonygraham Exp $
 *
 * See Copying for the status of this software.
 */</programlisting>

</section>

<section id="fo-area-includes">
<title>#includes</title>

<programlisting>#include &lt;fo-area-table-body.h></programlisting>

<para>The public interface for the type of area generated by this formatting object.</para>

<programlisting>#include &lt;fo-table-body-private.h></programlisting>

<para>The private interface of this formatting object type.</para>

</section>

<section id="fo-area-area-new2">
<title>FoFo _area_new2()</title>

<para>Add the area generated by the formatting object to the area tree.</para>

<programlisting> /**
 * fo_table_body_area_new2:
 * @fo:      #FoTableBody
 * @context: #FoFoAreaNew2Context
 * @error:   #GError
 *
 * Create a new area for @fo and add it to the parent area.
 *
 * A pointer to the parent area is in @context.
 **/
void
fo_table_body_area_new2 (FoFo                *fo,
                         FoFoAreaNew2Context *context,
                         GError             **error)
{
 FoTableBody *table_body = (FoTableBody *) fo;
 FoArea *use_parent_area;
 FoArea *new_area;

 g_return_if_fail (table_body != NULL);
 g_return_if_fail (FO_IS_TABLE_BODY (table_body));
 g_return_if_fail (context != NULL);
 g_return_if_fail (error == NULL || *error == NULL);

 new_area = fo_area_table_body_new ();
 use_parent_area = context->parent_area;

#if defined(LIBFO_DEBUG) &amp;&amp; 0
 g_warning ("*** table-body parent before new area:");
 fo_object_debug_dump (parent_area, 0);
 g_warning ("*** end table-body parent");
 #endif

FO_AREA (new_area)->generated_by = fo;</programlisting>

<para>Areas keep track of which FO generated them so they can get some
property values, e.g., colors, from the FO rather than loading the
area objects with duplicates of all the applicable formatting object
property values.</para>

<programlisting> FO_FO (fo)->areas = g_list_append (FO_FO (fo)->areas, new_area);</programlisting>

<para>FOs keep track of which areas they've generated</para>

<programlisting> fo_area_add_child (use_parent_area, new_area);</programlisting>

<para>Attach the new area to the area tree.</para>

<programlisting> new_area = fo_area_size_request (new_area);</programlisting>

<para>The new area asks its parent to allocate space for it. Anything
could happen at this point: the area might not fit in the space
remaining for it on the current page, so the new area, the parent
area, and all containing areas up the page area may need to be split
so one part of the new area is on the current page and the rest on the
next page (or on multiple pages if it is big enough).</para>

<para>Consequently, the area returned by fo_area_size_request() might
not be the same area that was passed to it. The return value is the
last area resulting from the original new_area.</para>

<programlisting> fo_area_area_set_width (new_area, fo_area_get_available_width (new_area));

#if defined(LIBFO_DEBUG) &amp;&amp; 0
 g_warning ("*** table-body parent after new area:");
 fo_object_debug_dump (parent_area, 0);
 g_warning ("*** end table-body parent");
#endif

 *(context->new_area) = new_area;</programlisting>

<para>'Return' the new area so there's somewhere to hang the areas
generated by the children of the current formatting object.</para>

<programlisting>}</programlisting>

</section>
</section>