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
|
Writer application code.
Exact history was lost before Sept. 18th, 2000, but old source code
comments show that Writer core dates back until at least November
1990.
== Module contents ==
* inc: headers available to all source files inside the module
* qa: unit, slow and subsequent tests
* sdi
* source: see below
* uiconfig: user interface configuration
* util: UNO passive registration config
== Source contents ==
* core: Writer core (document model, layout, UNO API implementation)
* filter: Writer internal filters
* ascii: plan text filter
* basflt
* html: HTML filter
* inc: include files for filters
* rtf: thin copy&paste helper around the UNO RTF import filter (in writerfilter)
* writer
* ww8: DOC import, DOC/DOCX/RTF export
* xml: ODF import/export, subclassed from xmloff (where most of the work is done)
* uibase: user interface (those parts that are linked into sw & always loaded)
* ui: user interface (optional parts that are loaded on demand (swui))
== Core ==
There is a good overview documentation of basic architecture of Writer core
in the OOo wiki:
http://wiki.openoffice.org/wiki/Writer/Core_And_Layout
http://wiki.openoffice.org/wiki/Writer/Text_Formatting
Writer specific WhichIds are defined in sw/inc/hintids.hxx.
The details below are mainly about details missing from the Wiki pages.
=== SwDoc ===
The central class for a document is SwDoc, which represents a document.
A lot of the functionality is split out into separate Manager classes,
each of which implements some IDocument* interface; there are
SwDoc::getIDocument*() methods to retrieve the managers.
However there are still too many members and methods in this class,
many of which could be moved to some Manager or other...
=== SwNodes ===
Basically a (fancy) array of SwNode pointers. There are special subclasses of
SwNode (SwStartNode and SwEndNode) which are used to encode a nested tree
structure into the flat array; the range of nodes from SwStartNode to its
corresponding SwEndNode is sometimes called a "section" (but is not necessarily
what the high-level document model calls a "Section"; that is just one of the
possibilities).
The SwNodes contains the following top-level sections:
1. Empty
2. Footnote content
3. Frame / Header / Footer content
4. Deleted Change Tracking content
5. Body content
=== Undo ===
The Undo/Redo information is stored in a sw::UndoManager member of SwDoc,
which implements the IDocumentUndoRedo interface.
Its members include a SwNodes array containing the document content that
is currently not in the actual document but required for Undo/Redo, and
a stack of SwUndo actions, each of which represents one user-visible
Undo/Redo step.
There are also ListActions which internally contain several individual SwUndo
actions; these are created by the StartUndo/EndUndo wrapper methods.
=== Text Attributes ===
The sub-structure of paragraphs is stored in the SwpHintsArray member
SwTxtNode::m_pSwpHints. There is a base class SwTxtAttr with numerous
subclasses; the SwTxtAttr has a start and end index and a SfxPoolItem
to store the actual formatting attribute.
There are several sub-categories of SwTxtAttr:
- formatting attributes: Character Styles (SwTxtCharFmt, RES_TXTATR_CHARFMT)
and Automatic Styles (no special class, RES_TXTATR_AUTOFMT):
these are handled by SwpHintsArray::BuildPortions and MergePortions,
which create non-overlapping portions of formatting attributes.
- nesting attributes: Hyperlinks (SwTxtINetFmt, RES_TXTATR_INETFMT),
Ruby (SwTxtRuby, RES_TXTATR_CJK_RUBY) and Meta/MetaField (SwTxtMeta,
RES_TXTATR_META/RES_TXTATR_METAFIELD):
these maintain a properly nested tree structure.
The Meta/Metafield are "special" because they have both start/end
and a dummy character at the start.
- misc. attributes: Reference Marks, ToX Marks
- attributes without end: Fields, Footnotes, Flys (AS_CHAR)
These all have a corresponding dummy character in the paragraph text, which
is a placeholder for the "expansion" of the attribute, e.g. field content.
=== Fields ===
There are multiple model classes involved for fields:
- enum RES_FIELDS enumerates the different types of fields.
- SwFieldType contains some shared stuff for all fields of a type.
There are many subclasses of SwFieldType, one for each different type
of field.
For most types of fields there is one shared instance of this per type,
which is created in DocumentFieldsManager::_InitFieldTypes()
but for some there are more than one, and they are dynamically created, see
DocumentFieldsManager::InsertFldType(). An example for the latter are
variable fields (RES_GETEXPFLD/RES_SETEXPFLD), with one SwFldType per
variable.
- SwXFieldMaster is the UNO wrapper of a field type.
It is a SwClient registered at the SwFieldType.
Its life-cycle is determined by UNO clients outside of sw; it will get
disposed when the SwFieldType dies.
- SwFmtFld is the SfxPoolItem of a field.
The SwFmtFld is a SwClient registered at its SwFldType.
The SwFmtFld owns the SwField of the field.
- SwField contains the core logic of a field.
The SwField is owned by the SwFmtFld of the field.
There are many subclasses of SwField, one for each different type of field.
Note that there are not many places that can Expand the field to its
correct value, since for example page number fields require a View
with an up to date layout; therefore the correct expansion is cached.
- SwTxtFld is the text attribute of a field.
It owns the SwFmtFld of the field (like all text attributes).
- SwXTextField is the UNO wrapper object of a field.
It is a SwClient registered at the SwFmtFld.
Its life-cycle is determined by UNO clients outside of sw; it will get
disposed when the SwFmtFld dies.
|
