Age | Commit message (Collapse) | Author |
|
Change-Id: I208064aef57e0ef4b149183869f0908580e189f1
Reviewed-on: https://gerrit.libreoffice.org/13528
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I6adcaa8534efefa474d489125d3fb95f150e3e89
|
|
So the const_cast<> in CppunitTest_sw_uiwriter can go away.
Change-Id: Id7d4234154cd6bed43cb5270b50208061038dcf7
|
|
Change-Id: If2de38d23c5753e703517b5ef82d0f00070c2f34
|
|
Change-Id: I262efe47d8a28d1462cf35314a99c4404ffa2200
|
|
Change-Id: Ia38bdf402595dc0b7e6dabd80a4e93e53142b719
|
|
Change-Id: If961ecfe27c6f478f030bab746278b885482b229
|
|
Commit f9eff2a402a4cd28d7dbfb6ce27cbf96b31e576f is not quite right
because it will leave the mpNext chain unreachable; that could perhaps
be imporoved by calling RemoveFromLayout(), but...
Actually the problem is basically that one of the deleted SwCellFrms
points to a SwTableBox with getRowSpan() -1 (because it has been merged)
and thus IsInCoveredCell() returns true and that causes ~SwCellFrm() to
skip disposing the SwAccessible stuff, so the SwCellFrm is still
contained in the SwAccessibleMap.
Because it's rather hard to prevent this sort of thing in general,
better change SwAccessibleMap::Dispose() to assume that if it found its
way into the SwAccessibleMap it should be disposed and removed.
Change-Id: Ib4cec6924cb026ae30bdac6857957adf237b4d70
|
|
Change-Id: I4daf01450a4aa8f1d2bc6eae731a735d0d38a074
|
|
Change-Id: I173728b9f800b6a9c6e81d496a268b4e42cf4db9
|
|
Change-Id: I7daf52a60e3fac8d9f86b464e86af60e0495fcb1
|
|
I can't easily see what component is missing for SVM saving, and we do
the same in CppunitTest_sw_htmlimport already, so why bother.
Change-Id: Iba917e211fc721f8e275b3ce04a0e02c0759485b
|
|
Change-Id: I9c3e03324c69beb5af4c43da208086600876f875
|
|
...which resolves the mystery of 0ba6360363fb73b5b200bbc486ed8eeac5f3d337
"Garbage in, garbage out?"
Change-Id: I51f102699d0474872c80392b27f71030b5e3fb59
|
|
Change-Id: I8dc3a0ed7bfce62b0d20c6bff143d77c0f26963f
|
|
Change-Id: I74c6e8633ee5ac477d2f7ac8ee468204076bc886
Reviewed-on: https://gerrit.libreoffice.org/13488
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
rather uglyish unittest, but still worth it as cutting nothing needing
to have sideeffects is really kind of non-obvious and prone to return
Change-Id: I02bbfb05f019874d873670cdae060ac3183f5ca6
|
|
Change-Id: I2ae917b43b18b14dce01121902a678d45ad520fe
|
|
...to use single ASCII character literals "more directly" in the OUString API
(instead of having to go via an intermediary OUString ctor call). Especially
useful for character literals that are defined as const variables or via macros
("direct" uses of character literals in the OUString API can often simply be
replaced with single-character string literals, for improved readability).
(The functions overloaded for OUStringLiteral1 are those that are actually used
by the existing LO code; more could potentially be added. The asymmetry in the
operator ==/!= parameter types is by design, though---writing code like
'x' == s
is an abomination that shall not be abetted.)
Change-Id: Ic5264714be7439eed56b5dfca6ccaee277306f1f
|
|
Non-ASCII characters (like Unicode "é", represented as two bytes \xC3 \xA9 in
the UTF-8--encoded source file, and presumably passed trhough unchanged by
compilers into the resulting string literal object) in the OUString "literal"
ctor trigger a SAL_WARN_IF in rtl_uString_newFromLiteral, but are copied
"verbatim" into the resulting OUString, which will thus contain UTF-16 code
units \x00C3 \x00A9 (if char is unsigned) resp. \xFFC3 \xFFA9 (if char is
signed).
That assertXPathContent shall indeed match such an odd OUString value looks
suspiciously like a bug elsewhere, papered over by a broken test. To be
investigated.
Change-Id: I07c995ad0e17235c214d7630fb34e8ef35d5ad30
|
|
Change-Id: I844c00639307c14140ba7e8a1b919e3f2ecdc114
|
|
Change-Id: I5d5746869e47a1d25d6bec28452394e215d4427d
Reviewed-on: https://gerrit.libreoffice.org/13483
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I5421cf5a7d1a2ff4db81d028f44a490c234b9ccf
|
|
Change-Id: Icda252e1f092707728d3a24df50fba7080e759bb
|
|
Change-Id: Ia957541a5997961aa86b2eb8537ebd29d3092691
|
|
SwPageDesc no longer contains RES_BACKGROUND but XATTR_FOO.
Change-Id: Ie722b0279f9d9831338f6613a4722010afd1543e
|
|
fix assert on loading ooo123653-1, we don't care about ranges that end before
the starting point we are interested in
Change-Id: I46ddf882ce4099dbcd77c62569c5c51f1ce5aa76
|
|
Change-Id: I8283ddd868639e6535e27798d91a7273d77f048c
|
|
Change-Id: I64690ce1d6960dea52bae6a5bc1d0f1de742cb63
|
|
To use it, enable "Print layout" in Options->Load/Save->HTML Compatibility,
and select the HTML Document file type in the Writer Save As dialog.
Change-Id: I763ab8340a59050fd5c68677715679f41fd91fb3
|
|
The SwInputFld is copied because it doesn't have HasDummyChar() set
although it has 2 dummy characters; TODO why is that...
Change-Id: Iee91c1d0cf7a7a928e7383c1839f8192e8d4d5b0
|
|
... should fix field dupes"
This reverts commit f384598d8eec91c3c0f84a07ff3e59b8e3e13b3f.
The attributes have to be copied in case splitting a paragraph creates
an empty paragraph.
Change-Id: Icd5730dd9ab8a68f737492645988a4d2f07af7a0
|
|
Change-Id: Ifdb896108cf0db0a9be7ba419df785da536c0fab
Reviewed-on: https://gerrit.libreoffice.org/13465
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
Change-Id: Ia6e166a4158d28f1a4145e51040f2f5637827197
Reviewed-on: https://gerrit.libreoffice.org/13466
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
This reverts commit 07c00671443f3f0a2e2e6c3a54c391f040e8fd2b.
The bug is because the check of the GotoHeaderTxt() is inverted.
Actually in the old code it is a bit easier to understand what is intended,
even though it is more verbose, so just revert the commit.
|
|
Change-Id: Iac3917c42ff70b6cd594355fe5296aff97cb70b9
Reviewed-on: https://gerrit.libreoffice.org/13453
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7e52bba78a0fbe32814510b44ad049d3504e7164
|
|
Change-Id: I5d6071096307adbe7df0178000346cf915afa3e7
Reviewed-on: https://gerrit.libreoffice.org/13477
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I813cc6bdc92b03bdfdd5202a85e958020a9c52c8
|
|
Change-Id: I286df7dc70e7f8e6e911f02d2e8aa6ebb390ef61
|
|
Change-Id: I559d1e44d9096a2583af8e05468b3743ac210c6c
|
|
Change-Id: I84e475a64cf09e4eeea524b73f8febf7f0a1a46b
|
|
Change-Id: I893d358f8a842e19248cfeb151170ed2872c3dae
|
|
Change-Id: Ia58bed9c4a0be4b909789e8bdcd64f06230c0f43
|
|
Regression from 01a32b7d074511bed24044dc94e1159aea62722b (fdo#85179 RTF
filter: import image border, 2014-10-23), there were a number of
problems here:
- CppunitTest_sw_htmlexport: revert back to the old behavior, where in
case there is no border, we don't set the color of it.
- The testcase of the above commit omitted fLine=1 shape property, which
is present in the original bugdoc, and only with that should we put a
border around the shape.
- Let fLine=1 explicitly change the line style from NONE.
- dmapper: if line style is NONE, then don't bother setting the border
color and width.
Change-Id: Iffee41066d42822b699c478821645b9742df3f58
|
|
Change-Id: Ib2c1d439866764a5c3510f0796efe6bc0d8d2a1e
|
|
Change-Id: Ic4d9c99c8a2b994cec8828808d02a46ec6a18e2c
|
|
Change-Id: I2cd312255f80e22ead614d0ea12a2130fb8bbeaa
|
|
Change-Id: Idc4dfb74734f1203586b04ea86a05905f5dac694
|
|
Change-Id: Ie4bb2b3bf7d2df58c30a54ded68f7b932c2111ed
|