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
The problem is that for an at-page anchor SwXDrawPage::add() sets an
anchor position, but then a fieldmark is inserted and the node with the
anchor position is deleted.
The code that sets the surprising anchor position for at-page shape was
added in commit cf345e026f "Fix #91289#:
Draw objects anchored at page but without page number" and is similar to
the code for fly-frames added in commit
2e6d999cf8 "If no page number is given for
page bound frames, calculate it using cursor" except that it is missing
a check for GetPageNum() == 0, for no obvious reason.
The matching code to replace the anchor position with a page number is
in SwFlyFrameFormat::MakeFrames() and was added in commit
572a48cd16 "Fix #85019#: Insertion of
flyframes without correct pagenumber"; it's not clear if this is only
needed for shapes inserted via the above 2 UNO APIs or also for shapes
inserted via UI.
Then there is the issue that the page number is set in
XMLTextShapeImportHelper::addShape() only after the shape is inserted,
which was added and commented in commit
b5fc47fe5c, earlier than all the above
commits; testing shows that if the page number is set before inserting
the shape, the shape ends up on the expected page anyway.
Let's change this:
1. the page number is set before inserting the shape
2. at-page anchor with page number is left as is
3. at-page anchor without page number gets anchor position and is changed
to at-char
Change-Id: I2f874bec8424de5eee94cf022e3b49382eaa55f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132479
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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>
In case <draw:frame> has style:rel-width="..." and style:rel-height="...", then the ODF spec says that:
> To support consumers that do not support relative width, producers
> should also provide the width in a svg:width 19.575 attribute.
If the motivation is to support simple consumers, then it's better if we
write the up to date layout size as the fallback value, not what was the
layout size at insert time.
(But don't ignore this at import time: 80% width and "scale" for height
is a valid combination, and then height/width is needed to know the
ratio.)
Change-Id: Iefeb43cdb141b01a732086c37186201a3fef0952
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131662
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Map
<text:line-break loext:clear="..."/>
to com.sun.star.text.LineBreak and set its Clear property based on the
XML attribute.
Change-Id: I76d375de23146592c2327df16aa5066ee2a6598d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131645
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This attribute is needed when a numbering is built using multiple,
independent <text:list> elements. In that case the markup to connect
these are either:
<text:list text:style-name="L1">
</text:list>
...
<text:list text:continue-numbering="true" text:style-name="L1">
</text:list>
In case there is no other list in-between, or:
<text:list xml:id="..." text:style-name="L1">
</text:list>
...
<text:list text:continue-list="..." text:style-name="L1">
</text:list>
In case there are other lists in-between.
This means that at least in case all the text nodes of the numbering are
after each other, then the random value in xml:id="..." is never
referenced, so it can be omitted.
This helps deterministic ODF output when the input is HTML, where there
are never text:continue-list="..." attributes that would refer to these
xml:id="..." attributes.
Change-Id: Ice69422a12d4229879f89f3a4a24ed926c6d43af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131322
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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>
Previous fix had crafted condition for fixing one specific
case but it was braking other cases.
(svx/source/unodraw/unoshtxt.cxx)
For example it was not possible to remove text inside textbox
and save that -> it was not saved in LOK case.
Problem is that we had not saved text inside shape and due
to calling GetBackgroundTextForwarder() we did reset to
empty content. In this patch we force UpdateData() call
by releasing lock just before we try to do some final
text cursor operations what applies changes in the content
and prevents us from losing it.
Call which was invoking GetBackgroundTextForwarder() was:
file: xmloff/source/draw/ximpshap.cxx
method: SdXMLShapeContext::endFastElement
line: mxCursor->gotoEnd( false );
After that I found that we had bug which breaks test:
sd/qa/unit/import-tests.cxx odp/shapes-test.odp
It occurs when using this patch or when not using my code
but removing locking functionality for SvxTextEditSourceImpl.
NbcSetOutlinerParaObjectForText triggers shape resizing
even when no text is present inside.
Summary:
1. revert hack from https://git.libreoffice.org/core/+/71b66b0039819f38c935b4eb5d5951ceaf6e8468%5E%21
2. trigger text update by releasing lock for a moment to keep
correct state
3. fix bug with resizing empty shape
Change-Id: Idf1fc6caf19dfb932ce7caa21034f76fa04ce5f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130474
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
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>
... resulting in a stripped-down, Writer-only build to decrease
the resulting WASM bytecode size.
It removes the following code from the build:
* All other major modules: Base, Calc, Chart, Draw, Impress and
Math and related writerperfect filters
* The premultiply tables
* The (auto-)recovery functionality
* All accessibility (but not the accessibility document checker)
* The LanguageGuess component
* EPUB support
* The start center / BackingWindow
* The TipOfTheDay functionality
* The splash screen communication
Currently crashs with anything different then soffice --writer.
Closing the document also still crashes.
FYI: many of these features are now behind ENABLE_WASM_STRIP_*
defines, but they normally don't work on their own, globally!
That's because we started with stripping the main components.
Change-Id: Ib9c0f9452815910c0a2aceaf142ba1ad4a9cb0d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126182
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This builds on top of commit 28d67b7927
(tdf#107776 sw ODF shape import: make is-textbox check more strict,
2019-08-26). Before that commit, any non-empty parent style name on a
shape resulted in an sw textbox. After that commit, we filtered out Writer
images by checking for the Frame parent style name.
The problem with this approach is that in case two documents are to be
merged together, then it's reasonable to rename the Frame style, but
then the complex content inside the shape gets lost.
Fix the problem by going with a middle ground: require Frame as a
prefix, but allow other names as well. This gets e.g. FrameX to work
without breaking the "reject Graphics" use-case.
Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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
This is just the theme itself, we don't refer to this theme from e.g.
shape text color yet.
Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502
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
Noel Grandin