Originally SmUnHorNode::Arrange() was somewhat kludgy. This change
implements a similar manner with SmBinHorNode::Arrange().
Change-Id: Ic18d2e7f70becfabb2c651719926e358a4585526
Reviewed-on: https://gerrit.libreoffice.org/26841
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
which was a regression from fa614231733800f4a961b77e36c86f8840d12251.
Change-Id: Ia7bab72dbd6f82519024809cf6384e1442a02327
Reviewed-on: https://gerrit.libreoffice.org/27033
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
move it to when the dialog is closed rather than trying to
launch it as soon as any modifications take place because
those are happening during threaded code and the restart
is always cancelled by the dialog itself leading to repeated
restart dialogs
Now at least it doesn't crash, but if we open an oxt on the command
line, a restart will reopen it, which is probably not what we want.
Maybe this restart on an extension modification is a bad idea in
the first place.
Change-Id: Ib7d6179e6703ed3353fce44c3e54f5be1c1dfa68
Had to rename 'clipRegion' to 'localClipRegion' to silence
a warning created by [-Werror=shadow]. The shadowed entry
is a function definition, so in this case the warning is
questionable and maybe unwanted by the compiler
Change-Id: I05aa93ad1d9b34dc8e82a4a2a099cf8070c01463
at the moment AddonsOptions::Notify is called with a null this
which crashes during adding an extension
regression from...
commit 3bdc5063f942b9ea3b6e39e707926fbc516c19f9
Date: Wed Jun 22 02:30:43 2016 +0200
tdf#89329: use shared_ptr for pImpl in addonsoptions
Change-Id: Ic28951e56bb8beca2a01ef2a1864eadcf3864e5b
if there is a reason for this then perhaps it needs to be protected
with pEvent->window == widget_get_window(pThis->getMouseEventWidget()
Change-Id: I714b67c3e6ace932a605dcd00d337c92c5fdfd19
If the previous break was also a continuous section break,
this break was simply ignored ever since
commit 1fdd61db155cf63d5dd55cc2bfb45af33796e131.
Thus, the default handler took over and assigned PROP_PAGE_DESC
if there was some kind of page style known
(either the first page/Standard defaults or any "converted" styles
that had been created) which effectively became a new page break.
Change-Id: I839570b0330ba274552cc671014e997c42765f4b
Reviewed-on: https://gerrit.libreoffice.org/26567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Obsoletes xmlsec1-ooxml.patch.1 and xmlsec1-vs2015.patch.1.
Adds xmlsec1-keyinfo-revert.patch.1 till the LO side is adapted to the
new xmlsec requirements.
Change-Id: I1a46ad8fd7e9c8b4fa7a97591a1d90922969393d
Reviewed-on: https://gerrit.libreoffice.org/24403
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Using the global ThreadPool (getSharedOptimalPool()) can lead to
problems when more than one usage executes and one of them
already calls waitUntilEmpty() what of course influences the
other usage. Thus I added an own instance of ThreadPool for
async loading of chart models in writer
Change-Id: I4bea64af0d36e87081abec95c75574966d0fe5b9
Use buffering in the drawinglayer, and don't do slow stuff in the
windows gdi renderer.
Conflicts:
svgio/source/svgreader/svgstyleattributes.cxx
Change-Id: Id955ee6a3b03e568c2678f02d77af35d2e5ba1d4
See svg bug doc, which is processed quite slowly. Beyond needing faster
renderers, there is also demand to improve the handling of primitives
created by SVG import.
Conflicts:
drawinglayer/source/primitive2d/patternfillprimitive2d.cxx
vcl/win/gdi/gdiimpl.cxx
Change-Id: I10992a5746b8b2d6b50e3ee3fe415a035685c9ba
Some graphic sub systems have problems to create correct
geometry for fat line drawing when 'empty' control points
are handed over for bezier curves. Avoid this by offering the
mathematical correct default in that cases.
Change-Id: I20f484ef4537076889d832d83581844690514acc
Especially if synchronous loading is requested, an async worker is on the way
and we would need to 'wait' for the data.
Change-Id: I20f9938738c1b46bda6b9a7f5a761e82153aed3b
Generating primitives for chart visualisation can be moved to a
paralell executed task that loads the chart, thus speeding up
initial visualization. This is not possible for e.g. PDF or print
targets, only for edit visualization. On fallback, the replacement
images of the charts are used which are metafiles and have less
quality as primitives, but load quicker.
Change-Id: I68caa9e1bec50832bce535b5f54633d53cdef037
When loading/importing connectors from ODF format, use the available path
data _only_ if the redundant data of start and end point coordinates of
path start/end and connector start/end is equal. This is to avoid using errorneous
or inconsistent path data at import of foreign formats. LibO itself always
writes out a consistent data set. Not using it when there is inconsistency
is okay since the path data is completely redundant, just to avoid recalculation
of the connector's layout at load time, no real information would be lost.
A 'connected' end has prio to direct coordinate data in Start/EndPosition
to the path data.
Change-Id: Id5aff0889e1e61112b6185f2384b7922f90a16a9
If OLE is a chart, buffer the primitives used for presentation as
info at the SwOLEObj, after getting them the first time using the
ChartHelper.
Change-Id: I6d7486185f6eac450de9328d37ea800f424f351b
Drawing fat lines is slow on linux due to X11 having no direct
support for it. This leads to creating the PolyPolygon geometry
for each fat line, then tesselate and draw as trapezoids. This
is not buffered in any way and is done at each paint.
As a side effect, fat lines composed of multiple anti-aliased
lines also show errors since AA-ed edges do not add up graphically.
Since we have cairo now available it makes sense to use it
for fat line drawing, it is markedly faster despite being a software
renderer. No such gains for PolyPolygons though.
Change-Id: If4001556e2dd4c15ecf2587cad6ce1e864558f2d
With certain CMIS host URLs, it is possible that exception handler
in Content::getObject() will recursively call itself with the same
data (xParent from the same URL).
This patch checks if the new URL is not the same as own, to avoid
this.
Change-Id: Ifaeb4ff27a9c809c5c96fa35ec190c3263a8fe62
Reviewed-on: https://gerrit.libreoffice.org/26977
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
