Also move the relevant tests and clean-up the names a bit to make
it mroe consistent.
Change-Id: I929ef9c13b954fd6a506471231d1bc41e4ef9980
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176027
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
In the case the input file does have a graphical
representation of the Diagram as image file, the
DiagramModel was not fully loaded. For being able
to edit the Diagram in the future it is necessary
to re-create the geometry, thus a full model is
needed.
Needed to know at recreation if this is the first
time the geometry gets self-created using the
layout/creation mechanism to decide if to apply
the style or use the saved/reapplyable data from
secure/restoreDataFromShapeToModelAfterDiagramImport
mechanism, added that.
Change-Id: Icb7590306ab59728e83b800b8637333e0d372de5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168223
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
create a plugin that finds methods we can mark as final because they are
not override in subclasses.
Which is useful both as documentation (telling you that you don't need
to worry about subclasses changing the implementation under you),
and for performance, letting the compiler elide virtual calls in many
cases.
Apply the results to a subset of stuff in /include
Change-Id: I7b5cc893ec2f343bc356bfc338e4cf531ffba1e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165054
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The events may be processed after the shell has been destroyed. This is
happening reliably after commit e2bfc34d14
(Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable,
2024-03-11) when controlling LibreOffice from external Java scripts; but
obviously, it could happen before as well.
Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase.
Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:\libcmis\inc\libcmis/document.hxx(51): warning C4589: Constructor of abstract class 'libcmis::Document' ignores initializer for virtual base class 'libcmis::Object'
C:\libcmis\inc\libcmis/document.hxx(51): note: virtual base classes are only initialized by the most-derived type
C:\libcmis\inc\libcmis/folder.hxx(58): warning C4589: Constructor of abstract class 'libcmis::Folder' ignores initializer for virtual base class 'libcmis::Object'
C:\libcmis\inc\libcmis/folder.hxx(58): note: virtual base classes are only initialized by the most-derived type
Change-Id: Icc7f94cc02796a86b47b025df69ec3db971ad11e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163777
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
using the bin/find-can-be-private-symbols.py script
to find classes with large numbers of exported symbols
that can hidden.
before
exported = 58104
imported = 30810
unused_exports = 35433
after
exported = 55094
imported = 31073
unused_exports = 32423
Change-Id: Idd0a70ee3740afd5ca1a86771e0e2ff8090d102d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163456
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Similar to commit 798d21e2a1 (tdf#157965:
UNO methods are expected to return sizes in mm/100, 2023-10-29); this
was an omission from commit 9e92a17cb6
(starmath: Improve glyph positioning, 2023-09-19).
The method is called in DomainMapper_Impl::appendStarMath(), and the
returned value is used to define object size using UNO methods.
Change-Id: I37cc4d5dd18641915495b97f0d99fa10a805e18c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160827
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
SVG files aren't supported in OOXML, but we can write it using the
MS OOXML extension, which is supported in the latest MSO versions.
For now this only implements the support in the exporter.
Change-Id: I688180fb5772f3999c2ee3020bc234f90d57cc2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157237
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
In deep detection, first check if it's a broken ZIP package. If it is,
set the RepairPackage media descriptor property to true.
Pass the RepairPackage value to the OOXML filter detection.
Change-Id: Ic958283f3cce92ac29ce93ac330cc9e409e3eb78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159976
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
it in several places. Currently these places get a Sequence<sal_Int8>
by call of StaticTokenMap().getUtf8TokenName() and immediately after
that generate an OUString from it using reinterpret_cast<const char*>
and the OUString ctor with 8-Bit character buffer array. The patch
moves this conversion to StaticTokenMap.
Change-Id: Ia2af110e2a0f1708e0685115d325c1c12cab3857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159514
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Currently LibreOffice uses the VML fallback, when a docx document has a
wpc:wpc element. This patch implements to use the choice part with the
wpc:wpc element. That is often called 'drawing canvas'.
The patch uses a similar approach as for SmartArt. The drawing canvas is
imported as group shape and for the background an additional rectangular
shape is inserted as first in the children vector.
Not using VML has the advantage, that the custom shape import is used
for preset shapes. VML import produces problems because some properties
are not available in VML or the current VML import has deficits. The
test suite shows examples, what is better without using the VML
fallback. Affected bug reports are e.g. tdf#104671 or tdf#154828.
A drawing canvas must be used in Word for connector shapes. A connector
in Word on the drawing canvas is not written as cxnSp element, but as
ordinary wsp element with additional wps:cNvCnPr child element. The patch
generates a connector in such case.
Unsolved problems:
The path of a curved connector in OOXML is basically incompatible to
the path which LibreOffice generates. This patch uses the default
path for a curved connector. Same is done in import in Impress. Using
the VML fallback had generated a custom shape with the current path
and handles, but the connections to the target shapes were lost.
Export to docx is missing. The drawing canvas is not recreated,
instead a group with the additional background shape is exported. That
is no regression, using VML has produced a group too on export.
I don't know whether XML_graphicFrame can occur in
WordprocessingCanvasContext. At least charts and math equations are
not possible on the drawing canvas in Word.
Import of WordArt shapes does not work. That is not regression. It
works neither in the VML import.
Change-Id: I04bf8407efd1939cdf3137775f8afad420b74014
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156629
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Revert "Revert "tdf#118133 DOCX import: disable lazy-loading of tiff images""
This reverts commit c6bf16909d.
Lazy-loading doesn't work with cropped TIFF images, because in case of Lazy-load TIFF images
we are using MapUnit::MapPixel, but in case of cropped images we are using MapUnit::Map100thMM
and the crop values are relative to original bitmap size.
Change-Id: I2dbf6caf08d7899ec2eae683996d997809d62b89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158509
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Rename WriteImage -> writeGraphicToStorage to make it more clear
what the method does.
Remove returning the rel ID string in some methods that write the
graphic into the stream (or the call chain), as it is never used
later on, so it is better to not return it if it is not used (it
could be abused).
Change-Id: I78558671b82aedb34bd0f37bf7781c47ebf1cf5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157235
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Noel Grandin