They are called only by themselves recuirsively,
but not from outside.

Change-Id: I1cde392c95bbc60ac7937d0bf3cd4b0fd062568b

Change-Id: I0e61aeb0705ed13872d252ee1594f9ab4aab4f8a

This thing seems a good optimization to me, but
it would be good to hide all of this swapping thing
inside GraphicObject class, to make our code more
robust (e.g. no image loss because of missing
manual swap in / swap out call).
Auto swapping mechanism will take care of that, anyway.

Change-Id: I933dafd95597ffff038dc6aeb0a64fcaa3941bd8

Tested with importing large *.rtf and *.docx test documents
with lots of images -> auto swapp out works.

Change-Id: Ib040edaa89c9bcb966c58b75f0392e6d9f7a165e

Change-Id: I2b6d6eaa072d9948eb5734e978d68d3bc37701b2

Change-Id: Ib295bd71b5cf16fd75d04818dfd415ff24cb2655

Painting via GraphicObject is obsolete.
See fdo#68927 where the problem was the quality of svg
graphics, it seems a good idea to extend this improvement
to all graphic type.

Change-Id: I57a26d4fcfea8e4f666504a90281365e8a9a7e1d

Change-Id: If09aa23768f73bbf659966e4e5aac82dca83d1b6

Change-Id: I7a8ad7814231f129d5d1146ceb36eb2c22b2aff1

Change-Id: I75f17ab5e55119965fcede2b220979cefc1e26ab

Change-Id: I09b8d11027f4a1e8470b81677388d4a573b372a6

Before an image data is used GraphicObject should be swapped in.
When a GraphicObject is swapped in auto swapping mechanism
is triggered which can swap out some of the images.
We should avoid to swap out the same image on which the swap
in method was called before because the caller code assumes that
the image data is there.

Change-Id: Ia4addc370742aea5fbf185cf87e3c062a5ebf5be

It's a Writer specific problem, that images lost during export
because of not swapped in graphic data.
Other components (Impress, Calc...) use SdrGrafObj to get the
graphic and SdrGrafObj calls swap in before retrun with the
graphic.

Change-Id: I7398d8e3f6535199b10de048acd58543bdb42531

Related to the bug fdo#52226.
The problem was that the images were somehow swapped out but
were not swapped in during export.
Test the main Calc formats: ODS, XLS, XLSX, HTML.

Conflicts:
	sc/qa/unit/subsequent_export-test.cxx

Change-Id: I4835ff2960fbd11cc9750ed3da20df26cd6cbaba

Related to the bug fdo#52226. The fix in *.rtf and *.docx
export was this commit:
9dd5caac
The problem was that the images were somehow swapped out but
were not swapped in during export.
Test the main Writer formats: ODT, RTF, DOC, DOCX.

Related to the bug fdo#52226.
The problem was that the images were somehow swapped out but
were not swapped in during export.
Test the main Impress formats: ODP, PPT, PPTX

Change-Id: I97ba98d0eb05ef2c1de3fbeaa527bc9f6f54d742

So we can be sure it is always called when user data changed.

Change-Id: If107907afffb85a7a57817f5807847a5c028416c

No reason to swapout the image directly after the import
because it will be used for rendering just a second later.

Change-Id: I78c8ef9225c55f306182dc5efd7bcaf0e88521c0

We have some good auto mechanisms for that.

Change-Id: I487dbf4a5fc69c7563dfbc5c21f9ebdb05ba6b9e

We have a good auto swapout mechanism which will
prevent excessive memory use.

Change-Id: I362f51c724ac31704561abe8b961910f5d490f04

When ImpGraphic::ImplSwapOut() is called with null
pointer it was assumed that it is becase the graphic is
a link and so we don't need to swap out it actually (we can
load it anytime using the link), only clear the graphic's
internal data.

The problem with that it can happen that ImplSwapOut()
is called with null pointer accidentally on a non-link
graphic object which leads to that we loose the graphic.
Seems more robust to use an explicit indicator
(GRFMGR_AUTOSWAPSTREAM_LINK) for links swapout.
indicator

Change-Id: Icf31524a192c7866278ba6a13eb85648aa69f554

Call it inside ImplAssignGraphicData() which assign
GraphicObject members using Graphic's data. With that
ImplAfterDataChange() method also called in constructors.

It's important to call ImplAfterDataChange(), because this
will trigger the auto swaping mechanism.

Change-Id: I45af91f8df2fb5b0143fcc5eb05e82e4d408d0bc

Change-Id: I5baac12f97ea7fa36293844331ca548b7bc2cdfd

Change-Id: I56d18dec48ccccab637ed3d818f4dd757c6f873b

Change-Id: I4639fb32c1dfc115bc33ce071fc3440138605362

Change-Id: I733fd4b998ba4d0bde2f91f2b3d76205f0dc8020

Change-Id: Ib5b5f653b027bfe5c05c0db417a2aa713309d9a5

Change-Id: Ib927d3e1b1349f9a1b5f575180d217fe31f1f11f
Reviewed-on: https://gerrit.libreoffice.org/12296Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>

Change-Id: I8dbe23bfec15fbc905407f64a3a87a5c75dbcd54

Change-Id: I1ea75499fa9db95f34d3fb438469559849541a53

Project: translations  7a93a556c365806ff1306e70f970feaf1bd7581f

As could be seen when running in dbgutil build or with environment
variable OOO_ENABLE_LOCALE_DATA_CHECKS=1

Change-Id: Iaf3b4cbe58acea9fa8aed0b1793e0ff28c089de6

Change-Id: Iaaabed4d0b507dafb7873da42869a856fc6ba573

Change-Id: I1b7aeb3d055baacbf67065f67991894a420897b7

Change-Id: I51ceee96f246006802879d94964ca161b63139fc

Change-Id: I8d10c0d2b24ec20795a504b4538b196cf1ce499a

and remove SV_NUMBERFORMATTER_VERSION_ADDITIONAL_I18N_FORMATS

Change-Id: I63f341e74a1eb7172dbb024a5cef66435a46e1df

Change-Id: I66fd200f1a504af22430e0471e1c98927101a9de

Change-Id: I63e8925e54c48cc35e09d9cd993520d6c85622eb

Change-Id: Ia6e9594654f89cadaedc19e7c3bddc1083cf9347