It causes problems if we handle those imported images differently which
are identified by a package URL, so after the first load remove
this URL and handle images on the same way as inserted images.

Some related bugs:
* #i44367#
* #i124946#
* #i114361#
* fdo#73270

The image in the test document has a special ID which is different
from that one which is generated by LO internally so after ODF export
the new generated image URL is different from the imported one.

Change-Id: I4e7d3490674c5f86bec5c7c6e1c975dcafd7c265

Change-Id: Iff0942b9b545f27dd74b73bee3f8ac785539867d

Change-Id: I26ae7aaab0e2d1685fd9c961aba027e1399b6911

Change-Id: I933aea4f9cb1ccd58f9a07e7d32ff28077f8bb33

This reverts commit 6661fdab.

Change-Id: Ib101d2605e5e739bb1d063fa7019e4e5930462a0

Why do we still use a double buffered FBC? It apparently works in the
feature/opengl-vcl branch.

Change-Id: I48b6879b9a9f7fec67f4da25cade46a32d8ad6fa

Change-Id: I0dda7886718b0e3ff81a0d6d43cca2887877ea9d

Change-Id: I65a0bef7e817c82285a0e053846798f02e8d7fc8

 are valid in HTML anchor names (missing: ':' and '.')

Change-Id: I44f1d1135067103fdcc7482793371c5b95c14cec
Reviewed-on: https://gerrit.libreoffice.org/12466Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: I3a534578df727f2aaab6e36839f0e62e6fc8f208

Change-Id: I6116b4c2b8e03e819a430cbdcb7874af6508fb62

Change-Id: I54d404d98cff433735ede23ddf4944a4149f559c

Change-Id: I3e5374145fb4a1bea1d1d900dc32380df4a408e9

Change-Id: I582edaf0e9c138822135c614f973ff205d751aa0

Change-Id: I999404544b1ed35a19096df58172e62bd1685e75

Change-Id: I7177521a9bf9c845216e2b6c91d20df93b137987

Change-Id: I8b3d1f7af217d36a9baf62df3e62f1361b8c57bb

Change-Id: I4b7829a1abe1459f2e4915159588fd3e16a14eea

Change-Id: I8006aaa4474f086ce5381f59afcf7a5f15279b55

Change-Id: I07a822a7c03a4746fd609ca6ea743b92253cf6de

Change-Id: Idd6c9f9752659fc5da575e5a3f0ffc15ce5dbe1c

Change-Id: Ie368fecd39189dc6ea72737b0c695c55a2d350a9

Change-Id: I5348977de17d3f916cecabe4b5c3f7630a89667e

Change-Id: Ifb29bd3e9c5dc7671c189fd9daa010305f7a85a4

Change-Id: I86d9f131ed48067984cee3fce13d48c82e7f4775

Change-Id: Icfbbae898749196e27199802ec728417d5205bc5

Change-Id: I55ea4ca2774433b204d2b0197e720ece4b0dadab

Change-Id: I4eec581ad83c8aceea8e853d2d19275f77029a68

Change-Id: I3e2738210b2fb598e15528e262f76a3ec140ab18

Change-Id: Icba402cecdc4997e95250544a887b9ed3399f197

Change-Id: I474006e128788336680e28c9f73d4a26e68541c6

Change-Id: Ifed65f41ab2375d702bf0c4299c65d1e3d78a7f0

Change-Id: I615ee0ec9aca3c30018fb45f91240471b88e96eb

pleasing cleanup of whacky ScRawToken::sbyteOffset, etc.

Change-Id: I5ad97f8dab7c5dc9d5f0286bf606b619126c22c9

Currently rtftok doesn't handle multibyte string as destination
text very well. For example, RTF files created by MSO 2010 Traditional
Chinese version use CP950 (aka BIG5) for unicode to ansi conversion.
When a Chinsese numbered list was picked, the Chinese dot ( unicode
0x3001, big5 0xa142 ), was used by default as a list number suffix.
However when it is imported , only a single B (0x42) were left.
The theory of the patch is to collect both hex string and normal
character with m_aHexBuffer, and convert it into OUString as late
as possible. It allows prefixes and suffixes to be imported from
RTF files created by MSO 2010 TC correctly.

Reviewed on:
	https://gerrit.libreoffice.org/12435

Conflicts:
	sw/qa/extras/rtfimport/rtfimport.cxx

Change-Id: I63062da39bf36ea27ec11e5d0eb1d1abf5018d96

Change-Id: I484331c4dd5feedf8587530912bb65556c1689c0

Change-Id: I839435338f4acf80c40896b6c86f7ef122f5449d

Change-Id: I7408be90f1ff552f4bb33e8a89d4b9075634e3e5

Change-Id: I4f5f0f653f2ce7782ec1d1fc5ef550a21a9c1d35