[Libreoffice-commits] core.git: animations/README.md apple_remote/README.md basegfx/README.md bin/README.md cli_ure/README.md compilerplugins/README.md ios/README.md jvmfwk/README.md libreofficekit/README.md o3tl/README.md oox/README.md README.md setup_native/README.md sfx2/README.md sw/README.md unotest/README.md ure/README.md xmloff/README.md
Hossein (via logerrit)
logerrit at kemper.freedesktop.org
Mon Apr 19 09:14:19 UTC 2021
README.md | 2
animations/README.md | 2
apple_remote/README.md | 7 -
basegfx/README.md | 2
bin/README.md | 2
cli_ure/README.md | 3
compilerplugins/README.md | 2
ios/README.md | 3
jvmfwk/README.md | 2
libreofficekit/README.md | 37 ++++---
o3tl/README.md | 12 --
oox/README.md | 1
setup_native/README.md | 3
sfx2/README.md | 6 -
sw/README.md | 216 +++++++++++++++++++++++-----------------------
unotest/README.md | 3
ure/README.md | 3
xmloff/README.md | 10 +-
18 files changed, 162 insertions(+), 154 deletions(-)
New commits:
commit 628c1c3b0791bb0866917442040dc491de2acb61
Author: Hossein <hossein.ir at gmail.com>
AuthorDate: Mon Apr 12 22:29:51 2021 +0430
Commit: Michael Stahl <michael.stahl at allotropia.de>
CommitDate: Mon Apr 19 11:13:41 2021 +0200
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 at allotropia.de>
diff --git a/README.md b/README.md
index 2e5561998892..35a68bcf4795 100644
--- a/README.md
+++ b/README.md
@@ -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
diff --git a/animations/README.md b/animations/README.md
index d03a756a1682..053cd2b0f46e 100644
--- a/animations/README.md
+++ b/animations/README.md
@@ -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`.
diff --git a/apple_remote/README.md b/apple_remote/README.md
index aed352e42e4b..2f7418ff20c7 100644
--- a/apple_remote/README.md
+++ b/apple_remote/README.md
@@ -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
diff --git a/basegfx/README.md b/basegfx/README.md
index fd4660d8eab1..76f2102b9e65 100644
--- a/basegfx/README.md
+++ b/basegfx/README.md
@@ -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`).
diff --git a/bin/README.md b/bin/README.md
index 572be3174773..b81d1f4d1cf3 100644
--- a/bin/README.md
+++ b/bin/README.md
@@ -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.
diff --git a/cli_ure/README.md b/cli_ure/README.md
index 8cf07cf00b24..b6f27e7c6979 100644
--- a/cli_ure/README.md
+++ b/cli_ure/README.md
@@ -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]`
diff --git a/compilerplugins/README.md b/compilerplugins/README.md
index e076f408f07a..9dbea95a56c7 100644
--- a/compilerplugins/README.md
+++ b/compilerplugins/README.md
@@ -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>
diff --git a/ios/README.md b/ios/README.md
new file mode 100644
index 000000000000..81d89ed828b2
--- /dev/null
+++ b/ios/README.md
@@ -0,0 +1,3 @@
+# LibreOffice for iOS
+
+LibreOffice for iOS
diff --git a/jvmfwk/README.md b/jvmfwk/README.md
index b21540851683..3f99d9dba89a 100644
--- a/jvmfwk/README.md
+++ b/jvmfwk/README.md
@@ -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
diff --git a/libreofficekit/README.md b/libreofficekit/README.md
index 4932b791d319..7eb7bb5fd355 100644
--- a/libreofficekit/README.md
+++ b/libreofficekit/README.md
@@ -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
diff --git a/o3tl/README.md b/o3tl/README.md
index 89cb9a5c1315..dccfc6028d91 100644
--- a/o3tl/README.md
+++ b/o3tl/README.md
@@ -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
diff --git a/oox/README.md b/oox/README.md
index 8f42418dd902..a522b583cdcb 100644
--- a/oox/README.md
+++ b/oox/README.md
@@ -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
diff --git a/setup_native/README.md b/setup_native/README.md
new file mode 100644
index 000000000000..ce145720fa8a
--- /dev/null
+++ b/setup_native/README.md
@@ -0,0 +1,3 @@
+# Native Code and Scripts for LibreOffice Installer
+
+Contains native code and scripts for LibreOffice installer.
diff --git a/sfx2/README.md b/sfx2/README.md
index 58e97d62361d..3b91584759eb 100644
--- a/sfx2/README.md
+++ b/sfx2/README.md
@@ -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.
diff --git a/sw/README.md b/sw/README.md
index f4c6e44e1c28..58a6cc9e1bdb 100644
--- a/sw/README.md
+++ b/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).
-
-- 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"
+ 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"`
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
diff --git a/unotest/README.md b/unotest/README.md
new file mode 100644
index 000000000000..633282b4a817
--- /dev/null
+++ b/unotest/README.md
@@ -0,0 +1,3 @@
+# Tests for UNO
+
+Contains tests for UNO
diff --git a/ure/README.md b/ure/README.md
index 62ab46110284..bb63a57420c7 100644
--- a/ure/README.md
+++ b/ure/README.md
@@ -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]`
+
diff --git a/xmloff/README.md b/xmloff/README.md
index 3eb276c096ad..4c08c6b31645 100644
--- a/xmloff/README.md
+++ b/xmloff/README.md
@@ -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]`
More information about the Libreoffice-commits
mailing list