SdPage::IsExcluded() decides if a slide is hidden,
SdXImpressDocument::render() checks for this and returns early if
needed. In that case PDFExport::ExportSelection() detects that the
produced metafile has no actions and avoids creating a PDF page.
Then Impress links are created using the
vcl::PDFExtOutDevData::CreateLink() call in
drawinglayer::processor2d::VclMetafileProcessor2D::processTextHierarchyFieldPrimitive2D(),
not specifying the PDF page number explicitly. This means the link is
created on the "current" page number, set in
vcl::PDFExtOutDevData::SetCurrentPageNumber(), called by
PDFExport::ExportSelection(), but that filter/ code can't know about
hidden slides in sd/.
Fix the problem by setting the page number again in
SdXImpressDocument::render(), that way the link created by drawinglayer
will end on the correct page.
Change-Id: Ic29e345d45bc7c944d65e6e450f1d742dd0e9f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90299
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
If the D&D-Start described as in the task is an
OLE object we need to create a Persist-object
to copy the included EmbeddedObjectContainer
Change-Id: Ib8b9677bbc3e6c5b3895abc55e6da5b0a96e33d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90263
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
After 424a7f4045 "add some more libs to libmerged"
had added javaloader to libmerged, destruction of static xStaticRef started to
cause problems at least during CppunitTest_services of --enable-mergedlib
Windows builds (presumably because the relative order of static variable
destruction had changed).
Change-Id: I8307570222cc9a3d9511d090d0dae7f7dfe7a9ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90254
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
When the http response is 404 or something like
that we shouldn't retry the download embeded image
constantly. This causes libreoffice to short freezes.
Change-Id: I7381d04f12e9fbea961dd0e3333ea0d39aa93d14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90102
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I8d8a3e13932b004678b305f9a6883062854f9201
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90140
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
To be specific, this focuses on the case where a single cell has btlr
direction, but the containing row does not, and there is a row span.
The old code that took the logical right of the cell frame served two
purposes, it seems to me:
- in the rare case where the 1st row is wider then a subsequent row, we
make sure that as the cell frame is expanded downwards, we're still
inside the table polygon
- in the tb-rl ("Japanese") case, the logical right maps to physical
bottom, and this way the cell frame is OK to render not only into its
own row frame, but can expand also downwards.
Given that btlr maps left to bottom, this mechanism is broken there. Be
consistent with the working tbrl case, so just expand towards the
logical left in the btlr case.
The rest of the changes just make sure that SwAttrHandler::FontChg()
calls SwFont::SetVertical() with the correct bVertLayoutLRBT parameter,
which instantly fixes the actual position of the text.
Change-Id: I9032e7c6de72cec704843f3aae3c7848e139ebfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90241
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
resulting broken table layout with incomplete cell merging,
for example, content in extra table rows and in columns
of different lengths.
Change-Id: Ic5057e43d4c66e34ffc1373030be66815ff52563
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90136
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
When the dialog is about to show, it requires to
send to client side the "created" message. However,
in the constructor has already assigned a notifier
from the parent window.
Change-Id: I1120ad1c1c70449048d6739b8564d1c1f6b1c7e3
Reviewed-on: https://gerrit.libreoffice.org/84908
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Henry Castro <hcastro@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90243
Tested-by: Jenkins
It seems after a style is applied, the outliner view pointer points to
an OutlinerView that has been removed. This results in a crash when
trying to access OutlinerView functions to set cursor focus to the
document. Avoid this by checking if a style has just been applied.
Change-Id: Idda11567506fcc60a830dce70b86e12e2079c7a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90198
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Those form-related services are needed to handle the bugdoc and
another document with form elements that I was given.
'adb logcat' output for a debug build already showed the cause
of the crashes with messages like:
W cppuhelper: 31:cppuhelper/source/shlib.cxx:288: unknown constructor name "com_sun_star_form_ORadioButtonControl_get_implementation"
Change-Id: I20232e097bedba13b94e3ff01839d55da819e6cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90232
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Links can be created using link or widget annotations, this helps
finding the relevant code when reading the debug output. Same for page
objects.
Change-Id: Iec7f5c5d92da6dfcd0e8b6681a949a42a095ce18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90233
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to e394800294622c606ca01e3f75c2affc77f547cc
- faulty link due to an improper uppercase letter
Change-Id: I7955da53204d5eb8bf4dff2713f304776f2befc4
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/90040
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Change-Id: I631e050316acdcbb42dfbb5e6476a4e8e7cc0f8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90221
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
Not needed at all and gtk3 is already disabled there.
Change-Id: Ic6f8be17645df22a414ae4b191a97b9bf1c16d1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90206
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
For tdf#124292, Qt's own HiDPI scaling was explicitly disabled,
but it turns out, you can't really scale QStyle painting then.
This patch series had a 2nd approach also used by Gtk+ currently,
which relied on the scaling of ths Cairo surface, which works
surprisingly good, but has to lie about the real DPI value, so
nothing is scaled twice. Also all icons are then scaled instead
of rendered with the proper resolution.
When HiDPI support in Qt is enabled, and the application is
started using QT_SCALE_FACTOR=1.25, Qt simply lowers the reported
resolution, keeps the logical DPI value of 96 and changes the
devicePixelRatio to the specified value. But LO still expects
the real DPI values and sizes, so we have to multiply a lot of
rectangles, sizes and positions.
The current result is far from perfect, which you can see with
the various graphics glitches, but it at least doesn't crash
anymore in the ControlType::Editbox sizing code.
The main problem is all the up and downscaling in the
getNativeControlRegion code, so LO knows the size of the widgets
for the correct layouting, since there seem to be no API to
get the scaled values from Qt / QStyle.
Change-Id: I687b1df6ef27724ce68326d256e9addccd72e759
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86239
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
