Change-Id: Ibc6e54bf7f907ae1c500be5c67995419c91aa089

+ OSL_ENSURE to check row-level buffering of the horizontal
cell ranges with the same cell attributes

Change-Id: If265e1c5a389d4c63bfda4017173d8fe41badb6b

Change-Id: Ib2b58b5d39f946463eaecdc51f10f11cbc35aa1f

Change-Id: I752a4bc01425c09e2bd3cc8cac96f3cf22f1222d

Change-Id: I3a6e668b930cb5f65abe345fdf5b5e4b1b511440

...similarly to 0fdbb5b0 "Make
cpp_uno/gcc3_linux_x86-64 bridge work with GCC 4.7"

Change-Id: Idcafcb07678d02446172d7fde30631a342f6437e

Change-Id: I0cf3b4446cdd60162aa979c7e223d37d9f508014

Change-Id: I096e1eb534562e4428b66b7b73ab2900e0c09a55

Change-Id: I680ed37995b12abf54526b9205b131a62b5cf734

Change-Id: If40d1ccdec77c1bf0753411da71ac5c0b42c2765

Use libcurl to perform the request and get the response. Improve error
messages (only use SAL_WARN, though, so sadly not visible to end-users).

Still to do: Decode the response and attach it to the signature. Implement
request encoding and response decoding for Windows.

I probably should extend (and rename) the HashContextScope class to handle all
resources that need explicit deallocation, instead of calling
curl_slist_free_all(), curl_easy_cleanup() and SECITEM_FreeItem() in so many
places.

The error handling of the PDF export functionality would need to be
re-designed so that we could show actual error messages to the user instead of
generic "signing failed" ones. But that is typical for much of our code...

Change-Id: I6288de3f09021f8e0f385870143fefffbac2a706

Change-Id: Ia5687bf2d68eef06aeb618d5387c663807d24560

Use the digestAlg in the NSSCMSSignerInfo, once we have it, as
hashAlgorithm. Use a random number as nonce.

Temporarily, dump the TimeStampReq object to a file for inspection in a
DBG_UTIL build.

Change-Id: I696271b3ccc6cef86a70bc78f86d6eae27a4af77

Change-Id: I1829d5efb4b3a0a80f0f0124dcb3de1ebeca5fc5
Reviewed-on: https://gerrit.libreoffice.org/14550Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Idb8e8ab8f73248021b9aa13efa04e77d9e331475
Reviewed-on: https://gerrit.libreoffice.org/14530Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ibe226daf26086eb9878a6da5b8ec2d8d2fc9e141
Reviewed-on: https://gerrit.libreoffice.org/14551Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I6da03869dea172fb8d50396010152479afec9cde
Reviewed-on: https://gerrit.libreoffice.org/14554Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I40ea3b781ec35171706a277acff6eb2eab29c297

...the implementation in ChartView.cxx oddly got removed from
<https://gerrit.libreoffice.org/#/c/14431/1> to
<https://gerrit.libreoffice.org/#/c/14431/2>, but the declaration in
chartcore.component was missing from the start

Change-Id: I71699ee74278f7e419eca63c5784b46efc42d96b

Change-Id: Id91be8ec8a97d8fad398d798cd2a9b77773a39e2

Change-Id: If6e0cbf8544ca7a4668cdc67fcf390d8835b7017

Change-Id: Icae6b6f07ad8dbd287fdfc689739187883a07775

This is workaround patch.

ToolBox::ImplFormat() method places it to the new position, when the new
item is added.
ToolBox::ImplFormat() method determines whether or not the item is newly
added, using that the new item's Top Coordinate is 0.
However, it seems that the non-new item's Top Coordinate is 0 on Windows 7
with default(aero) theme, using small icons.
We also need to consider in this case.

Change-Id: I35cf81502799432f63e0920219fcbaac9050d81f
Reviewed-on: https://gerrit.libreoffice.org/14538Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

The document in tdf#77122 shows that frames can exist without a
name. Going to frame properties showed "Frame1" as the name for each
frame, and pressing OK didn't "set" this suggested name - the name
remained blank.

An alternative fix is removing "pNameED->SaveValue();".  However,
this approach seems safer.

Change-Id: I1ed9d67442d55f2c481e6e4b35a876721a835522
Reviewed-on: https://gerrit.libreoffice.org/14548Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

FnChgOrdinalNumber should return true if it changes the ordinal number.
This seems to be accentually removed when the function was
internationalized and has always returned false since.

Change-Id: I633058a99ec033e0c33f807776364a52e22e9c64
Reviewed-on: https://gerrit.libreoffice.org/14535Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

if transform is put into an inner tspan element rotated text isn't rendered rotated

Change-Id: I6fcab1db0e213c65fe8ba88a7694fd10c902bfec
Reviewed-on: https://gerrit.libreoffice.org/14314Reviewed-by: Katarina Behrens <bubli@bubli.org>
Tested-by: Katarina Behrens <bubli@bubli.org>

Change-Id: Ia8c237009634eb0c750db42da4f68a31d40c5368

Change-Id: I76e7f2b29c6583c32a3c2b49f3365688f8f81bce

Change-Id: I94271681ea4ec7617eaf706fb443ebb9d1b0bc15

Change-Id: I91311e2017a93dbfbffb20b9ba4595c62ce8165b
Signed-off-by: Timothy Pearson <kb9vqf@pearsoncomputing.net>
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: Iacb18a06057b6becd077a49a71a95fb7e0961f3f

Change-Id: I6a327df821ea439e6dcffe26eeee022c3e3583e8

Change-Id: I8b58ae33ad71d0df6ea30f205b4f331541f5b821

e.g. fdo#66455-1.ods exported to OOXML

Change-Id: I81c65071cef820076b3f4788b45152cb48eb608d

Change-Id: Ic35f1188e66cf89f203b34f354a2c4b11f1f65a2

Change-Id: Iefb52f6fa77cf90955dbb47c1b9ca7ab699a43eb

Change-Id: I943be2cf660d2dc77eebd776208af96c0b5f67a4

We implement in many places wrong default values based on how MSO 2007
behaves. Newer MSO versions produce correct files so our import is
wrong. Instead of changing the default value we need to be able to use
default values based on the document producer.

Change-Id: I6a2a0b30885ebccc384d17f896709ecdd475d786

Change-Id: I8cdfe1cddf57a36054bfe850173ef6130aa608b5