Updated README.md files
* Updated README.md contents to fix various issues * Fixed source links by using [git:], processed by mkdocs scripts * Added README.md for ios, setup_native, unotest * Fixed issues with "underline" and "less than" sign Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This commit is contained in:
Hossein
Michael Stahl
parent
1a984f2ff1
commit
628c1c3b07
18 changed files with 161 additions and 153 deletions
|
|
@ -53,7 +53,7 @@ If you want to use Clang with the LibreOffice compiler plugins, the minimal
|
|||
version of Clang is 5.0.2. Since Xcode doesn't provide the compiler plugin
|
||||
headers, you have to compile your own Clang to use them on macOS.
|
||||
|
||||
You can find the TDF configure switches in the distro-configs/ directory.
|
||||
You can find the TDF configure switches in the `distro-configs/` directory.
|
||||
|
||||
To setup your initial build environment on Windows and macOS, we provide
|
||||
the LibreOffice Development Environment
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# Containers for the css::animation animation UNO API
|
||||
# Containers for the css::animation UNO API
|
||||
|
||||
Contains containers for the `css::animation` UNO API, used in `slideshow` and `sd`.
|
||||
|
|
|
|||
|
|
@ -2,10 +2,9 @@
|
|||
|
||||
The library is used to interact with the "Apple Remote Control" on Mac.
|
||||
|
||||
This is an early version of Martin Kahr's "Remote Control Wrapper"
|
||||
library
|
||||
(http://martinkahr.com/2007/07/26/remote-control-wrapper-20/index.html
|
||||
) with modifications by Eric Bachard. Unfortunately the exact extent
|
||||
This is an early version of Martin Kahr's ["Remote Control Wrapper" library](
|
||||
<http://martinkahr.com/2007/07/26/remote-control-wrapper-20/index.html>)
|
||||
with modifications by Eric Bachard. Unfortunately the exact extent
|
||||
of (and rationale behind) the modifications done is unknown, at least
|
||||
until the original upstream source version it is based on is
|
||||
found. Version control of this just starts with the monolithic commit
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# Algorithms and Data Types for Graphics
|
||||
|
||||
Algorithms and data types for graphics (e.g. polygons, vectors, matrices and the like - see that used in "canvas").
|
||||
Algorithms and data types for graphics (e.g. polygons, vectors, matrices and the like - see that used in `canvas`).
|
||||
|
|
|
|||
|
|
@ -8,4 +8,4 @@ build, or are simply generally useful. One example is
|
|||
bin/find-german-comments <directory>
|
||||
|
||||
which will try to detect and extract all the German comments in a
|
||||
given source code hierarchy / directory.
|
||||
given source code hierarchy `/` directory.
|
||||
|
|
|
|||
|
|
@ -3,4 +3,5 @@
|
|||
Support assemblies and tools for the MS .NET UNO binding.
|
||||
|
||||
## See also
|
||||
`git:cli\_ure/readme.txt`
|
||||
|
||||
`[git:cli_ure/readme.txt]`
|
||||
|
|
|
|||
|
|
@ -63,4 +63,4 @@ in rewriting mode (during which no object files are generate).
|
|||
|
||||
## Code Documentation / HowTos
|
||||
|
||||
<http://wiki.documentfoundation.org/Clang_plugins>
|
||||
<https://wiki.documentfoundation.org/Clang_plugins>
|
||||
|
|
|
|||
3
ios/README.md
Normal file
3
ios/README.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# LibreOffice for iOS
|
||||
|
||||
LibreOffice for iOS
|
||||
|
|
@ -9,7 +9,7 @@ IMPORTANT: The `<updated>` element in `vmfwk/distributions/OpenOfficeorg/javave
|
|||
should only be updated for incompatible changes, not for compatible ones. As stated in the commit
|
||||
message of <https://gerrit.libreoffice.org/#/c/69730/> in LibreOffice gerrit:
|
||||
|
||||
"**javavendors\_\*.xml \<updated\> should not have been updated...**
|
||||
javavendors\_\*.xml <updated\> should not have been updated...
|
||||
|
||||
Changing `<updated>` causes `jfw_startVM` and `jfw_getSelectedJRE` (both
|
||||
`jvmfwk/source/framework.cxx`) to fail with `JFW_E_INVALID_SETTINGS`, which in turn causes functionality
|
||||
|
|
|
|||
|
|
@ -8,22 +8,23 @@ tiled rendering API).
|
|||
|
||||
## Integrating LOK Into Other Software
|
||||
|
||||
LOK functionality can be accessed by including LibreOfficeKit.h[xx] in your
|
||||
LOK functionality can be accessed by including `LibreOfficeKit.h[xx]` in your
|
||||
program.
|
||||
|
||||
LOK initialisation (lok_init) requires the inclusion of LibreOfficeKitInit.h in
|
||||
your program. If you use the C++ LibreOfficeKit.hxx header, it already includes
|
||||
LibreOfficeKitInit.h for you.
|
||||
LOK initialisation (`lok_init`) requires the inclusion of `LibreOfficeKitInit.h` in
|
||||
your program. If you use the C++ `LibreOfficeKit.hxx` header, it already includes
|
||||
`LibreOfficeKitInit.h` for you.
|
||||
|
||||
(LibreOfficeKit.hxx is a simple and fully inlined C++ wrapper for the same
|
||||
functionality as in LibreOfficeKit.h.)
|
||||
(`LibreOfficeKit.hxx` is a simple and fully inlined C++ wrapper for the same
|
||||
functionality as in `LibreOfficeKit.h`.)
|
||||
|
||||
An example program can be seen on:
|
||||
https://gitlab.com/ojwb/lloconv
|
||||
<https://gitlab.com/ojwb/lloconv>
|
||||
|
||||
## Tiled Rendering
|
||||
|
||||
To use LOK Tiled Rendering you will need the following before the LOK includes:
|
||||
|
||||
#define LOK_USE_UNSTABLE_API
|
||||
|
||||
(This must be define before ANY LOK header, i.e. including the Init header.)
|
||||
|
|
@ -36,12 +37,12 @@ to bottom-up).
|
|||
## Tiled Editing
|
||||
|
||||
On top of the tiled rendering API, a set of new methods have been added to the
|
||||
lok::Document class to allow basic editing, too. Communication between the LOK
|
||||
`lok::Document` class to allow basic editing, too. Communication between the LOK
|
||||
client and LibreOffice is a two-way channel. The client can initiate an action
|
||||
by calling the above mentioned methods. The most important methods for the
|
||||
client -> LibreOffice communication are:
|
||||
|
||||
- initializeForRendering(), expected to be called right after
|
||||
- `initializeForRendering()`, expected to be called right after
|
||||
`lok::Office::documentLoad()` returned a `lok::Document*`.
|
||||
- `postKeyEvent()`, expected to be called when the user provides input on the
|
||||
(soft-)keyboard.
|
||||
|
|
@ -56,9 +57,9 @@ The other way around (LibreOffice -> LOK client) is implemented using a
|
|||
callback. A LOK client can register a callback using the registerCallback()
|
||||
method. Whenever editing requires some action on the client side, a callback
|
||||
event is emitted. The callback types are described using the
|
||||
LibreOfficeKitCallbackType enumeration in LibreOfficeKitEnums.h, the callback
|
||||
`LibreOfficeKitCallbackType` enumeration in `LibreOfficeKitEnums.h`, the callback
|
||||
function signature itself is provided by the LibreOfficeKitCallback typedef in
|
||||
LibreOfficeKitTypes.h. The most important callback types:
|
||||
`LibreOfficeKitTypes.h`. The most important callback types:
|
||||
|
||||
- `LOK_CALLBACK_INVALIDATE_TILES`: drop all tiles cached on client-side that
|
||||
intersect with the provided rectangle
|
||||
|
|
@ -70,19 +71,19 @@ LibreOfficeKitTypes.h. The most important callback types:
|
|||
|
||||
There are currently two known LOK clients supporting tiled editing:
|
||||
|
||||
- gtktiledviewer (see below), which allows testing the LOK core implementation
|
||||
- `gtktiledviewer` (see below), which allows testing the LOK core implementation
|
||||
on (desktop) Linux
|
||||
- (LibreOffice on) Android
|
||||
|
||||
Core has next to no idea what is the LOK client, so for effective development,
|
||||
it's recommended that the core part is developed against gtktiledviewer, and
|
||||
it's recommended that the core part is developed against `gtktiledviewer`, and
|
||||
once a feature works there, then implement the Android part, with its slower
|
||||
development iteration (slow uploading to the device, the need to link all
|
||||
object files into a single .so, etc).
|
||||
object files into a single `.so`, etc).
|
||||
|
||||
* Debugging with gdb and gtktiledviewer
|
||||
* Debugging with gdb and `gtktiledviewer`
|
||||
|
||||
To run gtktiledviewer:
|
||||
To run `gtktiledviewer`:
|
||||
|
||||
bin/run gtktiledviewer --lo-path=$PWD/instdir/program path/to/test.odt
|
||||
|
||||
|
|
@ -90,11 +91,11 @@ To receive all incoming events from core use `G_MESSAGES_DEBUG=all`
|
|||
|
||||
G_MESSAGES_DEBUG=all bin/run gtktiledviewer --lo-path=$PWD/instdir/program ../test.odt
|
||||
|
||||
To debug with gdb:
|
||||
To debug with `gdb`:
|
||||
|
||||
export LO_TRACE='gdb --tui --args'
|
||||
|
||||
before bin/run, this will run gtktiledviewer in the debugger instead.
|
||||
before `bin/run`, this will run gtktiledviewer in the debugger instead.
|
||||
|
||||
## LibreOfficeKitGtk
|
||||
|
||||
|
|
|
|||
|
|
@ -13,25 +13,21 @@ to boost, but isn't as of now)."
|
|||
|
||||
## Class Overview
|
||||
|
||||
- `git:o3tl/inc/o3tl/cow_wrapper.hxx`
|
||||
- `[git:include/o3tl/cow_wrapper.hxx]`
|
||||
|
||||
A copy-on-write wrapper.
|
||||
|
||||
- `git:o3tl/inc/o3tl/lazy_update.hxx`
|
||||
- `[git:include/o3tl/lazy_update.hxx]`
|
||||
|
||||
This template collects data in input type, and updates the output type with the given update functor,
|
||||
but only if the output is requested. Useful if updating is expensive, or input changes frequently, but
|
||||
output is only comparatively seldom used.
|
||||
|
||||
- `git:o3tl/inc/o3tl/range.hxx`
|
||||
|
||||
Represents a range of integer or iterator values.
|
||||
|
||||
- `git:o3tl/inc/o3tl/vector_pool.hxx`
|
||||
- `[git:include/o3tl/vector_pool.hxx]`
|
||||
|
||||
Simple vector-based memory pool allocator.
|
||||
|
||||
- `git:o3tl/inc/o3tl/functional.hxx`
|
||||
- `[git:include/o3tl/functional.hxx]`
|
||||
|
||||
Some more templates, leftovers in spirit of STLport's old functional
|
||||
header that are not part of the C++ standard (STLport has been
|
||||
|
|
|
|||
|
|
@ -157,6 +157,7 @@ custom shapes. OpenXML SDK tools might help when fixing
|
|||
|
||||
## Export
|
||||
Here is how LO's enhanced custom shapes are exported:
|
||||
|
||||
* Shape name is `ooxml-*` - they are imported from ooxml, export as is.
|
||||
* Denylist - ODF presets that has OOXML equivalent.
|
||||
We convert adjustment values case by case. Microsoft Office
|
||||
|
|
|
|||
3
setup_native/README.md
Normal file
3
setup_native/README.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# Native Code and Scripts for LibreOffice Installer
|
||||
|
||||
Contains native code and scripts for LibreOffice installer.
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
`SFX` is the "old" framework, used for historical reasons.
|
||||
|
||||
An attempt of documentation of this module is located in `git:sfx2/doc`.
|
||||
An attempt of documentation of this module is located in `[git:sfx2/doc]`.
|
||||
|
||||
It contains base classes for document model, view and controller, used
|
||||
by "old" applications like `sw`, `sc`, `sd` (while "new" applications
|
||||
|
|
@ -16,10 +16,10 @@ subdirectory.
|
|||
Documentation about SFX dispatch, SDI etc.:
|
||||
<https://wiki.openoffice.org/wiki/Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2>
|
||||
|
||||
Document load/save code is maintained in `git:sfx2/source/doc/docfile.cxx`
|
||||
Document load/save code is maintained in `[git:sfx2/source/doc/docfile.cxx`]
|
||||
`SfxMedium` class, which handles all the twisty load and save corner cases.
|
||||
|
||||
`git:sfx2/source/appl/sfxhelp.cxx` Start procedure for the online
|
||||
`[git:sfx2/source/appl/sfxhelp.cxx]` Start procedure for the online
|
||||
help viewer top level window; handling of help URL creation and
|
||||
dispatch.
|
||||
|
||||
|
|
|
|||
214
sw/README.md
214
sw/README.md
|
|
@ -5,61 +5,61 @@ 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
|
||||
* `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: plain text filter
|
||||
* basflt
|
||||
* 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)
|
||||
* 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`: Writer core (document model, layout, UNO API implementation)
|
||||
* `filter`: Writer internal filters
|
||||
* `ascii`: plain text filter
|
||||
* `basflt`
|
||||
* `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)
|
||||
* `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
|
||||
- <https://wiki.openoffice.org/wiki/Writer/Core_And_Layout>
|
||||
- <https://wiki.openoffice.org/wiki/Writer/Text_Formatting>
|
||||
|
||||
Writer specific WhichIds are defined in sw/inc/hintids.hxx.
|
||||
Writer specific WhichIds are defined in `sw/inc/hintids.hxx`.
|
||||
|
||||
The details below are mainly about details missing from the Wiki pages.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
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:
|
||||
The `SwNodes` contains the following top-level sections:
|
||||
|
||||
1. Empty
|
||||
2. Footnote content
|
||||
|
|
@ -69,40 +69,40 @@ The SwNodes contains the following top-level sections:
|
|||
|
||||
### 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
|
||||
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
|
||||
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
|
||||
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
|
||||
SwTextNode::m_pSwpHints. There is a base class SwTextAttr with numerous
|
||||
subclasses; the SwTextAttr has a start and end index and a SfxPoolItem
|
||||
The sub-structure of paragraphs is stored in the `SwpHintsArray` member
|
||||
`SwTextNode::m_pSwpHints`. There is a base class `SwTextAttr` with numerous
|
||||
subclasses; the `SwTextAttr` has a start and end index and a `SfxPoolItem`
|
||||
to store the actual formatting attribute.
|
||||
|
||||
There are several sub-categories of SwTextAttr:
|
||||
There are several sub-categories of `SwTextAttr`:
|
||||
|
||||
- formatting attributes: Character Styles (SwTextCharFormat, RES_TXTATR_CHARFMT)
|
||||
and Automatic Styles (no special class, RES_TXTATR_AUTOFMT):
|
||||
these are handled by SwpHintsArray::BuildPortions and MergePortions,
|
||||
- formatting attributes: Character Styles (`SwTextCharFormat`, `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 (SwTextINetFormat, RES_TXTATR_INETFMT),
|
||||
Ruby (SwTextRuby, RES_TXTATR_CJK_RUBY) and Meta/MetaField (SwTextMeta,
|
||||
RES_TXTATR_META/RES_TXTATR_METAFIELD):
|
||||
- nesting attributes: Hyperlinks (`SwTextINetFormat`, `RES_TXTATR_INETFMT`),
|
||||
Ruby (`SwTextRuby`, `RES_TXTATR_CJK_RUBY`) and Meta/MetaField (`SwTextMeta`,
|
||||
`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)
|
||||
- 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.
|
||||
|
||||
|
|
@ -110,90 +110,90 @@ There are several sub-categories of SwTextAttr:
|
|||
|
||||
There are multiple model classes involved for fields:
|
||||
|
||||
- enum SwFieldIds 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
|
||||
- `enum SwFieldIds` 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()
|
||||
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 SwFieldType per
|
||||
`DocumentFieldsManager::InsertFieldType()`. An example for the latter are
|
||||
variable fields (`SwFieldIds::GetExp/SwFieldIds::SetExp`), with one `SwFieldType` 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.
|
||||
- SwFormatField is the SfxPoolItem of a field.
|
||||
The SwFormatField is a SwClient registered at its SwFieldType.
|
||||
The SwFormatField owns the SwField of the field.
|
||||
- SwField contains the core logic of a field.
|
||||
The SwField is owned by the SwFormatField of the field.
|
||||
There are many subclasses of SwField, one for each different type of field.
|
||||
- `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.
|
||||
- `SwFormatField` is the `SfxPoolItem` of a field.
|
||||
The `SwFormatField` is a `SwClient` registered at its `SwFieldType`.
|
||||
The `SwFormatField` owns the `SwField` of the field.
|
||||
- `SwField` contains the core logic of a field.
|
||||
The `SwField` is owned by the `SwFormatField` 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.
|
||||
- SwTextField is the text attribute of a field.
|
||||
It owns the SwFormatField of the field (like all text attributes).
|
||||
- SwXTextField is the UNO wrapper object of a field.
|
||||
It is a SwClient registered at the SwFormatField.
|
||||
Its life-cycle is determined by UNO clients outside of sw; it will get
|
||||
disposed when the SwFormatField dies.
|
||||
- `SwTextField` is the text attribute of a field.
|
||||
It owns the `SwFormatField` of the field (like all text attributes).
|
||||
- `SwXTextField` is the UNO wrapper object of a field.
|
||||
It is a `SwClient` registered at the `SwFormatField`.
|
||||
Its life-cycle is determined by UNO clients outside of `sw`; it will get
|
||||
disposed when the `SwFormatField` dies.
|
||||
|
||||
### Lists
|
||||
|
||||
- SwNumFormat (subclass of SvxNumFormat) determines the formatting of a single
|
||||
- `SwNumFormat` (subclass of `SvxNumFormat`) determines the formatting of a single
|
||||
numbering level.
|
||||
|
||||
- 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
|
||||
- `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
|
||||
applied.
|
||||
|
||||
- SwNumberTreeNode is a base class that represents an abstract node in a
|
||||
- `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
|
||||
actual SwTextNode and also with a SwNumRule;
|
||||
SwTextNode::mpNodeNum points back in the other direction
|
||||
- `SwNodeNum` is the subclass of `SwNumberTreeNode` that connects it with an
|
||||
actual `SwTextNode` and also with a `SwNumRule`;
|
||||
`SwTextNode::mpNodeNum` points back in the other direction
|
||||
|
||||
- SwList represents a list, which is (mostly) a vector of SwNodeNum trees,
|
||||
one per SwNodes top-level section (why that?).
|
||||
- `SwList` represents a list, which is (mostly) a vector of `SwNodeNum` trees,
|
||||
one per `SwNodes` top-level section (why that?).
|
||||
|
||||
- IDocumentListsAccess, sw::DocumentListsManager owns all SwList instances,
|
||||
- `IDocumentListsAccess`, `sw::DocumentListsManager` owns all `SwList` instances,
|
||||
and maintains mappings:
|
||||
+ from list-id to SwList
|
||||
+ from list style name to SwList (the "default" SwList for that list style)
|
||||
+ from list-id to `SwList`
|
||||
+ from list style name to `SwList` (the "default" `SwList` for that list style)
|
||||
|
||||
- IDocumentListItems, sw::DocumentListItemsManager contains a set of all
|
||||
SwNodeNum instances, ordered by SwNode index
|
||||
- `IDocumentListItems`, `sw::DocumentListItemsManager` contains a set of all
|
||||
`SwNodeNum` instances, ordered by `SwNode` index
|
||||
|
||||
- the special Outline numbering rule: SwDoc::mpOutlineRule
|
||||
- the special Outline numbering rule: `SwDoc::mpOutlineRule`
|
||||
|
||||
- IDocumentOutlineNodes, sw::DocumentOutlineNodesManager maintain
|
||||
a list (which is actually stored in SwNodes::m_pOutlineNodes) of SwTextNodes
|
||||
- `IDocumentOutlineNodes`, `sw::DocumentOutlineNodesManager` maintain
|
||||
a list (which is actually stored in `SwNodes::m_pOutlineNodes`) of `SwTextNodes`
|
||||
that either have the Outline numrule applied,
|
||||
or have the RES_PARATR_OUTLINELEVEL item set (note that in the latter case,
|
||||
the SwTextNode does not have a SwNodeNum and is not associated with the
|
||||
SwDoc::mpOutlineRule).
|
||||
or have the `RES_PARATR_OUTLINELEVEL` item set (note that in the latter case,
|
||||
the `SwTextNode` does not have a `SwNodeNum` and is not associated with the
|
||||
`SwDoc::mpOutlineRule`).
|
||||
|
||||
- SwTextNodes and paragraph styles have items/properties:
|
||||
+ RES_PARATR_OUTLINELEVEL/"OutlineLevel" to specify an outline level without
|
||||
necessarily having the outline SwNumRule assigned
|
||||
+ RES_PARATR_NUMRULE/"NumberingStyleName" the list style to apply; may be
|
||||
empty "" which means no list style (to override inherited value)
|
||||
Only SwTextNode has these items:
|
||||
+ RES_PARATR_LIST_ID/"ListId"
|
||||
determines the SwList to which the node is added
|
||||
+ RES_PARATR_LIST_LEVEL/"NumberingLevel"
|
||||
the level at which the SwTextNode will appear in the list
|
||||
+ RES_PARATR_LIST_ISRESTART/"ParaIsNumberingRestart"
|
||||
restart numbering sequence at this SwTextNode
|
||||
+ RES_PARATR_LIST_RESTARTVALUE/"NumberingStartValue"
|
||||
restart numbering sequence at this SwTextNode with this value
|
||||
+ RES_PARATR_LIST_ISCOUNTED/"NumberingIsNumber"
|
||||
- `SwTextNodes` and paragraph styles have items/properties:
|
||||
+ `RES_PARATR_OUTLINELEVEL/"OutlineLevel"` to specify an outline level without
|
||||
necessarily having the outline `SwNumRule` assigned
|
||||
+ `RES_PARATR_NUMRULE/"NumberingStyleName"` the list style to apply; may be
|
||||
empty `""` which means no list style (to override inherited value)
|
||||
Only `SwTextNode` has these items:
|
||||
+ `RES_PARATR_LIST_ID/"ListId"`
|
||||
determines the `SwList` to which the node is added
|
||||
+ `RES_PARATR_LIST_LEVEL/"NumberingLevel"`
|
||||
the level at which the `SwTextNode` will appear in the list
|
||||
+ `RES_PARATR_LIST_ISRESTART/"ParaIsNumberingRestart"`
|
||||
restart numbering sequence at this `SwTextNode`
|
||||
+ `RES_PARATR_LIST_RESTARTVALUE/"NumberingStartValue"`
|
||||
restart numbering sequence at this `SwTextNode` with 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 SwTextNode.
|
||||
these are different from `"phantoms"` because there's still a `SwTextNode`.
|
||||
|
||||
Note that there is no UNO service to represent a list.
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ possible between frames:
|
|||
|
||||
- You can visit the tree by following the upper, lower, next and previous pointers.
|
||||
- The functionality of flowing of a frame across multiple parents (e.g. pages)
|
||||
is implemented in SwFlowFrame, which is not an SwFrame subclass. The logical
|
||||
is implemented in `SwFlowFrame`, which is not an `SwFrame` subclass. 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.)
|
||||
- In case a frame is split into multiple parts, then the first one is called
|
||||
|
|
|
|||
3
unotest/README.md
Normal file
3
unotest/README.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# Tests for UNO
|
||||
|
||||
Contains tests for UNO
|
||||
|
|
@ -3,4 +3,5 @@
|
|||
Beginnings of standalone UNO distribution.
|
||||
|
||||
You may also want to read the README located at:
|
||||
`git:ure/source/README`
|
||||
`[git:ure/source/README]`
|
||||
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ via its UNO API, which has the advantage that the same import/export
|
|||
code can be used for text in all applications (from/to Writer/EditEngine).
|
||||
The filter consumes/produces via SAX UNO API interface (implemented in
|
||||
"sax"). Various bits of the ODF filters are also implemented in
|
||||
applications, for example [git:sw/source/filter/xml].
|
||||
applications, for example `[git:sw/source/filter/xml]`.
|
||||
|
||||
There is a central list of all element or attribute names in
|
||||
`git:include/xmloff/xmltoken.hxx`. The main class of the import filter
|
||||
`[git:include/xmloff/xmltoken.hxx]`. The main class of the import filter
|
||||
is SvXMLImport, and of the export filter SvXMLExport.
|
||||
|
||||
The Import filter maintains a stack of contexts for each element being
|
||||
|
|
@ -42,6 +42,6 @@ to the OpenOffice.org XML format but is possibly outdated and obsolete.
|
|||
When adding a new XML token, you need to add its entry in the following three
|
||||
files:
|
||||
|
||||
* `git:include/xmloff/xmltoken.hxx`
|
||||
* `git:xmloff/source/core/xmltoken.cxx`
|
||||
* `git:xmloff/source/token/tokens.txt`
|
||||
* `[git:include/xmloff/xmltoken.hxx]`
|
||||
* `[git:xmloff/source/core/xmltoken.cxx]`
|
||||
* `[git:xmloff/source/token/tokens.txt]`
|
||||
|
|
|
|||
Loading…
Reference in a new issue