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

Change-Id: I795ce25011509de8f2aff488d4d46b86290ab3a3

Change-Id: Ic2391f4da06e26ee11a2463d2508b0dccdbf52bd

Change-Id: Icc3aad14d9d0c59c1c1c8f124f0626a9f947b93f

Change-Id: I352702ac50708a8f8c40e2752821178223052b7c

Also remove code from SwRangeRedline::dumpAsXml(), where that extra data
pointer seems to be ~always 0, so don't bother dumping it.

Change-Id: I4509b9366c1862248fcd3cc7ca6bb257ea7517f8

Change-Id: Ib6e23cbbcc7037dfdab53c4243091afbf819d445
Reviewed-on: https://gerrit.libreoffice.org/14613Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

with unit testing

Change-Id: I2a0e09f699c8489f61453b4144dd6181bd9b47fd
Reviewed-on: https://gerrit.libreoffice.org/14603Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: I2362c2c7a1c637b02eeebcae8ee1e3c0fc2b2422

Change-Id: Ie1c92ff5f65b019d3f1306917cd924036eea7909

Change-Id: I902fcb3fef7100279c34494e95cacfd3e5caf153

Change-Id: I5f2577dd1f047331a58d33e05684b673e6dbd11e

Change-Id: I4942a9ef4d3805865896c83cd9efa66437857ba1

Change-Id: I0e6c0900d28e7f01ebf88bcabc7dc6d5bbdb1b6a
Reviewed-on: https://gerrit.libreoffice.org/14594Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: I88f1d0a134ffa3fbb9a5b5abdabbd4774f457e81

bit/byte thinko I imagine

Change-Id: I85ef6de4a4e6cffcd9c593eb15da692a2617736e

so we could create bitmap devices that have the same stride that cairo expects,
provide getBitmapDeviceStrideForWidth to get a default value

Change-Id: I7ecc6f54a734b3f6bed59c699ac3b482c4ad7c47

doesn't appear to be equivalent, first continue now skips
second GetBound assign that original code would have done

This reverts commit b56614c6.

Change-Id: I113670064fd285795234ae9c9e09be0cc0697cd0

At least in CppunitTest_smoektest there is a case where
SystemWindow::setOptimalLayoutSize tries to downcast a VclGrid as a VclBox
(stack top below), and that even appears to be unnecessary as the only place
that requires the downcast is the Dialog::settingOptimalLayoutSize override.  So
maybe it is guaranteed that GetWindow(WINDOW_FIRSTCHILD) is a VclBox if this is
a Dialog, but need not be the case if this is not a Dialog?  Or the real bug is
elsewhere...

SystemWindow::setOptimalLayoutSize()
SystemWindow::DoInitialLayout()
FloatingWindow::StateChanged(StateChangedType)
SfxFloatingWindow::StateChanged(StateChangedType)
SmToolBoxWindow::StateChanged(StateChangedType)
vcl::Window::ImplCallInitShow()
vcl::Window::Show(bool, unsigned short)
SfxChildWindow::Show(unsigned short)
SfxWorkWindow::HidePopups_Impl(bool, bool, unsigned short)
SfxDispatcher::DoActivate_Impl(bool, SfxViewFrame*)
SfxViewFrame::DoActivate(bool, SfxViewFrame*)
SfxApplication::SetViewFrame_Impl(SfxViewFrame*)
SfxViewFrame::SetViewFrame(SfxViewFrame*)
SfxViewFrame::MakeActive_Impl(bool)
SfxBaseController::ConnectSfxFrame_Impl(SfxBaseController::ConnectSfxFrame)
SfxBaseController::attachFrame(com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&)
(anonymous namespace)::SfxFrameLoader_Impl::impl_createDocumentView(com::sun::star::uno::Reference<com::sun::star::frame::XModel2> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, comphelper::NamedValueCollection const&, rtl::OUString const&)
(anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&)
framework::LoadEnv::impl_loadContent()
framework::LoadEnv::startLoading()
framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&)
...

Change-Id: I786ad451fdf73eca22860695a614ee5b889a83cd

Change-Id: I45081f5f80c4a571af0abebd23a4fed6623498a0

Change-Id: I955d82d8dd7a6092feb1de03c7c6486125f30831

Note that checks in the code against exceeding that limit apparently are
broken, though. After the previous change I ended up with an invalid PDF where
the signature hex string in the output PDF had brutally overrun its
allocation.

Now Adobe Reader says "The signature includes an embedded timestamp but it
could not be verified". This is progress. Perhaps I just need to tell Adobe
Reader to trust the certificate from the TSA I used.

Change-Id: I1e8644ee641592a985e0190b52bf76839f99b3e7

I think Adobe Reader expects the timestamp info to include the TSA's
certificate.

Change-Id: Iedf1c4a9952b12ac61b4ba7f73bee339480e821d

It it scary to keep pointers to stack variables that have gone out of scope in
a data structure that is in an outer block and used there later.

Change-Id: Iced8b809d50089a4e6f9867be9b8501cce59d16f