LibreOffice » sw
View module in: cgit
Exact history was lost before Sept. 18th, 2000, but old source code comments show that Writer core dates back until at least November 1990.
inc: headers available to all source files inside the module
qa: unit, slow and subsequent tests
source: see below
uiconfig: user interface configuration
util: UNO passive registration config
core: Writer core (document model, layout, UNO API implementation)
filter: Writer internal filters
ascii: plain text filter
docx: wrapper for the UNO DOCX import filter (in writerfilter) for autotext purposes
html: HTML filter
inc: include files for filters
rtf: thin copy&paste helper around the UNO RTF import filter (in writerfilter)
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 (
There is a good overview documentation of basic architecture of Writer core in the OOo wiki:
Writer specific WhichIds are defined in
The details below are mainly about details missing from the wiki pages.
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…
Basically a (fancy) array of
SwNode pointers. There are special subclasses of
SwEndNode) which are used to encode a nested tree
structure into the flat array; the range of nodes from
SwStartNode to its
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
SwNodes contains the following top-level sections:
The Undo/Redo information is stored in a
sw::UndoManager member of
which implements the
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
There are also
ListActions which internally contain several individual
actions; these are created by the StartUndo/EndUndo wrapper methods.
The sub-structure of paragraphs is stored in the
SwTextNode::m_pSwpHints. There is a base class
SwTextAttr with numerous
SwTextAttr has a start and end index and a
to store the actual formatting attribute.
There are several sub-categories of
formatting attributes: Character Styles (
and Automatic Styles (no special class,
these are handled by
SwpHintsArray::BuildPortions and MergePortions,
which create non-overlapping portions of formatting attributes.
nesting attributes: Hyperlinks (
RES_TXTATR_CJK_RUBY) and Meta/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 (
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.
There are multiple model classes involved for fields:
enum SwFieldIdsenumerates the different types of fields.
SwFieldTypecontains 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::InsertFieldType(). An example for the latter are variable fields (
SwFieldIds::GetExp/SwFieldIds::SetExp), with one
SwXFieldMasteris the UNO wrapper of a field type. It is a
SwClientregistered at the
SwFieldType. Its life-cycle is determined by UNO clients outside of
sw; it will get disposed when the
SfxPoolItemof a field. The
SwClientregistered at its
SwFieldof the field.
SwFieldcontains the core logic of a field. The
SwFieldis owned by the
SwFormatFieldof 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.
SwTextFieldis the text attribute of a field. It owns the
SwFormatFieldof the field (like all text attributes).
SwXTextFieldis the UNO wrapper object of a field. It is a
SwClientregistered at the
SwFormatField. Its life-cycle is determined by UNO clients outside of
sw; it will get disposed when the
SwNumFormat (subclass of
SvxNumFormat) determines the formatting of a single
SwNumRule (NOT a subclass of
SvxNumRule) is a list style, containing one
SwNumFormat per list level.
SwNumRule::maTextNodeList is the list of
SwTextNode that have this list style
SwNumberTreeNode is a base class that represents an abstract node in a
hierarchical tree of numbered nodes.
SwNodeNum is the subclass of
SwNumberTreeNode that connects it with an
SwTextNode and also with a
SwTextNode::mpNodeNum points back in the other direction
SwList represents a list, which is (mostly) a vector of
SwNodes top-level section (why that?).
sw::DocumentListsManager owns all
and maintains mappings:
SwListfor that list style)
sw::DocumentListItemsManager contains a set of all
SwNodeNum instances, ordered by
the special Outline numbering rule:
a list (which is actually stored in
that either have the Outline numrule applied,
or have the
RES_PARATR_OUTLINELEVEL item set (note that in the latter case,
SwTextNode does not have a
SwNodeNum and is not associated with the
SwTextNodes and paragraph styles have items/properties:
RES_PARATR_OUTLINELEVEL/"OutlineLevel"to specify an outline level without necessarily having the outline
RES_PARATR_NUMRULE/"NumberingStyleName"the list style to apply; may be empty
""which means no list style (to override inherited value) Only
SwTextNodehas these items:
SwListto which the node is added
RES_PARATR_LIST_LEVEL/"NumberingLevel"the level at which the
SwTextNodewill appear in the list
RES_PARATR_LIST_ISRESTART/"ParaIsNumberingRestart"restart numbering sequence at this
RES_PARATR_LIST_RESTARTVALUE/"NumberingStartValue"restart numbering sequence at this
SwTextNodewith this value
RES_PARATR_LIST_ISCOUNTED/"NumberingIsNumber"determines if the node is actually counted in the numbering sequence; these are different from
"phantoms"because there’s still a
Note that there is no UNO service to represent a list.
The layout is a tree of
SwFrame subclasses, the following relationships are
possible between frames:
SwFlowFrame, which is not an
SwFramesubclass. The logical chain of such frames can be visited using the follow and precede pointers. (“Leaf” is a term that refers to such a relationship.)