Change-Id: I399d086181a9f513cd95157e815551f0be9b9e95

Change-Id: I2bd2782db41b58634627706b96238fcf8297547a

Change-Id: I0b370ac227bbd833078804d8a276b48666df734c

Change-Id: I9c9087bcd66d1383d08f49099f8d050cff5adb5b

Change-Id: Ie8667b1119cb60936a1a522086b1c99d0f4066b7

Change-Id: If17439ae83eb063a7ab054c3701e23dd48f1edd1

Change-Id: Iecee21acd140ce12ee34ac077b1450205cc28618

Change-Id: I8868e19a75376d5abf2d62eda1774c9bd2defa4c

Change-Id: I18868b542524f0e94ec7b06e753ee2385ede9a95

Change-Id: I5dfc43bdd4d8490a47c718dc49acba0ca5f7b526

Change-Id: Ib89d8f72fc7e874968c2d9481df80b53dc982f62

Change-Id: Ic27d7728025b3d666c0ebaf9ec4cd2006d0c89bf

Change-Id: I2d3120a173097208bd29eb52ab3dea3af870f6ae

Change-Id: I3ee442ab6dac31eb7daac32e7a9ed5c6526f07ba

The existing situtation of not having any explicit rules for header
files does not work because it requires a make restart after
the headers are generated in order for the headers to be delivered.

Because requiring running make twice to get a complete rebuild is bad,
add some rules to force the headers to be delivered immediately.

Change-Id: I5b4d5c8f8e9c9d7d0874fc797e62972eaa1dd904

except moving ScPostIt into source/filter/inc/xeescher.hxx

Change-Id: I85fbfe88e30edce5a48a65c494ced7b2129964ff

Change-Id: Ibb3918b95c2518fd83f566bb726273dbf90cf8c8

The docx spec doesn't say what is the default value, the rtf spec says
it's 720, not 1440.

Change-Id: Icb331591d4f2f96a7786f808d99af5974e645f8e

The Lanczos scaling is of very good quality, but it's rather slow,
which can be very noticeable with large images, so it's not a very
good default for everything. And in general, it's not good to refer
to a specific algorithm when all one usually wants is fast/default/best.

Some of these changes are a bit of a guess between default/best,
but the general logic is that best should be used only for images
that won't be large or where the possible waiting does not matter.

Change-Id: I53765507ecb7ed167890f6dd05e73fe53ffd0231

    Use ksc5601.h header from XFree86 Project Inc. Patch contributed by
    Oliver-Rainer Wittmann with minor changes from Pedro Giffuni
    http://svn.apache.org/viewvc?view=revision&revision=1179296

The used bilinear algorithm is apparently of a rather low quality,
use the new generic box algorithm instead. That makes it somewhat
slower, but the result is cached, and hopefully the speed difference
is not that significant.

Change-Id: I5a4dbe4851d467babc0d0fdcc3375b35441daf93

If the metafile contains just one single bitmap, the drawing code
optimizes by just using that one bitmap. It (=the resulting pixmap
after scaling etc.) however has not been cached so far, which means
smoothscaling (to be done) would be quite slow with every paint.

Change-Id: I30950c55fbadfddedc7df31283c66ed064b1a1a6

if( !number ) { ... ++number; } would never get beyond 1.

Change-Id: Iac33df3a21280c76fcdd130b699b4ab6466b1f46

The document from bnc#765998 contains a rather huge WMF with poor
quality. It could be smoothscaled to get a much better result,
but doing that would be too slow with an image of this size,
and it would be done every single time the image would need to be
painted, because the resulting image would not be cached.

One reason for this is that the WMF appears to be kinda broken (or let's
say imprecise [which is no wonder after trying to read things like
http://msdn.microsoft.com/en-us/library/dd162607(v=vs.85).aspx
and trying to understand what exactly rlcFrames is supposed to be]).

Change-Id: I017db36ec96f5405ff5965943003d5aa93018a37

Change-Id: Ie3c017eb9c6ceadd4b7982eb2a28c74bf6767631

According to docs http://msdn.microsoft.com/en-us/library/dd162589(v=vs.85),
cxDest/cyDest are "Logical width/height of the destination rectangle.",
so there should be no +1 as there would be if they were the top-bottom corner.

Change-Id: Iefa6db8e6131abe785b7878d97df1c891b73011c

It's rather lame that Rectangle from tools primarily specifies
the rectangle as topleft/bottomright, rather than topleft/size,
as that easily leads to confusion such as here.

Change-Id: Ice86fae90d9159b98e0896b6c875b99c3e1a3686

Change-Id: I8702f8e4b76731ab167533478ba754c94114f419

Change-Id: I284bc45abab57127ea972ed4d4b8164b54bfa18b

Change-Id: I5f0e7aefdea80bbb9cf61b991c5b706bd2023dfa