- 17 Nis, 2019 3 kayıt (commit)
-
-
Henry Castro yazdı
document" Change-Id: I976318fe299306b65190b4f5ae0ed2565830c6f7 Reviewed-on: https://gerrit.libreoffice.org/70475 Tested-by: Jenkins Reviewed-by:
Jan Holesovsky <kendy@collabora.com> Reviewed-by:
Henry Castro <hcastro@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/70794Tested-by:
-
Muhammet Kara yazdı
Users need an in-process copy of pdf to share with peers and discuss the redacted areas Change-Id: I68c16c6f09690a9d5cd2df191963107029e5ed88 Reviewed-on: https://gerrit.libreoffice.org/70863Reviewed-by:
Andras Timar <andras.timar@collabora.com> Tested-by:
-
Noel Grandin yazdı
The message from clang-tidy is: warning: object destroyed immediately after creation; did you mean to name the object? The guard in RequestHandler::ExecuteCmdLineRequests comes from commit cf333a87 Date: Sun Jan 21 22:10:09 2018 +0300 tdf#38915: set cProcessed condition on any process outcome and I'm sure it's intention was to set the flag on exit from the function, not immediately. Reviewed-on: https://gerrit.libreoffice.org/60183Reviewed-by:Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins (cherry picked from commit 867ee21f) Change-Id: Ibf874a5774770df00b9db7f673554e7ffda55072 Reviewed-on: https://gerrit.libreoffice.org/66168 Tested-by: Jenkins Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
- 16 Nis, 2019 2 kayıt (commit)
-
-
Muhammet Kara yazdı
Users might accidentally move the main shape of the page being redacted. Let's prevent that. Change-Id: Ic0f3c2c819d1f974d203fa5fd70d57e5545ba8ef Reviewed-on: https://gerrit.libreoffice.org/70843Reviewed-by:
-
Mike Kaganski yazdı
Excel expects the group field items to be in ascending order starting from "<01/02/2010", then "Jan", "Feb", ..., then end with ">01/02/2020". Change-Id: I29e9b55f43091ed007f59e10dec64f46a37c7d5f Reviewed-on: https://gerrit.libreoffice.org/70800 Tested-by: Jenkins Reviewed-by:
-
- 15 Nis, 2019 8 kayıt (commit)
-
-
Tor Lillqvist yazdı
Might help in some cases in the customer application. Change-Id: Icdc13780d4623e9df8bc057760c1295d7d6ffd61
-
Ashod Nakashian yazdı
Change-Id: Ica7448458ecc5e9adc802a288f72b1fceb709f79 Reviewed-on: https://gerrit.libreoffice.org/70724Reviewed-by:
Ashod Nakashian <ashnakash@gmail.com> Tested-by:
-
Ashod Nakashian yazdı
The slide-sorter is actually still necessary to apply/change the master slide of a given slide, so we must enable it. Change-Id: I3f59f58be76ab1c63453b4f6288044572800a556 Change-Id: I7554ba4afd28d7ea4f3ed6ba375d9765a89ef21c Reviewed-on: https://gerrit.libreoffice.org/69618Reviewed-by:
-
Ashod Nakashian yazdı
Change-Id: Ife85b3c728c59f7fb4e0184211efc9b652c5f4e7 Reviewed-on: https://gerrit.libreoffice.org/69615Reviewed-by:
-
Ashod Nakashian yazdı
Change-Id: I4cb6ce6d961b4ba4d542c14cb37370788cf75e45 Reviewed-on: https://gerrit.libreoffice.org/69613Reviewed-by:
-
Ashod Nakashian yazdı
Currently reordering of slides is only supported for presentations, although it is provisioned for spreadsheets as well. Change-Id: I6c35066d6a5ef7586d34a8e8b89db69a20b86572 Reviewed-on: https://gerrit.libreoffice.org/69612Reviewed-by:
-
Ashod Nakashian yazdı
For spreadsheets, selected parts are still unimplemented, so returns false for all. For presentations, visible parts seem to be always return false at load time. Change-Id: I90c79617f88deec98849bb374ca0ba177cd9c9af Reviewed-on: https://gerrit.libreoffice.org/69611Reviewed-by:
-
Ashod Nakashian yazdı
Change-Id: I8624de25b0bb66020002890f33758e52059a24ab Reviewed-on: https://gerrit.libreoffice.org/69610Reviewed-by:
-
- 13 Nis, 2019 3 kayıt (commit)
-
-
Ashod Nakashian yazdı
Change-Id: I1e09d458d1c6c4842750368fbd45ef326fa1bedb Reviewed-on: https://gerrit.libreoffice.org/70160Reviewed-by:
-
Ashod Nakashian yazdı
Change-Id: Iebd85e5e60c76e6d0756d15e1fa6107a3fcc837d Reviewed-on: https://gerrit.libreoffice.org/70162Reviewed-by:
-
Mike Kaganski yazdı
Two tests in sc/qa/unit/pivottable_filters_test.cxx were extended to also test round-trip of group fields in XLSX. Change-Id: I70b7c15b09040c64fa1da2f88001af7ba16f2c6f Reviewed-on: https://gerrit.libreoffice.org/69653 Tested-by: Jenkins Reviewed-by:
-
- 12 Nis, 2019 7 kayıt (commit)
-
-
Mike Kaganski yazdı
Despite being optional as per ECMA-376-1:2016, Excel 2016 seems to require the presence of "name" attribute in dataField element of pivot table definition, so make sure to write at least empty string there. Change-Id: Iaab5674f86b7dd0b267776678e11af47086635d7 Reviewed-on: https://gerrit.libreoffice.org/70522Reviewed-by:
-
Mike Kaganski yazdı
The test should guarantee presense of w:val attribute of w:rStyle element. Turns out we must not use w: namespace before attribute name; likely it is true when attribute namespace is the same as of its element. Change-Id: I28e2936b51f039473326c6debf4b5559e2baf24c Reviewed-on: https://gerrit.libreoffice.org/70612 Tested-by: Jenkins Reviewed-by:
-
Mike Kaganski yazdı
It turns out that this change revealed unit tests written incorrectly (and untested), or maybe which became broken (not testing) because of some previous assertXPath change? They incorrectly used 3-arg form of it to check node content equality to passed string, while in fact, an attribute was looked for with that name, and its empty return tested to match default empty 4th argument. Change-Id: If24e18518543102d115a22a6282e4cca9cf694e2 Reviewed-on: https://gerrit.libreoffice.org/70581Reviewed-by:
-
Dennis Francis yazdı
field labels, else on export to xlsx, Excel will fail to load the pivot table due to case-insensitive duplicate field labels in the pivotCacheDefinition1.xml. This could be done just for xlsx export filter, but we do normalization in dpcache.cxx anyway and it would not hurt if we do a case-insensitive normalization here. The private member ScDPCache::AddLabel had code duplication and more importantly it is called in loop for every label in the database so results in O(n^2) time complexity where n is the number of labels, so removed it to reuse normalizeLabels() at the only call-site. Also added a unit test that checks case-insensitive normalization. Change-Id: Id563dee232a98a2aea9f4fc29254f6942e1c5ba7 Reviewed-on: https://gerrit.libreoffice.org/70498Reviewed-by:
Dennis Francis <dennis.francis@collabora.com>
-
Tor Lillqvist yazdı
I wonder wheter we should just include all of instdir/share. Seems that I have to add more and more of it all the time anyway. I don't remember why I thought (many years ago) that an app would need just a subset. (Maybe I thought that an app would not, at least not initially, have functionality that would use most of the stuff in shre. But that has changed now.) Change-Id: I62f935e3ab9c4709373fad11ed120ecca033b4aa
-
Tor Lillqvist yazdı
Change-Id: I71a822495c8a41cf01efe611911afcafea81118d
-
Tor Lillqvist yazdı
Quikee said it was OK. Change-Id: I8f45d3c5e264f5658985399487e9c6e2a3fbced3
-
- 11 Nis, 2019 5 kayıt (commit)
-
-
Tor Lillqvist yazdı
Change-Id: I6287aee720bbddcb28142bcbdb910b89e942c4ec
-
Tor Lillqvist yazdı
Change-Id: I8473b1f411a45c7c17e742ca0d69245d77f078f7
-
Dennis Francis yazdı
under colFields tag if there is only one data-field. <colFields count=[*]> <field x="-2"/> <--- -2 indicates data field. </colFields> Excel 2013/2016 seems to crash at the presence of '<field x="-2"/>' in colFields when there is only one data-field. Additionally, call GetOutputRangeByType(sheet::DataPilotOutputRangeType::TABLE) on all ScDPObject's in non-const mode, so that the internal pOuput member of ScDPObject is populated. Otherwise the const GetOutputRangeByType(sheet::DataPilotOutputRangeType::TABLE) call always return an invalid range. This also adds 2 unit tests :- 1. To check the presence of <field x="-2"/> in colFields tag if there are more than one data-fields. 2. To ensure the absence of <field x="-2"/> in colFields tag if there is only one data-field. Change-Id: I8f470bd1ab883f73586f04a3fcc30e3fbf948c4a Reviewed-on: https://gerrit.libreoffice.org/70316 Tested-by: Jenkins Reviewed-by: -
Tomaž Vajngerl yazdı
When we drag a entry in TreeListBox, we execute a PaintDDCursor which paints a "cursor" of a possible drag target (for example to show where the entry will be moved to if we want to change the order). The problem with this fuction is that it paints a line directlly at that location, and that it uses invert raster operation to draw a line. So to hide the line it just needs to draw again. On MacOS this invertion causes a problem and draws the whole area black, which is the cause of this bug. So instead of inverting the drawing of the drag target cursor has now been moved into the main Paint method, where it redraws the whole entry, and if present, also the drag target cursor. This means that all we need to do is Invalidate the entry, which then just gets redrawn in a normal Paint pass. One exception is still MacOS, which doesn't invalidate the entry, but redraws the entry directly. DnD is MacOS is a bit different as it is not async (if I understand correctly) so the invalidate has no effect. Reviewed-on: https://gerrit.libreoffice.org/70521 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 14abbc6e) Change-Id: I8542f47940a3b90114ea4bbbac57fd303ca3434b
-
Mike Kaganski yazdı
Change-Id: I51bd7c6695ef52b08e0b6d809160d74daebb8505 Reviewed-on: https://gerrit.libreoffice.org/65298 Tested-by: Jenkins Reviewed-by:
Aron Budea <aron.budea@collabora.com>
-
- 10 Nis, 2019 2 kayıt (commit)
-
-
Mike Kaganski yazdı
... to avoid treating \" as in-argument " instead of end of argument See https://docs.microsoft.com/en-us/windows/desktop/api/shellapi/nf-shellapi-commandlinetoargvw Change-Id: Ie283ba04117e13bc06c5b92412a945f945e67ff3 Reviewed-on: https://gerrit.libreoffice.org/61214 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Tor Lillqvist <tml@collabora.com> Tested-by:
-
Jan Holesovsky yazdı
Change-Id: Iedb31bbe0e81dc9568e84858d8d26eac03c47ffb Reviewed-on: https://gerrit.libreoffice.org/70208Reviewed-by:
-
- 09 Nis, 2019 2 kayıt (commit)
-
-
Muhammet Kara yazdı
After the commit c2330b14e2bfa170131a83c375ec0b1a91c95415, different page sizes and orientations are handled properly, and Impress pages are converted to Draw perfectly. Change-Id: Ib9ab6b298e12fc0d8e9440bf63f31ad6dd05ab35 Reviewed-on: https://gerrit.libreoffice.org/69910 Tested-by: Jenkins Reviewed-by:
Muhammet Kara <muhammet.kara@collabora.com> (cherry picked from commit db76236e) Reviewed-on: https://gerrit.libreoffice.org/69917Reviewed-by:
-
Muhammet Kara yazdı
Change-Id: I7136717936668fbb1d87b5d9491430c13c5e73fd Reviewed-on: https://gerrit.libreoffice.org/69909 Tested-by: Jenkins Reviewed-by:
-
- 08 Nis, 2019 1 kayıt (commit)
-
-
Tamás Zolnai yazdı
Change-Id: I4eacbe8ad2025a54c13f4c0fa06e30e5ab59b721 Reviewed-on: https://gerrit.libreoffice.org/70344 Tested-by: Jenkins Reviewed-by:
Tamás Zolnai <tamas.zolnai@collabora.com>
-
- 07 Nis, 2019 7 kayıt (commit)
-
-
Eike Rathke yazdı
Change-Id: I4713b15061e831e1dfeccf8d59e46c0aa2ac4a18 Reviewed-on: https://gerrit.libreoffice.org/70351Reviewed-by:
Eike Rathke <erack@redhat.com> Tested-by: Jenkins
-
Vasily Melenchuk yazdı
The userformscontainers is required property to pass checks in getter/setter, but returning true instead of actual type is not a best idea. So let's return actually expected dummy empty container. Change-Id: I5cc3e5462ed82f6f2f8e5a45d9fc2d9f9ce1c76f Reviewed-on: https://gerrit.libreoffice.org/67431 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 24e7d982) Reviewed-on: https://gerrit.libreoffice.org/70235Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Eike Rathke yazdı
Prepare for "Japan's Y2K" Gengou calendar era switch after 2019-04-30 The emperor Akihito will abdicate on 2019-04-30. The next emperor will be Naruhito, but so far neither the new era name (Heisei for Akihito) nor its abbreviation or a Unicode character are determined. At least introduce the new era with some dummy names (Naruhito,Na,N). Change-Id: I8c0af390ca0408ac259e47e7eaf2e49b5889c9ba Reviewed-on: https://gerrit.libreoffice.org/58142Reviewed-by:
-
Armin Le Grand yazdı
By error the ClipRegion's geometry was replaced by it's BoundRect expanded to PixelBounds. If the ClipRegion is not a rectangle, this will create wrong results. To do both - extend to PixelBounds and have the original geometry included - use the PolyPolygon topology as needed (see comment in code for details) Reviewed-on: https://gerrit.libreoffice.org/70146 Tested-by: Jenkins Reviewed-by:
Armin Le Grand <Armin.Le.Grand@me.com> (cherry picked from commit 362c1cf2) Conflicts: sw/source/core/doc/notxtfrm.cxx Change-Id: If3f75223144eba8eb23909a7c701ad544346099b Reviewed-on: https://gerrit.libreoffice.org/70158Tested-by:
Xisco Faulí <xiscofauli@libreoffice.org> Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: Ie14600e9f9a1e1c4e99c7a872f5d677453481888 Reviewed-on: https://gerrit.libreoffice.org/69666 Tested-by: Jenkins Reviewed-by:
-
Eike Rathke yazdı
This was done long ago for the tr-TR locale as well. Change-Id: I5bf8595f6d49adb7fd76b3c4924c4d72b3b8ea5e Reviewed-on: https://gerrit.libreoffice.org/69717Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
Luboš Luňák yazdı
The assert in the bugreport is triggered by ScPrintFunc::CalcPages() passing uninitialized values of nEndRow (and others). These variables apparently get initialized only by constructors that take ScPrintState. These ctors also set (the somewhat poorly named) bState and the call to CalcPages() is guarded by this. However, GetPrintState() will simply create ScPrintState filled with these uninitialized values and later on this will be used with these ctors, so bState will be set, but nEndRow will be bogus. Although 5217a2a0 introduced tdf#121439, this strange bState logic and unitialized variables has been these since the initial commit, and the code doesn't take any precautions to check whether the values are valid or not, so I assume this always was just lucky enough to work and 5217a2a0 finally triggered a problem. Given that it's rather unclear to me how this is supposed to work properly, just add an extra flag to both ScPrintFunc and ScPrintState marking whether the values are set or not and make CalcPages() depends on this flag instead. Change-Id: I0620de6562865c24f5a0edca2566b01546bf2e2b Reviewed-on: https://gerrit.libreoffice.org/68739Reviewed-by:
Luboš Luňák <l.lunak@collabora.com> Reviewed-by:
-
