As Eike indicated in https://bugs.documentfoundation.org/show_bug.cgi?id=146404#c4
COLOR format codes are preserved in ods/fods format.
The pb was the missing map back.
Indeed, we had the mapping for [COLOR<something>] => Color value (eg: "ffaa16")
but not the reverse mapping Color value => [COLOR<something>]
Eike had provided the right code pointer in xmlnumfi.cxx.
First, I thought using PaletteManager but this one is in svx and svx shouldn't be used in xmloff
(dependency pb).
Then I used ChatGpt (GPT-5.6 Luna) and it pointed the right process.
It just consisted to use a similar callback system (DECL_LINK, IMPL_LINK, LINK) of GetUserDefinedColor.
In addition, by testing all this, I noticed that maList in XColorList::GetIndexOfColor was empty.
So I added the Load call in case mbListDirty is true.
Change-Id: I0ef6b5901f2e4c757e88994412dbf79a13100ffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210518
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
The default drawing style names a theme color now, and a PPTX saved
to ODF and back came out with every shape green. A shape that really
did name a theme color lost the reference and came back plain.
A color item holds the color and the theme reference together.
Setting a plain color started from the item the shape inherits from
its style and overwrote the color alone, so the inherited reference
won. Clear the reference, which is what an explicit color means.
The ODF export repeats each shape's fill on a paragraph style,
applied after the graphic style, and the paragraph properties had no
complex color. Carry it there too.
A style's graphic properties took a complex color only when it was
the character one, matched by element name. Match on the context id,
which the fill and stroke colors share.
Add a round trip test through ODF and PPTX with a plain shape, a
themed one, and a themed one with a luminance modulation.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia9550222d18a243287240e4184666d78d0abdd22
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10060
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 07cf37b104983f765d3e1005f677e0058df12026)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210510
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In Word only the first-page-shared flag is shared between header and
footer, while the existence of header and footer is independent.
Split into core flags `DisableFirstHeader` / `DisableFirstFooter`,
properties `HeaderNoFirst` / `FooterNoFirst` (which allows removing some
special checks as the name prefix checks now cover these).
`SectionPropertyMap::setHeaderFooterProperties()` had some special code
to turn off a header but not a footer, add that to do it consistently.
Also rename the ODF attributes, `is-first-page-header-enabled` better
describes the values than `is-first-page-header-shared`.
Signed-off-by: Michael Stahl <michael.stahl@collabora.com>
Change-Id: Ieee9cb7a8f7b4fb7e66352c95142d8ccb06f9cb5
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4383
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit a443891f1a6480421fa08c311526c1a9d4bdd642)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206703
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The problem with not having some but not all headers enabled on a page
style is that Word does page margins differently than Writer, and this
causes `testTdf116486` and `testFdo44176` to fail.
In Writer, it's always additive: page `fo:margin-top` + header
`fo:margin-bottom` gives the spacing from the top of the page to the
body text.
In Word, there is a `w:header` (from top of page to header) and `w:top`
(from top of page to body text) and the problem is, they're not
additive, both are measured from top of page.
If all headers are enabled,
`SectionPropertyMap::PrepareHeaderFooterProperties()` can map this to
`HeaderHeight` and `HeaderBodyDistance` properties, but of course those
won't be used if there's no header on the page.
So import `w:top` as a new property "MinTopBodyDistance" (and also
"MinBottomBodyDistance") implemented as new item
`RES_FRMATR_PAGE_MIN_TOP` (and also `RES_FRMATR_PAGE_MIN_BOTTOM`).
Use it in `SwLayoutFrame::Format()` to set the page frame margins, but
only if there is no header; else rely on the existing header properties.
Export this to ODF as
`coext:min-page-margin-top` and `coext:min-page-margin-bottom`.
Signed-off-by: Michael Stahl <michael.stahl@collabora.com>
Change-Id: I9d98bbf7138c9ef04d4ab1ddcb4c3183a12d9b11
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4310
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e065ba01c029cd01c9128afccdc953e2e3a49e65)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206702
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A broken ODF document may have draw:fill-image-name on the page layout
or drawing-page properties referencing a name with no matching
<draw:fill-image> element in <office:styles>. When the same page layout
also has a style:background-image with actual image data (the old
mechanism), recover the missing bitmap table entry from it.
This is done before deactivateOldFillStyleDefinitions so the
BackGraphic property indices are still valid. The recovered bitmap is
inserted into the BitmapTable so the draw:fill-image-name reference
resolves correctly, making the background image visible in the page
setup dialog (Area tab) and in Collabora Online.
Change-Id: I5c1b658621f288af026c57e69d13363fbc1fe45a
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1142
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit b370baba6ac0daa31395f47b80bc5c11cc561b1e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206429
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In case of 2 characters string text,
with a delimiter as text and a blank width string like
"-"_)
the delimiter is now treated as text
Add qa test with format of bug report:
[>0]#,##0_);[<0](#,##0);"-"_)
Change-Id: Idd4542bd186c6b6b348f6716bee2fd5055f2c83f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199314
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
found by converting tdf34406-1.odp to pptx and running officeotron on the output
INFO - Validating part "/ppt/slides/slide4.xml" using schema "29500T/pml.xsd" ...
ERROR - (slides/slide4.xml:2 col:24,296) cvc-datatype-valid.1.2.3:
'-4900000' is not a valid value of union type 'ST_PositiveFixedPercentage'.
The import data in content.xml looks like:
<style:style style:name="ce8" style:family="table-cell">
<style:graphic-properties draw:fill="solid" draw:fill-color="#808080"
draw:opacity="-4900%"
where the opacity value is wildly out of range. So validate on input.
Change-Id: I1d9146a3f38f975a5e229f63e17fca6fb435439b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194950
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 80c58f15baf79f19b954b1199cbca9c2f3dcf8bf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194952
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Implements support for ODF fo:text-align start and end in paragraph
styles. The new alignment options can be selected in the paragraph
dialog. Further user interface changes are tracked as separate bugs.
This change also adds START and END to css.style.ParagraphAdjust, which
is flagged as an incompatible UNO API change.
Change-Id: I2ee57f0029de7b794bc1ecd3eddbbd90af5dfdb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192932
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Currently, we do not correctly implement fo:text-align "start" or "end".
Support for these attribute values is faked at the parser level by
always treating "start" to mean "left", and "end" to mean "right".
In addition to this, previously, the ODF serializer always printed
"start" for left alignment, and "end" for right alignment. This behavior
is harmless for documents that only contain LTR paragraphs, but mirrors
the alignment of all RTL paragraphs per the ODF standard. Other programs
cannot view these documents as intended.
This change updates the ODF serializer to instead print "left" for left
alignment, and "right" for right alignment, reflecting our actual
document layout.
Change-Id: I3a1134924f4adf71b7a0ea3f672e8c1580770841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192858
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
What is actually reported is Use-of-uninitialized-value but I don't see
a problem of an uninitialized value. But I do see that nVal is -2147483648
so presumably that's the actual problem.
Change-Id: I9e5bdcb0e8fdfc6274888c1d7f1c94a65a8613d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192238
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Add new paragraph justification options "Minimum glyph scaling"
and "Maximum glyph scaling" to improve typography, like DTP software
do, allowing to typeset visually better paragraphs, especially narrow
columns without unacceptably big word spacing.
* Add spin boxes to Alignment in paragraph formatting dialog window;
* Store properties in paragraph model:
css::style::ParagraphProperties::ParaPropScaleWidthMinimum
css::style::ParagraphProperties::ParaPropScaleWidthMaximum
Note: desired glyph scaling is already supported by ODF/UNO,
see css::style::CharacterProperties::CharScaleWidth.
* Implement visual layout of minimum and maximum glyph scaling,
limited by the available extra word spacing and letter spacing,
too.
Note: last line can exceed the paragraph width, because minimum
glyph scaling, also minimum letter scaling of the last line
haven't been applied there, yet.
* Add ODF import/export (loext:text-scale-maximum and
loext:text-scale-minimum, where style:text-scale is for the
desired text scaling).
* Add ODF unit test.
Note: hyphenated lines, lines with multiple portions haven't
been using custom glyph scaling, yet.
Note: resolution of glyph scaling is 1 percent, which will
avoid of overgeneration of font types using variable fonts.
Change-Id: I9b4576dde4303437b64e37202c47f888f94c3f67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190534
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Use the returned object directly, instead of creating an O(U)String.
Concatenate with adjacent appends.
Change-Id: Id84563876bbb0df50d9e0bfc0b0c033630d4be81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190351
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Before the change, ODF import created unique font name every time,
using '?' as extra; that meant that every document with embedded
fonts would create and register its fonts, even when it was already
registered by a different document. On the other hand, OOXML import
would rely on file name match, which might not guarantee that the
files were actually identical.
This change compares the existing file content, which would only
happen when the files are of the same size. This also writes the
file only after doing all the checks.
Change-Id: I2377bd6c24291d9b4113607b4d48a223187b635c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189270
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Similar to commit 0e9091b6db
2025-05-26
sd: PPTX embedded fonts - skip common fonts
Tests for font embedding were modified to embed fonts not in the
common font list.
Change-Id: Ia0d95bc8be7cf6b590f8074cabe3568271ef18f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188989
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Add new paragraph justification option "Maximum letter spacing"
to distribute letters on (part of) the available blank area of the
justified line instead of overstretching word spacing, like DTP
software do.
This improves typography a lot, allowing typesetting visually better
i.e. more readable paragraphs, minimizing or removing rivers and
too big word spacing (which was common in columns or text without
hyphenation).
* Add spin box to Alignment in paragraph formatting dialog window,
(also add spin boxes for future Minimum and the alternative
percent-based Desired letter spacing, see CharKerning);
For example (only ASCII visualization!), 100% maximum letter
spacing adds a space character-width blank space between the
characters, including the original space:
0%:
Lorem ipsum
pellentesque dolores
vitae.
100%:
L o r e m i p s u m
pellentesque dolores
vitae.
Normal value: 3%-5% (or more for very narrow columns), which means
e.g. 1-2 twips (twip = 1/20 pt) letter spacing in a ~12 pt text.
Note: resolution of the custom letter spacing is only 1 twip yet.
* Store properties in paragraph model:
css::style::ParagraphProperties::ParaPropLetterSpacingMaximum
css::style::ParagraphProperties::ParaPropLetterSpacingMinimum
Note: desired letter spacing is already supported by ODF/UNO,
see css::style::CharacterProperties::CharKerning.
* Implement visual layout of maximum letter spacing.
Note: after the last character of the line, there is an
unwanted letter-spacing, yet (which is visible only with
big letter-spacing values).
* Add ODF import/export (loext:letter-spacing-maximum and
loext:letter-spacing-minimum)
* Add ODF unit test.
Note: hyphenated lines and lines with multiple portions do not
yet use custom letter spacing, yet.
Change-Id: Ieac9f21631b90ae46bed4501f12da0d15ed84d63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188653
Tested-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
... property #2"
This reverts my 25.2 commits d4dad2e181
and 5a617f77ee.
Obviously this entire thing is just too broken
for a simple guy like me to fix.
It seems like each kind of control has its own definition
of what should happen if the border is not specified.
So much for ODF standardization of default style values...
This makes it virtually impossible to force a setting at import time,
and since styles (without specified fo:borders)
could theoretically be shared between the different control types,
it might also make it impossible to force an export as well?
make CppunitTest_xmloff_style
Change-Id: I0182878a16213ad2c7f06524fe85388aae86551f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187654
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
It makes no sense to insist on a random type, only to reinterpret_cast
it everywhere. An opaque void fits the case perfectly.
Change-Id: If945b1c59d98c5f561350db649f29fe8036e7cdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186982
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previously, when authoring documents containing multiple languages,
certain characters (e.g. smart quotes) could use the wrong/undesired
font. For example, if a Chinese word is quoted inside English text, the
right quotation mark would use the Chinese font rather than the
intuitively-expected English font. Users had no way to control this
behavior.
With this change, Writer will now set an appropriate style:script-type
hint when the user manually specifies a language for a selection in the
user interface. This can be used to quickly correct instances of the
above problem.
Change-Id: I6f8c924d230e3518272e2abb1cbea5e0e7451e9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186394
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Several font weights (Ultra Light, Light, and Medium) were incorrectly
saved to file.
ULTRALIGHT and LIGHT were saved as fo:font-weight 150 and 250,
respectively. But, according to ODF spec, the values of the
fo:font-weight attribute are normal, bold, 100, 200, 300, 400, 500, 600,
700, 800 or 900:
https://docs.oasis-open.org/office/v1.2/cd05/OpenDocument-v1.2-cd05-part1.html#a_20_184_fo_font-weight
This change fixes ULTRALIGHT and LIGHT to map to 200 and 300,
respectively.
This change also introduces awt::FontWeight::MEDIUM and gives it an
arbitrary 105% value (the percentage values in awt::FontWeight make no
sense at all, THIN numeric value is 100, so it should be 25% of NORMAL
whose numeric value is 400, but it is 50% in awt::FontWeight), and fix
the mapping to and from awt::FontWeight to handle medium weight
properly, and fixes the numeric weight values saved to file.
The backward compatibility for this change are likely negligible since
we don’t support extended font families on Windows, or Linux for
non-variable fonts.
Change-Id: I80ece7bb05462b0f3aceb7f39409f8135f63e94d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186128
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Implemented the ODF 1.0 style:script-type text property. This property
can be used by documents to influence which script type-dependent
attributes are used when rendering certain characters.
This implementation uses the following semantics:
- If unset, the behavior is as it was in previous versions.
- If set to latin, asian, or complex, those characters not mapped by the
ODF standard to a script type are treated as latin, asian, or complex,
respectively.
- If set to ignore, all characters will be treated as latin. This value
is intended to be used for interoperability with file formats that
don't implement script types (e.g. HTML).
Change-Id: If81a1390ee455fd971dea655d161d9c3f44fd08a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186309
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Before commit e61a179b4f (tdf#166627: embed
fonts everywhere we emit font data, 2025-05-23), embedding of fonts only
happened during export of content.xml, to avoid complexity of shared data
between different instances of SvXMLExport, created separately per stream.
The said commit introduced a way to pass the data between these instances,
and embedding now is done by any SvXMLExport instance that needs to emit
font-face-decls. Currently, only the first declaration of a used embedded
font gets its font-face-src.
But this is wrong, when the same embedded font in another stream, where it
is also used, does not reference its files. This patch allows all streams
to emit font-face-src for all fonts used in it. File duplication in ZIP is
avoided by passing the embedded file information between SvXMLExport, with
font file hash and its path in ZIP, instead of font names.
Change-Id: I7a62e50c086d8741dbc8aadf61d0f008bad916ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185720
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit 69ed893087 (tdf#160253: fix list
identifier export decision code) made a large change to the autostyle
collection procedure, which became more precise. It turns out, that
before that change, exporting content.xml gathered autostyles from
page definitions, too, meaning that the fonts used there were marked
as used in that pass. After the change, that pass doesn't look into
the page styles and their content, and the fonts that are only used
in headers/footers aren't seen as used in that pass.
The font embedding procedure was previously implemented to only do
the embedding during content.xml export, to avoid duplicating font
files from each pass. Since each stream was exported by a separate
instance of SvXMLExport, it was considered difficult to maintain the
already embedded fonts list across all passes. It assumed that the
export of content.xml sees all used fonts.
But after the described change, this assumption doesn't hold anymore.
We need to make sure to embed all fonts found in all passes.
This change introduces such state, implemented as set of font names
maintained in the object that exports all the streams, creating an
exporter for each. Using a new set of function to set and get the
"already embedded" font list in SvXMLExport, the outer object passes
that list to each created SvXMLExport instance, and after the call
to `filter`, retrieves the updated list, to pass it to the next one.
The change required to move some members from XMLFontAutoStylePool
to SvXMLExport, to avoid additional complexity of passing the list
from SvXMLExport to XMLFontAutoStylePool. The implementations of
the moved methods are kept in XMLFontAutoStylePool.cxx, because the
internal structs used in the methods are defined there.
After the change, some of the embedded font file references, that
previously appeared in content.xml, will now be in styles.xml.
Change-Id: Iaa26f1d1d623dee5a5c43600ea5fd2af1d04b46f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185704
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In LO 7.5, ORichTextModel changed the app default to use a flat border
(in order to better match how PDF/print looks)
while the file-spec's default for undefined borders is 3d,
so during import time we ALWAYS need to specify 3d as the border.
The patch replaces 25.2 commit 5a617f77ee
tdf#156707 xmloff import: always provide ControlBorder property
which wasn't wrong, but just was incomplete.
It only handled the situation where there was a fo:border element
which didn't specify 3d/flat/none,
but didn't handle the situation where there was no fo:border at all
in style:graphic-properties.
[On export, since the 3d property is the default value,
fo:border is not even provided as something to be exported,
and therefore only "solid" and "none"
are ever exported as fo:border qualifiers.]
I modified the unit test to remove the fo:border
by clearing the unused-by-3d green border colour
(although the green was seen if the wrong flat border was assigned).
make CppunitTest_xmloff_style CPPUNIT_TEST_NAME=testTdf156707
Change-Id: I70718fe964a7c3578f8edbf8591fe2e3417ec60b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185619
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
To avoid of rivers and too much hyphenation, add minimum
and maximum word spacing options, similar to XSL-FO/CSS
and DTP software.
Only limiting hyphenation was implemented: hyphenation
of the words are disabled, if it's possible to expand
or shrink the spaces of the line within the values specified
by the maximum and minimum word spacing. First try to apply
the minimum word spacing, and if not possible, then the
maximum word spacing.
Note: maximum allowed shrinking has been applied for the
hyphenated lines instead of the minimum to remove the
hyphenation, yet. With the suggested default word spacing
values, this results no or minimal differences.
New UNO paragraph properties:
com::sun::star::text::ParaWordSpacingMinimum
com::sun::star::text::ParaWordSpacingMaximum
New ODF paragraph attributes:
loext:word-spacing-minimum
loext:word-spacing-maximum
New paragraph settings on Text Align pane:
Minimum word spacing
Maximum word spacing
While the desired word spacing got "Desired" label.
Note: suggested values of minimum, desired and
maximum word spacing are 80%, 100% and 133% (default
values e.g. in Adobe InDesign), in narrow columns e.g.
60%, 100% and 150%.
Follow-up to commit 7d6696757d
"tdf#159923 sw cui offapi xmloff: add custom word spacing".
Change-Id: I7f2a07f7fdb634cb16cdd8c2c937ca911b968405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184595
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Add com::sun::star::text::ParaWordSpacing UNO
and loext:word-spacing ODF extensions to set
desired word spacing of a justified paragraph
relative to the width of the space character,
like DTP software do.
Add Justification section and "Word spacing"
spin box to the Text Align pane of paragraph settings.
This extends not only the smart justify interoperability
feature for custom shrinking (until 0%), but for custom
expansion, too, until 1000%, like Adobe InDesign do.
Note: this value hasn't been applied in the last
paragraph line, yet.
See also XSL-FO/CSS word-spacing and
commit 7d08767b89
"tdf#130088 tdf#119908 smart justify: fix DOCX line count + compat opt."
Change-Id: I06f771335135e4682a1d1abfc9a247dbe4bc6b66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184187
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
manage SvXMLImportPropertyMapper with unique_ptr instead
of rtl::Reference, which avoids a bunch of ref-counting
traffic
Change-Id: I1e0e95408cdd5dc4271fa72178e57087737eb062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Julien Nabet