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
|
<!-- vim:tabstop=4:shiftwidth=4:noexpandtab:textwidth=80
-->
<sect1 id="kernel_part_ccontentstream">
<title>CContentStream</title>
<para>
Content stream can consist of one or more <xref linkend="stream"/>.
It is responsible for everything on a page. If anything visible is
changed the content stream must be changed. Content stream is a
stream processed sequentially. Page can consist of one or more
content streams and these streams must be concatenated before reading
(objects can be splitted between two content streams). Content stream
consists of operators and their operands. Each operator updates
graphical state.
</para>
<sect2 id="observing_ccontentstream">
<title>Observing ccontentstream</title>
<para>
Generally, changing anything visible on a page means changing
something in underlying content stream. Because operators are
processed sequentially changing of one operator/operand may
affect many following operators (e.g. their bounding boxes).
Page needs to know if a content stream is changed because it
must reparse operators. CContentStream implements observer
subject interface so for example cpage (as content stream
maintainer) can be informed when it is changed.
</para>
</sect2>
<sect2 id="changing_ccontentstream">
<title>Changing ccontentstream</title>
<para>
Content stream can be changed in two ways. Either by
ccontentstream methods or by requesting raw operator and changing
its operands. The third way is to add/delete whole stream.
This problem is solved by Observers <!-- Target of link is commented out <xref linkend="kernel_part_ccontentstream_observers"/> -->.
</para>
</sect2>
<sect2 id="storing_pdf_operators">
<title>Storing pdf operators</title>
<para>
Operators are processed sequentially and there are many situations
when only some types of operators are needed. Clear solution is to
use the <xref linkend="iterator" />. With this patter we can process
operators one by one. If we need specific iterators we just create
another child of basic iterator. There are be
<emphasis>simple</emphasis> and <emphasis>composite</emphasis>
operators. Operators form a <emphasis>tree-like</emphasis> structure. This is more
readable than a list of all operators. So we implement another
tree-like queue. Only the first level of operators is stored in
ccontentstream. Each composite operator stores its children.
This is an example of <xref linkend="composite" />. Simple and
composite operators are accessed uniformly.
<mediaobject>
<imageobject>
<imagedata fileref="kernel/images/ccontentstream_operator.png" format="PNG"/>
</imageobject>
<caption><para>Operator queues</para></caption>
</mediaobject>
</para>
</sect2>
<sect2 id="changing_pdf_operators">
<title>Changing pdf operators</title>
<para>
Deleting and inserting an operator is not easy because it is stored
in two queues. We have information only about one queue (that one
which was used to get the operator) so we need to find out the
position in the second queue and change it adequately.
</para>
</sect2>
</sect1>
|
