Presumably after 7a076dd9a6 "use more concrete UNO
classes in writer", CppunitTest_chart2_export started to fail with
> [_RUN_____] Chart2ExportTest::testStockChart
[...]
> warn:sal.osl:3513253:3513253:sal/osl/unx/module.cxx:152: dlopen(instdir/program/libmswordlo.so, 257): instdir/program/libmswordlo.so: undefined symbol: _ZTI12SwXTextFrame
[...]
> unknown:0:Chart2ExportTest::testStockChart
An uncaught exception of type com.sun.star.io.IOException
- SfxBaseModel::impl_store <file:///tmp/Chart2ExportTest__testStockChart_4uwve4.tmp> failed: 0xc10(Error Area:Io Class:Write Code:16) at sfx2/source/doc/sfxbasemodel.cxx:3205 at sfx2/source/doc/sfxbasemodel.cxx:1783
etc. (And marking only SwXTextFrame as SAL_DLLPUBLIC_RTTI would then cause
> sw/source/core/unocore/unoframe.cxx:1271:18: error: dynamic_cast from 'com::sun:⭐:uno::XInterface' with default type visibility to 'SwXTextFrame' with default type visibility [loplugin:dyncastvisibility]
> xFrame = dynamic_cast<NameLookupIsHard*>(pFrameFormat->GetXObject().get().get()); // cached?
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/XInterface.hdl:15:40: note: base class 'com::sun:⭐:uno::XInterface' with default type visibility defined here [loplugin:dyncastvisibility]
> class SAL_NO_VTABLE SAL_DLLPUBLIC_RTTI XInterface
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
> sw/inc/unotext.hxx:44:7: note: intermediary class 'SwXText' with hidden type visibility defined here [loplugin:dyncastvisibility]
> class SwXText
> ~~~~~~^~~~~~~
> sw/inc/unoframe.hxx:47:7: note: intermediary class 'SwXFrame' with hidden type visibility defined here [loplugin:dyncastvisibility]
> class SwXFrame : public cppu::WeakImplHelper
> ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> sw/inc/unoframe.hxx:174:26: note: derived class 'SwXTextFrame' with default type visibility defined here [loplugin:dyncastvisibility]
> class SAL_DLLPUBLIC_RTTI SwXTextFrame final : public SwXTextFrameBaseClass,
> ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
in turn.)
Change-Id: I5535853885a471d846458d3c6baf538ef047546b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137300
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(patch https://gerrit.libreoffice.org/c/core/+/137084 cont'd)
In SF_PythonHelper._PythonDispatcher():
Force a hardcoded call of the methods in the Dialog
service which may potentially be invoked while the
dialog is displayed, bypassing the generic CallByName()
Basic builtin function:
Activate
Center
EndExecute
Resize
Execute => was missing in the list
Case when a parent dialog opens a child dialog
(Controls is already hardcoded because returning an array)
Change-Id: Ia12fccbb61362768301df6670161f258b32d3a78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137289
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
...similar to cf69bb4f50
"-Werror,-Wunused-result", after c6965c5bcc
"tdf#145528 add round1Rect to SmartArt text area corrections"
Change-Id: I59292c7e4aae07be2ea46ae5c3db9629fa129a58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137295
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
we don't need them here.
Shaves 10% off load time
Change-Id: I38050c131af24bf0cc7cadb71d0d4d9fa7a5a9f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137290
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so with FocusOnly set when it doesn't have focus don't react to scroll-events
Change-Id: I520550590c7102ad823b677dfcce184b8b4ca377
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137268
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Some SmartArt types use text area rectangles different from defaults.
The new rectangle is available in element <txXfrm>. This patch adds the
needed corrections for type round1Rect. It is four times used in
SmartArt 'Titled Matrix' with rotations 0deg, 90deg, 180deg and 270deg.
Change-Id: I8c82b446a982ad93026e976b2a47d509b858858d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137287
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
The checks of valid bottom were introduced in commit
f50ec0bda2
Author Martin Gallwey <mtg@openoffice.org>
Date Wed May 16 16:08:38 2001 +0000
#86580#, #86953#, #86294#, make ReadUserDataSequence bullet-proof
Possibly initially, bBrowse passed to SwView::ReadUserData was
sometimes false; but at some point it became always true, making
the code using right and bottom (stored in aVis) unreachable. That
became evident after commit db93b92d78
Author Noel Grandin <noel@peralex.com>
Date Thu Mar 17 11:21:56 2016 +0200
loplugin:constantparam in sfx2
So just drop the unused pieces, that for large documents often resulted
in last position not being restored, because the code exited early at
nBottom > (m_pWrtShell->GetDocSize().Height()+nAdd) check.
Change-Id: If9b4e6faa2754b94cb1298a7221e70736c94f27e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137186
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
And don't lock up if the calculated minimum exceeds the maximum
(sidebar remains unresizable in that case, however).
Change-Id: Ibe96a43ad5d6a3fe4132a9fb64fe244ab022668d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137267
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Aron Budea <aron.budea@collabora.com>
The difference between normal (rich text) content control and a plain
text one is that if you try to format a subset of the contents, that's
possible in the rich text case, but the plain text case extends the
formatted range to the entire content control.
Handle this in SwTextNode::InsertHint(), similar to how it's done for
input fields.
Change-Id: I9a1ad0095f0ca810da24d5c4ce4aa48d1ac59225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137280
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to da7edbd2fd925bd80fdd6affe2ff6510c8ac1c5d
- (related) tdf#134281 tdf#149351 Update shortcuts descriptions
usable on the Presenter Console and the presentation canvas.
Also the one added in c11b6b64f6
Change-Id: I55a392730ca24f92cac1e11e1f3c2ef1771a00d3
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/137240
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
With previous implementation there was an bug which causing missing
incrementing ordered bullets. For example:
A. Lettered bullet uppercase 1 (A. )
A. Lettered bullet uppercase 2 (B. )
A. Lettered bullet uppercase 3 (C. )
This patch is fixing that, and increments is working correctly:
A. Lettered bullet uppercase 1 (A. )
B. Lettered bullet uppercase 2 (B. )
C. Lettered bullet uppercase 3 (C. )
It is also make sure that nested and skipped bullets are working correctly:
1) Numbered bullet w/ bracket one (1) )
Skipped bullet
2) Numbered bullet w/ bracket two (2) )
a) Lettered bullet w/ bracket lowercase 1 (a) )
b) Lettered bullet w/ bracket lowercase 2 (b) )
Change-Id: I1d1ad9ee549039077b418756efefb10bacfa1ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137112
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
We need to detect that the storage name is empty, so in that case
the root storage needs to be set as the current storage.
Change-Id: Ibe3287ccf1f1513a3531dcf4d540a456cca8dfb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137276
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This sets the color, line width, line style to the borders of
the table when rendering the data table. We also need the
ChartModel inside DataTableView, so we can access the needed
line dashes.
Change-Id: Id3bef23b75e88517d6569ad87a716f178ed64343
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137158
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
as opposed to opaque UNO interfaces.
This is a prelude which enables performance work because now I can
regular C++ method
Change-Id: I9bcfdca1000b4439431c9ea3b17bed081d80f0b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137275
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...when building against a recent libc++ that marks std::clamp [[nodiscard]], in
code newly introduced in 7e23cbdbb6 "tdf#149551
separate TextRotateAngle from TextPreRotateAngle"
Change-Id: Ifdce627b5d76fac269f1403e7bb98d4576dfa682
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137257
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These crc values are the results of Bitmap::GetChecksum() calls, and for
headless Linux the formats of those bitmaps (ScanlineFormat::N24BitTcBgr |
ScanlineFormat::TopDown vs. ScanlineFormat::N24BitTcRgb |
ScanlineFormat::TopDown) depend on little vs. big endian (see the definition of
SVP_24BIT_FORMAT in vcl/inc/headless/CairoCommon.hxx), so these tests failed on
big endian Linux s390x.
So I updated the tests with whatever values I got reported on s390x, whether or
not those values are actually correct...
Change-Id: I05d2b656ae2e0cf00cd870b895e1bf3cb9cf82f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137270
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
OOXML's <w:sdt> with <w:text> describes a plain text content control. We
are currently mapping this to fields, and then on export it's possible
to map this to FORMTEXT fields. The trouble is that our doc model could
not differentiate between content controls and fields for non-formatted
form text, so the exporter can't do the opposite of import.
This has the benefit that input fields do a reasonable job of providing
the feature set of plain text content controls, but it has the downside
that we map two OOXML features to a single Writer concept, loosing
formatting.
Fix this by introducing a dedicated "plain text" content control type,
which can be used for OOXML's <w:sdt> with <w:text>, and keep using the
input field only for OOXML fields.
This commit just adds the document model & UNO API, follow-up commits
will add the remaining functionality.
Change-Id: I0a0317adbd5f58c6ab880dccf6170292462d2671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137263
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
xEnd should not be smaller than xStart for compatibility
Add first Document tests
Change-Id: Ia8898d79db8c2885c6253ee9aaca793082b9dd20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137262
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This is followup to commit 7e23cbdb. That commit contains for several
types of shapes a correction of the position and size of the text area
rectangle.
That commit fixes bugs tdf#59802, tdf#136234, tdf#118009 and duplicate
tdf#142841 were the here tested shape types are involved.
Change-Id: I7c8c9676cf3dbdcc3f91fe25d75901b63d0ca4da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137264
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
build.patch.1 is extended to avoid:
> C:/lo/master/workdir/UnpackedTarball/pdfium/third_party/libopenjpeg/openjpeg.c(438): error C2491: 'opj_decoder_set_strict_mode': definition of dllimport function not allowed
and also is extended to avoid:
> /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/stl_tree.h:2028:5: note: no known conversion for argument 1 from ‘std::pair<fxcrt::RetainPtr<CPDF_Object>, std::unique_ptr<CPDF_PageObjectAvail> >::first_type {aka fxcrt::RetainPtr<CPDF_Object>}’ to ‘const CPDF_Object* const&’
Change-Id: Icacc05627a8612b33d6445685d26470e7c757b8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137238
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Using different methods of creation (one using DecodeMechanism::NONE,
another using DecodeMechanism::WithCharset) gave differently encoded
end results, comparing unequal.
The proper way is using DecodeMechanism::NONE on the document's URL,
as implemented in commit 06756e412b
Author Mike Kaganski <mike.kaganski@collabora.com>
Date Sat Nov 18 22:41:40 2017 +0300
One more proper construction of vnd.sun.star.pkg URL
Co-authored-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I272f277ef8b4bd23e6cb7884e68f3c79f742683a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136901
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Round-tripping depends on earlier commits for this bug.
These two attributes are SvxColorItems in EditEng,
but SvxBrushItems in Writer. So direct mapping doesn't work.
Although it might be a highlight, LO doesn't have such a silly
duplicate thing in the editeng code. So just map this as
the same thing used for normal char background.
As of LO 7.x, we default to exporting as char background anyway,
so highlight is on the way out in LO.
P.S. Highlight is one of 17-ish colors. It is the background
button in the Char panel in MS Word. Background is on Word's
Para panel (even though it is a character property),
and so it can fairly easily be removed in MS Word.
Change-Id: Id25879d90ba4a0eeff2d6afed030fc029d1c1039
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137239
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Regression from commit 78e25558e8
(tdf#106059 PDF export: create a reference XObject for JPG images with
PDF data, 2017-02-23), once a PDF image was inserted to a document, an
encrypted PDF export lost those images.
The reason for this is that we started to preserve PDF images as vector
data with the above commit, but this means we copied over PDF objects
from PDF images to the export result as-is, so encryption was not
performed for them.
Fix this by separating the write of the PDF object headers, stream
content and object footer and then calling
checkAndEnableStreamEncryption() / disableStreamEncryption() for each
object, even if it's not something our PDF export created but comes from
a PDF image.
Note that when existing PDF files are signed, PDF objects are also
copied into a vcl::filter::PDFDocument, but such PDF images are never
encrypted, so it's fine to have stub implementations in
vcl::filter::PDFDocument.
Change-Id: I2f74b9f51cd35b4319221532ca890e197bab9cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137242
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
make this reproducible without asan
Change-Id: I32cee0a22616e96d85c59d76319a6f6074fcde8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136228
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The import filter had only one member for both and had it mapped to
TextPreRotateAngle. That resulted in lost text area rotation when a
shape had both types of rotations, and sheared text when only text
area rotation existed.
The patch introduces a new 'moTextAreaRotation' member for the 'rot'
attribute of the <bodyPr> element. It is mapped to 'TextRotateAngle'
property. It becomes the 'draw:text-rotate-angle' attribute of the
<draw:enhanced-geometry> element for a shape and 'style:rotate-angle'
for chart elements in ODF. It must also be used to simulate 'upright'
and is used for the 'rot' attribute in <txXfrm> of diagram shapes.
The 'moRotation' member is now only used for the 'TextPreRotateAngle'
property. That angle describes a rotation of the text without changing
the text area. Valid values are multiples of 90deg. It is used for
simulating vertical writing modes that are not yet implemented. It has
no corresponding attribute in ODF. To make the meaning clear in code,
the member is renamed to 'moTextPreRotation'.
MS Office recalutes a diagram on file opening from layout.xml and
data.xml. That is not yet implemented in LO, but we use drawing.xml,
which gives the state of the diagram at time of saving. The patch
handles the 'rot' attribute of <txXfrm> element as well. It has to be
mapped to moTextAreaRotation, because it might contain angles, which
are not multiples of 90deg, for example diagram 'Gear'.
The <off> and <ext> child elements of <txXfrm> describe the actual used
text area rectangle. The existing import calculates the difference of
the actual used text area rectangle to the predefined one and
incorporates it into the TextArea*Distance attributes. The patch adds
calculating the current values of the text area rectangle as it would
be using the preset markup. At that time in import there is no
SdrObjCustomShape object, thus we cannot use its GetTextBounds() method.
So it is down manually, covering most of those types, which are used in
diagrams of MS Office.
Remarks to unit tests:
Now the rotation introduced by txXfrm is no longer in
TextPreRotateAngle, but in TextRotateAngle. According changes are in
SdImportTest::testN86510_2
Test, testFdo87488
Now the correct preset text area rectangles are used. That requires
adaption of the needed distances. Done in
SdImportTest::testBnc870237()
SdImportTest::testTdf93830()
SdImportTestSmartArt::testTdf134221()
The buggy 'upright' export is fixed. Adaption in
ScExportTest2::testTdf137000_handle_upright()
Change-Id: I79df1559f88b76e96988fe745304dc4162de6316
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136447
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
pngwrite is now replaced by PngImageWriter which uses libpng so these
old files are removed.
Change-Id: Ie91c314f30b8f56682890000b90009f408a79094
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137140
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
I presume there's a better way to do all this.
Change-Id: Id7e6cd3be5b82e419f17bba31834fef7cfe8299b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137237
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
