[Libreoffice-commits] core.git: Changes to 'private/llunak/mailmerge_02'
Luboš Luňák
l.lunak at collabora.com
Fri Nov 14 04:33:40 PST 2014
New branch 'private/llunak/mailmerge_02' available with the following commits:
commit 44f40b82d52cfe60de3f18ed5aeae04171c9b197
Author: Luboš Luňák <l.lunak at 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.lunak at 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.lunak at 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.lunak at 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.lunak at 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 <rattles2013 at 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.lunak at 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.lunak at 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.lunak at 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 <vmiklos at 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 <vmiklos at 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 <vmiklos at 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 <vmiklos at 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.lunak at 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.lunak at 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.lunak at 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.lunak at collabora.com>
Date: Tue Oct 21 19:57:45 2014 +0200
more local variable
Change-Id: Ibe67ecdd5b121ad5624bfd111dca33897d6e1991
commit 19baf54e08b30f7e0218f9086054bc1afd540f00
Author: Jan-Marek Glogowski <glogow at 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 <glogow at 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 <mstahl at 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)
More information about the Libreoffice-commits
mailing list