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
|
<sect1 id="kernel_part_pdfoperators">
<title>Operators</title>
<para>
Every page has its content stream which contains the description of every object
on a page. Content stream consists of operators and their operands specifying how to alter
graphical state of a page.
These operators specify what and how it is displayed. They are processed sequentially.
If no content stream is avaliable (or is empty) the approperiate page is empty.
</para>
<sect2 id="pdfoperators"><title>PdfOperators</title>
<para>
Content stream consists of operators and their operands. Operators can be
either simple or composite objects. The requirement for processing operators sequentially
and representing operators in human readable form resulted in storing each operator in two queues.
<mediaobject>
<imageobject>
<imagedata fileref="kernel/images/pdfoperators.png" format="PNG"/>
</imageobject>
<textobject><phrase>Operator overview</phrase></textobject>
<caption><para>Operator overview</para></caption>
</mediaobject>
</para>
</sect2>
<sect2 id="changing_pdf_operators"><title>Changing pdf operators</title>
<para>
Changing the visible object properties means wrap those objects into other objects. Object can depend on previous
objects. We need to be able to iterate backwards.
Summarizing these requirements with human readable representation of operators leads to these decisions:
<itemizedlist mark="circle">
<listitem><para>sequentially processing the list, the order has to be the same as in the file we edit -
<xref linkend="iterator" /></para>
</listitem>
<listitem><para>grouping and wrapping operators - <xref linkend="composite" /> and
specific <xref linkend="decorator" /></para>
</listitem>
</itemizedlist>
The first requirement is needed when simulating the display process of an pdf viewer (e.g. when
finding out the absolute position of an operator). <xref linkend="composite" /> used in
representation of pdf operators
is very useful, when changing objects (e.g. changing an existing text object to composite is very easy allowing us to
add some special formatting). This becomes very useful with the <xref linkend="decorator" />
which allows us to change this object in conjuction with previous changes.
<mediaobject>
<imageobject>
<imagedata fileref="kernel/images/pdfoperatorexample.png" format="PNG"/>
</imageobject>
<textobject><phrase>Example of changed pdf operator</phrase></textobject>
<caption><para>Example of changed pdf operator</para></caption>
</mediaobject>
</para>
</sect2>
</sect1>
<sect1 id="kernel_part_pdfoperatorsiterator">
<title>Pdfoperator iterator</title>
<para>
<xref linkend="iterator" /> allows us to iterate over items. When designed correctly
specific iterator can be added easily.
</para>
<sect2 id="PdfOperatorIterator">
<title>PdfOperatorIterator</title>
<para>
Pdf operator iterator is a bidirectional iterator over PdfOperator objects.
This iterator is special. The information about next and previous object is stored in the object itself.
This iterator works with smart pointers which brings us the problem of dependency cycle and objects would
not get deallocated. This was solved by introducing another type of smart pointer which can handle this.
It is very similar to a normal bidirectional linked list. The iterator class holds the information whether it is before the
beginning, after the end or at a valid item.
</para>
</sect2>
<sect2 id="extending_iterator">
<title>Extending iterator</title>
<para>
Basic iterator class implements one Template method. Specific iterators are created by
overloading this method. It decides whether an item is valid or not.
There are two important children of the base iterator class.
<itemizedlist mark="opencircle">
<listitem><para>AcceptingPdfOperatorIterator class</para></listitem>
<listitem><para>RejectingPdfOperatorIterator class</para></listitem>
</itemizedlist>
These two classes either accept a set or operators or accept everything except those iterators. Extending these classes
requires only defining the set of operators.
<mediaobject>
<imageobject>
<imagedata fileref="kernel/images/pdfoperatoriterator.png" format="PNG"/>
</imageobject>
<textobject><phrase>Pdf operator iterators overview</phrase></textobject>
<caption><para>Pdf operator iterators overview</para></caption>
</mediaobject>
</para>
</sect2>
</sect1>
|
