Age | Commit message (Collapse) | Author |
|
this improves load time by 20%.
We switch from shared_ptr to tools::SvRef to manage the objects
I noticed some double inheritance like this:
DomainMapper
LoggedProperties
Properties
SvRefBase
LoggedTable
Table
SvRefBase
so to be safe I made all the ref-count-base-class inheritance
virtual.
Change-Id: Ia3de9733f5c6966e8171f43d083dcc087040b8cd
Reviewed-on: https://gerrit.libreoffice.org/57022
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iab61e0a7cac2dc89e6b04875a62894b181aa0ff4
Reviewed-on: https://gerrit.libreoffice.org/54016
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Talking about names when those are numbers is confusing.
Change-Id: Icfeed8924daeb1d6f658118515f9d4a76229106e
Reviewed-on: https://gerrit.libreoffice.org/41540
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Also use default member initializers where possible.
Change-Id: I641ea8e81506d826d4d81e9be21a1a0c8d6160e9
Reviewed-on: https://gerrit.libreoffice.org/39555
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ie7182fa30155a8090421cf9a669525be99f0e0a7
Reviewed-on: https://gerrit.libreoffice.org/38042
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
Change-Id: Ia85f5a7a9846802de7a1495e70d16c9e3418dc3e
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Change-Id: I1cdf56df10516f01ca091043b6a01bc14095413a
Reviewed-on: https://gerrit.libreoffice.org/15242
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ib5649d8979093bb147c61eebcf95a472ad899672
|
|
Change-Id: Ic8c691c4185ec8b808e75885f9354c35d68be58c
|
|
Change-Id: I7fb61144d8ff263e97de8cb7088b9eefdaafe52f
|
|
The margin of the floating table from top of the page is not being preserved correctly and it also get increased.
The w:tblpPr tag is also not preserved.
Reviewed on:
https://gerrit.libreoffice.org/9185
Change-Id: I8a27a4bab94a1afd27a7ba49ca55ff014918fffc
|
|
|
|
Change-Id: Idedee38be19bc770518b85af62c9fc2b5b64e822
|
|
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
|
|
Change-Id: I8149471775d623f52231d12f05a28e98b33fae6a
|
|
Change-Id: I0d4a624ee75e701966a2694642d71483c6ec572f
|
|
Change-Id: I5bc51b739c663d3e123c9d7fb4c2a70f01f8c841
|
|
Left margin wasn't implemented, that's simple. Right margin of the table
was set to the cell margin in commit
53d27a30ce5f2c9f7d37a4089286116854c16215, which turns out to be wrong:
it's true that the right margin should be >0, but not because of the
cell margin but because of the table margin. The new behavior matches
what the binary import always did.
Change-Id: Ifc24e4f086c49d5d575defdfca1d27e497fa03dc
|
|
Change-Id: Ia3a95d785d19f7be750e3723c1c159395ae8476f
|
|
In Word, just like normal tables, floating tables should be positioned
in a way that the start of the cell text has the same horizontal
position as normal paragraph text.
To emulate this, first the table should be moved left by the table
border distance, then also by the border with / 2; as done for
non-floating tables already.
Change-Id: I581311fbb08009e6c1839106e8f615d078a4a705
|
|
When importing docx with 2 <w:tbl> following each other, we have 2
possible behaviors: either merge them as one table as we did before or
split them into two tables. The tables need to be split if they have
different floating position properties.
This required the ooxml tokenizer to repeat the table properties for
each row of the table: or how would we know we don't need to split the
table?
The basic idea behind this hack is to temporarily store the table
position and table properties before saving them. Thus we can compare
them at the end of the row and decide to split the table or not.
Change-Id: I2e3e70dfe7386090fe356575ee9d0e81aa031dc4
|
|
|
|
Change-Id: I5c848a8d4c860a83d6729b8db40f744afad906d5
|