sw/README

   1 Writer application code.
   2
   3 Exact history was lost before Sept. 18th, 2000, but old source code
   4 comments show that Writer core dates back until at least November
   5 1990.
   6
   7 == Module contents ==
   8  * inc: headers available to all source files inside the module
   9  * qa: unit, slow and subsequent tests
  10  * sdi
  11  * source: see below
  12  * uiconfig: user interface configuration
  13  * util: UNO passive registration config
  14
  15 == Source contents ==
  16  * core: Writer core (document model, layout, UNO API implementation)
  17  * filter: Writer internal filters
  18    * ascii: plan text filter
  19    * basflt
  20    * html: HTML filter
  21    * inc: include files for filters
  22    * rtf: thin copy&paste helper around the UNO RTF import filter (in writerfilter)
  23    * writer
  24    * ww8: DOC import, DOC/DOCX/RTF export
  25    * xml: ODF import/export, subclassed from xmloff (where most of the work is done)
  26  * uibase: user interface (those parts that are linked into sw & always loaded)
  27  * ui: user interface (optional parts that are loaded on demand (swui))
  28
  29 == Core ==
  30
  31 There is a good overview documentation of basic architecture of Writer core
  32 in the OOo wiki:
  33
  34 http://wiki.openoffice.org/wiki/Writer/Core_And_Layout
  35 http://wiki.openoffice.org/wiki/Writer/Text_Formatting
  36
  37 Writer specific WhichIds are defined in sw/inc/hintids.hxx.
  38
  39 The details below are mainly about details missing from the Wiki pages.
  40
  41 === SwDoc ===
  42
  43 The central class for a document is SwDoc, which represents a document.
  44
  45 A lot of the functionality is split out into separate Manager classes,
  46 each of which implements some IDocument* interface; there are
  47 SwDoc::getIDocument*() methods to retrieve the managers.
  48
  49 However there are still too many members and methods in this class,
  50 many of which could be moved to some Manager or other...
  51
  52 === SwNodes ===
  53
  54 Basically a (fancy) array of SwNode pointers.  There are special subclasses of
  55 SwNode (SwStartNode and SwEndNode) which are used to encode a nested tree
  56 structure into the flat array; the range of nodes from SwStartNode to its
  57 corresponding SwEndNode is sometimes called a "section" (but is not necessarily
  58 what the high-level document model calls a "Section"; that is just one of the
  59 possibilities).
  60
  61 The SwNodes contains the following top-level sections:
  62
  63 1. Empty
  64 2. Footnote content
  65 3. Frame / Header / Footer content
  66 4. Deleted Change Tracking content
  67 5. Body content
  68
  69 === Undo ===
  70
  71 The Undo/Redo information is stored in a sw::UndoManager member of SwDoc,
  72 which implements the IDocumentUndoRedo interface.
  73 Its members include a SwNodes array containing the document content that
  74 is currently not in the actual document but required for Undo/Redo, and
  75 a stack of SwUndo actions, each of which represents one user-visible
  76 Undo/Redo step.
  77
  78 There are also ListActions which internally contain several individual SwUndo
  79 actions; these are created by the StartUndo/EndUndo wrapper methods.
  80
  81 === Text Attributes ===
  82
  83 The sub-structure of paragraphs is stored in the SwpHintsArray member
  84 SwTxtNode::m_pSwpHints.  There is a base class SwTxtAttr with numerous
  85 subclasses; the SwTxtAttr has a start and end index and a SfxPoolItem
  86 to store the actual formatting attribute.
  87
  88 There are several sub-categories of SwTxtAttr:
  89
  90 - formatting attributes: Character Styles (SwTxtCharFmt, RES_TXTATR_CHARFMT)
  91   and Automatic Styles (no special class, RES_TXTATR_AUTOFMT):
  92   these are handled by SwpHintsArray::BuildPortions and MergePortions,
  93   which create non-overlapping portions of formatting attributes.
  94
  95 - nesting attributes: Hyperlinks (SwTxtINetFmt, RES_TXTATR_INETFMT),
  96   Ruby (SwTxtRuby, RES_TXTATR_CJK_RUBY) and Meta/MetaField (SwTxtMeta,
  97   RES_TXTATR_META/RES_TXTATR_METAFIELD):
  98   these maintain a properly nested tree structure.
  99   The Meta/Metafield are "special" because they have both start/end
 100   and a dummy character at the start.
 101
 102 - misc. attributes: Reference Marks, ToX Marks
 103
 104 - attributes without end: Fields, Footnotes, Flys (AS_CHAR)
 105   These all have a corresponding dummy character in the paragraph text, which
 106   is a placeholder for the "expansion" of the attribute, e.g. field content.
 107
 108 === Fields ===
 109
 110 There are multiple model classes involved for fields:
 111
 112 - enum RES_FIELDS enumerates the different types of fields.
 113 - SwFieldType contains some shared stuff for all fields of a type.
 114   There are many subclasses of SwFieldType, one for each different type
 115   of field.
 116   For most types of fields there is one shared instance of this per type,
 117   which is created in DocumentFieldsManager::_InitFieldTypes()
 118   but for some there are more than one, and they are dynamically created, see
 119   DocumentFieldsManager::InsertFldType().  An example for the latter are
 120   variable fields (RES_GETEXPFLD/RES_SETEXPFLD), with one SwFldType per
 121   variable.
 122 - SwXFieldMaster is the UNO wrapper of a field type.
 123   It is a SwClient registered at the SwFieldType.
 124   Its life-cycle is determined by UNO clients outside of sw; it will get
 125   disposed when the SwFieldType dies.
 126 - SwFmtFld is the SfxPoolItem of a field.
 127   The SwFmtFld is a SwClient registered at its SwFldType.
 128   The SwFmtFld owns the SwField of the field.
 129 - SwField contains the core logic of a field.
 130   The SwField is owned by the SwFmtFld of the field.
 131   There are many subclasses of SwField, one for each different type of field.
 132   Note that there are not many places that can Expand the field to its
 133   correct value, since for example page number fields require a View
 134   with an up to date layout; therefore the correct expansion is cached.
 135 - SwTxtFld is the text attribute of a field.
 136   It owns the SwFmtFld of the field (like all text attributes).
 137 - SwXTextField is the UNO wrapper object of a field.
 138   It is a SwClient registered at the SwFmtFld.
 139   Its life-cycle is determined by UNO clients outside of sw; it will get
 140   disposed when the SwFmtFld dies.
 141