office-gobmx/sw
Miklos Vajna 9fa68f05e1 SwFlyCntPortion::SetBase: adjust position of the textbox if necessary
In case of inline shapes, it's not possible to just copy the AnchorType
property of the shape to the textbox, as we want the textbox at the
expected position, not inline. OTOH, an inline shape has an implicit
position, so we can't position its textbox at import-time.

Solve the problem by setting the position of the textbox as we create
the layout of the inline shape.

Change-Id: I425ff5e0760858ebcbe457ed0ce9e4977ae8bc74
2014-05-28 15:57:12 +02:00
..
inc SwTextBoxHelper: extract getTextRectangle() from syncProperty() 2014-05-28 15:57:11 +02:00
qa CppunitTest_sw_rtfimport: enable on Mac 2014-05-28 01:47:38 -05:00
sdi
source SwFlyCntPortion::SetBase: adjust position of the textbox if necessary 2014-05-28 15:57:12 +02:00
uiconfig Resolves: fdo#79124 options cells shift down when unit clicked 2014-05-26 20:41:02 +01:00
util
AllLangResTarget_sw.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
CppunitTest_sw_filters_test.mk
CppunitTest_sw_htmlexport.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
CppunitTest_sw_layout_test.mk
CppunitTest_sw_macros_test.mk
CppunitTest_sw_odfexport.mk
CppunitTest_sw_odfimport.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
CppunitTest_sw_ooxmlexport.mk
CppunitTest_sw_ooxmlimport.mk
CppunitTest_sw_ooxmlsdrexport.mk
CppunitTest_sw_ooxmlw14export.mk
CppunitTest_sw_rtfexport.mk
CppunitTest_sw_rtfimport.mk
CppunitTest_sw_uiwriter.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
CppunitTest_sw_uwriter.mk
CppunitTest_sw_ww8export.mk
CppunitTest_sw_ww8import.mk
Executable_tiledrendering.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
JunitTest_sw_complex.mk
JunitTest_sw_unoapi.mk
Library_msword.mk sw: try not to include sw/souce/core stuff from sw/source/filter 2014-05-23 16:11:34 +02:00
Library_sw.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
Library_swd.mk
Library_swui.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
Library_vbaswobj.mk sw: move sw/source/core/uibase to sw/source/uibase 2014-05-27 11:13:02 +02:00
Makefile
Module_sw.mk
ooxmlexport_setup.mk
PythonTest_sw_python.mk
README sw: document uibase dir 2014-05-27 11:13:16 +02:00
UIConfig_qa.mk
UIConfig_sglobal.mk
UIConfig_sweb.mk
UIConfig_swform.mk
UIConfig_swreport.mk
UIConfig_swriter.mk
UIConfig_swxform.mk

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
   * ww1
   * 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.

This is a huge class with hundreds of methods; there are some efforts
to split up the class into many smaller classes that implement more
specific interfaces but this is not fully implemented yet; see the various
IDocument* classes.

=== 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.