summaryrefslogtreecommitdiff
path: root/cppcanvas
diff options
context:
space:
mode:
Diffstat (limited to 'cppcanvas')
-rw-r--r--cppcanvas/source/mtfrenderer/emfplus.cxx37
1 files changed, 33 insertions, 4 deletions
diff --git a/cppcanvas/source/mtfrenderer/emfplus.cxx b/cppcanvas/source/mtfrenderer/emfplus.cxx
index 7389e2336ffa..011a204a1b33 100644
--- a/cppcanvas/source/mtfrenderer/emfplus.cxx
+++ b/cppcanvas/source/mtfrenderer/emfplus.cxx
@@ -72,6 +72,7 @@
#define EmfPlusRecordTypeResetWorldTransform 16427
#define EmfPlusRecordTypeMultiplyWorldTransform 16428
#define EmfPlusRecordTypeSetPageTransform 16432
+#define EmfPlusRecordTypeSetClipRect 16434
#define EmfPlusRecordTypeSetClipPath 16435
#define EmfPlusRecordTypeSetClipRegion 16436
#define EmfPlusRecordTypeDrawDriverString 16438
@@ -1701,27 +1702,55 @@ namespace cppcanvas
aWorldTransform.eDx, aWorldTransform.eDy));
break;
}
+ case EmfPlusRecordTypeSetClipRect:
+ {
+ int combineMode = (flags >> 8) & 0xf;
+
+ EMFP_DEBUG (printf ("EMF+ SetClipRect combine mode: %d\n", combineMode));
+ EMFP_DEBUG (if ( combineMode > 1 ) printf ("EMF+ TODO combine mode > 1\n"));
+
+ float dx, dy, dw, dh;
+
+ ReadRectangle (rMF, dx, dy, dw, dh, false);
+
+ EMFP_DEBUG (printf ("EMF+ RectData: %f,%f %fx%f\n", dx, dy, dw, dh));
+
+ B2DPoint mappedPoint (Map (dx, dy));
+ B2DSize mappedSize( MapSize (dw, dh));
+
+ ::basegfx::B2DPolyPolygon polyPolygon( ::basegfx::B2DPolygon( ::basegfx::tools::createPolygonFromRect( ::basegfx::B2DRectangle( mappedPoint.getX(), mappedPoint.getY(),
+ mappedPoint.getX() + mappedSize.getX(),
+ mappedPoint.getY() + mappedSize.getY() ) ) ) );
+
+ updateClipping (polyPolygon, rFactoryParms, combineMode == 1);
+
+ break;
+ }
case EmfPlusRecordTypeSetClipPath:
{
- EMFP_DEBUG (printf ("EMF+ SetClipPath\n"));
+ int combineMode = (flags >> 8) & 0xf;
+
+ EMFP_DEBUG (printf ("EMF+ SetClipPath combine mode: %d\n", combineMode));
EMFP_DEBUG (printf ("EMF+\tpath in slot: %d\n", flags & 0xff));
EMFPPath& path = *(EMFPPath*) aObjects [flags & 0xff];
::basegfx::B2DPolyPolygon& clipPoly (path.GetPolygon (*this));
clipPoly.transform (rState.mapModeTransform);
- updateClipping (clipPoly, rFactoryParms, false);
+ updateClipping (clipPoly, rFactoryParms, combineMode == 1);
break;
}
case EmfPlusRecordTypeSetClipRegion: {
+ int combineMode = (flags >> 8) & 0xf;
+
EMFP_DEBUG (printf ("EMF+ SetClipRegion\n"));
- EMFP_DEBUG (printf ("EMF+\tregion in slot: %d combine mode: %d\n", flags & 0xff, (flags & 0xff00) >> 8));
+ EMFP_DEBUG (printf ("EMF+\tregion in slot: %d combine mode: %d\n", flags & 0xff, combineMode));
EMFPRegion *region = (EMFPRegion*)aObjects [flags & 0xff];
// reset clip
if (region && region->parts == 0 && region->initialState == EmfPlusRegionInitialStateInfinite) {
- updateClipping (::basegfx::B2DPolyPolygon (), rFactoryParms, false);
+ updateClipping (::basegfx::B2DPolyPolygon (), rFactoryParms, combineMode == 1);
} else {
EMFP_DEBUG (printf ("EMF+\tTODO\n"));
}
d-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2017-12-14No need to keep these whitelisted functions decorated with SAL_CALLStephan Bergmann The only effect SAL_CALL effectively has on LO-internal code is to change non- static member functions from __thiscall to __cdecl in MSVC (where all other functions are __cdecl by default, anyway). (For 3rd-party code, it could be argued that SAL_CALL is useful on function declarations in the URE stable interface other than non-static member functions, too, in case 3rd-party code uses a compiler switch to change the default calling convention to something other than __cdecl. But loplugin:salcall exempts the URE stable interface, anyway.) One could argue that SAL_CALL, even if today it effectively only affects non- static member functions in MSVC, could be extended in the future to affect more functions on more platforms. However, the current code would already not support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c "loplugin:salcall fix functions" changed FrameControl_createInstance in UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even though its address (in ctl_component_getFacrory, in the same file) is passed to cppuhelper::createSingleFactory as an argument of type cppu::ComponentInstantiation, which is a pointer to SAL_CALL function. Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6 Reviewed-on: https://gerrit.libreoffice.org/46436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2017-12-11loplugin:salcall fix functionsNoel Grandin since cdecl is the default calling convention on Windows for such functions, the annotation is redundant. Change-Id: I1a85fa27e5ac65ce0e04a19bde74c90800ffaa2d Reviewed-on: https://gerrit.libreoffice.org/46164 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2017-01-26Remove dynamic exception specificationsStephan Bergmann ...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>