Wrap the text portions inside the content control in a
<loext:content-control> XML element. Also map the (so far) single UNO
property of it to <loext:content-control
loext:showing-place-holder="...">.
This is just initial export for inline text content controls, more
properties are to be added in follow-up commits.
Change-Id: I5d928255b925ed7e08fb635ba39f546e9a4879de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132717
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
already in its ctor
which changed since...
commit 9009663deb
Date: Sun Feb 26 22:48:06 2017 +0100
tdf#83257 [API-CHANGE] Pivot chart implementation
which defers it, take a probably safely backportable approach here to
fix it.
Change-Id: I1863791af7ae737f337993833a9cf1429a3a8028
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132286
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Refer to the 12 pre-defined colors by name + don't write the attribute
for the case when there is no theme.
Change-Id: I37c984b3371ec878a0d733977f5c937dce27c440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131717
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The ODF spec says that text:continue-numbering="true" should only
continue the numbering in case the styles of the previous and the
current list match.
In contrast, Word continues the numbering even in case there is e.g.
numbering, then bullets, then numbering again, in case the list styles of
the two numberings are the same.
Work this around at import time when the generator confirms that the
document is coming from Word. At least Office 2019 and the latest
renderer at office.com is affected.
(I've mailed dochelp@microsoft, no answer yet.)
Change-Id: Ib63e14322e5501a6220f798abd9365d7913dab4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130503
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The fix for tdf#145700 has changed the internal handling so, that
values larger than 100% from MS binary import are now kept und correctly
used. But ODF 1.2 and 1.3 have the range restricted to
zeroToHundredPercent.
The patch writes values larger than 100% in extended namespace for our
'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so
that older versions get a meaninful value, but clamps it to [0,100] if
necessary to get valid files.
Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The fix tries to make rendering similar to MS Office.
The ODF standard follows closely the extrusion in RTF and MS binary
format. Rendering uses the 3D scene engine.
The main problem was, that the z-component of the direction was
interpreted with opposite sign. As result the maximum of a light was at
false position. Especially a direction from the observer to the object
has produced a light behind the shape and so looks as if light was off.
The wrong z-direction has produced lighting, which was less intensive
than in MS Office. To compensate that, a third light source was added
as workaround. That part is removed.
Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity
and D3DMaterialSpecular (= UI Specular color). That was not only wrong
in OOo but in my previous patch too.
D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'.
Relationship is Intensity = 2^c3DShininess.
D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and
and c3DKeyIntensity. The light source was missing, but needs to be
included, because c3DSpecularAmt is 'the ratio of incident to specular
light that is reflected on a shape'.
The old unit tests are adapted to this change.
MS gives no information how it softens a light in case of harsh=false.
ODF specifies it as 'implementation-defined'. The patch uses four
additional lights, which have directions in 60° angle to the original
light. The light intensity is distributed. That comes near to rendering
in MS Office. Changing our 3D engine to provide 'soft' lights was not
doable for me.
The way MS Office renders a 'metal' surface is different from ODF
specification. To distinguish the kinds, I have introduced a new
property MetalType. I have discussed it with the ODF TC (see minutes
from 2022-02-07) and got the advise to use namespaced values.
Therefore the datatype is not boolean.
The 'Surface' drop-down in the extrusion bar is changed to make the two
kinds of rendering 'Metal' available to the user.
If a user sets surface 'Metal' in the UI of MS Office, it sets not only
fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our
3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color
not implemented. To get a similar rendering I change the material color
of the 3D-objects as workaround.
Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Refer to the 12 pre-defined colors by name + don't write the attribute
for the case when there is no theme.
Change-Id: Ib6ab5b7b34d896a36e04309bf0cb410998acce01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126566
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Which requires describing the schema, which is really just a new
<loext:theme> element, the rest reuses the color-table markup, which
wasn't used in ODF so far (but was used in our .soc files).
Also make sure that we only do this in ODF extended mode (which is the
default).
Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
...after aa5ee0085c "Stop swallowing exceptions in
~ScopeGuard" had dropped the catch blocks from ~ScopeGuard to make it usable in
Library_salhelper in 0c1c300ed7 "Rather use
ScopeGuard to prevent catch and rethrow". But using the original
suppress_fun_call_w_exception, which used css::uno::Exception, would have caused
the same circular-dependency issue again that
aa5ee0085c had solved, so drop the use of
css::uno::Exception (and SAL_WARN, which triggered a number of missing #include
<sal/log.hxx>) also from suppress_fun_call_w_exception. After all, that was
__COVERITY__-only code that wasn't meant to be actually run, so it shouldn't
matter if we just catch everything and silently terminate.
Change-Id: If28a214709e4636e1c23a49f2d95d87c91492f14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126404
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
so we don't have to pass in the size of the string literal.
This is mostly a preparatory change, to make an another
patch of mine less noisy.
Change-Id: Idafcd68586b8b465e63dc89e4a4180d2e70ac3a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125080
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Remove overloads taking const char* which were not needed, because
every their use eventually took a string literal convertible to
OUString directly.
Many other literals were converted to OUStringLiterals.
Change-Id: Ia1e742a8087776cd20bf5094dc415dafd9a8834a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123155
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
And the same in the other direction: link a para style from a char
style.
With this, the ODT filter is on par with the DOCX one for this feature.
Change-Id: Idd994b933672ab47a5f87a75c92abc137d3c73b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122753
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
we only use it at one site, and at that site we can use the CharClass
inside the formatter whose locale we just updated.
Spotted by erack.
Change-Id: I049c6fc399e62cfe83f3ae396ea8d0e7497e673f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122250
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
noting that XMLTokenEnum was already being treated as being limited to
32-bits, we bitmask it together with namespaces
Change-Id: Ic48f2a662452d1b8e022078d31a723d2ac65aef0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121707
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is just the import side, the export side still needs doing.
The used attribute was already part of ODF, and NumberingLevel for para
styles where already imported/exported for DOCX.
Change-Id: I8385ed23dc799c99e81318387236341b404d01a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121515
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
When <c15:showDataLabelsRange> boolean flag is present, the imported
label texts are added as the first text field in oox data label model.
The cell-range associated is also preserved. The export part preserves
the how labels were store originally in <c15:datalabelsRange>.
However in order to make the custom labels reflect the contents of the
cells in the associated cell-range, more work needs to be done. For this
the labels present in <c15:datalabelsRange> needs to be made available
as a data-sequence with a new "role" like "point-labels" in
XInternalDataProvider implementation and and make the label renderer
read this data source rather than consulting the custom label fields
property which is static after import.
Change-Id: Ibc7045fa5ea209d463680c96efb49a06662d2500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
... as they may be significant as separators between keywords of
same letters.
Also strip trailing empty text as meaningless, except if the only
element.
>General;General<
earlier both General were written as
<number:number-style style:name="N111P0" style:volatile="true">
<number:number number:min-integer-digits="1"/>
<number:text/>
</number:number-style>
for which now <number:text> is not.
Change-Id: I4809b1c784667994303b49d8e4ab0e857367e2cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120856
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Map it to <text:bibliography-mark loext:local-url="...">.
Note how this can be a relative URL, while the text:url attribute is
typically a http(s) URL.
Change-Id: If16171c9761221841ff07824cb0466fd42911480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119407
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
in SvXMLImport.
Remove an assert in XSecParser because std::move on std::optional
does not make the optional empty, unlike it's effect on std::unique_ptr.
Change-Id: Ie94d01423bf694a37e4bd7f2c0235c5f79a44efe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119302
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
With CWS impress64 a partial fix for this was implemented to drop
unreferenced named items including all non-color fills after ODF import,
but this is only done in sd so move the code that does that to svx and
call it from sc and sw as well.
Implement some UNO interface for this, it's at least better than a magic
string, and not obvious how a better solution would look like since it's
known only at the end of the import if a bitmap is used or not.
Another problem: when the Area tab is used to change to a different kind
of fill, the items with the details for the previous fill aren't
cleared, and so they are written to ODF files. Hence bitmaps in the
file can be referenced even if they aren't actually used, and bloat up
the files.
Fix this by dropping all unused draw:fill-image-name attributes in ODF
import.
Also do the same for Gradient and Hatch fills; Transparency gradients
can be combined with anything so leave them as they are.
Change-Id: I0b591fd9f963d974d0c3e7208b99621ad61dd93c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118950
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Instead of style:num-prefix and style:num-suffix new list format
is much more flexible for storing list multilevel numberings.
Now it is possible to have not just prefix/suffix but any random
separators between levels, arbitrary levels order, etc.
Internal LO format for list format is changed: instead of placeholders
like %1, %2, etc we right now use %1%, %2%... Reason: for ODT documents,
having more than 9 levels there is ambiguity in "%10": it is "%1"
followed by "0" suffix, or "%10"?
Aux changes:
* removed zero width space hack: since format string is always defined
this hack is interfering with standard list numbers printing
(see changes in ooxmlexport14.cxx, ww8export3.cxx tests)
* changed cross-references values to lists: they are now including full
list label string: previously this was bit self-contradictory (see
changes in odfexport.cxx and check_cross_references.py tests)
Change-Id: I9696cc4846375c5f6222539aeaadbca5ae58ce27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117156
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
If Options → LibreOffice → Security → Security Options
and Warnings → Options... → Security Options → Remove personal
information on saving" is enabled.
Use the same time (1970-01-01T00:00:00) for mandatory
time stamps, and replace authors and creator-initials with
"1", "2", "3" etc., also to avoid of joining adjacent
redline ranges.
Note: to see the work of the unit test in Linux command line:
(cd sw && make UITest_writer_tests7 UITEST_TEST_NAME="tdf90401.tdf90401.test_tdf90401_remove_personal_info" SAL_USE_VCLPLUGIN=gen)
Change-Id: I3b4d710dbeeee12177aff378597cd2b683ca6c25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117319
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
to OpenDocument format using
<style:table-row-properties loext:text-changes-only="false"/>
Rename also com::sun::star::text::TextTableRow::IsNotTracked
to com::sun::star::text::TextTableRow::HasTextChangesOnly.
Follow-up to commit 05366b8e66
"tdf#60382 sw offapi: add change tracking of table/row deletion".
Change-Id: Iefb0d4095af0983fdd15697d5b80073d18d21bd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116212
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Miklos Vajna