| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Id96026910ffbdda72bfb7a4bf8653c63759e7c96
|
|
Change-Id: I90069f562c61359f9b226b147fe99807ecb3ad8a
|
|
Change-Id: Ie122a6befd94c836b6f08a7fe3ec8e4f2d67c690
|
|
Change-Id: I604244b032855e0e6b94e3ed4217ee87d92c8419
|
|
Change-Id: I3229ae20624c753d5e802d56251a628399a85817
|
|
Change-Id: I948d7c241f8024edb3bdced21d9d819571f02387
|
|
Change-Id: I6ba77dad167e2989e7151a8fa3c085c9133ed623
|
|
Change-Id: I5fae2ec81b50203e9d6100f8c938fb3643ff651f
|
|
Change-Id: I1625af99f9b13eaae7b74c65b6306bae6d063627
|
|
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
|
|
|
|
- see manifest)
|
|
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
|
|
Change-Id: I0cc47b152835d69e90226f42609eabe5291f55f3
|
