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

Change-Id: Ia0bee4a370e130a7e6fddd7cc984c31aa9a39a5d

Change-Id: I97c0f9154828c1d3ce801482242d951de8eab7e7

Change-Id: Ia4779dba9b8068d172d47ce2aff32219634a9616

Change-Id: I7b68754b1ac2fd3bd1ca8944deeded646a2e74d6

Change-Id: I64a73fb73b16ce265cd78d76c0325db051e55e26

Change-Id: I0d4f9b14f2a41a3acb08ba1b6c13fdf1174021e7

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

... with unknown encoding, mapping non-ASCII chars to something that
doesn't cause trouble (in FilterDetect::detect()).

Change-Id: Ibf2a2e2fd7c0c00e55042d2ccad173fab7a1b0bd

...because rtl_ImplGetFastUTF8UnicodeLen has already checked that.

Change-Id: I17f2b80f374073934a8f0b1a97099d4dec89ce4e

Keep the fast path fast, fall back to the text encoder in case there's a
fly in the ointment.

Change-Id: I94507856a7f3170f770adb741aa1e282d0d2400c

This reverts commit 05050cdb,
not all places that use e.g. OStringToOUString to convert potential UTF-8
are guaranteed to fulfil the prerequisites necessary to use fromUtf8 (and
some places like e.g. in codemaker are happy with the best-effort effect
of OStringToOUString's OSTRING_TO_OUSTRING_CVTFLAGS).