Age | Commit message (Collapse) | Author |
|
Change-Id: I59193af4c0b4945ef9612862e57a276cc1d89ea4
|
|
8f8bc0dcf3bc253ae49159d52db049767f476ced "Move string hash function into String
class" had introduced a new getHash64 that, besides returning sal_uInt64 instead
of just sal_Int32, didn't do sampling of only a handful of characters, but
always computed the hash over all characters (as the usage in SfxItemSet and
SdPage appears to require for either performance or approximated correctness).
However, it would be advantageous to keep the stable URE interface as small as
possible. Now, O(1) sampling was apparently considered state of the art when
the rtl string classes were first created, closely copying java.lang.String,
which at that time demanded sampling for hashCode(), too---but never sampling
more than 15 characters, with the obvious (in hindsight, at least) performance
catastrophes, so they changed it to O(n) somewhere along the way.
Based on that, this commit changes the existing hash functions to not do
sampling any more, and removes the newly introduced -64 variants again. (Where
the extended value range of sal_uInt64 compared to sal_Int32 was hopefully not
vital to the existing uses.)
The old implementation used sampling only for strings of length >= 256, so I did
a "make check" build with an instrumented hash function that flagged all uses
with inputs of length >= 256, and grepped workdir/{Cppunit,Junit,Python}Test for
hits. Of the 2849 hits encountered, 2845 where in the range from 256 to 295
characters, and only the remaining four where of 2472 characters. Those four
were from CppunitTest_sc_subsequent_filters_test, importing long text into a
cell, causing ScDocumentImport::setStringCell to call
svl::SharedStringPool::intern, which internally uses an unordered_set. These
results appear to justify the change.
Change-Id: I78fcc3b0f07389bdf36a21701b95a1ff0a0d970f
|
|
Change-Id: I5fe47cfaee84c17584ba7c3d160e65b55f4e3474
|
|
Change-Id: Ie975f8a970eec63b593933ebb2394db76d537c51
|
|
Change-Id: Id1d838fe4316bbc0e1137d395bb15db3585aed84
|
|
Change-Id: I6a90bbc1fc2faa379a72dd0a61dd96a829676e2c
|
|
Change-Id: Ieba5e6b1c1f32125a4c266e5252d9c1bc729f061
|
|
Change-Id: I628c1506573c7d5ec182048a20ed996c9ae879c4
|
|
Change-Id: Ic4a198d737692734ae3fbc096f370a3aa0667c5b
|
|
Change-Id: I3aad235d92b3972b44199294c0f3de65ad57f450
|
|
Change-Id: Ib9ab63cdf21f54b1611de37c5538a300a1b39ba6
|
|
Change-Id: I6fc331ae0706f4bb193543011c8d4ae0a385fcc0
|
|
Change-Id: Iee327c3dd75bebb35d99de01eaa7103956e08974
|
|
Change-Id: I6e0e6c1e4880a652ea4d8f0cccf9d8103c2cbbef
|
|
Change-Id: I1288f1f6f38d1475b4eb5272509e479bd9f2552d
|
|
Change-Id: Iaf118eca7a7b24945afbc1959ad78c712e4a299b
|
|
Change-Id: I2cacac2aa7e48b3b9d8d060137d5c6d6f1d06b3f
|
|
Change-Id: I7d108e7ae387f9c07cce182a0bb09b69a6608226
|
|
Change-Id: Ibebf394d69ed4845d91176727f291187ba35ed34
|
|
Change-Id: Ia94c417be95f5cd8c1d694a61c5004b0e8486416
|
|
The problem was that in case a shape had multiple (e.g. two) paragraphs,
and in case the first paragraph had an explicit character height, but
not the second, then the cursor carried over the explicit character
height to the second paragraph, but it shouldn't, as that leads to
incorrect character height in the second paragraph.
Fix this by remembering the default character height and using that in
case nothing is set explicitly.
Change-Id: I66e06d5cf192739fb254f7280c74617171d9ee6a
|
|
Change-Id: I475daf63c9548176f37449a26731cb176cf0ea3e
|
|
Change-Id: Ib0f6699e994f5a71603779b8227bf081b71a5dd6
|
|
Change-Id: Iab0165ef642dfee5bd315fc1f42f4bad8e86aa47
|
|
Change-Id: Iadc9f9ef444fe36d58304c2d6219021173385118
|
|
Change-Id: Ia453c7868e030e3f10a7f69c1e2d28244758fdef
|
|
Change-Id: Ibd5178f35d735e94065a3fbb6b61de53e53b1b0c
|
|
Change-Id: Ib7691a078c45f1eb8c78bd4e639503a732e3ef8c
|
|
Change-Id: I50c116a4d143b8ee20340f45c6624266371050ca
|
|
Change-Id: Iee3e292dd6c35f52c64d4a264a850def7ae15b0d
|
|
Change-Id: Iddb64e592ae47dd5f22430778b8018fc8c9880c5
|
|
Change-Id: I9257ec4d9ccb7c602a9537230b61be944371d3ad
|
|
There was a problem that in style.xml and document.xml in <w:ind> tag "right" & "left" margin
attributes gets added(w:right=0 & w:left=0),if these attributes are not set in original document.
(In this case LO should not write these attributes in <w:ind>)
eg. if original doc has implicit right and left indentation values set(In style.xml) and there is no
explicit values provided for some para (In document.xml) still it used to write w:right=0 and w:left=0
in <w:ind> tag of document.xml which overrides an entry from style.xml.
XML difference :
- Original file:
<w:ind w:left="567" />
- Roundtrip file Before Fix:
<w:ind w:left="567" w:right="0" w:hanging="0"/>
- Roundtrip file After Fix:
<w:ind w:left="567" w:hanging="0"/>
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7816
Change-Id: Ifa01bae24d48bb38d5e255356247c46a43beefcc
|
|
Change-Id: I449173ea1c4418cc2cc978862fe465e33e7b4338
|
|
Change-Id: I133012cf88020e38eb0fc0932979347b996943fe
|
|
Change-Id: I670eaa51aa95bf29f51bc6542eae2f562987d5a4
|
|
Change-Id: I7111d4064d033e27659c7b45650d596df22c593f
|
|
While copying slides to different slide decks,
styles were not being copied if there is already one
with the same name. This patch renames and copies those
to keep the formatting intact.
Change-Id: I66f71493f1fd658eed43e39aa7ae7ee7b5463b34
|
|
hashCode() seems to do sampling while creating the hash.
hashCode64() will not.
Change-Id: Id30f5a2a774cf5244dbc00da9649e95a532484be
|
|
Change-Id: Iaab33ab752a67e2acd374e0c08045c3e9da22ce7
|
|
in favour of ReadXXX methods.
Change-Id: Ic2c0a7b6b92ff4c236ae99b39d77f3d935b301e3
Reviewed-on: https://gerrit.libreoffice.org/7915
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Convert the template based read_lenPrefixed methods to regular
methods.
Change-Id: Ifd0e93aca055e55a0575e4377ec2b8e266dfb019
Reviewed-on: https://gerrit.libreoffice.org/7895
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
First, I updated the clang rewriter to do the conversion.
Then I lightly hand-tweaked the output for the few places where
the rewriter messed up, mostly when dealing with calls on "this".
Change-Id: I40a6a977959cd97415c678eafc8507de8aa3b1a9
Reviewed-on: https://gerrit.libreoffice.org/7879
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I22276dd551c4d1311a113ce6c38cc5eb97ed12ef
|
|
Change-Id: I8b8ea2d56d5aac9e5577e60b44b4d2eddf265dce
|
|
Change-Id: Iaaad9302ef8edb47fa95ce8ca608b6f36449521b
|
|
In Writer shapes had no cropping property so far. With this
commit this is introduced as a FillProperty and has the same
type as the cropping used for pictures
(Picture context menu > Picture > Crop).
Layout and UI will be an other step. On the UI it would be placed
on the Shape context menu -> Area, when Bitmap is selected as fill type.
Note: In case of picture/graphic, cropping property is imported from
and exported to a:srcRect instead of a:fillRect.
Change-Id: Idc1ed2d40cb20b6992e94f14e7e4d853e1f55d02
|
|
...and fix its XTypeProvider::getTypes
Change-Id: Ic36b17b14da21a29ca5530dd5e2ad03ee3da0782
|
|
Change-Id: I50521b0dab7325313ed5a3303f09a0692d76d19d
|
|
Change-Id: Ied87e18f8297fb8e85fdbcab38d719664e3ed066
|