avoid malloc in the common case
Change-Id: I3820065c2b070eddf7cfcba117ec1be73735957f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125562
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
res is only defined if NDEBUG is *not* defined. So it doesn't exist in a
"standard" build using -DNDEBUG and shouldn't be used.
Change-Id: Iebae9898d50030f994a7289e2bc3fe3052172dee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125582
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
No idea if that would make actual difference, but it simply looks
odd that we use such a value, in view of all other efforts to improve
accuracy of rad<->deg conversions.
The value is used that is already present elsewhere in the code, e.g.
in sc/source/core/opencl/op_statistical.cxx.
Change-Id: I098f2bf748670e3250035d74d1bf7d1e224dd66b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125557
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
so do the same replacement with GtkWindow under X11 for gtk3 that we do
in MenuButtons for the popover with direct popovers when the constraint
is GTK_POPOVER_CONSTRAINT_NONE
Change-Id: Ia903b24c54e6d3acc18df1ab912600e07b7f844d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125543
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Writer/ODF has a feature to have paragraphs in a list without having a
list label, but they do take the indent of the list level into account.
Word doesn't appear to have this feature, so the export forces such
paragraphs to refer to a non-existent numId 0, so they are not part of a
list.
Take the left indent from the list level and write it into the pPr.
Change-Id: I8ad56e51e2d4dfd691e3c38532f1a824f5276fd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125555
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
We had doc model for this, but the UNO API and the PPTX import was
missing.
Change-Id: I199e9cc235a783d91700ce74f17d442f41d3c3f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125532
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
and where inability to escape window under X11 hasn't been a problem to date
Change-Id: I14aa5fe2cf443b6214aed48266d5bd32b8b9c700
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125541
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
with the intent to do the same replacement with GtkWindow under X11 for
gtk3 that we do in MenuButtons for the popover with direct popovers when
the constraint is GTK_POPOVER_CONSTRAINT_NONE
Change-Id: I629c30b44a9e362ba0d924bb229930b5f0dc7ed3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125540
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
we can use the file from tdf#134867 to test tdf#136551
although one bug is in calc and the other is in writer
In the end, the problem is in the sax parser when dealing
with files bigger than 10Mbs so the problem is not
specific to one component
Change-Id: If366626b386c592a0b780692a951b27a3e5cdbe5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125538
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
By ignoring the a:ln group, the contents in that group
(like transparency) were being applied to the text.
Well, it should only apply to a line around the text,
which LO isn't doing.
[Well, LO can do this as Fontwork, but perhaps that
doesn't match so well with text in shapes generally?]
At any rate, don't allow one group's settings
to override the others. Keep them separate and then apply
a bit of merging logic to try to achieve the best look.
So emulate a little bit. If the outline is not very
transparent (less transparent than the main text)
then it may (if thick or opaque enough) dominate
the text.
For simplicity (and because there is no right answer overall)
I just compared transparency and used the more opaque colour.
Unit tests potentially affected:
-export-tests-ooxml1.cxx: tdf100348_FontworkBitmapFill.odp -> PPTX
-now imports black instead of yellow (MSO sees gradient colors)
-so previously completely wrong, and now perhaps even more wrong?
-export-tests-ooxml3.cxx: tdf114848.pptx
-shows blue text regardless - defined by area.
-can't see where this is set in MSO2016. Perhaps illegal?
- : tdf125573_FontWorkScaleX.pptx
-no visual difference. Same as tdf100348, but with black outline.
- : tdf119087.pptx
-should be green, not purple. [Added test for that.]
- : tdf143315-WordartWithoutBullet.ppt
-no visual difference (COL_AUTO outline?)
-import-tests2.cxx: tdf129686.pptx
-poor test usage (but also weird transparent default).
-no visual change.
-ooxmlimport2.cx: tdf143476_lockedCanvas_position.docx
-no visual difference. Irrelevant since we can't RT
Change-Id: Iff0d95506dd64825444a99e62a6c2bd5e1dc122f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125300
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Now that all the abstract dialogs are welded, update and rename
the existing boilerplate macros, to cut down the C'n'P code size.
Change-Id: Iff8f452ca3dfce9a63c4fb73ab3a5025566810e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125511
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
* Some variables that were only used in the calendar_hijri.cxx
are now moved out of the header file, and they are no loner
member variables of the the class Calendar_hijri. They are now
placed in the the i18npool namespace.
* Removed unused variables SynMonth, EveningPeriod and LeapYear
* Moved a global variable definition to the member function that was
the only place it was used. It is now a local variable.
Change-Id: I8a8b25765bd8ed5640b1a0cfa46ec9903b460a53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125433
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
For Qt >= 5.14, don't require a window handle to retrieve
the screen and then the associated DPI value from that one,
but directly use 'QWidget::screen' (introduced in QT 5.14)
to retrieve the screen.
Previously, no DPI values would be set in case there was
no window handle.
This makes UI scaling work without having to manually set
'SAL_FORCEDPI' on Wayland.
While various UI elements (like e.g. the "Help" -> "About LibreOffice"
still look quite broken with the qt5 and kf5 VCL plugins
in a Plasma Wayland session (at least on my Debian testing with
Qt 5.15.2 and Plasma 5.23), they look OK
when using the qt6 VCL plugin with a custom build of qtbase
and qtwayland from Qt's "dev" git branches.
Change-Id: I5feae46ed86a8b7d3cf92d4a973f7a0f9a9f95de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125507
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This one looks useful, so why hide it behind dbglevel=2.
Change-Id: I424808ae8ccd2ab7edcd1a75cd7c4479a0ec3b13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125501
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
