Change-Id: Ic42209c7a53c23d7b003778c2d2c88a8682569e4

Change-Id: Ib59fa91eb9d32ea437c182d3c0f3b9348816bf7b
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>

Michael Stahl <mst@openoffice.org> Mar 30 2011

    solaris11: #i117606#: solaris.mk: add -Bdirect -z defs to LDFLAGS

Change-Id: Iab16960010810185a3b1f7c617c44db3d9822fb5
Reviewed-on: https://gerrit.libreoffice.org/14579Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I65baf9e4583c78ca3128352112fdeeffce3b3225

Change-Id: I5bbddaebb6cf820afced89e634814f485ec38859

Change-Id: I37cbfbcc887ec82e750ba1bc614f4eda77be933b

Change-Id: Id1af6eb4064a524b12113b5b52b15f2ea4d6ada4

This reverts commit a785df6a plus follow-up
3594c9ce "presumably destroy flushes" and
b5b19508 "WaE: -Werror=unused-variable," as it
triggered the assert(nLen <= 8) in ColorMask::ImplCalcMaskShift
(include/vcl/salbtype.hxx) in various tests.

Change-Id: Ic5433522fcd9b8cc7c4e82704cebe7d9bbcea586

The build fails in harfbuzz, though, some ICU problem.

Change-Id: I5071a26b1cc0f6524f6b2af8740d915209727381

Change-Id: I1fb80f10098eee414514e95ddd069d772beadca1
Reviewed-on: https://gerrit.libreoffice.org/14651Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Remove outdated icons from themes, to make future maintenance easier.
Fixed file names and updated 'missing' log, 'copyright' text and 'links' for themes- where needed.
(Checked against current 'images.zip' bundled themes and git history).

Change-Id: If97378582377a64ed798eb44596ac56b89e3eb12
Signed-off-by: Andrew <dent.ace@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/14583Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: I236e8db4cf63fc284b1491591001357a0c662471

Change-Id: I20914ec147b2af096bd40ec0e4da7567a44abaaa

Change-Id: Ib4979a90134a71f6f26d20ea9430d2ae7f338dbc

Change-Id: Id71a46d19e67599af26d0e34303dc73517c4d17f
Reviewed-on: https://gerrit.libreoffice.org/14638Tested-by: Yousuf Philips <philipz85@hotmail.com>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I5d1244fa50974c63133d0ca98de11cba0d7fb902
Reviewed-on: https://gerrit.libreoffice.org/14639Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>

When formatting a 180k char Writer paragraph, most of the time is spent
in vcl::ScriptRun::next(), which is called twice per line from
SwTxtGuess::Guess(), once via GetTxtBreak() and once via GetTxtSize().

In the second call, from GetTxtSize(), the end position of the line is
known, and passed to vcl, and iterating beyond that position seems
pointless.

This reduces vcl::ScriptRun::next() from 24 to 11 billion callgrind
cycles when built with GCC 4.9.2 -m32 -Os.

Change-Id: Ia23fcccaf5ef9c9ecdcb54bfc8f0f8a043c8711e

TransliterationImpl::transliterate() has a slow-path for the case when
more than one trasliteration module is cascaded which swaps 2
uno::Sequence.  This is unbelievably slow because non-const
Sequence::operator[] does a function call into cppu to check whether COW
has to be done.

This speeds up transliterate() from 344 billion to 101 billion callgrind
cycles when built with GCC 4.9.2 -m32 -Os.

Commit d2771b63 added a second
transliteration module that is enabled by default, making the problem
visible, especially with long paragraphs in Writer.

Change-Id: I2799df9173ac73aab8c4eb4cc6f592976b06c8da

Change-Id: I84c7a4cde694395fa70c60edffd63fb45ffcb3a8

Change-Id: Ifcd5766ce10de44f38d5c383cd7dc35b75152e88

... it could not be verified"

I got some insight reading this question and reply on stackoverflow:
http://stackoverflow.com/questions/18761993/steps-to-include-timestamp-in-pdf-signature

I had been doing the timestamping wrong in the same way: I had timestamped the
hash of the PDF document, not of the signature. That is wrong. If you think
hard, it is obvious: It is the (rest of the) signature that needs an
authenticated timestamp, not the PDF document contents. After all, if the
document contents is timestamped, but not the signature, that doesn't prevent
tampering with the signature after the timestamping. When you timestamp the
signature, that proves the date of the signature. (And the signature proves
the authenticity of the document contents.)

So I had to re-engineer the code a bit. I create two originally identical NSS
CMS messages with signatures, encode one signature into DER, take the hash of
the signature, get a timestamp from the TSA for that hash. Then I add that
timestamp to the other CMS message as an unsigned attribute of its signature,
sign it, encode it, convert to hex, and store it the document.

(I first tried to use just one CMS message, but NSS stopped with an assertion
when I tried to encode the signature of the same message a second time, after
adding the timestamp attribute to the signature. Go figure.)

(I did verify the the encoded signatures, taken from what should be identical
but separate CMS messages, was in fact identical. So I am fairly sure the idea
described above is sound.)

But, it doesn't help. Adobe Reader still complains "The signature includes an
embedded timestamp but it could not be verified".

Change-Id: I4e4cd0443005e82f597586942badc7145ef64160

No change to functionality or end result. Preparation for an attempt to fix
the remaining problem with RFC3161 timestamped signature.

Change-Id: I5790a85399e9f94d816e8fab791a03d607113116

and assert is bollox as well

Change-Id: I966aa4efe1191f1a7957d3117d9c3ccabe041178

Change-Id: I249fe09319d6e0995d9ffdc7e4396b9b1787ad28

Change-Id: Ibf176df1e54138480030086abad0d045d27f19d1

That way the conversion from basebmp to cairo becomes unnecessary on blitting
the thing onto a cairo surface for gtk3 and opens a route to using cairo, e.g.
especially for text, to render to basebmp surfaces.

Change-Id: I1d11f503410af9c92a97018e9ee20045412b157e

Change-Id: I0f28b986542b4d30c0a2cb75e15fb258af98e9cd

Change-Id: I60e1951fe56e4b00ee0caa142eb0e19dcb6d12b7

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

Change-Id: I15b64f874f72715cea04f656e1b883c6cf45a86c
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>

where each unit is actually 32bit with unused upper 8bit.

Change-Id: I5c406cebe406d2db6fda73d744dfd22a99b80ba3

Change-Id: I9c3a6afea188d04c0d31d5685468b3d45a342840

Change-Id: I7af6b84da0ebfe9067690153665fb2470fdebcf4
Reviewed-on: https://gerrit.libreoffice.org/14607Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Change-Id: I6e0b093d99dba731ff5723d6575f887346463908
Reviewed-on: https://gerrit.libreoffice.org/14605Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Fast bitmap scaling overflowed the LUT used by the nearest-neighbor algorithm.
When a bitmap has 46k pixel on a side and is enlarged, the scaling code
overflows the 32-bit long, resulting in negative indexes, which then segfaults.

This isn't as rare as it sounds. At least in web-view in writer the border/shadow
bitmap is as long as the document (which is an issue in its own right,)
which can overflow for large documents during scaling and segfault.

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

At least in JunitTest_sw_unoapi it happens that this downcast is called from
~SwCharFmt -> ~SwFmt -> SwClient::ModifyNotification -> SwDepend::Modify ->
SwClient::ModifyNotification -> SwEndNodeInfo::Modify, i.e., the downcasted
object is in destruction and no longer an SwCharFmt but only an SwFmt.  Whether
or not that chain of calls is actually sane---casting down to merely an SwFmt
is a quickfix at least.

Change-Id: I33f0d76c42daa2530b8d417df059de57190c5070

Change-Id: I8eb0c9bda0883bc08aed3acd7eaa72480848c6f3

With this, ODF_text_reference_v3.odt does not report any broken services, but
the app still crashes anyway - tdf#89642.

Change-Id: If73835534184ffbac1c91b2c5bca33bded50c41f

.. in favour of just using the underlying constants from
css::util::NumberFormat

Change-Id: I0c6b128b66c91b268f5ae300f9c17c7792df5e99

Change-Id: I8484b985e46ad34fa45b02aa07130d3259336082