Age | Commit message (Collapse) | Author | Files | Lines |
|
"grfmgr" uses its own scaling functions instead of the scaling
functions available on Bitmap object. The step to use the Bitmap::Scale
for most scenarios was already made, now the "grfmgr" functions are
not used anymore.
In addition this commit fixes croping the bitmap with large zoom
levels.
(cherry picked from commit 764525b39c78bfad1f6fc44a8517a565547f67cf)
Conflicts:
svtools/source/graphic/grfmgr2.cxx
Change-Id: Ib27029d2cdf4684146befc131e3c72656dfa407c
|
|
regression from f6a34255af1339cd7132b7527dc0c10c10d38249
Change-Id: Iabfaf92629cd4d53ab7af5f3e3013eb81bb8104d
(cherry picked from commit 2536fae7b8565b5dd9f09bb3dc015576fafe4031)
Signed-off-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I042d6de9533f0f33e1fb64c3b92dc1bafaa6149f
|
|
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.
Conflicts:
svtools/source/graphic/grfmgr2.cxx
Change-Id: I30950c55fbadfddedc7df31283c66ed064b1a1a6
|
|
if( !number ) { ... ++number; } would never get beyond 1.
Change-Id: Iac33df3a21280c76fcdd130b699b4ab6466b1f46
|
|
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
|
|
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: I1563dc2afc49c7b1115192db00fbd08a7524154e
|
|
This reverts commit 99cad9fd7f413adecffc527d334eff616799cc4b.
|
|
Arguably such annoyingly thin double borders don't make much sense
anyway, because they're essentially 2 hairlines with ~no space between,
but unfortunately older LO versions are able to create them;
since the refactoring in 2d045cdb69176b280812dda0b813371cf1ac72e2,
which changed the BorderWidthImpl::Get* methods to return 0 due to
rounding, they were ignored at least in the HTML import, which is a
regression.
So add a special purpose hack that essentially rounds up the first line
to 1 but not the other lines so the visual result is a hairline single
border.
Change-Id: I20ac4675bcf67ea58a6931a40bff3605390e9c0d
(cherry picked from commit 601bfe2ce3113719b2f8edaba2ccb6b630051a9a)
Reviewed-on: https://gerrit.libreoffice.org/451
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
|
|
Change-Id: Ibf6bdf48e5855583f14cd2be36f1e4896a396d32
Signed-off-by: Michael Stahl <mstahl@redhat.com>
|
|
Writer sets this flag dynamically via Ruler::SetStyle depending on
the text direction, the flag is set by default and gets unset for the
vertical ruler, because the initial text direction is horizontal,
see SwView::StateTabWin.
Ruler::SetStyle calls Ruler::ImplInitExtraField, which modifies mnVirOff,
however mnVirWidth depends on mnVirOff, but gets updated only in Resize.
This patch copies the code from Resize to ImplInitExtraField, we cannot
just call Resize from ImplInitExtraField due to possible infinite recursion.
Change-Id: Ic7bb897059295aebe86c11977c37419017b55787
Signed-off-by: Petr Mladek <pmladek@suse.cz>
|
|
Change-Id: I2ee41160e5cb10694ccdb5a1cdaf7d4abfeb23bb
Signed-off-by: Andras Timar <atimar@suse.com>
|
|
Change-Id: I352c6041cc520dc76c302190dcf3a6945f5ac85f
Signed-off-by: Petr Mladek <pmladek@suse.cz>
|
|
Change-Id: I4f632545d383c4887342aa2959987d4ac3638eb4
Signed-off-by: Petr Mladek <pmladek@suse.cz>
|
|
Change-Id: I3ac2e8e3219c12be84ce38cb98342f0dce0d6476
|
|
Change-Id: Ib374998199afff347786764716646e73dd12de2a
(cherry picked from commit 3c6bc3cb6a673c552e2839e421656341151bf12e)
|
|
Word uses a completely different definition of "width" of a double border
than OOo and ODF: for Word the width is apparently the largest of the 3
component widths, while OOo and ODF define the width as the total with of
all 3 components. The new border implementation in LO 3.4 was apparently
inspired by Word's double border definition, which resulted in
various import filter regressions, see the previous fixes:
36e43b52992735c622833e923faa63774b9e2f76
e2ffb71305c5f085eec6d396651c76d6daee3406
70a6a4d425558340bb49507975343a3e0a1bdde8
These fixes set the ScaleMetrics, which actually seems sub-optimal as
there is a ScaleItemSet function somewhere that apparently re-scales
all items in an itemset, which could undo the fixes.
Also, one of the fixes actually managed to break RTF/DOCX import
of double borders, as that ended up in the same code via the API.
This commit now reverses the change, so that the width of a border is
now always the total with of all components, which is (imho) much more
intutitive, and also leads to a consistent UI where selecting say 3pt
width has predictable results, no matter what the border style.
The border widths are now converted in the Word format import/export
filters (writerfilter and sw/source/filter/ww8), and various tests
were adapted to the new handling.
(cherry picked from commit 2d045cdb69176b280812dda0b813371cf1ac72e2)
Conflicts:
sw/qa/extras/ooxmltok/ooxmltok.cxx
Change-Id: I50456c49b1a298569607e6c88f19f18441348ac3
|
|
Change-Id: I83942f6408b32b68631dde5d260fa8c8e01bdbfd
|
|
Change-Id: Ie764adf7a602e9335e6da1de94d6f737feea6364
|
|
Change-Id: If58683331c50f2a95204e8e2dea11edbef3ccb63
|
|
Change-Id: I9dbf5d510ebaff8448a152d75a006a183303bd81
(cherry picked from commit 5ae11320a26a6356dfadeb812e0d6baf5bdc951c)
Signed-off-by: Caolán McNamara <caolanm@redhat.com>
|
|
so menus have consistent whitespace at left regardless of containing
checkboxes/radiobutton entries. Its nasty to have menus "suddenly"
appear without whitespace as submenus of ones with whitespace.
This is a logical consequence of MENU_FLAG_SHOWCHECKIMAGES always
set (in the absence of SetMenuFlags where usage has generally
dropped MENU_FLAG_SHOWCHECKIMAGES accidentally)
Change-Id: I9501381b91415131eff5143a0c88142221530fb6
|
|
Update calls to factories to use new ::create methods
Change-Id: I01d4417820f52718836c92faf3c2fae0dc96b30d
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, added some tweaks.
|
|
Change-Id: I2c49b95279d90ebb06f38ed83061a5f1a905a555
|
|
Change-Id: Ifa58823b593a545c66ef78ebe13e576127e60dc9
|
|
Change-Id: I8a71851c0c602c17a4088fb969afa07808f5fe20
|
|
Change-Id: I7e1ae9622bc89b584ddbb307dac15b0ed56ae563
|
|
Change-Id: I2ec1bc3fd5dd5d38c2b3b9600265943083873515
|
|
Change-Id: Ib074b6a4ac6c2fe89edf0a0e4b2faf2d8a8eae68
|
|
Change-Id: I199276a99063d5a125be1f2cd5d71574f078a82e
|
|
Change-Id: Iac8049c49520a5fd119c4617144af302f924475b
|
|
Change-Id: I8848d0e687c3b19be1a8bc1f41c2a0c94e13bbbf
|
|
Change-Id: Iad21ad040e797690a80f94e2eec8e38b8bffadb2
|
|
Change-Id: Ic354fc145c75eb24aa010627467fae007cfbf024
|
|
Change-Id: Ib37f1fc9658cb50227463cf2aa1421ba47b2ec9f
|
|
Change-Id: I51b86a10caa5da6e12583c2b22404b0d9282b13d
|
|
Change-Id: Ic30cdeffabec1eb1a6c153ac450a3d28064ef534
|
|
Change-Id: Ia7c1da0eedc5d64ef3f2b17fb999bec3b242af88
|
|
Change-Id: I7c3409ac39e690fcf2f7e4085bf6857e6bd182fb
|
|
Change-Id: Icd566610229fe080bb45b746459abed15112c225
|
|
Change-Id: I173275e0f8faa852500d108f65636080f79636c6
|
|
Change-Id: I962aeac0c7feeabb7963016d5afcfeca5a48ccfe
|
|
...where the OSL_FAIL line numbers did not point at the relevant code.
Change-Id: I4d12d63782378cbbc446cdcd77c07676ffc81d78
|
|
Change-Id: I3aab81682310cbf1da8af6dc0a5d71eb8e3140e4
|
|
Change-Id: I3ac70ea343edde406e78845a112aabcbd8ff65b1
|
|
Change-Id: I75c88b83903c7510291b9d021fd4837b2c8d5e4c
|
|
Change-Id: I3854a9958f49dbbabe7a604e4604d5d8f79adc11
|