Caolán McNamara
ae6ce55091
On export, always write ControlBorder and ControlBorderColor to the
auto style for control shapes, even when the property state is
DEFAULT_VALUE.
On import, when fo:border is absent, apply the control model's default
border to the shape.
a) New document, user sets flat (2) border:
The constructor default is 2 (flat) but getPropertyDefaultByHandle
returns 1 (3D). Property state is DIRECT_VALUE and the filter exports
fo:border as before. On reimport fo:border is present and applied.
No change in behavior.
b) New document, user sets no (0) border:
Same as flat, DIRECT_VALUE, exported by the filter. No change.
c) New document, user sets 3D (1) border:
1 matches getPropertyDefaultByHandle so property state is
DEFAULT_VALUE and the export filter would previously skip it.
Now export always adds adds ControlBorder explicitly, so fo:border
is written. On reimport fo:border is present so applied.
d) Old document (pre tdf#152974) with no fo:border:
These documents never wrote fo:border for 3D because that was the
real default. Now on import the importer detects the missing
fo:border and queries getPropertyDefault("Border") for the control
which returns 1 (3D) for text controls, restoring the original
border. On reexport the exporter writes an explicit fo:border.
e) Label controls (tdf#167358):
Labels default to no (0) border. Their getPropertyDefault
returns 0, so the importer applies no border when fo:border is
absent, so this fix effort shouldn't cause that problem again.
Change-Id: I365adf84e9d26ae3231331230178381d31bfa829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200685
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
ODF Import and Export Filter Logic
The main library "xo" contains the basic ODF import/export filter
implementation for most applications. The document is accessed
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].
There is a central list of all element or attribute names in
[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 read. There are many classes specific to particular elements, derived from SvXMLImportContext.
Note that for export several different versions of ODF are supported, with the default being the latest ODF version with "extensions", which means it may contain elements and attributes that are only in drafts of the specification or are not yet submitted for specification. Documents produced in the other (non-extended) ODF modes are supposed to be strictly conforming to the respective specification, i.e., only markup defined by the ODF specification is allowed.
There is another library "xof" built from the source/transform directory, which is the filter for the OpenOffice.org XML format. This legacy format is a predecessor of ODF and was the default in OpenOffice.org 1.x versions, which did not support ODF. This filter works as a SAX transformation from/to ODF, i.e., when importing a document the transform library reads the SAX events from the file and generates SAX events that are then consumed by the ODF import filter.
OpenOffice.org XML File Format
There is some stuff in the "dtd" directory which is most likely related to the OpenOffice.org XML format but is possibly outdated and obsolete.
Add New XML Tokens
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]