- 28 May, 2019 40 kayıt (commit)
-
-
andreas kainz yazdı
Change-Id: Ibdca2026f29483948c2fafaf499a82d2a4acf08b Reviewed-on: https://gerrit.libreoffice.org/73095 Tested-by: Jenkins Reviewed-by:
andreas_kainz <kainz.a@gmail.com>
-
Miklos Vajna yazdı
There is no reason why Ctrl-A should be a NOP when you have an image selected. No test, there is one in the cp-6.0 copy&paste code, that coverage will arrive as part of that copy&paste code forward-port. Change-Id: If0013ee0e9ff9a6fb038a22de7b5d3c76e5c52b9 Reviewed-on: https://gerrit.libreoffice.org/73118Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
-
andreas kainz yazdı
Change-Id: I33e7882ed2792a9d1f23ee42645efc4f5003f01d Reviewed-on: https://gerrit.libreoffice.org/73099 Tested-by: Jenkins Reviewed-by:
-
Grzegorz Araminowicz yazdı
Change-Id: Ie1c14bdc4f4db6f8f919433d40ea2281736c38ed Reviewed-on: https://gerrit.libreoffice.org/73097 Tested-by: Jenkins Reviewed-by:
Grzegorz Araminowicz <grzegorz.araminowicz@collabora.com>
-
andreas kainz yazdı
Change-Id: I51bf435b555302fe96493f540f5e5a8dc33d0267 Reviewed-on: https://gerrit.libreoffice.org/73081 Tested-by: Jenkins Reviewed-by:
-
Olivier Hallot yazdı
* Update helpcontent2 from branch 'master' - Remove xml comments from file xml comments inside <bookmark> index are moved as is to Pootle and are not handled as comment when brought back to translated file. Change-Id: I040cf84851dea3feea26054cb9a0a20e1241c53b Reviewed-on: https://gerrit.libreoffice.org/73112 Tested-by: Jenkins Reviewed-by:Olivier Hallot <olivier.hallot@libreoffice.org>
-
Gülşah Köse yazdı
Change-Id: I4bd0986f23414edc857ca890f6437c6029116e72 Reviewed-on: https://gerrit.libreoffice.org/73070 Tested-by: Jenkins Reviewed-by:
Gülşah Köse <gulsah.kose@collabora.com>
-
Stephan Bergmann yazdı
...with e.g. `--convert-to pdf abw/abi10006-1.abw` as obtained by bin/get-bugzilla-attachments-by-mimetype, reporting > vcl/source/fontsubset/cff.cxx:1697:63: runtime error: signed integer overflow: 55810 * 52845 cannot be represented in type 'int' and > vcl/source/fontsubset/cff.cxx:1137:38: runtime error: signed integer overflow: 233492066 * 52845 cannot be represented in type 'int' Using unsigned here is faithful to the algorithm presented in Chapter 7 Encryption of "Adobe Type 1 Font Format" (<http://wwwimages.adobe.com/ www.adobe.com/content/dam/acom/en/devnet/font/pdfs/T1_SPEC.pdf>). Change-Id: Ic27a5ebbe5f766fef425d241e14487ea4ae81da4 Reviewed-on: https://gerrit.libreoffice.org/73104 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com>
-
Stephan Bergmann yazdı
...not an SfxInt16Item. Probably a typo introduced when adding the class with bf3f3a6b "notebookbar: working number format listbox". (Found with -fsanitize=vptr when switching Calc to "View - User Interface - Tabbed Compact".) Change-Id: I6142b20750872037767e1857edeae83b1b2fa849 Reviewed-on: https://gerrit.libreoffice.org/73089 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: Icfd6c5cbc405bad51a0d7f10cdb55c70a1fe5b00 Reviewed-on: https://gerrit.libreoffice.org/73078Reviewed-by:
Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
-
Zdeněk Crhonek yazdı
Change-Id: I45aa7b4fda0f19319d3e009bf8d29099e8497c71 Reviewed-on: https://gerrit.libreoffice.org/73067 Tested-by: Jenkins Reviewed-by:
Zdenek Crhonek <zcrhonek@gmail.com>
-
Michael Meeks yazdı
Reviewed-on: https://gerrit.libreoffice.org/72781Reviewed-by:
Jan Holesovsky <kendy@collabora.com> Tested-by:
-
Noel Grandin yazdı
There were O(n^2) issues all over the places where we walk these lists. This takes the opening time from 10m+ to 4m. (*) Invalidate the sorting on a much less aggressive basis, by having the SwTextAttr objects tell the SwpHints object when start and end pos changes (*) Add a bool field to indicate when the maps become unsorted, so we can resort them only when we actually need sorted access (*) Add an API for walking the list of SwTextAttr* without triggering sorting, which is particularly important when the RedlineManager starts moving things around. (*) Add various asserts to catch code that tries to iterate over these sorted lists but triggers resorting during the loop. I also moved some of the logic around so that instead of update hint delete hint insert hint it now goes delete hint update hint insert hint which means that the needToSort flag does not get set because the hint is disconnected while it is being updated. Change-Id: Ie153ddafc9ef9e3470d588db2be2457c676232a8 Reviewed-on: https://gerrit.libreoffice.org/73090Reviewed-by:Noel Grandin <noel.grandin@collabora.co.uk> Tested-by:
-
László Németh yazdı
by removing the redundant export of the temporary DOCX import character styles for bullets of bulleted lists. Note: this commit will fix the older documents – sometimes with thousands of unused styles – by the next export. The problem was escalated from the commit f9c8d97d "tdf#95213 DOCX import: don't reuse list label styles" Change-Id: I90590352c0c85a92dbad19a45e82339e1201f1e9 Reviewed-on: https://gerrit.libreoffice.org/73098 Tested-by: Jenkins Reviewed-by:
László Németh <nemeth@numbertext.org>
-
Jan-Marek Glogowski yazdı
Current qt5+cairo uses the plain VCL canvas. This patch is just a copy of Gtk3Surface (minus comments) with a different update call. This way the Cairo path now uses the Cairo canvas instead. It fixes at least tdf#122668 for me, but other Impress bugs might be fixed this way too. Change-Id: Iba511c851001753328293c28e53eaa4acc4315d0 Reviewed-on: https://gerrit.libreoffice.org/72921Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins Reviewed-by:
Aleksei Nikiforov <darktemplar@basealt.ru>
-
Caolán McNamara yazdı
https://gerrit.libreoffice.org/#/c/71829/ Change-Id: Ia98de7da7182ae35cbd83fdede89f3955ca45ece Reviewed-on: https://gerrit.libreoffice.org/73092Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Jan-Marek Glogowski yazdı
... and drop the special examples handling. All these lists are already static. The only "drawback" are the previously range-based for loops in SmElementsDockingWindow. Change-Id: I7a6cfbe74c29fcc14557aef1d5ef31d599b33fc0 Reviewed-on: https://gerrit.libreoffice.org/73076 Tested-by: Jenkins Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de>
-
Jan-Marek Glogowski yazdı
Since there is also no other information, like a label. Also removes one unneeded level of layout indirection. I'm not sure about the root placeholder child added by glade, but other dialogs have it too, so keep it. Change-Id: I235cc1ab5ea9ef37079353ee150eb000cb665dd1 Reviewed-on: https://gerrit.libreoffice.org/73075 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
Change-Id: If62dcbffe6514966418bbf78ef3392cc3219f159 Reviewed-on: https://gerrit.libreoffice.org/73074 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
(regression from c6b7f555)
-
Michael Stahl yazdı
This reverts commit c5338e3a. The actual problem was fixed in previous commit for tdf#125475. ValidateFrame() must only be called in text formatting with a SwTextLineAccess keeping the corresponding SwTextLine alive. Change-Id: I5b092b094f620f2dc2524aa5a83c673ec6b1fbbe Reviewed-on: https://gerrit.libreoffice.org/73048 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
Michael Stahl yazdı
SwCache::DeleteObj() may decide to shrink the cache, and then the SwTextFrame::mnCacheIndex goes stale, because only SwCacheObj::m_nCachePos is updated. In this bugdoc, this can happen *inside* SwTextFrame::Format(), where first it succeeds to find an existing SwTextLine, then some footnotes anchored in this paragraph are moved around and formatted, creating new SwTextLines, and SwCache::DeleteObj is called. Later, any access of the original frame's SwTextLine fails to find it and eventually some null pointer crash happens. Newly added SwTextLine::UpdateCachePos() requires that SwTextFrame lives longer than its SwTextLine; there was another problem with that, because SwTextFrame::FormatEmpty() was throwing away the mnCacheIndex, which could then cause a second SwTextLine to be created for the same SwTextFrame, and the first one is not deleted until it falls to the bottom of the LRU list. Apprently for this particular document the problem didn't happen before commit 3d37463e and/or commit 31ae7509 but that is mostly luck. Change-Id: I7bef1b340a453d6dd44d51a1dc69ee5fd0b697db Reviewed-on: https://gerrit.libreoffice.org/73047 Tested-by: Jenkins Reviewed-by:
-
Grzegorz Araminowicz yazdı
up to maximal size of primFontSz constraint. Do not override text size changed by user. Change-Id: If7ea6bbb96cb839831d877edc274a1b0eefdaf21 Reviewed-on: https://gerrit.libreoffice.org/73050 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I48195dfd64a0dc4f34860f88e3f63e5a0531453f Reviewed-on: https://gerrit.libreoffice.org/73085Reviewed-by:
-
Luboš Luňák yazdı
ZipPackageStream::saveChild() already had one threaded compression, but that still uses only one thread for one stream. Many documents contain many streams (where this is useful), but large documents often contain one huge content.xml, which then would be compressed using just one thread. But it is in fact possible to do deflate in parallel on the same data, at the cost of somewhat increased CPU usage (spread over threads). This is handled separately from the background thread path, as integrating these two approaches would probably be needlessly complex (since they both internally use ThreadPool, the tasks should often intermix and parallelize anyway). On my 4-core (8 HT threads) machine this reduces the compression time of tdf#113042 from 3s to 1s. Change-Id: Ifbc889a27966f97eb1ce2ce01c5fb0b151a1bdf8 Reviewed-on: https://gerrit.libreoffice.org/73032 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Luboš Luňák yazdı
It can be easily separated out, it looked like hacked in. And I will need to do more refactoring of the class, so this shouldn't be more complex than necessary. Change-Id: I302da55409e9195274907ca4939c37fbb2427b18 Reviewed-on: https://gerrit.libreoffice.org/73031 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
E.g. with the bugdoc from tdf#93553, most of the streams to save are actually small, they just do not provide XSeekable. Since it seems all the streams are already fully available by the time the zip packaging is done, fallback to XInputStream::available() to find out if the stream is small. With this, the zipping part of saving tdf#93553 is now down from ~1.5s to ~0.5s. This presumably also makes the hack for tdf#93553 unnecessary. Change-Id: Id9bb7d835400d6d8f147f5c11ade684a549aba53 Reviewed-on: https://gerrit.libreoffice.org/73030 Tested-by: Jenkins Reviewed-by:
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I202a98d76a37a564315374893b44ec25ef7798b3 Reviewed-on: https://gerrit.libreoffice.org/73005 Tested-by: Jenkins Reviewed-by:
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ic331c845f0a8f06c4a8f8f79b6f87e26ca7c3a7d Reviewed-on: https://gerrit.libreoffice.org/72972 Tested-by: Jenkins Reviewed-by:
-
Tor Lillqvist yazdı
Based on the corresponding macOS code. Work in progress. The image support ifdeffed out still (because it uses some macOS specific APIs for which I couldn't right away find the equivalent iOS ones). I made it much simpler than the macOS code. I dropped the keeping of a local in-process clipboard completely. Firstly, as far as I see, the iOS clipboard API (UIPasteboard etc) does not even offer the possibility to separately offer some formats and actually provide the data on request. Secondly, we must be prepared anyway that the system can kill an iOS app at any stage while the user is using some other app, so we need to make sure everything that is copied goes onto the system clipboard right away anyway. I had to disable the copying of HTML to the clipboard as that lead to a mysterious assertion failure. See comment in DataFlavorMapper::openOfficeToSystemFlavor(). But RTF seems to work well, too. I assume RTF is what gets used for cross-application copy/paste (and cross-device, even, through Apple's Universal Clipboard thing, where you can copy/paste between your Macs and iOS devices on the same network). I am not sure how relevant the various application/x-openoffice-foo formats are. Change-Id: I174495e33d86fc3990996c229243c05d6cbfcda7
-
Jens Carl yazdı
Change-Id: I816ccde944903e0ff3ac23e92632056a3192b060 Reviewed-on: https://gerrit.libreoffice.org/73069 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
When pasting a table we get: warn:legacy.osl:29407:29407:sw/source/core/layout/findfrm.cxx:1136: <SwFrame::FindPrevCnt_()> - unknown layout situation: current frame should be in page header or page foote ... because SwCellFrame's constructor inserts the content of the cell before the SwCellFrame's mpUpper is set, so it's not connected to anything; hence FindNextCnt()/FindPrevCnt() can only return frames inside the cell anyway, and all of those are newly created, so invalidating a11y flow-relations for them seems pointless because a11y doesn't even know about them yet. Change-Id: I96eb59d6ecfdaa453894d06494c6c50faa7cd1bd Reviewed-on: https://gerrit.libreoffice.org/73046 Tested-by: Jenkins Reviewed-by:
-
Julien Nabet yazdı
See http://document-foundation-mail-archive.969070.n3.nabble.com/Fishy-assignment-in-editdoc-editeng-td4262109.html Remove the previous comment less clear Change-Id: I06b0bc3254068d58146d9582c2b69afbadbe56ee Reviewed-on: https://gerrit.libreoffice.org/73062Reviewed-by:
-
Julien Nabet yazdı
Change-Id: Icfa8a2d2f6283b0961aa99debadf1e3d29ddaa53 Reviewed-on: https://gerrit.libreoffice.org/73068Reviewed-by:
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ie2d1a6dad1dc17777f05aa033ea5fed1807261ce Reviewed-on: https://gerrit.libreoffice.org/72636 Tested-by: Jenkins Reviewed-by:
-
Gabor Kelemen yazdı
Change-Id: Ibf6c181ecfb219ba5d142236471af03f8d3b32c6 Reviewed-on: https://gerrit.libreoffice.org/73072 Tested-by: Jenkins Reviewed-by:
-
Julien Nabet yazdı
Change-Id: I1cb5d3e6a1bf3c18b637273ed4fac671ad12354e Reviewed-on: https://gerrit.libreoffice.org/73065Reviewed-by:
-
Gülşah Köse yazdı
Change-Id: Id12838cf08a2e5b74b53bd0036804b886b41098f Reviewed-on: https://gerrit.libreoffice.org/73041 Tested-by: Jenkins Reviewed-by:
-
Gülşah Köse yazdı
Change-Id: I521b3a86d1fb215c6f355b198cfd5d9b5f777490 Reviewed-on: https://gerrit.libreoffice.org/73040 Tested-by: Jenkins Reviewed-by:
-
Julien Nabet yazdı
Change-Id: I6c09bf2af4b902fdc215ec31bf2dad490e41384e Reviewed-on: https://gerrit.libreoffice.org/73066 Tested-by: Jenkins Reviewed-by:
-
