[Libreoffice-commits] core.git: vcl/source vcl/win
Armin Le Grand
alg at apache.org
Mon Jun 17 12:24:00 PDT 2013
vcl/source/gdi/outdev6.cxx | 10 ++++++++--
vcl/win/source/gdi/salgdi_gdiplus.cxx | 27 +++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 2 deletions(-)
New commits:
commit 8681545a76e71ceef95c8ec9cdb5d692fd1ce21e
Author: Armin Le Grand <alg at apache.org>
Date: Wed May 29 09:54:44 2013 +0000
Resolves: #i121591# Corrected some transparent printing stuff for windows
(cherry picked from commit d4b5b8bf22edc31f18232abd764edddb2ca19738)
Conflicts:
vcl/win/source/gdi/salgdi_gdiplus.cxx
Change-Id: I8191f945de10786982fcd1e94afc4f8adbe653bc
diff --git a/vcl/source/gdi/outdev6.cxx b/vcl/source/gdi/outdev6.cxx
index 6b4f90e..9d2e355 100644
--- a/vcl/source/gdi/outdev6.cxx
+++ b/vcl/source/gdi/outdev6.cxx
@@ -282,8 +282,14 @@ void OutputDevice::DrawTransparent( const PolyPolygon& rPolyPoly,
const double fTransparency = 0.01 * nTransparencePercent;
if( mbFillColor )
{
- // draw the transparent polygon
- // NOTE: filled polygons are assumed to be drawn as if they were always closed
+ // #i121591#
+ // CAUTION: Only non printing (pixel-renderer) VCL commands from OutputDevices
+ // should be used when printing. Normally this is avoided by the printer being
+ // non-AAed and thus e.g. on WIN GdiPlus calls are not used. It may be necessary
+ // to add (OUTDEV_PRINTER != meOutDevType) to the entering if statement, thus
+ // using the fallbacl some lines below (which is not very good, though). For
+ // now, WinSalGraphics::drawPolyPolygon will detect printer usage and correct
+ // the wrong mapping (see there for details)
bDrawn = mpGraphics->DrawPolyPolygon( aB2DPolyPolygon, fTransparency, this );
}
diff --git a/vcl/win/source/gdi/salgdi_gdiplus.cxx b/vcl/win/source/gdi/salgdi_gdiplus.cxx
index cc772e9..bbf8149 100644
--- a/vcl/win/source/gdi/salgdi_gdiplus.cxx
+++ b/vcl/win/source/gdi/salgdi_gdiplus.cxx
@@ -187,6 +187,33 @@ bool WinSalGraphics::drawPolyPolygon( const ::basegfx::B2DPolyPolygon& rPolyPoly
Gdiplus::DllExports::GdipSetSmoothingMode(pGraphics, Gdiplus::SmoothingModeNone);
}
+ if(mbPrinter)
+ {
+ // #i121591#
+ // Normally GdiPlus should not be used for printing at all since printers cannot
+ // print transparent filled polygon geometry and normally this does not happen
+ // since OutputDevice::RemoveTransparenciesFromMetaFile is used as preparation
+ // and no transparent parts should remain for printing. But this can be overriden
+ // by the user and thus happens. This call can only come (currently) from
+ // OutputDevice::DrawTransparent, see comments there with the same TaskID.
+ // If it is used, the mapping for the printer is wrong and needs to be corrected. I
+ // checked that there is *no* transformation set (testcode commented out below) and
+ // estimated that a stable factor dependent of the printer's DPI is used. Create
+ // and set a transformation here to correct this
+ const Gdiplus::REAL aDpiX(aGraphics.GetDpiX());
+ const Gdiplus::REAL aDpiY(aGraphics.GetDpiY());
+
+ // test code to check the current transformation at the graphics device
+ //Gdiplus::Matrix matrix;
+ //aGraphics.GetTransform(&matrix);
+ //Gdiplus::REAL elements[6];
+ //matrix.GetElements(elements);
+
+ Gdiplus::Matrix aPrinterTransform;
+ aPrinterTransform.Scale(Gdiplus::REAL(100.0) / aDpiX, Gdiplus::REAL(100.0) / aDpiY);
+ aGraphics.SetTransform(&aPrinterTransform);
+ }
+
Gdiplus::DllExports::GdipFillPath(pGraphics, pTestBrush, pPath);
Gdiplus::DllExports::GdipDeletePath(pPath);
More information about the Libreoffice-commits
mailing list