New branch 'private/llunak/mailmerge_02' available with the following commits: commit 44f40b82d52cfe60de3f18ed5aeae04171c9b197 Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Sun Nov 9 22:59:41 2014 +0100
avoid unused argument warning Change-Id: Ib67b804423b521407710f8319cb89977e44494cc commit 390b6e5cf66363275ac693bfc37ead8508412c86 Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Sun Nov 9 22:37:11 2014 +0100 speed up SwDoc::IsInHeaderFooter() by using SwFrmFmtAnchorMap Now that it's possible to quickly find anchored objects for a node, it's actually faster to check the node hiearchy rather than layout. Conflicts: sw/source/core/doc/doclay.cxx Change-Id: I5f93d5af32c744f1773535e5ec8537334d1ff58a commit f679e32f892d7ac198d511d53b524d7059ff42fc Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Sun Nov 9 15:30:08 2014 +0100 faster mapping from nodes to SwFrmFmt's anchored at them The SwFrmFmtAnchorMap class provides reverse mapping to SwFrmFmt::GetAnchor().GetCntntAnchor(), so that when code somewhere needs to update SwFrmFmt's anchored at a position, it's not necessary to iterate over all of them (which can be a large number e.g. with mail merge). One special catch with the multimap of SwNodeIndex keys is that the values of those keys change (whenever the node structure of the document changes, indexes of nodes change as a result). This makes it impossible to use any hashing container, as the hashes would change without the container noticing, but multimap should work fine, as it just requires that the keys remain sorted, and that is the case. Nevertheless, the old code in the two converted places is intentionally left there in debug mode to verify the reverse mapping is updated correctly. I intentionally went with SwNodeIndex rather than SwPosition, as SwIndex (the other component of SwPosition) was causing some trouble (see e.g. the SwPosition comparison operator< , where two same positions are different if one is registered and the other not) and it doesn't appear to be actually necessary. Conflicts: sw/inc/doc.hxx sw/inc/frmfmt.hxx sw/source/core/attr/swatrset.cxx sw/source/core/doc/docnew.cxx sw/source/core/inc/frmtool.hxx sw/source/core/layout/atrfrm.cxx sw/source/core/txtnode/ndtxt.cxx Change-Id: I7f1768558f60155d4ba83c84aa7f9e34dc65ebf9 commit 0bc4baf73ce11a777195a31c23496960f60f6dfb Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Sun Nov 9 10:33:00 2014 +0100 do not break encapsulation of SwFmtAnchor::GetCntntAnchor() Conflicts: sw/source/core/doc/DocumentContentOperationsManager.cxx sw/source/core/frmedt/fefly1.cxx sw/source/core/frmedt/feshview.cxx sw/source/core/layout/flycnt.cxx sw/source/core/txtnode/atrflyin.cxx Change-Id: I0a320eb990f9a3b6800447a97a84c118239bae96 commit 0e8534395c3ba0d328a14525d145ff3e75b1457d Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Sat Nov 8 09:41:02 2014 +0100 do not bother with nice unique names during mailmerge When using a single document for all the generating MM documents, there can be a significant number of sections/etc. , enough to make searching them all in order to find a next nice unique name take a noticeable time. Since it's very unlikely anybody will ever care about nice names after mailmerge, just get some unique name in a fast way. Conflicts: sw/source/core/doc/docbm.cxx sw/source/core/doc/doclay.cxx sw/source/core/doc/docnum.cxx sw/source/core/doc/doctxm.cxx sw/source/core/docnode/ndsect.cxx sw/source/core/inc/MarkManager.hxx Change-Id: Id6b8d39a67529984cb93bb369f2c6eab401f1799 commit 4ca3a96ff8b5c05aa8a4e48000a1ee485a59707a Author: Adam Co <rattles2...@gmail.com> Date: Tue Nov 26 13:56:46 2013 +0200 Moved 'DateTimeToOString' from 'filter' package to 'tools' package After the move now other classes can convert DateTime to OString also Reviewed on: https://gerrit.libreoffice.org/6816 Conflicts: sw/source/filter/ww8/docxattributeoutput.cxx Change-Id: I0ceb9a5cc26103a6cb36d7765a717770ec3fbe7d commit 0524dee2a9a1b4ff43a19654ab73ff764e7cadef Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Sat Nov 8 09:15:49 2014 +0100 actually use return value of GetUniqueSectionName() in SwDoc::UpdateSection() Change-Id: I6d9ae98e900e5e42c5253ee9b2f71bec351b54d1 commit e64428fa982838bd40d068ac65943fcf3c1ed76f Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Fri Nov 7 16:14:21 2014 +0100 do not iterate over all bookmarks in SwTxtNode::Update() 3f9872185e introduced new API for fast finding of marks to a specific text node, so use that (code itself based on cb46aaf2d7). This makes mailmerge faster (since it can create a huge document, and especially with the change to use UNO bookmarks to mark starts of MM documents inside the larger single document there can be a large number of marks). Conflicts: sw/source/core/txtnode/ndtxt.cxx Change-Id: I30ec69acf423e9a62fae5f5492ed8744cb727a56 commit 7b47afeed36c6b9089ac484e2331377d36251d0f Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Thu Nov 6 16:43:28 2014 +0100 name of mailmerge marks is actually irrelevant UNO bookmarks have internals names and ignore this Conflicts: sw/source/uibase/dbui/dbmgr.cxx Change-Id: I37baa4c9bcf9cec37f91e3b1d0fb2fad322ceda8 commit a6b78999adc23f70071de811d36c19ce01aee013 Author: Miklos Vajna <vmik...@collabora.co.uk> Date: Fri Oct 31 10:22:28 2014 +0100 SwDBManager::MergeMailFiles: set unique fly names at the end of the merge When generating a unique fly name, we have to iterate over all the existing flys to find out what's the first not used one, so doing this for every new fly inserted by mail merge is O(n^2). During import, we already skip this and only do it once at the end of the import, which is O(n). Fix the performance problem by skipping the unique fly name generating when we produce a combined mail merge document as well, and just generate them once the mail merge is complete. For a test document having 12 text frames and 2000 mail merge records, the times for css::text::MailMerge::execute() is 9m37.330s -> 8m18.811s. Conflicts: sw/inc/doc.hxx sw/source/core/doc/DocumentLayoutManager.cxx sw/source/uibase/dbui/dbmgr.cxx Change-Id: Idfa8e9fe3acc93f1138f5bb12c2419c1492f8ff1 commit 5b09df234f11e4d964170e8872897552cdf71021 Author: Miklos Vajna <vmik...@collabora.co.uk> Date: Thu Oct 30 11:59:17 2014 +0100 sw: use new bookmark API in lcl_FillBookmarkArray() for text nodes For a document of 1000 pages and having 13000 bookmarks, this helps a lot on ODF export: 2m51.565s -> 2m23.412s on my machine. Conflicts: sw/source/core/unocore/unoportenum.cxx Change-Id: I8c8a7cd2b83a94ab7f2de17e0b4cb449fc4c0e1a commit 6b4e5d0acd28a1ccbfad666fa39febf099c364b1 Author: Miklos Vajna <vmik...@collabora.co.uk> Date: Thu Oct 30 11:06:52 2014 +0100 sw: add API that provides fast access to marks of a text node sw::mark::MarkManager already provides two methods to provide not so slow mark access: - some marks (bookmarks, annotation marks) have their own container, so it's possible to iterate over only those types, not all of them - the containers are sorted by the start position of the marks, so it's easy to ignore marks that are after the current text node However, it's not possible to ignore marks ending before the current text node. This is a problem, as e.g. during ODF export, we have to iterate over every bookmark for each paragraph, so the operation is not linear. On the other hand, the start and end position of bookmarks are stored using SwPosition, and the SwIndex of the SwPosition is already registered in the SwIndexReg of the SwTxtNode, so the text node sort of already knows what bookmarks start/end at the current paragraph, it just doesn't known which position belongs to what mark (if it belongs to a mark). Fix the problem by adding a pointer to SwIndex that can optionally point back to the mark that owns it. Also, in the sw::mark::MarkBase methods (which are the only ones allowed to touch those positions) always set that pointer. With this, it's possible to get the bookmarks of a node (list of bookmarks which start or end in the current node) in a much faster way for text nodes. Conflicts: sw/inc/index.hxx sw/source/core/bastyp/index.cxx Change-Id: I7ceeff4dce852b4d72f2a73ae6a2423c7a781e41 commit acb201e5e874443dde7cb80a069a8722be7ce4fa Author: Miklos Vajna <vmik...@collabora.co.uk> Date: Tue Oct 28 15:44:06 2014 +0100 SwXTextPortionEnumeration ctor: avoid dynamic_cast in the common case For a document of 1000 pages and with 1000 bookmarks, this brings a considerable speedup on ODF export: before: real 3m28.187s after: real 2m51.565s Change-Id: Ic3f85c727a8ea4b5012d5c3f0a5887ff47762fb8 commit f84c3330365268b6d8d2c21ddd150ca11857bd1d Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Wed Oct 22 13:20:49 2014 +0200 do not repeatedly relayout mailmerge document after each change When mailmerge uses a single document for all the generated documents, doing a layout of this increasingly large document after every generated document addition was getting slower and slower (no wonder). My recent changes should have removed all needs for any layout in progress, so it should be enough to just once calculate the final layout. The final layout still appears to be needed, leaving it as it is to get layout done on the fly puts e.g. 2-page documents on wrong starting page (maybe just invalidating something would fix that). Debug build shows warnings from vdraw.cxx about moving anchor from an invalid page because of broken layouting, but those were there already before, so I assume those are not really significant (or at least made worse by this commit). Conflicts: sw/source/uibase/dbui/dbmgr.cxx Change-Id: I62601ad6dccaa008783d1ce34c9e4f66f9621a56 commit 57658e82c04d00fda60aaf9e22eb16cd1d6cfbb0 Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Mon Oct 20 22:05:51 2014 +0200 compute page offset for mailmerge based on source document rather than target This removes another need for doing repeated and expensive layouts of the target document. Conflicts: sw/inc/doc.hxx sw/source/core/doc/docnew.cxx sw/source/uibase/dbui/dbmgr.cxx Change-Id: Id78bc3ccc71c17e42f858dc9660866b9c94dea3a commit 708cada5d76a26b6b2ac2885bf6b48f1205f1dd5 Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Mon Oct 20 15:13:03 2014 +0200 use bookmarks to mark mailmerge parts in a mailmerge document (fdo#80823) Instead of page numbers, which - was somewhat fragile (and broken, as it was actually off-by-one) - required repeated re-layout of the increasingly large document, making mailmerge awfully slow. The re-layout is not removed by this commit, as it needs further checking whether it can be removed. See the bugreport for details. Conflicts: sw/inc/doc.hxx sw/source/core/doc/docnew.cxx sw/source/ui/dbui/mmoutputpage.cxx sw/source/uibase/dbui/dbmgr.cxx sw/source/uibase/inc/mmconfigitem.hxx Change-Id: Ib09bd5f5a6a549c3d38ca40b0f32c0d2831fdd4c commit 6a3bc5f88114edf3c951c78d8e845cf99f82b5eb Author: LuboÅ¡ LuÅák <l.lu...@collabora.com> Date: Tue Oct 21 19:57:45 2014 +0200 more local variable Change-Id: Ibe67ecdd5b121ad5624bfd111dca33897d6e1991 commit 19baf54e08b30f7e0218f9086054bc1afd540f00 Author: Jan-Marek Glogowski <glo...@fbihome.de> Date: Mon Sep 15 00:13:06 2014 +0200 MM: export the SwDocShell mail merge via UNO This saves the loading time for large document. Use it if you want to present the generated document to the user or write a mail merge unit tests. This includes: * renaming "only" to "shell" at multiple occurences * dropping the DBMGR_MERGE_SINGLE_FILE special type for the mail merge wizard in favour of an additional SwMergeDescriptor boolean * cleanup and renaming of the internal merge type enums, so these actually match the diffferent merge targets: printer, email, file and shell (cherry picked from commit 9835bb562cfe3a5d386c24d86176ba7bb5ab26d2) Conflicts: offapi/type_reference/offapi.idl sw/inc/dbmgr.hxx sw/source/ui/dialog/swdlgfact.cxx sw/source/ui/dialog/swdlgfact.hxx sw/source/ui/envelp/mailmrge.cxx sw/source/uibase/dbui/dbmgr.cxx sw/source/uibase/inc/mailmrge.hxx sw/source/uibase/uno/unomailmerge.cxx Change-Id: I33c6773972195193687ba9c3e12b562310d330c1 (cherry picked from commit bf07857ff32d887bd215745430cfb6552577ff28) (cherry picked from commit 7966c022502f852a495b1f0ce2dcec79e15b8dcf) commit 404cb780a96ee4e4bc92dcf2f1704f8675f7e042 Author: Jan-Marek Glogowski <glo...@fbihome.de> Date: Mon Sep 15 00:00:03 2014 +0200 MM: dump debug documents based on environment var Introduce SW_DEBUG_MAILMERGE_DOCS=<n> to dump n mail merge debug documents (partly merged and working copies). This will speed up mail merge unit tests and allows dumping of an arbitrary amount of intermediate mail merge documents. (cherry picked from commit 0a5cd87e591d7f87bfab92716079af719259f143) Conflicts: sw/source/uibase/dbui/dbmgr.cxx Change-Id: Idb9fc19f99ccafe5574897bd1e687d439c52ebe5 (cherry picked from commit 12052969b6edf9119f60d685a170f2fd442f2e67) (cherry picked from commit 48cc32ea4760ad73f574cda9219b9d220c77fb66) commit eabd9b085bcae9d61dbeb8cedf263c17916b1311 Author: Michael Stahl <mst...@redhat.com> Date: Fri Sep 12 21:50:36 2014 +0200 :sw: rename SwDoc::Append to something unique (cherry picked from commit 3b11057b75434526f67e678ddc1deb9ebd61c752) Conflicts: sw/source/uibase/dbui/dbmgr.cxx Change-Id: Ibb9db5ecdea6439df20fc1ee609267dcdd864405 (cherry picked from commit 4896a4984473857d5b12df69a287c44c485105b7) (cherry picked from commit bd73285aff577350d7dff4907aad9053f7721dd1)
_______________________________________________ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits