Tomaž Vajngerl
5286d91e80
Import classifies each formula cell:
- Plain non-array, no coext:spill: the import-time walk over
the freshly compiled RPN decides if the formula intends an
array. If yes, prepend @ at the front of the parse and at
the back of the RPN.
- Plain non-array + coext:spill="true": a master saved while in
spill state. Comes back at 1x1 with the dynamic flag, the
position marked spilled. The next interpret re-checks the
blockers.
- Array formula (matrix dims): static array master by default.
coext:spill="true" promotes it to a dynamic-array master.
Legacy Ctrl+Shift+Enter (CSE) arrays without the marker keep
their static iteration-and-pad behaviour.
Export reverses:
- ODF always strips @ on save. The @ is an in-memory marker
only. OOXML and the UI grammar keep it.
- Dynamic master: coext:spill="true" in extended ODF, matrix
dims as before. In spill state, write as plain non-array with
coext:spill="true".
- Static array master: matrix dims, no coext:spill.
GetFormula skips the {} wrapping for dynamic-array masters so
they read back as plain formulas. Static array masters keep {}.
XML_SPILL is added to the xmloff token machinery and the ODF
extension schema (OpenDocument-v1.4+libreoffice-schema.rng)
gains coext:spill on table-cell.
Tests cover each import shape, the FODS export of regular and
spilled masters, the @ insertion on CompileXML, and the @
stripping at the formula-compiler level. ArrayFormulasStatic.ods
is a legacy fixture whose B1 = AND(C4:C52) summarises 49 per-row
value checks. The test runs the grid on import and after an ODS
round trip and confirms plain bare-range cells gain @ while the
five matrix masters stay static, keep their {} wrapping, and
get no coext:spill in the saved XML.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ib8ae345528185c824415ec5d039b6d5cf0d7eac8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4663
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a21f6a3a0eae72fef90576d249d96dc00beeb2c5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207171
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
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]