Mike Kaganski
7f398acee4
A hyperlink in Impress or Draw can carry a name, the Hyperlink
dialog's Name field: the description a screen reader announces, and
what PDF export writes as the link annotation's Contents. Saving the
document and loading it again lost it, and a tooltip carried by a
PPTX never arrived at all, so the link fell back to describing itself
by its own visible text.
Commit 8bf8873f30 (tdf#161583
drawinglayer,editeng,svx,sd: add "Name" to SvxURLField ...,
2025-03-06) gave SvxURLField the name and wired the export path to
it, but no filter. It is not reachable over UNO either, and both
filters go through UNO, so neither had anywhere to put it.
Give the URL field a Name property, and read and write it in both
filters: office:name in ODF, and the tooltip of a:hlinkClick in
OOXML. On import that tooltip becomes the name rather than
Representation, which TextRun overwrites with the link's text; a
shape's own hyperlink goes through the same import context and is
unchanged. A Draw or Impress hyperlink now survives both round trips,
as a Writer one already did.
Inserting a field into shape text does not reach
SvxUnoTextField::CreateFieldData: SvxUnoTextBase builds the stored
field with SvxFieldData::Create, which needs the name too, or it is
dropped again on the way in.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I43d44d55ab460547bbed8acd04d8938a4ee9a615
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12270
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f6218048f057a229eea7f15c198d850ceedd95dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211048
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]