summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-07-14Added changes for KDE4feature/svg-optimisations-5-0Jan-Marek Glogowski3-2/+3
Change-Id: I5941fa97848fa3b0129d01c2b6f554f5b8c4019f
2016-07-08Adaptions for Linux build, mostly CairoArmin Le Grand2-5/+39
Change-Id: I7721308f6af5d9e3af7dfe7787f6234b0c1eeeb2
2016-07-08Adaptions for packport to libreoffice-5-0Armin Le Grand6-97/+80
Change-Id: I36899154cacc334920b25fba39cc641d04600fbc
2016-07-07Added using an own instance of ThreadPoolArmin Le Grand1-5/+41
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
2016-07-07tdf#82214 optimize PatternFillPrimitive and SVGArmin Le Grand2-63/+99
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
2016-07-07tdf#82214 optimize performance for primitivesArmin Le Grand8-199/+440
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
2016-07-07tdf#99165 avoid passing empty control points for beziersArmin Le Grand2-4/+24
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
2016-07-07sw: tdf#50613 fix async chart load handlingArmin Le Grand2-27/+63
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
2016-07-07sw: tdf#50613 fix waitFinished into a loopArmin Le Grand1-2/+3
Change-Id: Ic8a720657c326d8d51bb3a73688b8f02b7096488
2016-07-07tdf#50613 add support to load charts asynchronouslyArmin Le Grand5-13/+146
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
2016-07-07tdf#83360 avoid inconsistent connector path dataArmin Le Grand1-0/+50
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
2016-07-07tdf#50613 buffer OLE primitives for chartsArmin Le Grand3-22/+61
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
2016-07-07tdf#50613 add close_path to correctly show closed polygonsArmin Le Grand1-0/+5
For closed polygons it is essential to add a close_path to correctly show the last line join. Change-Id: Ib6f37bbc5e85133f21a936b186eb0ab12773f7da
2016-07-07tdf#50613 speedup fat line drawing on linux using cairoArmin Le Grand4-0/+348
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
2016-05-04Updated coreChristian Lohmaier1-0/+0
Project: translations 55f537a40d2824d54f75d888399feadd0fac469d update translations for 5.0.6 rc3 and force-fix errors using pocheck Change-Id: I0ef48316613cf9213416f8e40043c56de4c500b4
2016-05-04bump openssl to 1.0.2hChristian Lohmaier1-2/+2
Reviewed-on: https://gerrit.libreoffice.org/24617 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 7ecaf61287606001eac9b3d76df95a0a900e11c0) Change-Id: I1e7c090ff58dc296641a1ce00a2ca4189e9e4156 Reviewed-on: https://gerrit.libreoffice.org/24621 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2016-05-04update creditsChristian Lohmaier1-1263/+1316
Change-Id: Icb4a443dba8eb22e49fe622ed5ef7c84fabc901b (cherry picked from commit fe81d707b5b4e832b249ae879a75f336cd06a81f)
2016-04-27update creditsChristian Lohmaier1-1041/+1053
Change-Id: I63a025efc0208b93887bc02acb360311b56688e9 (cherry picked from commit 72f89e0f0e2e766eb9739b6833a91139b4ae5e29)
2016-04-26Updated coreChristian Lohmaier1-0/+0
Project: translations 2de5bed5aa0facebf1a42166dedbeadfad49977f update translations for 5.0.6 rc2 and force-fix errors using pocheck Change-Id: I02d4482ea918a8986b6e04983a7c7e629145d791
2016-04-26tdf#79679 vcl: dashed lines show as solid lines when importing EMF filesChris Sherlock4-47/+26
Backported fix to 5.0. Issue is a regression in commit 09c722873b2d378d2d155f5f1dd7d8f3fb2012e9. (EMF/WMF: fix rendering of pen styles (dash, dot, dashdot, dashdotdot). I've looked at how the latest version of Word on the Mac works, and it turns out that the spacings for the PenStyle enumerations in the LogPen objects for all the create pen EMF records are as follows: * PS_DOT - ■ □ ■ □ ■ □ ■ □ ■ □ ■ * PS_DASHDOT - ■ ■ ■ □ ■ □ ■ ■ ■ □ ■ * PS_DASHDOTDOT - ■ ■ ■ □ ■ □ ■ □ ■ ■ ■ (where ■ is the actual filled in area, and □ is the space between the filled in areas) In other words, each dash fills in the space of three dots, and there is the one dot worth of empty space between the dashes and dots. Each "dot" has a width and height equal to the width specified in the pen. So basically, we seem to be arbitrarily setting the dot, dash and distance lengths arbitrarily, which were reasonable guesses but tended to produce very odd lines at different zoom levels. Change-Id: Ie8b5fa396e4fb0f480cb3594c8129a59f472c1b8 Reviewed-on: https://gerrit.libreoffice.org/22886 Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Tested-by: Chris Sherlock <chris.sherlock79@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/22928 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2016-04-26tdf#99172 support for vertical align import/export property for text boxesVasily Melenchuk2-0/+2
Change-Id: I1cf8d8d57a7245800e2b28b674301ebcb5470348 Reviewed-on: https://gerrit.libreoffice.org/23927 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit bef802a7bf7acb8331a1d776db9bbcc3bf16220b) Reviewed-on: https://gerrit.libreoffice.org/23935 Reviewed-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2016-04-26tdf#99450/tdf#99462: fix insert twice the same object in Photo albumJulien Nabet1-1/+0
For tdf#99450, see https://bugs.documentfoundation.org/show_bug.cgi?id=99450#c6 for full details tdf#99462 is also a consequence of this double insert. See https://bugs.documentfoundation.org/show_bug.cgi?id=99462#c2 Change-Id: I474495457088b93e0e86ea2e504f61c383ba059d Reviewed-on: https://gerrit.libreoffice.org/24327 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr> (cherry picked from commit 618e7622d08b20f6ea5f38144b61a187aced86af) Reviewed-on: https://gerrit.libreoffice.org/24330 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2016-04-26tdf#94449: special text attributes are not removed with paragraph styleOliver Specht1-1/+2
commit 3c0805e1f4f4d14e92c7e655d59c87de5c207e48 introduced removal of all character attributes applied to the complete paragraph if a paragraph style was applied. This should not remove special attributes like index entries, reference marks etc. Change-Id: I6fe92066269da2cf10c871ca319faf6fda91f4be Reviewed-on: https://gerrit.libreoffice.org/23591 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Oliver Specht <oliver.specht@cib.de> Reviewed-on: https://gerrit.libreoffice.org/24367 Reviewed-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-04-25Resolves: tdf#98366 paste document has 10x10 sized SdPages...Caolán McNamara1-23/+25
so long lines in them are clipped out in the preview. Change-Id: I355986ff4a9c9e53f8e8f5d41b63f74c633f41ee (cherry picked from commit 93efd7ebbad293d3729b8ea4b9726aff498f607f) Reviewed-on: https://gerrit.libreoffice.org/23994 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-04-19update creditsChristian Lohmaier1-1165/+1178
Change-Id: I52af3ba76cb6dbd8572eb524ce9d0c0bfb2c0596 (cherry picked from commit f4827e1bba5d6951cfc995531342395f8bc9a630)
2016-04-18Resolves: tdf#99322 re-establish group area listeners after update referenceEike Rathke1-0/+8
Change-Id: If2ec5f938c7278ce817de3d89dc84cc0584507ac (cherry picked from commit 44e2da58226448c5617eac08ca2ae3d9a9ad2afa) Reviewed-on: https://gerrit.libreoffice.org/24226 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-18Resolves: tdf#96172 crashtesting: avoid crash in layoutCaolán McNamara1-3/+3
sectfrm is riddled with workarounds for "half dead" section frames. This is yet another one. Change-Id: Ic03ad8971002d7dce308475f1497d1dda8045d15 Cherry-picked from 727ebae15e623660b9cc6f8db0e7558830bf920d Reviewed-on: https://gerrit.libreoffice.org/24155 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-04-18tdf#40863 only use polygons with area for WinClipRegionsArmin Le Grand1-12/+32
Due to a former fix CustomShapes have extra polygons with a single point in the top-left and bottom-right corner of their BoundRect, a workaround to allow getting their correct BoundRect in slideshow. Unfortunately this makes the win command CreatePolyPolygonRgn fail to create the needed ClipRegions so that the geometry is processed without clipping. Changed to only use polygons as input that have an area. Change-Id: I0eeda5776402777ed00de92f42a55f206575f58b Reviewed-on: https://gerrit.libreoffice.org/24059 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de> Reviewed-on: https://gerrit.libreoffice.org/24112
2016-04-14Resolves: tdf#73973 it's [crk-Latn-CA] and [crk-Cans-CA]Eike Rathke2-2/+6
(cherry picked from commit a2b289c403b7759032a2a50ae23b27f7bd74409f) Conflicts: i18nlangtag/qa/cppunit/test_languagetag.cxx Change-Id: I0da8562fc378f873e208919999bfc85f30d26778 Reviewed-on: https://gerrit.libreoffice.org/24083 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-04-14tdf#99224 PPTX export: implement support for images with textMiklos Vajna4-1/+31
In case an image had text, then ShapeExport::WriteGraphicObjectShapePart() wanted to write "only the text", but PowerPointShapeExport::WriteTextShape() had no idea how to write an image, so at the end nothing was exported. (cherry picked from commit fc70e4c4e192372f77511bc6ce2bc77b9c9539be) Conflicts: sd/qa/unit/export-tests.cxx Change-Id: I6c1ad0b41d4c5dc260b952322fb8a59e7f175603 Reviewed-on: https://gerrit.libreoffice.org/24017 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2016-04-13bump product version to 5.0.7.0.0+Christian Lohmaier1-1/+1
Change-Id: I186ef5b438f5ff28e0f860104d388b59fa7f2ec2
2016-04-13update emoji autocorrect entries from po-filesChristian Lohmaier6-664/+1486
Change-Id: Id84fb8cf436d946272d2850bc151529b28c5e920
2016-04-13Updated coreChristian Lohmaier1-0/+0
Project: translations 5d92a909d54033cb239b3398f6333968e8c8a787 update translations for 5.0.6 rc1 and force-fix errors using pocheck Change-Id: Id008a6a730afb16bb9dafd099698e1cc1d27eec2
2016-04-13update creditsChristian Lohmaier1-1463/+1773
Change-Id: I5525fcf891f5dae6d6972e045f4d3d7c6084b955 (cherry picked from commit 28ac7d0f0cea9067d7faba3b72a164729df26e5d)
2016-04-12tdf#99140 DOCX import: fix table at the bottom of the page to span over ...Miklos Vajna5-25/+84
... multiple pages. In short, one more blacklist entry when conversion should not be performed. Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport.cxx Also (because otherwise the first commit would introduce a regression): tdf#99140 DOCX import: fix table horizontal aligment to be 'from left' ... ... when it was 'manual'. Regression from commit c1e563f6efd09cd3463f1b92a3022ae288c92087 (fdo#76741 [DOCX] Table Alignment and width type, 2014-04-04), DOCX import code had to deal with two kinds of horizontal alignment when it came to floating tables: the alignment of the table itself, and the alignment of the float parameters. The problem is, in general it's wanted that the table is aligned according to the floating parameters, but in Writer the "from left" UI setting is described differently for tables and fly frames: tables use LEFT_AND_WIDTH for that, while fly frames use NONE. Fix the problem by touching the default only in case the floating parameters have something that's different from NONE. With this, the width of tables is no longer lost when they are described to be floating ones in the DOCX markup, but FloatingTableConversion() decides to ignore that. (cherry picked from commits d56deaeb2a1e8007e50fc2334f416fddd4e3cde3, c07f04ab422eadba0f2c3c128a0e3ff78e90cdf2, and fd61dee6457a44687f1142dd55bfee6b64fda2ef) Change-Id: I764f02cc58ae1b7af802b81e570e4feaf73ee2c1 Reviewed-on: https://gerrit.libreoffice.org/23987 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2016-04-12Resolves: tdf#97897 (re)broadcast if formula groups were splitEike Rathke1-1/+35
DeleteSelection() and DeleteSelectionTab() remove listeners for split formula groups, broadcast change after listeners of new groups have been established. Change-Id: I017e92b5cbc5f866768f3732e9997028c0c065fa (cherry picked from commit 94a95dce43e07b40350ed849db148b2946e3fd5e) Reviewed-on: https://gerrit.libreoffice.org/23895 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-12(re)broadcast if value replaces cell of grouped formulas, tdf#97897 relatedEike Rathke1-0/+5
Replacing a grouped formula cell with a different content may lead to the remaining cells of the group not being recalculated if they listen to a range that contains the current position. For example A1: 1 A2: =SUM($A$1:$A1) => 1 A3: =SUM($A$1:$A2) => 2 Enter 2 in A2 => A3 should be 3 but is not recalculated. Loading http://bugs.documentfoundation.org/attachment.cgi?id=122714 of tdf#97897 exhibits that behavior. Change-Id: I10b91e77549a7534143be3d6e3cc03026cdaa764 (cherry picked from commit ce28d83912d14bc81c455af64893842de78a8c8d) Reviewed-on: https://gerrit.libreoffice.org/23856 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-12(re)broadcast, same as in ScDocument::SetString(), tdf#97897 relatedEike Rathke1-0/+5
As with ce28d83912d14bc81c455af64893842de78a8c8d Change-Id: I7cd30509138368d73b43c82d71d520d55417d416 (cherry picked from commit b6ba851c02570c17e0484c94065a2e72c5675e58) Reviewed-on: https://gerrit.libreoffice.org/23870 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-12Resolves: tdf#98990 accept R1C1 notation entire column/row referencesEike Rathke1-5/+9
... which consist of only C4 or C[3] without a range operator. Change-Id: I1865f0ec4c4fec1101b93b6b40d6f26871a65f07 (cherry picked from commit 3c36ba50f65d663f35264f2a11c99c0ff98674a2) Reviewed-on: https://gerrit.libreoffice.org/23843 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-11tdf#98771 Update DocumentList.xml and SentenceExceptionList.xml for CroatianAndras Timar2-549/+584
Change-Id: Id450285a845c08115cbd66f74f2d4c22f7bede4e Reviewed-on: https://gerrit.libreoffice.org/23898 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-04-11tdf#65642 RTF filter: import \pgnrestart and \pgnucltrMiklos Vajna7-2/+62
This implicitly adds support for DOCX import of <w:pgNumType w:fmt="upperLetter"> as well. (cherry picked from commits abaf6bde4ee91c628bd55a7ec2e876a5d0ecff6e and d29b75c402ea635b3865501e43c9f349885913af) Conflicts: sw/qa/extras/rtfimport/rtfimport.cxx writerfilter/source/rtftok/rtfdocumentimpl.cxx Change-Id: Ib19ecb8f7ca0c867ae3be2b41e49ac4cacfd5bb6 Reviewed-on: https://gerrit.libreoffice.org/23916 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-04-09pCont can be nullCaolán McNamara2-1/+1
Change-Id: I7af6c5f4a14e330924a1ea12ebb6328884b8a565 (cherry picked from commit 617bbc9da95f7e4b13e3a999fd3085a4fee23ae4) Reviewed-on: https://gerrit.libreoffice.org/23937 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-08add a recursion guard to lcl_FindRangeNamesInUse()Eike Rathke1-5/+9
Change-Id: Ifbc02304f5a2e080db2d6645e2c7f825a2c56cb5 Reviewed-on: https://gerrit.libreoffice.org/23473 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-04-08foundry may be nullCaolán McNamara2-1/+2
Change-Id: I39359389a42e35e0131db1d0451fbd5531843f75 (cherry picked from commit b7bf06d5d6f640df1304b605a2eaa5276f998dcb) Reviewed-on: https://gerrit.libreoffice.org/23911 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2016-04-07tdf#99100 DOC import: handle subset of STYLEREF nativelyMiklos Vajna7-3/+63
Commit 4215bca95511af8e4ee96e3c8f521b35f638aef3 (export 'Chapter' field type as 'StyleRef' into .doc, 2015-08-21) mapped SwChapterField to STYLEREF in the DOC export. This field type was handled as a field mark on import. Instead of always handling it as a field mark, recognize the case when it's the subset we write and we can handle natively, and in that case create an SwChapterField again on import. Leave the complex case unchanged as before and keep using field marks for that. Also (because the header where STYLEREF is used is completely empty otherwise): tdf#99120 DOC import: fix lack of first share after odd section break Commit 848b1a05c5c41b5e7ff19c984f60c297a8143990 (fix for bnc#659631, 2011-02-04) made wwSectionManager::InsertSegments() use SwPageDesc::WriteUseOn() directly, instead of going via SwPageDesc::SetUseOn() that takes care of not throwing away the higher share bits of the bitfield. This way the "is first shared" flag of the bitfield got cleared, even when the input document had no title page declared, so first header/footer must be shared. Fix the problem by using SetUseOn() in the DOC import as well when it comes to handling odd/even page section breaks. (cherry picked from commits d635b351849b8b576c907abf22500d0fa89ab54f and 44a3eb37cd982c59f8350d53db3798b675230b35) Conflicts: sw/source/filter/ww8/ww8par5.cxx Change-Id: Icfa8c4be6538da5e02e2d5071af30a46ccfa712b Reviewed-on: https://gerrit.libreoffice.org/23889 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2016-04-06tdf#98989: vcl: fix handling of non-scalable fonts like "Courier"Michael Stahl1-1/+6
For a VirtualDevice only scalable fonts are cloned, but for non-scalable bitmap fonts still an empty PhysicalFontFamily with no PhysicalFontFace is created, which causes text to disappear (height 0). Suppress creation of such families like it was done in LO 4.3, so that the fall-back can handle it and map "Courier" to "Courier New". (regression from 8d6697587776136f3121733e1c29d4200720dbd9) (cherry picked from commit 2f89245fb7e1c94bed49dde10b08ab1cf41b597b) Change-Id: I6542a3f7a01bdf46ae2bcf328fa04064f7f86332 Reviewed-on: https://gerrit.libreoffice.org/23851 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-04-05tdf#97601 sw: don't mark an already modified chart as modifiedMiklos Vajna3-2/+31
Regression from commit e2b260fc98e833d4e64426b90992094f2da0498c (sw: let layout not mark embedded object as modified, 2014-06-03), an infinite loop was caused by: 1) SwDoc::SetOLEObjModified() triggering the maOLEModifiedIdle Idle 2) which at the end called SwWrtShell::CalcAndSetScale() 3) which at the end called chart::ChartModel::setModified() 4) where chart code called back into SwDoc::SetOLEObjModified() via the modification listener, and this happened again and again. The original fix wanted to avoid marking the document as modified without a user interaction, so fix the bug by only calling setModified() if it prevents a not-modified -> modified transition. This keeps the original bug fixed, but prevents the infinite loop, that is always a modified -> modified transition. (cherry picked from commit 078c00e3a3c971ac83154948d5f08462532b9dc6) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I3b56a91afaacd3e0b7cb646a492fd15f1b5168ee Reviewed-on: https://gerrit.libreoffice.org/23731 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2016-04-05currentlayout may be nullCaolán McNamara2-4/+4
Change-Id: I1e53482e722b82f052434f45e37a2fbdb2ea6ffc (cherry picked from commit a4bc9a43198074b529693f1852093d8d72eaae98) Reviewed-on: https://gerrit.libreoffice.org/23804 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2016-04-05hold bullet para by referenceCaolán McNamara3-16/+12
(cherry picked from commit c9a04aed449c3cf992224cfedcee7f330357b01a) Change-Id: I58025ea906426a7db4079042fa38954f1a3d076b Reviewed-on: https://gerrit.libreoffice.org/23799 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2016-04-04tdf#98987 sw: add AddVerticalFrameOffsets compat modeMiklos Vajna15-7/+119
The situation is the following: we have a text frame, with at least two anchored objects: one is wrapped not-wrap-through, the other is. In case the non-wrap-though one shifts the text content of the text frame right or down, then layout may or may not want to re-consider what is the top left corner of the text frame for anchoring purposes. Regarding the x position, sw layout repositioned the anchor point depending on the AddFrameOffsets compat mode: it's enabled for documents imported from Word, disabled otherwise. Regarding the y position, no repositioning was done, however the bugdoc shows that Word does the same repositioning on the vertical axis as well. Add a new AddVerticalFrameOffsets compat mode that enables vertical repositioning as well, and enable that mode for documents imported from DOCX. Also (squashed in, as the second commit partly undoes what the first one did): tdf#99004 SwAnchoredObjectPosition: handle textboxes when determining surround Writer TextBoxes are always wrapped "through", so that they can appear inside their shapes. However, the surround of the shape may influence its position. So when surround is asked for anchor position purposes, take the surround of the TextBox's "parent" shape instead of the one of the TextBox directly. With this, the textbox in the bugdoc is properly positioned inside its parent shape as expected. (The problem only happens when at least two shapes are anchored to the same paragraph.) (cherry picked from commits 911261a3a581b9f2f4262f1d5403d9be3bbecf63, f5e0236566b913aebb1376d97c7d37a23c69bd84, 50223ea6e212b60b7d33839c2753c5601fb50f95 and cd1b2f923e0b0be89a5d1c8cbc647133aac09ed5) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx sw/source/core/inc/anchoredobjectposition.hxx sw/source/core/objectpositioning/anchoredobjectposition.cxx sw/source/core/text/txtfrm.cxx sw/source/uibase/uno/SwXDocumentSettings.cxx Change-Id: Idc5cad7d86662008a92ff3bf5fbb3806aa2c7b07 Reviewed-on: https://gerrit.libreoffice.org/23739 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>